Monitoramento de Disco: métricas e ferramentas essenciais
Quando um banco de dados trava porque o disco ficou cheio, ou uma aplicação fica lenta porque a latência de I/O subiu, o incidente quase sempre chega antes do alerta. Disco é o subsistema silencioso da infraestrutura. Fica bem até parar de funcionar.
O monitoramento de disco é justamente o que transforma esse ponto cego em sinal antecipado. Ele cruza três dimensões distintas (capacidade, performance e saúde física) para detectar saturação de espaço, gargalos de leitura e escrita e degradação de hardware antes que virem incidentes de produção.
Neste guia, você verá quais métricas monitorar em HDDs, SSDs, NVMe e discos em nuvem, quais ferramentas usar em Linux, Windows e ambientes cloud, como definir thresholds de alerta que fazem sentido e quais armadilhas evitar quando o monitoramento vai para produção.
O que é monitoramento de disco e por que ele é crítico
Monitoramento de disco é o processo contínuo de coletar, armazenar e analisar métricas do subsistema de armazenamento para avaliar três aspectos complementares: quanto espaço ainda há disponível, com que velocidade o disco responde e qual o estado de saúde do hardware físico.
A criticidade vem da posição do disco na arquitetura. Aplicações, bancos de dados, filas, caches e sistemas de log dependem do disco para persistir estado. Quando a capacidade acaba, processos escrevem erros e morrem. Quando a latência cresce, a fila de I/O do kernel enche e a aplicação inteira pausa.
Ignorar o disco também é caro por outro motivo: falhas costumam se manifestar gradualmente. Um disco com reallocated sectors crescendo hoje quase sempre falha dias ou semanas depois. Esse intervalo é exatamente a janela de ação que o monitoramento precisa capturar. Sem ele, a equipe só descobre o problema quando a aplicação cai.
Por isso, o monitoramento de disco é peça central em qualquer estratégia madura de monitoramento de TI, junto com CPU, memória e rede.
Quais métricas de disco monitorar
Disco não se resume a uma única métrica. Uma boa estratégia trabalha três grupos distintos (capacidade, performance e saúde) e correlaciona os três para produzir diagnóstico confiável.
Capacidade e utilização de espaço
O grupo mais básico, mas ainda o mais comum causador de incidentes. Métricas principais:
- % de uso do filesystem: percentual ocupado em cada ponto de montagem
- Espaço livre absoluto: bytes livres, especialmente crítico em volumes grandes onde o percentual pode enganar
- Inodes: em sistemas Linux, inodes podem acabar antes do espaço quando há muitos arquivos pequenos
- Taxa de crescimento: quanto o uso cresce por hora ou por dia, permitindo previsão antes de atingir o limite
Alertar apenas em 95% de uso é uma receita para falhas. O disco pode saltar de 80% a 100% em poucas horas dependendo do workload.
Performance: IOPS, throughput e latência
Performance define se o disco está respondendo dentro do tempo aceitável para a aplicação. Quatro métricas compõem o núcleo:
- IOPS: operações de leitura e escrita por segundo. Varia drasticamente por tipo de mídia (HDD 75–200, SSD SATA 20–80 mil, NVMe 300 mil ou mais). Para aprofundar, veja nosso guia sobre IOPS em produção.
- Throughput: MB/s transferidos. Relevante para workloads sequenciais como backup e replicação.
- Latência de I/O (await): tempo médio por operação. Acima de 20 ms em HDD ou 5 ms em SSD indica fila crescente.
- Queue depth e %util: quanto o disco está saturado. %util acima de 80% por períodos longos sugere gargalo.
A latência é frequentemente o primeiro sinal de que o disco virou gargalo, antes mesmo do IOPS bater o teto teórico da mídia.
Saúde do disco (SMART)
SMART (Self-Monitoring, Analysis and Reporting Technology) é o protocolo que discos modernos usam para expor atributos de saúde física. Os atributos críticos para monitorar:
Reallocated_Sector_Ct: setores defeituosos realocados. Crescimento equivale a degradação em curso.Current_Pending_Sector: setores com erro aguardando realocação.Temperature_Celsius: temperatura de operação. Acima de 55°C reduz vida útil.Power_On_Hours: horas de uso acumuladas.Wear_Leveling_Count(SSDs): desgaste de células NAND.
Qualquer mudança significativa nesses atributos deve gerar alerta, mesmo que o disco ainda funcione. Ele está sinalizando que vai falhar em breve.
Como monitorar disco no Linux
Linux oferece utilitários de linha de comando maduros para investigação pontual e métricas que integram naturalmente com ferramentas de monitoramento centralizado.
Para capacidade, df -h mostra uso por ponto de montagem e df -i revela uso de inodes. Use ambos juntos.
Para performance, iostat -x 1 é o comando de referência. Ele exibe IOPS por dispositivo em tempo real com %util, await (latência de I/O) e svctm. Exemplo de saída em situação saturada:
A linha de sda mostra disco saturado: await de 28 ms e %util em 94% indicam fila crescente e tempo elevado por operação.
Para identificar o processo causador, iotop mostra I/O por PID, similar ao htop para CPU. É útil em diagnóstico ao vivo.
Para saúde, smartctl -a /dev/sda (do pacote smartmontools) expõe os atributos SMART. Em produção, o daemon smartd deve rodar continuamente enviando alertas quando atributos cruzam thresholds.
Em ambientes gerenciados por ferramenta de monitoramento, Prometheus com node_exporter coleta a maior parte das métricas acima automaticamente via /proc/diskstats. Zabbix tem templates nativos equivalentes para Linux. A documentação oficial do iostat descreve cada coluna em detalhe.
Como monitorar disco no Windows
Windows expõe métricas de disco via contadores de performance (Performance Counters), acessíveis por Performance Monitor (perfmon) ou coletores remotos.
Os contadores essenciais para disco:
LogicalDisk\% Free Space: espaço livre por volumePhysicalDisk\Avg. Disk sec/Read: latência média de leituraPhysicalDisk\Avg. Disk sec/Write: latência média de escritaPhysicalDisk\Disk Reads/seceDisk Writes/sec: IOPS de leitura e escritaPhysicalDisk\Current Disk Queue Length: comprimento da fila de I/O
A convenção histórica considera latência acima de 25 ms como sinal de gargalo em discos rotacionais e acima de 10 ms para SSDs corporativos.
Para coleta remota, a maioria das ferramentas de monitoramento usa WMI ou agentes nativos que extraem esses contadores e os enviam a um backend central. Detalhes dos contadores estão na documentação oficial da Microsoft.
Monitoramento de disco em ambientes cloud
Em nuvem, o disco vira um recurso gerenciado: EBS na AWS, Managed Disks no Azure, Persistent Disk no GCP. As métricas relevantes mudam de ênfase porque parte do hardware está abstraído.
Os três provedores expõem métricas comparáveis, ainda que com nomes diferentes. A tabela abaixo resume as principais:
| Métrica | AWS EBS | Azure Managed Disks | GCP Persistent Disk |
|---|---|---|---|
| IOPS | VolumeReadOps / VolumeWriteOps | Disk Read Operations/Sec | disk/read_ops_count |
| Throughput | VolumeReadBytes / VolumeWriteBytes | Disk Read Bytes/Sec | disk/read_bytes_count |
| Latência | VolumeTotalReadTime | Disk Read/Write Latency | disk/operation_time |
| Burst / Saturação | BurstBalance (gp2) | Disk IOPS Consumed % | disk/throttled_ops_count |
A grande diferença em relação ao on-prem: em nuvem, performance muitas vezes é provisionada. Um volume gp3 na AWS, por exemplo, tem IOPS e throughput baseline definidos na criação e pode estourar temporariamente para um limite burst. Monitorar o saldo de burst credit é tão importante quanto monitorar IOPS.
Em AWS, CloudWatch expõe a métrica BurstBalance para volumes gp2. Em Azure, Managed Disks têm limites por tier de performance. Em GCP, Persistent Disks têm performance proporcional ao tamanho do volume.
Para correlacionar disco em nuvem com outros recursos, as ferramentas de observabilidade e monitoramento de servidores podem ingerir essas métricas do CloudWatch, Azure Monitor e Google Cloud Monitoring e unificar em dashboards únicos. Isso é essencial em arquiteturas multi-cloud.
Referência oficial sobre tipos de volume EBS e seus limites de performance está disponível na documentação da AWS.
Thresholds e alertas recomendados
Thresholds genéricos falham rapidamente em produção. Cada tipo de workload e de mídia exige calibração. A tabela abaixo serve como ponto de partida, ajustável após algumas semanas de observação.
| Métrica | Severidade média | Severidade alta | Observação |
|---|---|---|---|
| % uso do filesystem | 80% | 90% | Usar espaço absoluto em volumes acima de 1 TB |
| Latência HDD (await) | 20 ms | 50 ms | Por 5 min consecutivos |
| Latência SSD SATA | 5 ms | 15 ms | Por 5 min consecutivos |
| Latência NVMe | 2 ms | 5 ms | Por 5 min consecutivos |
| %util | 80% | 95% | Sustentado por mais de 10 min |
| Reallocated sectors | qualquer crescimento | crescimento acelerado | Alerta imediato |
| Temperatura | 50°C | 55°C | Em disco de datacenter |
Para capacidade, alertar em 80% com severidade média e 90% com alta funciona para a maioria dos volumes. Em volumes grandes (mais de 1 TB), priorize espaço livre absoluto. Dez por cento de 10 TB ainda é 1 TB.
Para latência de I/O, os thresholds dependem da mídia: 25 ms para HDD, 10 ms para SSD SATA, 5 ms para NVMe. Ultrapassar esses valores por mais de 5 minutos consecutivos indica gargalo real, não ruído.
Para saúde, qualquer mudança em Reallocated_Sector_Ct ou Current_Pending_Sector deve gerar alerta. Não espere um valor mínimo. Temperatura acima de 50°C em disco de datacenter já merece investigação.
Alertas só valem se integrados ao fluxo de resposta a incidentes. Veja o nosso material sobre alertas de TI para evitar fadiga de alerta com thresholds mal calibrados.
Ferramentas de monitoramento centralizado
Comandos locais são úteis para investigação, mas produção exige coleta contínua e centralizada. As principais opções disponíveis no mercado brasileiro:
- Zabbix: open source, com templates nativos para Linux, Windows e storage em rede. Coleta via agente ou SNMP, armazena histórico longo e alerta por múltiplos canais.
- Prometheus + node_exporter: pull-based, foco em métricas em tempo real. Integra bem com Grafana para dashboards e com Alertmanager para alertas.
- CloudWatch, Azure Monitor e Google Cloud Monitoring: nativos de cada provedor, coletam métricas de disco automaticamente a partir dos recursos gerenciados.
- OpMon: plataforma brasileira que unifica Linux, Windows, storage em rede e cloud em um único dashboard, com ajuste fino para ambientes mistos.
- PRTG, SolarWinds e Datadog: alternativas comerciais com ampla cobertura e descoberta automática.
A escolha depende menos da ferramenta e mais da estratégia. Capacidade, performance e saúde precisam ser coletadas juntas, com alertas cruzando os domínios. Um disco com latência crescente e reallocated sectors subindo é um incidente iminente, não dois eventos isolados.
Planejamento de crescimento pode ser integrado à ferramenta de monitoramento ou tratado separadamente via capacity planning, que projeta consumo futuro com base em tendências históricas.
Boas práticas em produção
Algumas práticas separam um monitoramento bom de um que apenas cria ruído:
- Correlacione com aplicação. Disco raramente é o sintoma percebido. O usuário sente a aplicação lenta. Alertas de disco devem ser ligados a SLIs de aplicação para priorização correta.
- Monitore tendência, não só valor instantâneo. Espaço em 70% hoje pode ser tranquilo ou urgente dependendo da taxa de crescimento. Incluir previsão em dashboards evita surpresas.
- Separe alertas de capacidade, performance e saúde. São problemas com respostas diferentes: capacidade pede limpeza ou expansão, performance pede tuning ou upgrade, saúde pede substituição de hardware.
- Use thresholds dinâmicos onde fizer sentido. Para workloads com padrão sazonal, thresholds fixos geram falsos positivos. Ferramentas modernas suportam baselines dinâmicas baseadas em histórico.
- Valide alertas em simulação. Gerar carga artificial (por exemplo, via
ddoufio) confirma que o pipeline detecta a condição antes do incidente real. - Integre com a camada de rede. Storage em rede (NFS, iSCSI, SAN) tem comportamento diferente de disco local. Correlacionar disco com monitoração de redes é essencial para diagnosticar gargalos compartilhados.
Monitoramos sua infraestrutura 24×7, antes que o problema chegue ao usuário.
Detectamos falhas em servidores, aplicações e redes em tempo real com alertas inteligentes, dashboards e relatórios de SLA.
Conclusão
Monitoramento de disco efetivo é a diferença entre operar de forma reativa (lidando com indisponibilidades causadas por capacidade, latência ou falha física) e operar proativamente, atuando antes que o incidente atinja o usuário. As três dimensões (capacidade, performance e saúde) precisam ser coletadas juntas, correlacionadas e integradas ao fluxo de alertas da equipe.
Em infraestruturas mistas (on-prem, nuvem e containers) a complexidade multiplica. Cada camada tem métricas próprias, thresholds próprios e ferramentas próprias. A unificação dessas fontes em uma plataforma central é o que permite equipes pequenas gerenciarem ambientes grandes sem perder velocidade de resposta.
A OpServices ajuda empresas brasileiras a estruturar monitoramento de disco completo, incluindo capacidade, IOPS, latência e saúde SMART, integrado com o restante da infraestrutura e com processos ágeis de resposta a incidentes. Fale com um especialista para avaliar como podemos fortalecer a visibilidade do seu ambiente.
Perguntas Frequentes
O que é monitoramento de disco?
Quais métricas de disco devem ser monitoradas?
%util ou queue depth). Saúde: atributos SMART como Reallocated_Sector_Ct, Current_Pending_Sector, Temperature_Celsius e Power_On_Hours. Em SSDs, incluir Wear_Leveling_Count para acompanhar o desgaste das células NAND.Como verificar a saúde de um disco rígido?
smartctl -a /dev/sda do pacote smartmontools lista todos os atributos. No Windows, utilitários do fabricante ou ferramentas como CrystalDiskInfo fazem a leitura. Em produção, o daemon smartd deve rodar continuamente e emitir alertas quando atributos críticos como setores realocados, setores pendentes ou temperatura cruzam thresholds seguros.O que é IOPS e por que importa?
