Como monitorar a saúde do disco em um VPS

O que o monitoramento da integridade do disco em um VPS consegue realmente detetar

O monitoramento da integridade do disco em um VPS começa por um facto que a maioria dos guias evita: o disco não é seu. O sistema convidado vê um dispositivo de bloco virtual. A unidade física e todos os contadores armazenados nela pertencem ao host. smartctl /dev/vda não falha porque o comando foi digitado incorretamente. Falha porque não existe nada por trás desse dispositivo capaz de responder à pergunta.

SMART (tecnologia de automonitoramento, análise e geração de relatórios) é uma tabela de contadores mantida na própria unidade: setores realocados, setores pendentes, horas de funcionamento e erros de mídia. A leitura dessa tabela exige um caminho para que comandos ATA ou NVMe (non-volatile memory express) cheguem ao hardware real. Um disco paravirtualizado não fornece esse caminho. Por isso, o sistema convidado recebe o armazenamento sem os dados de telemetria.

O cliente monitora efeitos, não o hardware. Quatro sinais são visíveis dentro do sistema convidado: erros de E/S (entrada/saída) no log do kernel, um sistema de arquivos que é remontado como somente leitura, latência que aumenta gradualmente e espaço que se esgota. É possível gerar alertas para os quatro sinais atualmente, e todos aparecem antes de uma reclamação do usuário. Configure isso primeiro. A divisão de responsabilidades vem no fim, porque muda onde você deve concentrar o esforço.

O que o seu próprio servidor expõe

Não presuma em que situação está. Verifique primeiro e leia depois a secção correspondente.

sudo apt update && sudo apt install -y smartmontools nvme-cli
lsblk -o NAME,TYPE,SIZE,MODEL,TRAN
sudo smartctl -a /dev/vda

virtio-blk, o disco KVM habitual (máquina virtual baseada no kernel). O dispositivo é /dev/vda e o smartctl termina antes de enviar qualquer pedido:

/dev/vda: Unable to detect device type
Please specify device type with the -d option.

virtio-blk é um transporte paravirtualizado sem um conjunto de comandos ATA ou SCSI por trás. Por isso, não existe um canal para transportar um pedido SMART. -d sat e -d scsi falham da mesma forma, porque o problema está no transporte, não na flag.

Um disco SATA ou SCSI emulado. O dispositivo é /dev/sda e o smartctl consegue avançar o suficiente para o identificar. A linha do modelo mostra QEMU HARDDISK. Essa cadeia responde à pergunta por si só: está a ler um dispositivo criado pelo emulador, que não reporta capacidade SMART utilizável.

Um namespace NVMe. sudo nvme smart-log /dev/nvme0n1 devolve um log completo, o que pode induzir em erro. Verifique primeiro a identidade do controlador com sudo nvme id-ctrl /dev/nvme0 | grep -E '^(mn|sn)'. Um número de modelo que identifica um produto de armazenamento em rede significa que o controlador é software. Nesse caso, percentage_used e media_errors descrevem essa emulação, não a memória flash onde estão os seus dados. Se quiser saber qual é realmente o seu armazenamento, verifique o disco NVMe no Linux em vez de confiar na descrição do plano.

Um contentor, como LXC (contentores Linux) ou OpenVZ. Não tem um dispositivo de blocos próprio. lsblk mostra os dispositivos do host ou não mostra nada, e o smartctl é recusado porque o contentor não possui CAP_SYS_RAWIO:

Smartctl open device: /dev/sda failed: Permission denied

Há um aviso sobre o caso em que funciona. Se o smartctl numa VPS devolver uma tabela completa de atributos, leia o número de série antes de agir. Alguns hosts expõem um nó de dispositivo através de passthrough, e esses contadores pertencem a hardware partilhado por todos os tenants dessa máquina. Um Reallocated_Sector_Ct crescente nesse dispositivo deve originar um pedido de suporte. Não é uma afirmação sobre os seus dados.

Sinal 1: erros de I/O no log do kernel

Este é o sinal de maior valor que um tenant pode obter e não requer nenhum agente.

sudo journalctl -k -p err -b
sudo journalctl -k --since "7 days ago" | grep -iE 'i/o error|remount|ext4-fs error|buffer i/o'

Uma solicitação falhada do disco virtual aparece assim:

blk_update_request: I/O error, dev vda, sector 2101248 op 0x1:(WRITE) flags 0x800 phys_seg 1 prio class 0

A camada de blocos solicitou uma escrita ao host, e o host devolveu uma falha. Numa VPS, raramente se trata de uma célula flash avariada. Normalmente, o problema está na camada de armazenamento do host ou no caminho de rede até ao armazenamento ligado à rede. Portanto, é um evento do lado do provedor. Copie a marca temporal, o nome do dispositivo e o setor para o seu ticket, porque a equipa de armazenamento pode comparar esses dados com os próprios logs.

A sequência do ext4 mais importante é este par:

EXT4-fs error (device vda1): ext4_journal_check_start:83: comm cron: Detected aborted journal
EXT4-fs (vda1): Remounting filesystem read-only

A segunda linha é a que causa o problema, porque a máquina continua ativa. Responde a ping, responde a SSH e todas as escritas falham. Uma verificação HTTP simples continua a passar, enquanto a aplicação gera um erro em cada solicitação.

O XFS encerra o sistema de arquivos:

XFS (vda1): metadata I/O error in "xfs_trans_read_buf_map+0x1c0/0x2e0" at daddr 0x2 len 1 error 5
XFS (vda1): I/O Error Detected. Shutting down filesystem

journalctl -k lê apenas o boot atual, a menos que o journal esteja armazenado em disco. Muitas imagens incluem um journal volátil que fica na RAM. Ative a persistência, ou as evidências desaparecem precisamente no reboot que fará durante a investigação.

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald
journalctl --list-boots

Depois do próximo reboot, journalctl --list-boots deverá listar mais de um boot. Mesmo com a persistência ativada, um sistema de arquivos que passou para somente leitura não consegue registrar o que aconteceu depois. Esse é o argumento correto para enviar os logs para fora do servidor.

Sinal 2: detetar uma remontagem como somente leitura

Torne a falha explícita antes de tentar detetá-la.

findmnt -no SOURCE,FSTYPE,OPTIONS /

Procure errors=remount-ro nas opções. As imagens cloud do Ubuntu e do Debian definem esta opção em /etc/fstab, para que um erro de metadados remonte o sistema de ficheiros como somente leitura, em vez de continuar a operar sobre dados danificados. Se estiver em falta, adicione-a à entrada da raiz em /etc/fstab ou defina-a no superbloco com sudo tune2fs -e remount-ro /dev/vda1. Uma paragem explícita é preferível à corrupção silenciosa.

Um sinalizador de montagem não é prova. Faça um teste escrevendo:

touch /var/tmp/.disk-probe

Numa raiz montada como somente leitura, o comando apresenta exatamente:

touch: cannot touch '/var/tmp/.disk-probe': Read-only file system

Use /var/tmp, não /tmp. Na maioria das imagens, /tmp é um tmpfs mantido na memória, pelo que uma escrita bem-sucedida nesse local não prova nada sobre o disco.

Combine o teste de escrita com uma verificação de espaço e envie um heartbeat apenas quando todas as verificações forem bem-sucedidas:

sudo tee /usr/local/sbin/disk-probe >/dev/null <<'EOF'
#!/bin/sh
set -eu
probe=/var/tmp/.disk-probe
echo ok > "$probe"
test "$(cat "$probe")" = ok
rm -f "$probe"
used=$(df --output=pcent / | tail -n1 | tr -dc '0-9')
test "$used" -lt 90
inodes=$(df --output=ipcent / | tail -n1 | tr -dc '0-9')
test "$inodes" -lt 90
curl -fsS --max-time 10 "https://status.example.com/api/push/REPLACE_TOKEN?status=up&msg=OK" >/dev/null
EOF
sudo chmod 755 /usr/local/sbin/disk-probe
sudo /usr/local/sbin/disk-probe && echo probe-ok

probe-ok nessa última linha significa que toda a cadeia funciona. set -eu faz com que qualquer verificação falhada termine com um código diferente de zero antes de executar a linha curl, pelo que nenhum heartbeat é enviado. Essa inversão é o objetivo: o monitor fica vermelho porque nada chegou, e um servidor que não consegue escrever não é fiável para descrever o seu próprio problema. As leituras continuam a funcionar num sistema de ficheiros montado como somente leitura, pelo que o próprio script continua a arrancar.

Execute-o através de um temporizador do systemd.

# /etc/systemd/system/disk-probe.service
[Unit]
Description=Disk writability and space probe

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/disk-probe

# /etc/systemd/system/disk-probe.timer
[Unit]
Description=Run the disk probe every five minutes

[Timer]
OnBootSec=2min
OnUnitActiveSec=5min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now disk-probe.timer
systemctl list-timers disk-probe.timer
journalctl -u disk-probe.service -n 20 --no-pager

systemctl list-timers deve apresentar a unidade com uma hora de execução NEXT inferior a cinco minutos. Uma execução falhada aparece em journalctl -u disk-probe.service com o texto de erro do próprio shell, permitindo distinguir um sistema de ficheiros montado como somente leitura de um sistema cheio sem iniciar sessão no servidor.

Esse URL de push é um monitor de push do Uptime Kuma. Crie um monitor do tipo Push, copie o respetivo token para o script e defina o intervalo do heartbeat do monitor para um valor ligeiramente superior ao intervalo do temporizador, para que uma execução lenta não lhe envie um alerta às 03:00. Se ainda não tiver uma página de estado, uma instância autogerida do Uptime Kuma é o local mais económico para colocar esta verificação.

Há duas limitações importantes. O teste confirma que uma escrita foi aceite, mas não que os bytes chegaram ao armazenamento persistente, porque a leitura seguinte pode ser servida pela cache de páginas. Além disso, é executado na própria máquina que monitoriza, pelo que um servidor completamente bloqueado fica silencioso em vez de comunicar um diagnóstico.

Tendências de latência e throughput

sudo apt install -y sysstat
iostat -xdz 5 3

Leia primeiro r_await e w_await. Estes valores representam a média, em milissegundos, que uma leitura ou escrita demorou, incluindo o tempo de espera na fila. Em seguida, leia aqu-sz, que representa o número médio de pedidos em curso. Ignore %util num disco virtual: este valor apenas indica que a fila não estava vazia. Um dispositivo que processa muitos pedidos em paralelo pode ficar perto de 100 por cento sem estar próximo do limite. await é o valor que corresponde à experiência dos utilizadores.

Os valores absolutos são menos importantes do que a sua própria linha de base. Por isso, registe uma hora tranquila e guarde esse registo. /proc/diskstats é a fonte bruta, caso prefira recolher os contadores por conta própria.

Para fazer uma medição controlada:

sudo apt install -y fio
fio --name=readlat --filename=/var/tmp/fio.probe --size=512M --rw=randread --bs=4k --iodepth=1 --direct=1 --runtime=30 --time_based --group_reporting
rm -f /var/tmp/fio.probe

Leia o bloco clat percentiles, em particular o percentil 99. --direct=1 ignora a cache de páginas. Não ignora a cache do host. Por isso, o resultado descreve todo o percurso entre o seu processo e o armazenamento da plataforma. Execute o teste enquanto o servidor estiver inativo, porque ele concorre com a sua própria carga de trabalho.

O aumento de await sem erros no log do kernel normalmente não indica uma unidade com falhas. Trata-se de contenção no host, o equivalente, no armazenamento, ao tempo de CPU roubado por um vizinho ruidoso. Se o problema regressar à mesma hora todos os dias e o seu ticket for encerrado sem problemas, a solução é um plano cujo I/O não seja partilhado da mesma forma. É o que acontece com um VPS com armazenamento dedicado em vez de um VPS normal quando a carga de trabalho é limitada pelo disco.

Sinal 4: verificações do sistema de ficheiros que pode executar enquanto está montado

O ext4 mantém um contador de erros no superbloco, que persiste após reinícios mesmo quando os logs já não estão disponíveis.

sudo dumpe2fs -h /dev/vda1 2>/dev/null | grep -iE 'filesystem state|error count|first error|last error'

Um sistema de ficheiros saudável apresenta Filesystem state: clean e FS Error count: 0. clean with errors e um contador diferente de zero indicam que o kernel encontrou um erro de metadados em algum momento, mesmo que ninguém o tenha detetado e o log já tenha sido rodado. Esse comando deve fazer parte de uma verificação semanal.

Não pode executar fsck num sistema de ficheiros root montado, e e2fsck -n num sistema de ficheiros em uso reporta problemas causados apenas pelas alterações de dados que ocorrem durante a verificação. Para forçar uma verificação real, adicione fsck.mode=force fsck.repair=yes à linha de comandos do kernel para um arranque através da consola do seu fornecedor. O systemd-fsck executa então a verificação antes de montar o root com permissões de leitura e escrita.

O XFS não tem verificação online. xfs_repair -n /dev/vda1 recusa-se a executar contra um sistema de ficheiros montado, por isso deve ser usado em modo de recuperação. O XFS compensa essa limitação sendo explícito: encerra o sistema de ficheiros quando encontra um erro de metadados, em vez de continuar.

No Btrfs, os contadores são integrados e persistentes.

sudo btrfs device stats /
sudo btrfs scrub start -B /

write_io_errs ou corruption_errs acima de zero representam um evento real, e os contadores mantêm os seus valores entre reinícios até serem repostos. scrub relê cada bloco e verifica a respetiva soma de verificação, sendo o mais próximo de um teste de suporte disponível num disco virtual. A operação gera muita atividade de I/O, por isso agende-a para um período de menor utilização.

Sinal 5: espaço livre, incluindo o que o df oculta

Ficar sem espaço interrompe um servidor da mesma forma que um disco defeituoso, e acontece com muito mais frequência.

df -h /
df -i /
sudo du -xh --max-depth=1 / | sort -h | tail -n 20

No space left on device, enquanto df -h mostra espaço livre, significa que ficou sem inodes, e não sem bytes. df -i mostra IUse% a 100 por cento. Milhões de ficheiros pequenos num diretório de cache ou numa fila de correio causam este problema, e apagar ficheiros grandes não resolve.

O espaço que não é recuperado depois de apagar um ficheiro normalmente pertence a um ficheiro apagado que continua aberto por um processo em execução. sudo lsof +L1 lista os ficheiros cuja contagem de ligações chegou a zero. Reiniciar o processo que mantém um desses ficheiros aberto liberta o espaço.

O journal é um consumidor silencioso comum. journalctl --disk-usage indica o espaço que está a utilizar. Limite-o com SystemMaxUse=200M em /etc/systemd/journald.conf, seguido de sudo systemctl restart systemd-journald, e recupere o espaço imediatamente com sudo journalctl --vacuum-size=200M.

Há um caso que parece um erro, mas não é. Num armazenamento do host com thin provisioning, o pool do host pode ficar cheio enquanto o seu df ainda mostra gigabytes livres. As gravações falham então com erros de I/O no log do kernel, sem qualquer aviso de falta de espaço dentro do guest. Erros sem um sistema de ficheiros cheio são uma combinação que justifica abrir um ticket na mesma hora.

Ligando os sinais a um agente de métricas

Uma probe push responde sim ou não. Para analisar tendências, é necessário um agente de métricas, e o Prometheus node_exporter já exporta todos os dados acima sem configuração adicional. Os nomes das métricas que pode utilizar:

• node_filesystem_readonly passa para 1 quando um sistema de ficheiros é montado como somente leitura. Esse é o alerta de remontagem.
• node_filesystem_avail_bytes e node_filesystem_files_free abrangem, respetivamente, bytes e inodes.
• node_disk_io_time_seconds_total e node_disk_read_time_seconds_total fornecem o tempo ocupado e a latência como contadores que pode representar em gráficos.

Duas regras detetam os casos que realmente geram páginas:

- alert: FilesystemReadOnly
  expr: node_filesystem_readonly{fstype!~"tmpfs|overlay"} == 1
  for: 2m
- alert: FilesystemFillingUp
  expr: predict_linear(node_filesystem_avail_bytes{mountpoint="/"}[6h], 4*24*3600) < 0
  for: 30m

A segunda regra é acionada quando a tendência atual chega a zero no prazo de quatro dias. Assim, recebe um aviso com dias de antecedência, em vez de ser alertado quando o sistema de ficheiros está 95 por cento cheio e já só restam alguns minutos.

Quem é responsável por quê

O seu provedor é responsável pelos discos físicos. Ele lê os dados SMART, gere o array e substitui um disco com aumento de setores realocados, normalmente sem o informar, porque o array absorve a falha. É para isso que serve o RAID 10 no seu VPS: um disco avariado transforma-se numa reconstrução, e não numa interrupção. Não é possível ver nada disso, e pagar por essa abstração é precisamente uma das principais razões para alugar um servidor virtual.

Você é responsável pelos seus dados, e a telemetria dos discos também não os protegeria. Os eventos que realmente destroem dados de tenants são um rm acidental, uma implementação defeituosa, um intruso com a sua chave SSH e um incidente na plataforma que também afete o array. Os atributos SMART não preveem nenhum desses eventos.

Por isso, a proteção real de um tenant é um backup armazenado fora do servidor e uma restauração que você próprio tenha executado. Os snapshots do provedor são convenientes e ficam na mesma plataforma que o recurso protegido. É por isso que snapshots e backups são proteções diferentes. Agende um teste: uma vez por trimestre, restaure o backup mais recente num VPS novo, inicie a aplicação e registe quanto tempo demorou. Esse valor é o seu tempo real de recuperação. O primeiro teste é sempre mais demorado do que alguém previu.

Quando o SMART se aplica ao seu caso

Os guias que ensinam smartctl estão corretos e aplicam-se assim que o hardware é realmente seu:

• Um servidor dedicado ou bare metal, no qual sudo smartctl -a /dev/sda devolve a tabela completa de atributos e smartd pode enviar-lhe um email quando um atributo muda.
• Planos de armazenamento que disponibilizam um disco físico diretamente à máquina convidada. Os fornecedores documentam isto explicitamente, porque é uma vantagem comercial.
• Hardware que lhe pertence, em casa ou num espaço de rack que arrenda.
• Um disco ligado através de um controlador RAID, acessível com sudo smartctl -a -d megaraid,0 /dev/sda, ou uma caixa USB com -d sat.

Num NVMe real, sudo smartctl -a -d nvme /dev/nvme0 e sudo nvme smart-log /dev/nvme0n1 comunicam critical_warning e percentage_used diretamente a partir do disco. Num SATA real, os atributos que preveem falhas são Reallocated_Sector_Ct (5), Current_Pending_Sector (197), Offline_Uncorrectable (198) e Reported_Uncorrect (187). Se qualquer um deles deixar de ser zero, planeie a substituição. Os estudos em grande escala sobre discos continuam a chegar à mesma lista curta, e a maioria dos outros atributos é ruído.

Execute o daemon em vez de fazer verificações manuais.

sudo systemctl enable --now smartd
sudo smartctl -t short /dev/sda
sudo smartctl -l selftest /dev/sda

O log de autoteste deve mostrar Completed without error para a execução que acabou de iniciar. Ubuntu e Debian incluem /etc/smartd.conf com uma linha DEVICESCAN, atualizada em agosto de 2026, por isso o daemon deteta todos os discos que consegue ver e envia um email para root quando há uma alteração. Nada disso funciona num disco virtual, razão pela qual o restante deste guia existe.

FAQ

Por que o smartctl não funciona no meu VPS?

Porque o disco é virtual. Num guest KVM que usa virtio-blk, smartctl -a /dev/vda imprime /dev/vda: Unable to detect device type, porque um disco paravirtualizado não transporta um canal de comandos ATA ou SCSI por onde possa passar um pedido SMART. Num disco emulado, chega-se a um dispositivo cujo modelo mostra QEMU HARDDISK, sem dados SMART utilizáveis por trás. Dentro de um contentor, o smartctl é recusado diretamente por falta de CAP_SYS_RAWIO. Nenhum destes casos é uma configuração incorreta, e nenhum sinalizador -d os corrige.

Como sei se o disco do meu VPS está a falhar?

Monitorize os efeitos, não o hardware. Verifique sudo journalctl -k -p err -b à procura de linhas blk_update_request: I/O error e de Remounting filesystem read-only. Execute sudo dumpe2fs -h /dev/vda1 | grep -i 'error count' para encontrar erros que os logs já perderam. Acompanhe r_await de iostat -xdz 5 e compare-o com uma linha de base registada quando o sistema estava saudável. Num VPS, um erro de E/S normalmente indica um problema no armazenamento do host, não um disco prestes a falhar. Por isso, inclua-o num pedido de suporte com o timestamp e o setor afetado.

O que devo monitorizar para avaliar a saúde do disco do VPS?

Quatro alertas são suficientes. Uma montagem só de leitura, causada por node_filesystem_readonly == 1 ou por uma sonda de escrita que falhe. O espaço livre e os inodes livres a aproximarem-se de zero. Qualquer I/O error do kernel no último intervalo. Um heartbeat do servidor, para que o silêncio gere um alerta quando a máquina deixar de responder. Ignore tudo o que seja derivado do SMART, porque num disco virtual esses valores estão ausentes ou descrevem a emulação do hypervisor.

Por que o meu sistema de ficheiros foi remontado só de leitura?

O ext4 montado com errors=remount-ro faz isto deliberadamente quando encontra um erro de metadados: deixa de escrever em vez de continuar a agravar os danos. A causa aparece no log do kernel imediatamente antes da linha de remontagem, normalmente uma EXT4-fs error sobre um journal abortado depois de o dispositivo subjacente devolver um erro de E/S. Remontar como leitura-escrita sem verificar o sistema de ficheiros oculta o sintoma e mantém a causa. Recolha o log e, em seguida, verifique o sistema de ficheiros desmontado a partir do rescue mode com e2fsck -fy /dev/vda1.

Posso alguma vez ler dados SMART num servidor virtual?

Em casos específicos, sim. Servidores dedicados e bare metal fornecem atributos reais. O mesmo acontece com planos de armazenamento que disponibilizam um disco físico diretamente ao guest e com qualquer host que seja gerido por si. Algumas plataformas apresentam um controlador NVMe ao guest e nvme smart-log devolve um log. Por isso, execute primeiro sudo nvme id-ctrl /dev/nvme0: um número de modelo que identifique um serviço de armazenamento de rede significa que esses contadores vêm de um controlador de software. Mesmo quando um nó de passthrough expõe contadores reais numa máquina partilhada, eles descrevem hardware partilhado com outros tenants. Nesse caso, a única ação útil é abrir um pedido de suporte.