As 10 melhores ferramentas de monitorização RAID para servidores domésticos

Um array RAID pode parecer saudável enquanto um dos seus discos se deteriora silenciosamente. Também pode ficar degradado enquanto os discos restantes continuam a indicar SMART PASSED.

Por isso, uma boa monitorização precisa de mais do que uma única luz verde de estado. A melhor configuração para um servidor doméstico monitoriza o array, os discos físicos, as reconstruções ou scrubs e os alertas que indicam que algo mudou.

A monitorização de RAID é mais do que SMART

A integridade do RAID e a integridade dos discos respondem a perguntas diferentes.

Um monitor de arrays indica se o sistema de armazenamento ainda tem os membros esperados, se a redundância foi perdida e se está em curso uma reconstrução, ressincronização, scrub ou operação de consistência.

A monitorização SMART analisa o array subjacente, observando discos HDD, SSD e NVMe individuais. Pode revelar a temperatura, erros de suporte, sectores pendentes, sectores realocados, resistência, resultados de autotestes e outros sinais ao nível do dispositivo.

Monitorização de RAID
     |
     +-- Estado do array
     |     Saudável / Degradado / Offline
     |
     +-- Estado da unidade
     |     SMART / NVMe / Temperatura
     |
     +-- Recuperação
     |     Reconstrução / Ressincronização / Scrub
     |
     +-- Histórico
     |     Tendências / Erros / Capacidade
     |
     +-- Alertas
           E-mail / Push / Webhook / Chat

Esta distinção é importante porque um array saudável pode conter um disco em deterioração, enquanto um array degradado pode ainda conter vários discos individuais cujo estado SMART permanece normal.

O modelo de RAID subjacente é explicado com mais detalhe em como funciona o RAID, mas a monitorização começa com uma regra mais simples: monitorize tanto o array como os discos que lhe estão subjacentes.

O que deve realmente monitorizar uma ferramenta de monitorização de RAID?

Um monitor útil para um servidor doméstico deve abranger o maior número possível destas camadas, conforme o papel que desempenha:

Como classificámos as melhores ferramentas de monitorização de RAID

Isto não é uma classificação dos painéis mais bonitos. As ferramentas abaixo resolvem diferentes partes da stack de monitorização.

Avaliámo-los com base em cinco questões práticas:

• O que pode realmente observar? O estado do array, discos individuais, pools ZFS, RAID por hardware ou o servidor inteiro?
• Preserva o histórico? Um contador de erros que aumenta lentamente é frequentemente mais útil do que um único valor atual.
• Pode emitir alertas sem verificação manual? A monitorização deve revelar os problemas de forma proativa.
• Quão difícil é a implementação? Um único NAS doméstico não deverá exigir uma infraestrutura de observabilidade empresarial, a menos que o utilizador assim o pretenda.
• Complementa as ferramentas RAID nativas? As configurações mais robustas combinam normalmente um monitor específico do conjunto com uma camada de estado dos discos.

A ordem numérica é editorial e não corresponde a uma pontuação de referência sintética.

As 10 melhores ferramentas de monitorização de RAID para servidores domésticos, num relance

1. Netdata — Melhor painel geral de monitorização de RAID

O Netdata é a melhor escolha geral quando pretende uma única camada de monitorização para o sistema de armazenamento e para o resto do servidor doméstico.

Os atuais coletores de armazenamento abrangem várias arquiteturas relevantes para utilizadores de RAID.

Para RAID de software no Linux, o coletor de RAID MD lê /proc/mdstat e acompanha os dispositivos MD. Para discos físicos, o Netdata dispõe de um coletor SMART baseado no smartctl. O seu coletor de pools ZFS monitoriza o estado e o espaço dos pools através do zpool, enquanto o seu coletor StoreCLI RAID pode monitorizar adaptadores RAID de hardware compatíveis, discos físicos e baterias de reserva.

Esta abrangência dá ao Netdata uma vantagem sobre os painéis SMART de âmbito restrito.

RAID MD
SMART
ZFS
RAID de hardware
Sistemas de ficheiros
CPU
RAM
Rede
Contentores
     |
  Netdata
     |
Um painel

Um único agente Netdata pode ser executado de forma independente e expor o seu painel local na porta 19999. A conectividade à nuvem é opcional para o próprio agente de monitorização, embora o Netdata Cloud acrescente vistas centralizadas e funcionalidades adicionais para vários nós.

Isto torna o Netdata particularmente útil num servidor doméstico onde a monitorização do armazenamento deve coexistir com a carga do sistema, a pressão sobre a RAM, a capacidade do sistema de ficheiros, a atividade do Docker e o desempenho da rede.

Ideal para: utilizadores que querem um único painel a abranger o RAID e o resto do servidor.

Compromisso: o Netdata é abrangente, em vez de se focar obsessivamente nos discos. O Scrutiny proporciona uma vista mais simples quando o objetivo é estudar os atributos SMART e a deterioração das unidades físicas a longo prazo.

2. Scrutiny — O melhor para detetar tendências no estado das unidades

O Scrutiny é uma das adições mais úteis para um NAS doméstico, porque resolve várias limitações da monitorização SMART bruta.

O SMART expõe um grande número de atributos, mas nem todos são igualmente úteis. Os limiares definidos pelo fabricante também podem ser suficientemente conservadores para que uma unidade pareça “saudável” até a falha estar relativamente próxima.

O Scrutiny combina dados SMART com uma interface Web, armazenamento de tendências históricas, monitorização da temperatura e limiares adicionais baseados em dados reais de falhas de unidades.

Isto permite colocar questões como:

Setores atualmente pendentes

Janeiro       0
Março         0
Junho          2
Agosto        8

Um único relatório SMART atual indica que o valor é oito. O Scrutiny mostra que a métrica tem evoluído na direção errada.

Também suporta notificações configuráveis por e-mail, webhooks, ntfy, Gotify, Slack, Discord, Telegram e outros serviços.

O suporte para controladores RAID depende de ser possível smartctl consegue aceder às unidades físicas subjacentes. Por esse motivo, o Scrutiny documenta o passthrough do controlador e o mapeamento de dispositivos do Docker.

A limitação importante é igualmente clara:

O Scrutiny monitoriza as unidades, não a própria matriz RAID.

Uma matriz Linux MD deve continuar a ser monitorizada com o mdadm ou outra camada com conhecimento da matriz. Um pool ZFS deve continuar a ter monitorização específica do ZFS.

Ideal para: servidores domésticos com vários HDD ou SSD, onde são importantes as tendências históricas do SMART e da temperatura.

Compromisso: não confunda uma fila de discos saudáveis no Scrutiny com uma prova de que a matriz RAID está saudável.

A camada de monitorização do estado das unidades também depende das próprias unidades. Escolher unidades NAS adequadas reduz problemas evitáveis durante reconstruções e cargas de trabalho contínuas 24/7.

3. smartmontools — A melhor base para monitorizar HDD, SSD e NVMe

o smartmontools é muito menos apelativo visualmente do que o Scrutiny, mas é mais fundamental.

O projeto disponibiliza duas ferramentas principais:

smartctl
   |
Inspecionar e testar uma unidade

smartd
   |
Monitorizar continuamente as unidades

smartctl pode inspecionar informações SMART e de integridade de dispositivos ATA/SATA, SCSI/SAS e NVMe e iniciar autotestes das unidades. smartd é executado como um daemon e verifica continuamente os dispositivos quanto às condições de integridade configuradas.

Muitos produtos de monitorização de nível superior dependem, em última análise, destes dados. O coletor SMART do Netdata requer o smartmontools, o Scrutiny constrói a sua camada de integridade dos discos em torno dos dados do smartctl e os exportadores smartctl do Prometheus utilizam a mesma interface.

O projeto continua também a evoluir. O changelog atual do upstream indica o smartmontools 8.0 como a próxima versão, ainda não lançada, depois da 7.5.

Para um servidor doméstico leve, o smartd pode ser tudo o que é necessário:

Unidade
  |
SMART
  |
smartd
  |
Alerta

Não precisa necessariamente de uma base de dados, um painel e uma stack de métricas separados para saber que uma unidade ultrapassou um limiar importante.

Ideal para: utilizadores que pretendem uma base leve e madura para a saúde das unidades físicas e testes automatizados.

Compromisso: a saída da linha de comandos é menos acessível do que a do Scrutiny ou Cockpit, e o smartd, por si só, não fornece o mesmo tipo de análise visual histórica.

4. Monitor mdadm — Melhor monitor nativo para RAID por software do Linux

Se a matriz for Linux MD RAID, o mdadm deve continuar a fazer parte do plano de monitorização, mesmo que o Netdata ou outro painel esteja instalado.

mdadm --monitor compreende a própria matriz.

Pode comunicar eventos como:

• falha do dispositivo;
• matrizes degradadas;
• ativação da unidade sobresselente;
• desaparecimento do dispositivo;
• início da reconstrução;
• progresso da reconstrução;
• conclusão da reconstrução.

Isso preenche a lacuna deixada pelo SMART:

smartd
  |
As unidades estão saudáveis?

mdadm --monitor
  |
A matriz RAID está saudável?

Num servidor doméstico Linux minimalista, combinar a monitorização do mdadm com o smartd cria um sistema de monitorização surpreendentemente capaz, sem adicionar uma grande stack Web.

Ideal para: Debian, Ubuntu e outros servidores Linux baseados em MD RAID 1, 5, 6 ou 10.

Compromisso: o mdadm concentra-se no RAID por software do Linux, e não em ZFS, RAID de hardware ou análise gráfica a longo prazo.

5. OpenZFS ZED — Melhor monitorização nativa de eventos para pools ZFS

Os utilizadores de ZFS devem monitorizar o ZFS como ZFS, em vez de tentarem mapear todos os eventos para a terminologia RAID tradicional.

O ZED, o daemon de eventos do ZFS, monitoriza os eventos gerados pelo módulo do kernel do ZFS e executa as ações ZEDLET configuradas quando surgem classes de eventos correspondentes.

A relação de monitorização torna-se:

Kernel do ZFS
    |
  zevents
    |
   ZED
    |
Ações ZEDLET
    |
Notificações / automatização

Isto torna o ZED adequado para eventos de pools e dispositivos que pertencem ao próprio ZFS, em vez de um painel externo de discos.

Uma stack completa de servidor doméstico ZFS pode, portanto, incluir:

ZED
 |
Eventos do pool

smartd / Scrutiny
 |
Estado dos discos físicos

Netdata / Grafana
 |
Painel e histórico

Ideal para: utilizadores de TrueNAS, OpenZFS ou ZFS em Linux/BSD que querem gestão nativa de eventos nos seus pools.

Compromisso: O ZED é um daemon de eventos, não um painel completo e refinado. Combine-o com outra camada se a visualização a longo prazo for importante.

6. Cockpit Storage — Melhor GUI de monitorização de RAID para principiantes de Linux

O Cockpit é uma das formas mais fáceis de adicionar uma interface de administração baseada no navegador a um servidor Linux normal.

A aplicação Armazenamento suporta discos locais, partições, RAID, encriptação, NFS, iSCSI e outras operações de armazenamento comuns.

O Cockpit também adicionou informações sobre o estado SMART dos dispositivos à página Armazenamento, incluindo a possibilidade de executar autotestes aos discos a partir do navegador.

Isso torna-o uma opção excelente para principiantes num servidor que, de resto, se parece com isto:

Ubuntu / Debian / Fedora
          |
       Cockpit
          |
 Interface de armazenamento no navegador
          |
 RAID + SMART + montagens

É especialmente útil quando o utilizador quer gerir o armazenamento em vez de criar uma stack de observabilidade dedicada.

Ideal para: principiantes de Linux que querem o estado do RAID e dos discos numa interface de gestão de servidores simples.

Compromisso: O Cockpit é melhor a mostrar e gerir o estado atual do servidor do que a armazenar meses de histórico SMART detalhado.

7. Prometheus + smartctl_exporter + Grafana — Melhor para métricas a longo prazo

Quando a monitorização se torna um passatempo por si só, a stack do Prometheus oferece-lhe muito mais controlo do que um painel NAS criado para uma finalidade específica.

O oficial smartctl_exporter converte as estatísticas do smartctl em métricas do Prometheus. Requer o smartmontools 7.0 ou posterior, pois depende da saída JSON do smartctl.

A arquitetura é modular:

Exportadores SMART / RAID / ZFS
           |
       Prometheus
           |
         Grafana
           |
 Painéis + alertas

Os exporters adicionais ou as métricas dos nós podem acrescentar:

• capacidade do sistema de ficheiros;
• E/S do disco;
• pools ZFS;
• estado do MD RAID;
• temperatura;
• carga do servidor;
• métricas da UPS;
• atividade da rede.

Esta é a opção mais forte quando pretende responder a perguntas históricas, em vez de simplesmente verificar o estado atual.

Por exemplo:

• A temperatura do disco aumentou durante a última reconstrução do RAID?
• Quando surgiram pela primeira vez os erros incorrigíveis?
• A latência do armazenamento mudou depois de adicionar outro disco?
• Quanto cresceu a utilização do pool no último ano?

Os alertas do Grafana também podem avaliar regras baseadas no Prometheus e encaminhar notificações quando as condições são cumpridas.

Ideal para: entusiastas que pretendem métricas de longo prazo, painéis personalizados, correlação e alertas flexíveis.

Desvantagem: O Prometheus + exporters + Grafana exige consideravelmente mais configuração do que o Scrutiny ou o Netdata. Para um único NAS doméstico simples, essa complexidade poderá trazer poucos benefícios práticos.

8. Checkmk — Ideal para monitorizar vários servidores domésticos

Checkmk torna-se mais interessante quando o laboratório doméstico contém mais do que uma máquina.

Em vez de pensar apenas num NAS, poderá ter:

NAS
Servidor de cópias de segurança
Anfitrião Proxmox
Mini PC
Router
UPS
Switch
     |
   Checkmk

O agente Linux do Checkmk suporta a monitorização de hardware através de plugins, incluindo valores SMART de HDDs e SSDs modernos.

A documentação também contempla explicitamente discos ocultos atrás de controladores RAID compatíveis. Dependendo do controlador, podem ser necessárias ferramentas como smartmontools, tw_cliou podem ser necessárias ferramentas MegaRAID antes de o Checkmk conseguir aceder às informações do dispositivo subjacente.

A grande vantagem é a operação centralizada: vários anfitriões, estados dos serviços, regras de alerta, gráficos, inventário, capacidade e monitorização do sistema podem estar todos numa só interface.

Ideal para: laboratórios domésticos onde o estado do armazenamento precisa de ser monitorizado juntamente com vários servidores Linux e dispositivos de infraestrutura.

Desvantagem: O Checkmk representa uma sobrecarga desnecessária para um único NAS se o Netdata ou a monitorização nativa do sistema operativo já abranger os sinais de falha importantes.

9. StorCLI — Melhor para RAID por hardware LSI e Broadcom

O RAID por hardware exige uma abordagem diferente à monitorização, porque o sistema operativo pode ver um único disco virtual, enquanto o controlador gere vários discos físicos subjacentes.

Sistema operativo
      |
 Unidade virtual
      |
 Controlador RAID
      |
+-----+-----+-----+
Disco 1   Disco 2  Disco 3

StorCLI é o utilitário de gestão de linha de comandos da Broadcom para controladores RAID LSI/Broadcom compatíveis.

Pode inspecionar o estado do controlador, as unidades virtuais, as unidades físicas, as operações de reconstrução, as informações da caixa, a cache e os componentes de bateria ou de reserva compatíveis.

O estado do RAID de hardware pode incluir estados como:

• Otimizado;
• Parcialmente degradado;
• Degradado;
• Offline.

Essa visibilidade ao nível do controlador é essencial, porque as ferramentas SMART genéricas podem não conseguir detetar automaticamente as unidades membro através de todos os controladores RAID.

Uma combinação de monitorização útil é:

RAID Broadcom / LSI
        |
      StorCLI
        |
     Netdata
        |
Painel + Alertas

O coletor StoreCLI do Netdata pode obter informações do controlador e apresentá-las juntamente com as restantes métricas do servidor.

Ideal para: servidores domésticos que utilizam controladores de hardware Broadcom, LSI ou MegaRAID compatíveis.

Compromisso: o StorCLI é uma ferramenta de administração específica de controladores, e não um painel universal para servidores domésticos.

10. Zabbix — Ideal para alertas e automatização avançados de RAID

Zabbix é a opção mais orientada para infraestruturas desta lista.

Os seus modelos atuais do Agent 2 incluem monitorização SMART oficial, enquanto o estado da matriz e do controlador pode ser adicionado através de integrações suportadas, itens personalizados, scripts ou modelos adequados ao ambiente.

Uma implementação maior do Zabbix pode combinar:

SMART
RAID
ZFS
Sistema de ficheiros
UPS
Temperatura
Rede
Serviços
     |
   Zabbix
     |
Histórico
Acionadores
Notificações
Escalonamento

A sua força não está num ecrã de RAID dedicado. Está na capacidade de definir exatamente o que constitui uma falha e o que deve acontecer a seguir.

Por exemplo, um aviso pode ser encaminhado para um canal de notificações normal, enquanto uma matriz degradada ou um disco virtual offline desencadeia uma escalada mais urgente.

Ideal para: utilizadores avançados que já utilizam o Zabbix ou pretendem regras detalhadas de alerta e automatização para vários sistemas.

Compromisso: a complexidade da configuração é elevada. Instalar o Zabbix apenas para monitorizar dois discos num único NAS doméstico é geralmente desnecessário.

Que ferramenta de monitorização RAID deve realmente utilizar?

Estado do RAID vs estado SMART: não são a mesma coisa

Esta distinção é mais importante do que a escolha entre a maioria das ferramentas da classificação.

Um exemplo útil é:

mdadm:
Array saudável

Scrutiny:
Disco 3
Setor atualmente pendente = 0 → 2 → 8

O array ainda não falhou, mas o histórico da unidade física dá-lhe motivos para investigar.

Também pode acontecer o oposto:

mdadm:
Array degradado

smartctl:
Disco 1 APROVADO
Disco 2 APROVADO
Disco 3 APROVADO

O membro em falta pode ter desaparecido devido a cablagem, alimentação, problemas no controlador, enumeração do dispositivo ou outra falha não representada por um limiar de falha SMART.

Monitorização de mdadm vs ZFS vs RAID por hardware

A ferramenta de monitorização adequada depende, em parte, do local onde reside a lógica do RAID.

É por isso que a disposição do armazenamento afeta a arquitetura de monitorização. O RAID por software, o ZFS e o RAID por hardware expõem estados diferentes através de diferentes camadas de controlo.

Scrutiny vs Netdata: qual deve instalar?

Funcionam melhor em conjunto do que em oposição.

Assim, uma combinação simples para um servidor doméstico é:

Netdata
  |
Estado do array + do servidor

Scrutiny
  |
Tendências das unidades físicas

Se quiser apenas uma aplicação, o Netdata abrange mais camadas.

Se o sistema operativo do NAS já monitorizar bem o estado do array, o Scrutiny poderá acrescentar mais informação nova, pois fornece uma melhor visão histórica dos discos físicos.

Precisa do Prometheus e do Grafana para um NAS doméstico?

Normalmente, não.

Se o único requisito for:

Diga-me quando o RAID estiver degradado
Diga-me quando um disco estiver a falhar

os alertas nativos do array, juntamente com o smartd, o Scrutiny ou o Netdata, podem resolver o problema com muito menos infraestrutura.

O Prometheus e o Grafana começam a fazer sentido quando se preocupa com:

• histórico de meses ou anos;
• vários servidores;
• painéis personalizados;
• correlacionar a temperatura com a E/S;
• acompanhar o crescimento do armazenamento;
• combinar RAID com métricas de UPS, rede, Docker e do anfitrião;
• regras de alerta PromQL personalizadas.

A razão errada para instalar o Grafana é simplesmente o painel parecer impressionante.

A razão certa é ter perguntas que exigem um histórico de séries temporais.

Que alertas de RAID deve configurar?

A monitorização só se torna útil quando algo consegue chegar até si sem que tenha de abrir primeiro o painel.

Alertas do array

• array degradado;
• array offline;
• membro inesperadamente em falta;
• reserva ativada;
• reconstrução ou resincronização iniciada;
• reconstrução falhada;
• reconstrução concluída.

Alertas de unidades físicas

• falha do estado geral de funcionamento SMART;
• a contagem atual de setores pendentes aumenta;
• a contagem de setores incorrigíveis offline aumenta;
• a contagem de setores realocados aumenta significativamente;
• aviso crítico do NVMe;
• a resistência ou o desgaste do SSD aproximam-se do nível de substituição;
• a temperatura da unidade permanece fora do intervalo esperado.

Alertas do ZFS

• pool degradado;
• falha do dispositivo;
• os erros de checksum aumentam;
• o scrub deteta erros;
• a resilverização começa ou falha;
• a capacidade do pool aproxima-se do limite escolhido.

Alertas de RAID de hardware

• unidade física falhada;
• unidade virtual degradada;
• unidade virtual offline;
• reconstrução parada ou falhada;
• falha da cache do controlador ou da bateria de reserva.

A temperatura exata e os limites SMART não devem ser copiados cegamente de outro servidor. Diferentes modelos de unidades expõem atributos e intervalos de funcionamento diferentes.

O princípio é mais importante:

Um painel que nunca abre não é monitorização.

Teste SMART vs. Scrub vs. Reconstrução: três tarefas diferentes

Estas operações são frequentemente confundidas, mas analisam coisas diferentes.

Autoteste SMART

Um autoteste SMART é realizado por um dispositivo de armazenamento individual.

Uma unidade
   |
Teste SMART
   |
Resultado ao nível do dispositivo

Um teste SMART longo pode analisar uma maior parte da superfície da unidade do que um teste curto, mas não verifica a paridade do RAID nem as cópias de dados do ZFS em todo o sistema de armazenamento.

RAID Rebuild or Resync

Reconstrução ou resincronização do RAID

Uma reconstrução restaura a redundância após a falha ou substituição de um membro.
     |
RAID degradado
     |
Unidade de substituição
     |
Reconstrução / Resincronização

Redundância restaurada

É uma operação de recuperação, não um teste do estado do disco.

Verificação Scrub do ZFS ou verificação de consistência do RAID

Responde a uma pergunta diferente:

É por isso que a monitorização deve apresentar os três aspetos quando a arquitetura de armazenamento os suporta.

Ative os alertas nativos do NAS antes de instalar outro painel

Um sistema operativo NAS dedicado pode já disponibilizar a primeira camada de monitorização de que necessita.

Por exemplo, a gestão de armazenamento atual do ZimaOS apresenta o estado da matriz, o estado das unidades, a capacidade utilizável e as velocidades de leitura/escrita em Definições > Armazenamento. Quando um membro RAID falha, a matriz passa para um estado degradado, e o fluxo de recuperação orienta o utilizador durante a reconstrução após a substituição da unidade.

O ZimaOS também apresenta o progresso de longa duração das verificações RAID e de paridade, bem como informações detalhadas sobre o estado dos discos, na respetiva interface de armazenamento.

A ordem prática deverá, portanto, ser:

1. Ative os alertas nativos do NAS
        |
2. Confirme a deteção de matrizes degradadas
        |
3. Adicione o histórico das unidades físicas
        |
4. Adicione uma pilha de observabilidade mais abrangente apenas se for útil

O TrueNAS, o Unraid, o Synology, o QNAP e outras plataformas NAS disponibilizam igualmente funcionalidades nativas de monitorização do estado do armazenamento, que devem ser configuradas antes de adicionar um segundo sistema de monitorização.

A camada adicional deve responder a uma pergunta à qual a interface nativa não responde bem.

A monitorização do RAID não substitui a cópia de segurança

Um alerta perfeito pode indicar-lhe, em poucos segundos, que um disco falhou.

Não consegue restaurar a versão de ontem de uma pasta eliminada.

Não consegue recuperar ficheiros já encriptados por ransomware.

Não consegue recriar o NAS após um roubo, incêndio ou falha catastrófica do controlador.

É por isso que o RAID não é uma cópia de segurança.

RAID
  |
Disponibilidade após falhas de algumas unidades

Monitorização
  |
Detetar problemas rapidamente

Cópia de segurança
  |
Recuperar dados perdidos ou danificados

As três resolvem partes diferentes do problema da fiabilidade.

A monitorização torna-se especialmente importante durante as reconstruções, porque as unidades restantes podem ficar sujeitas a atividade contínua enquanto a redundância está reduzida. Uma falha de energia inesperada durante esse período acrescenta outro risco, razão pela qual a proteção por UPS durante as operações de armazenamento é importante independentemente da monitorização do estado das unidades.

Pilh as de monitorização de RAID recomendadas

Servidor Linux RAID simples

mdadm --monitor
       +
     smartd

Esta é a opção leve.

O mdadm monitoriza o conjunto Linux. O smartd monitoriza os discos. Nenhum dos dois requer uma plataforma Web pesada.

NAS doméstico fácil

Monitorização nativa do NAS
         +
      Scrutiny

A interface do NAS gere o estado do conjunto e as reconstruções, enquanto o Scrutiny acrescenta o histórico da saúde das unidades e notificações.

Servidor doméstico Linux geral

Netdata
   +
Scrutiny

O Netdata fornece monitorização do conjunto e de todo o servidor. O Scrutiny fornece um histórico mais detalhado das unidades físicas.

Servidor doméstico ZFS

ZED
 +
Scrutiny
 +
Netdata

O ZED gere os eventos nativos do ZFS, o Scrutiny acompanha as tendências das unidades e o Netdata fornece um painel mais abrangente do sistema.

Homelab avançado

smartctl_exporter
Exportadores de MD / ZFS
node_exporter
      |
  Prometheus
      |
   Grafana
      |
Alertas

Esta opção é adequada quando o histórico das métricas e vários servidores são importantes o suficiente para justificar a manutenção de uma pilha completa de observabilidade.

Servidor com RAID de hardware

StorCLI
   |
Netdata / Checkmk
   |
Alertas + Painel

O utilitário do controlador continua a ser a fonte de verdade para a camada de RAID de hardware, enquanto a plataforma de monitorização torna o seu estado visível e acionável.

Veredicto final

O Netdata é a melhor ferramenta geral de monitorização de RAID para a maioria dos servidores domésticos, pois pode funcionar sobre várias arquiteturas de armazenamento e, simultaneamente, monitorizar o próprio anfitrião.

O Scrutiny é a ferramenta complementar mais forte quando o histórico de cada unidade é importante. É particularmente útil para detetar alterações lentas nos atributos SMART antes de o próprio conjunto entrar num estado degradado.

O smartmontools continua a ser a camada fundamental da saúde dos discos, enquanto o mdadm Monitor continua a ser uma das respostas mais simples para RAID de software no Linux.

O OpenZFS ZED deve continuar a fazer parte de uma estratégia de monitorização nativa do ZFS, em vez de tentar substituir os eventos do conjunto por dados SMART genéricos.

O Cockpit é a opção gráfica mais fácil para um servidor Linux normal, enquanto o Prometheus e o Grafana fazem mais sentido quando as métricas de longo prazo se tornam uma necessidade real.

O Checkmk e o Zabbix tornam-se mais valiosos à medida que aumenta o número de sistemas monitorizados, e o StorCLI é essencial quando a lógica do RAID está integrada num hardware LSI/Broadcom compatível.

A estratégia mais fiável para um servidor doméstico é, portanto, feita por camadas:

Estado do conjunto
     +
Estado de saúde da unidade
     +
Estado da recuperação
     +
Alertas
     +
Histórico

Normalmente, o RAID falha por camadas, pelo que a monitorização também deve ser feita por camadas.

Perguntas frequentes

Qual é a melhor ferramenta de monitorização de RAID para um servidor doméstico?

O Netdata é uma das melhores opções gerais, pois consegue monitorizar RAID MD do Linux, dispositivos SMART, conjuntos ZFS, RAID de hardware compatível e o resto do servidor a partir de uma única interface. O Scrutiny é uma ferramenta especializada mais forte quando o histórico detalhado do SMART das unidades físicas é a prioridade.

O Scrutiny é uma ferramenta de monitorização de RAID?

O Scrutiny monitoriza as unidades físicas subjacentes a uma matriz RAID através dos dados SMART. Não substitui a monitorização ao nível da matriz, como o mdadm para RAID MD do Linux, o ZED para eventos do ZFS ou o StorCLI para controladores RAID de hardware compatíveis.

O SMART pode indicar PASSED quando uma unidade está a falhar?

SMART PASSED significa que a unidade ainda não ultrapassou a condição geral de falha SMART do dispositivo. Os atributos individuais podem, ainda assim, sofrer alterações preocupantes antes de esse estado passar para falhado. A monitorização histórica é útil porque torna essas tendências visíveis.

Qual é a melhor forma de monitorizar um RAID mdadm?

Utilize o modo de monitorização do mdadm para eventos da matriz e associe-o ao smartmontools ou ao Scrutiny para o estado das unidades físicas. O Netdata pode fornecer uma camada gráfica adicional de monitorização do RAID MD e do servidor.

Qual é a melhor forma de monitorizar um pool ZFS?

Utilize ferramentas nativas do ZFS, como o ZED e o zpool, para eventos e estado do pool. Adicione o smartmontools ou o Scrutiny para o estado das unidades individuais e o Netdata, o Prometheus ou o Grafana quando for necessária visualização histórica.

A monitorização do RAID deteta um disco rígido em falha antes de este falhar?

A monitorização isolada da matriz pode não ser suficiente. As ferramentas baseadas em SMART podem revelar alterações no estado das unidades antes de a matriz perder um membro, embora nenhum sistema de monitorização consiga prever de forma fiável todas as falhas de unidades.

Devo utilizar o Netdata ou o Scrutiny?

Utilize o Netdata quando quiser um único painel de todo o servidor que abranja RAID, armazenamento, CPU, RAM, rede e serviços. Utilize o Scrutiny quando as tendências SMART detalhadas e o histórico do estado das unidades forem a prioridade. Executar ambos pode ser útil, pois abrangem camadas diferentes.

Preciso do Grafana para monitorizar o RAID?

Não. O Grafana é útil para métricas de longo prazo, painéis personalizados, vários sistemas e correlação. Uma NAS doméstica simples pode muitas vezes ser monitorizada adequadamente com os alertas nativos e com o smartmontools, o Scrutiny ou o Netdata.

Que alertas deve enviar um servidor RAID?

No mínimo, configure alertas para matrizes degradadas ou offline, membros em falta, falhas de reconstrução, falhas de estado SMART, alterações importantes nos atributos SMART, temperaturas elevadas das unidades, erros do ZFS e falhas do controlador RAID de hardware ou da cache, quando aplicável.

Uma limpeza do RAID é o mesmo que um teste SMART?

Não. Um teste SMART é executado numa unidade individual. Uma limpeza ou verificação de consistência valida os dados e a redundância ao nível do sistema de armazenamento. Uma reconstrução restaura a redundância após uma falha ou substituição de um disco.

A monitorização do RAID substitui a cópia de segurança?

Não. A monitorização ajuda a detetar falhas rapidamente, e o RAID pode manter a disponibilidade após determinadas falhas de unidades. Nenhum dos dois restaura ficheiros eliminados, encriptados, corrompidos ou alterados anteriormente. Continua a ser necessária uma cópia de segurança separada.

Devo monitorizar SSDs e unidades NVMe em RAID?

Sim. Os SSDs e as unidades NVMe disponibilizam informações sobre o estado de saúde, como avisos críticos, temperatura, erros de suporte e resistência ou desgaste. Os atributos exatos diferem dos dados SMART dos HDD, pelo que a ferramenta de monitorização precisa de suporte adequado para o dispositivo.