Aquele comando uptime mostra 400 days. Ou 800 days. Talvez até 1,200 dias.
Você se sente orgulhoso. Seu servidor parece um rockstar.
Mas aqui está a verdade que só os apagões em produção ensinam: um uptime alto muitas vezes esconde mais problemas do que resolve.
Já vi servidores com dois anos de uptime falharem completamente após uma simples reinicialização. O número alto no era sinal de saúde. Era sinal de que noguém olhou de perto por um bom tempo.
Então, deixe-me compartilhar uma lista de verificação completa de saúde para servidores Linux. Da próxima vez que você vir um servidor com uptime alto, execute estas 25 verificações. Algumas são rápidas. Outras levam um minuto. Mas, juntas, elas revelam o que realmente está acontecendo sob a superfície.
Parte 1: Recursos do Sistema (O Básico que Engana)
Essas métricas parecem boas na superfície. Mas um uptime alto esconde uma deterioração lenta por baixo.
1. Observe a média de carga de 15 minutos em relação à contagem de CPUs
Execute os seguintes comandos:
uptime
nproc
Você verá três números: 1 minuto, 5 minutos e 15 minutos. Uma tendência de carga crescente é mostrada quando o número de 1 minuto é maior que o de 15 minutos — a carga está se acumulando mais rápido do que é limpa. O inverso (15 minutos maior que 1 minuto) significa que a carga está diminuindo em relação a um pico passado.
A questão real, no entanto, no é comparar os três números entre si. É comparar qualquer um desses números com a contagem de núcleos da sua CPU. Se a média de 15 minutos exceder consistentemente o número de CPUs retornado por nproc, seu sistema está saturado e o trabalho está enfileirando mais rápido do que pode ser processado.
O que verificar: Se a carga de 1 minuto for maior que a de 15 minutos, a carga está em tendência de alta. Se qualquer média exceder consistentemente a contagem de núcleos da CPU, você tem um problema de saturação. Compare os três números juntos para obter informações de tendência, mas sempre os ancore na contagem de núcleos.
2. Verifique a memória available, no a memória free
Execute o seguinte comando:
free -h
Olhe para a coluna available. Ignore free.
total used free shared buff/cache available
Mem: 30Gi 8.7Gi 16Gi 1.2Gi 7.2Gi 22Gi
Swap: 975Mi 0B 975Mi
Memória available é o que o sistema pode realmente dar a novos processos sem usar swap. Se esse número continuar caindo semana após semana, você tem um vazamento de memória lento.
O que verificar: Anote a memória available hoje. Verifique novamente em uma semana. Está menor?
3. Conte os processos zumbis
Execute estes comandos:
top -bn1 | grep "zombie"
Ou verifique a contagem de zumbis diretamente:
ps aux | awk '$8=="Z" {print $0}' | wc -l
Ou
ps -eo stat= | grep -c '^Z'
Um zumbi no é noda. Alguns são nocetáveis. Mas mais de dez zumbis que persistem por dias? Isso é um problema real. Cada zumbi ocupa um slot na tabela de processos. Encha essa tabela, e noda de novo pode ser executado. Sem novas sessões SSH. Sem novas verificações de monitoramento. Nada.
O que verificar: A contagem de zumbis deve ser zero na maioria das vezes. Alguns aqui e ali são ok. Zumbis persistentes no são.
Zumbis em excesso podem eventualmente esgotar os IDs de processo available ou os recursos da tabela de processos.
4. Verifique o uso de inodes, no apenas o espaço em disco
Execute isto:
df -i
O espaço em disco recebe toda a atenção. Mas os inodes (as estruturas de dados que armazenam informações de arquivos) podem acabar mesmo quando você tem bastante espaço. Quando isso acontece, você no consegue criar novos arquivos. Logs param de escrever. Serviços falham silenciosamente.
O que verificar: Procure por qualquer partição com IUse% acima de 85%. Esse é o seu sinal de alerta.
udev 4041811 635 4041176 1% /dev
tmpfs 4060692 1209 4059483 1% /run
/dev/nvme0n1p2 30433280 2949390 27483890 10% /
tmpfs 4060692 434 4060258 1% /dev/shm
tmpfs 4060692 16 4060676 1% /run/lock
efivarfs 0 0 0 - /sys/firmware/efi/efivars
/dev/nvme0n1p1 0 0 0 - /boot/efi
tmpfs 812138 268 811870 1% /run/user/1000
/dev/sda1 0 0 0 - /media/ostechnix/SK_WD_SSD
/dev/fuse 262144 40 262104 1% /etc/pve
5. Verifique processos presos em sono ininterrupto (estado D)
Execute isto:
ps aux | awk '$8=="D" {print $0}'
Processos no estado D estão esperando diretamente por hardware. Eles no podem ser mortos. Nem mesmo com -9. Alguns poucos são normais durante I/O de disco pesado. Mas se eles persistirem por mais de alguns minutos, algo está muito errado com seu subsistema de armazenamento.
O que verificar: Zero processos presos no estado D é o objetivo. Processos D persistentes geralmente indicam problemas de armazenamento, sistema de arquivos ou sistemas de arquivos montados em rede.
6. Procure por eventos do OOM Killer nos logs
Execute estes:
sudo dmesg | grep -i -E "killed process|out of memory|oom"
journalctl -k | grep -iE "oom|out of memory|killed process"
O OOM Killer é o último recurso do Linux. Quando a memória acaba completamente, o kernel começa a matar processos para se manter vivo. Isso nunca é um bom sinal. Em um servidor com uptime alto, você pode encontrar eventos OOM de meses atrás que você nunca notou.
O que verificar: Qualquer evento do OOM Killer significa que você teve um problema de memória. Um evento é um aviso. Múltiplos eventos significam que você tem um padrão.
Parte 2: Disco e Sistema de Arquivos (Onde o Apodrecimento Acontece)
Servidores com uptime alto geralmente apodrecem de fora para dentro, a partir do sistema de arquivos. Essas verificações detectam esse apodrecimento cedo.
7. Encontre os maiores arquivos de log
Execute estes:
find /var/log -type f -size +100M -exec ls -lh {} \;
du -sh /var/log/* | sort -hr | head -10
Arquivos de log crescem para sempre se a rotação de logs quebrar. E a rotação de logs quebra mais vezes do que você imagina. Um único trabalho cron mal configurado ou uma alteração de permissão de seis meses atrás pode parar toda a rotação de logs silenciosamente.
O que verificar: Qualquer arquivo de log único acima de 1GB precisa de investigação. Acima de 10GB já é um incidente. Em outras palavras, crescimento inesperado, independentemente do tamanho, justifica investigação.
8. Verifique se o logrotate está realmente funcionando
Execute estes:
logrotate --debug /etc/logrotate.conf 2>&1 | head -30
journalctl -u logrotate --since "30 days ago" 2>/dev/null | grep -i "error\|fail"
grep -i "logrotate" /var/log/syslog 2>/dev/null | grep -i "error\|fail" | tail -10
A rotação de logs pode falhar sem que noguém perceba. O trabalho cron é executado. O comando termina. Mas problemas de permissão ou diretórios ausentes causam falhas silenciosas. Em um servidor com uptime alto, a rotação de logs pode estar quebrada há anos.
Nota: o logrotate no escreve em um arquivo /var/log/logrotate.log dedicado por padrão em nonhuma distribuição importante. Seu estado é rastreado em /var/lib/logrotate/status e/ou /var/lib/logrotate/logrotate.status. Quaisquer erros que encontrar podem aparecer no journal do sistema ou no syslog, que é onde o segundo e o terceiro comandos procuram.
O que verificar: A saída de depuração deve mostrar cada arquivo de log sendo processado sem erros. Verifique /var/lib/logrotate/status e/ou /var/lib/logrotate/logrotate.status, dependendo da distribuição, para confirmar os carimbos de data/hora de rotação recentes para arquivos de log críticos.
9. Teste cada montagem NFS ou de rede
Execute estes:
mount | grep -E "nfs|nfs4|cifs"
for mount in $(mount | grep -E "nfs|nfs4|cifs" | awk '{print $3}'); do
timeout 5 ls $mount > /dev/null 2>&1
if [ $? -ne 0 ]; then
echo "STALE: $mount"
fi
done
Montagens NFS obsoletas são insidiosas. O servidor permanece no ar. A montagem parece fine. Mas qualquer processo que toque nessa montagem trava por 60 segundos ou mais. Servidores com uptime alto acumulam essas lentamente, e cada montagem obsoleta adiciona latência a tudo que a verifica.
O que verificar: Cada montagem de rede deve responder a ls em menos de 2 segundos. Travamentos significam montagens obsoletas.
Você também pode usar este comando:
mount | grep -E "nfs|nfs4|cifs" | while read -r line; do
mountpoint=$(echo "$line" | awk '{print $3}')
timeout 5 ls "$mountpoint" >/dev/null 2>&1
done
10. Verifique os tempos de espera de I/O do disco
Execute isto:
iostat -x 1 5
Olhe para a coluna %iowait e a coluna await.
Um iowait alto significa que sua CPU está gastando tempo esperando pelos discos. No entanto, o iowait sozinho pode ser enganoso em sistemas multi-core — um único processo vinculado a I/O em uma máquina com 32 núcleos pode saturar um disco enquanto mal aparece no iowait. Sempre correlacione com o valor await por dispositivo em iostat -x.
A coluna await mostra o tempo médio em milissegundos desde quando uma solicitação de I/O foi submetida até quando foi concluída. Sob carga de produção, valores acima de 20ms em SSDs SATA ou acima de 5ms em unidades NVMe merecem investigação. Tenha em mente que, sob carga leve, unidades NVMe modernas normalmente operam bem abaixo de 1ms e SSDs SATA abaixo de 2ms. Qualquer pico sustentado acima desses limites sob carga aponta para saturação do dispositivo ou degradação de hardware.
O que verificar: D confie em um único número %iowait. Use iostat -x para verificar os valores de await por dispositivo e procure por dispositivos se aproximando de 100% de %util. Correlacione com os tempos de resposta da aplicação para julgar se os números refletem um gargalo real para sua carga de trabalho.
11. Procure por arquivos com bits SUD/SGD definidos
Execute isto:
find / -perm /6000 -type f 2>/dev/null | grep -v "^/proc"
Os bits SUD e SGD permitem que programas sejam executados com privilégios elevados. Um pequeno conjunto deles é esperado em qualquer sistema — /bin/su, /usr/bin/passwd, /usr/bin/sudo e /usr/bin/newgrp são exemplos comuns. Mas com o tempo, novos podem aparecer. Software antigo pode adicioná-los. Configurações incorretas podem criá-los. Em um servidor com uptime alto, estes podem se acumular sem que noguém perceba.
Nota: em distribuições Linux modernas, alguns binários que antes exigiam SUD (como ping) foram migrados para usar capacidades do Linux. Se você vir um binário com SUD que no espera — mesmo um familiar — vale a pena confirmar contra o pacote padrão da distribuição.
O que verificar: Revise a lista. Qualquer coisa desconhecida precisa de investigação.
12. Encontre arquivos e diretórios graváveis por todos
Execute isto:
find / -type f -perm -0002 -ls 2>/dev/null | grep -v "^/proc"
Arquivos graváveis por todos são um risco de segurança. Qualquer usuário no sistema pode modificá-los. Em um servidor movimentado com muitos usuários, um arquivo de configuração gravável por todos pode levar à escalação de privilégios.
Diretórios graváveis por todos são frequentemente mais perigosos que arquivos. Execute isto para verificar diretórios também:
find / -type d -perm -0002 -ls 2>/dev/null
O que verificar: A lista deve ser muito curta. Arquivos de log do sistema às vezes são legíveis por todos, mas raramente graváveis por todos. Qualquer coisa em /etc ou /usr nunca deve ser gravável por todos.
Parte 3: Processos e Serviços (O Caos em Execução)
Um servidor com uptime alto pode acumular processos bagunçados como uma geladeira acumula comida velha.
13. Procure por processos com tempos de execução muito longos
Execute isto:
ps -eo pid,etime,comm,args --sort=-etime | head -20
Processos que estão em execução há meses podem estar fines. Ou podem estar travados, vazando memória ou no fazendo nada útil. Em um servidor com uptime alto, você frequentemente encontra scripts antigos que deveriam ter terminado, mas no o fizeram.
O que verificar: Para cada processo antigo, pergunte: Isso ainda deveria estar em execução? Dele precisa estar em execução? Pode ser reiniciado de forma limpa?
14. Verifique se há jobs cron sobrepostos
Execute isto:
# User-level crontabs
for user in $(cut -f1 -d: /etc/passwd); do
crontab -u $user -l 2>/dev/null
done
# System-level cron locations (these are where most production jobs actually live)
cat /etc/crontab
ls -la /etc/cron.d/
ls -la /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ /etc/cron.hourly/
Um job cron que leva 15 minutos para ser executado, mas é executado a cada 10 minutos, cria processos sobrepostos. Com o tempo, estes se acumulam. O sistema permanece no ar, mas funciona pior a cada dia. Um uptime alto esconde perfeitamente esses erros de agendamento.
Em servidores de produção, a maioria dos jobs agendados vive em /etc/cron.d/, /etc/crontab e nos diretórios cron.daily/weekly/monthly/hourly — no em crontabs de usuário. Verificar apenas crontabs de usuário perde a maioria do trabalho agendado em um servidor típico.
O que verificar: Procure por jobs que são executados com mais frequência do que levam para serem concluídos. Adicione registro em log para ver os tempos de execução reais.
15. Verifique o status dos serviços do systemd
Execute estes:
systemctl list-units --state=failed
systemctl list-units --state=inactive --all | grep -v "not-found"
Serviços com falha são óbvios. Mas serviços que pararam "com sucesso" quando deveriam estar em execução são mais difíceis de detectar. Em um servidor com uptime alto, um serviço crítico pode ter parado há meses sem que noguém percebesse.
O que verificar: Todo serviço que deveria estar em execução deve mostrar active (running). Qualquer coisa diferente precisa de uma razão.
Nota: Sistemas grandes podem ter centenas de unidades intencionalmente inativas. Revise apenas os serviços que se espera que estejam ativos.
16. Procure por serviços que ficam reiniciando
Execute isto:
# Find services with automatic restart counts above zero
systemctl list-units --type=service --state=running --no-pager | awk '{print $1}' | \
xargs -I{} sh -c 'count=$(systemctl show {} -p NRestarts 2>/dev/null | cut -d= -f2); \
[ "$count" -gt 0 ] 2>/dev/null && echo "NRestarts=$count {}"'
# Confirm with journal history for any service you find
journalctl -u service-name --since "7 days ago" | grep -E "Started|Stopped|Failed" | tail -20
Alguns serviços falham e reiniciam constantemente. O sistema os mantém "em execução" de certa forma. Mas reinicializações constantes significam que algo está quebrado. Em um servidor com uptime alto, isso pode continuar por meses sem que noguém olhe os logs.
A distinção chave: systemctl list-units --state=activating só mostra serviços atualmente no meio de uma inicialização no momento em que você executa o comando — ele no mostrará um serviço que falha e se recupera rapidamente. A propriedade NRestarts é o que realmente registra quantas vezes o systemd teve que reiniciar um serviço automaticamente, e ela persiste através desses ciclos de recuperação rápida.
O que verificar: Qualquer serviço com NRestarts acima de zero merece uma olhada. Faça referência cruzada com o journal para ver com que frequência ele está realmente falhando e qual erro ele registra antes de cada reinicialização. Além disso, investigue serviços com contagens de reinicialização inesperadamente altas ou em aumento constante.
17. Verifique se há timers com falha (substituto do cron do systemd)
Execute isto:
systemctl list-timers --all
Timers do systemd podem falhar silenciosamente. O timer é executado. O comando termina com um código de erro. Mas no alerta é disparado. Ao longo de meses, um timer de backup com falha significa no backups. Um timer de rotação de logs com falha significa discos cheios.
A flag --all sem nonhum filtro de estado é a abordagem correta aqui. Ela mostra todos os timers junto com seus horários de LAST e NEXT em uma única visualização. Filtrar por --state=waiting ou --state=running pode esconder timers que estão em estados inesperados, que é exatamente o que você está tentando encontrar.
O que verificar: Todo timer deve mostrar uma coluna LAST preenchida. Qualquer timer com uma coluna LAST vazia no foi executado com sucesso. Qualquer timer com uma data LAST muito mais antiga que seu intervalo configurado parou silenciosamente de funcionar.
Parte 4: Segurança (O Acúmulo Silencioso)
Problemas de segurança se acumulam lentamente em servidores com uptime alto. Essas verificações encontram o que os atacantes amam.
18. Verifique atualizações de segurança pendentes
Execute isto (Debian/Ubuntu):
apt list --upgradable 2>/dev/null | grep -i security
Em sistemas Ubuntu, também existe um comando dedicado para este propósito:
ubuntu-security-status
Execute isto (RHEL/CentOS/Rocky):
dnf updateinfo list --security
Um servidor com uptime alto geralmente significa no reboots. E no reboots geralmente significa no atualizações de kernel. E no atualizações de kernel significa que vulnerabilidades conhecidas permanecem sem correção por meses ou anos.
O que verificar: Atualizações de segurança pendentes devem ser aplicadas em dias, no em meses. Atualizações de kernel exigem reboots. Essa é a verdade dura.
19. Revise as tentativas de login SSH com falha
Execute estes:
sudo grep "Failed password" /var/log/auth.log 2>/dev/null || sudo grep "Failed password" /var/log/secure
sudo lastb | head -20
Muitos sistemas modernos armazenam logs de autenticação SSH apenas no journald. Nesses sistemas, você pode usar:
journalctl -u ssh
Ou,
journalctl -u sshd
Tentativas de SSH com falha mostram ataques de força bruta. Em um servidor com uptime alto exposto à internet, você pode ver milhares de tentativas de todo o mundo. Isso é ruído normal. Mas um pico repentino ou logins bem-sucedidos de IPs estranhos no é.
O que verificar: Procure por logins bem-sucedidos de IPs inesperados. Procure por padrões de tentativas com falha do mesmo IP.
20. Verifique se há contas de usuário no autorizadas
Execute estes:
grep -E "sh$|bash$" /etc/passwd
lastlog | grep -v "Never logged in"
Para shells que no sejam bash, você pode usar este comando:
getent passwd | awk -F: '$7 !~ /(nologin|false)$/'
Contas de usuário se acumulam com o tempo. Contratados saem. Administradores antigos vão embora. Mas suas contas às vezes ficam. Em um servidor com uptime alto, você pode encontrar contas que estão inativas há anos.
O que verificar: Todo usuário com acesso a shell de login deve ser autorizado e ativo. Dabilite ou remova o resto.
21. Verifique a segurança da configuração do SSH
Execute isto:
sshd -T | grep -E "permitrootlogin|passwordauthentication"
Login root com senha é perigoso. Autenticação por senha pela internet é arriscada. Em um servidor antigo com uptime alto, você pode encontrar configurações SSH desatualizadas que no foram atualizadas.
O que verificar: PermitRootLogin deve ser prohibit-password ou no. PasswordAuthentication deve ser no se você usa chaves. Nota: a antiga diretiva Protocol foi removida no OpenSSH 7.6 (2017) porque o SSHv2 é agora o único protocolo suportado — você no precisa verificar isso. Sistemas modernos impõem SSHv2 sem nonhuma diretiva de configuração.
22. Escaneie portas abertas que você no esperava
Execute estes:
ss -tulpn | grep LISTEN
nmap -sT -p- localhost 2>/dev/null
Servidores com uptime alto frequentemente acumulam serviços ao longo dos anos. Alguém instalou um banco de dados para um teste. Alguém iniciou um servidor web de depuração. Então todos esqueceram. Esses serviços esquecidos são alvos de ataque perfeitos.
O que verificar: Toda porta aberta deve ter um propósito documentado. Portas desconhecidas significam serviços desconhecidos.
23. Verifique se há rootkits
Instale se ainda no estiver presente (Debian/Ubuntu):
sudo apt install rkhunter chkrootkit
Instale se ainda no estiver presente (RHEL/CentOS/Rocky):
sudo dnf install rkhunter chkrootkit
Nota: A disponibilidade do pacote
chrootkitdepende da distribuição e dos repositórios habilitados. Verifique a documentação oficial da sua distribuição.
Em seguida, execute:
sudo rkhunter --check --skip-keypress
sudo chkrootkit
Rootkits são raros. Mas em um servidor com uptime alto que no foi examinado de perto em anos, vale a pena verificar.
Entenda o que essas ferramentas podem e no podem fazer antes de confiar em sua saída. Tanto o rkhunter quanto o chkrootkit são executados usando os próprios binários do sistema — binários que um rootkit sofisticado pode ter substituído. Um resultado limpo é um sinal fraco, no uma garantia. Ambas as ferramentas também geram falsos positivos significativos em sistemas modernos, particularmente o rkhunter em distribuições que atualizam pacotes com frequência. Cada aviso requer verificação manual antes de tirar conclusões.
Para uma garantia mais forte, considere um monitor de integridade de arquivos adequado, como AIDE ou Tripwire, que compara arquivos contra uma linha de base criptográfica obtida quando o sistema era conhecido por estar limpo.
O que verificar: Qualquer aviso do rkhunter ou chkrootkit precisa de investigação, mas espere falsos positivos. Verifique cada achado manualmente. D trate uma varredura limpa como um atestado de saúde.
Parte 5: Monitoramento e Validação (Os Sistemas que Vigiam)
Você no pode confiar em um monitoramento que está silencioso há 400 days. Essas verificações verificam os próprios vigilantes.
24. Verifique se seus alertas de monitoramento estão realmente funcionando
Execute estes:
# Check when the last alert was sent
grep "ALERT" /var/log/monitoring.log | tail -5
# Simulate a test alert
/usr/local/bin/send_test_alert.sh
Essa verificação dói. Já vi isso muitas vezes. Um servidor mostra 500 days de uptime. O painel de monitoramento parece verde. Então você descobre que o script de alerta parou de funcionar há 400 days. O disco encheu. A CPU superaqueceu. Mas noguém recebeu um único alerta.
Por favor, note que esses caminhos são apenas exemplos. Substitua-os pelos seus caminhos reais.
O que verificar: Quando foi o último alerta real deste servidor? Você pode disparar um alerta de teste agora mesmo? Dlguém o recebe?
25. Faça a pergunta da reinicialização (a mais importante)
Isso no é um comando. Isso é uma conversa.
Pergunte em voz alta: Se reiniciarmos este servidor agora mesmo, ele volta exatamente como deveria?
Dele todo serviço inicia corretamente? Todas as montagens estão presentes? A configuração de rede está correta? A aplicação sobe sem intervenção manual?
Se a resposta for "provavelmente" ou "no temos certeza" ou "deixe-me verificar o runbook", então o uptime é apenas um número. no é confiabilidade. no é segurança. É apenas sorte.
O que verificar: Teste uma reinicialização em um ambiente de staging. Ou agende uma durante uma janela de manutenção. A confiança real vem da prática, no de um contador.
Conclusão
Um uptime longo no é uma medalha de honra. É um ponto de dados.
Um servidor com 30 days de uptime e verificações de saúde regulares é mais seguro do que um servidor com 800 days de uptime e no validação. A pergunta no é "há quanto tempo isso está rodando?" A pergunta é "como sabemos que está funcionando corretamente?"
Execute esta lista de verificação uma vez por mês. no porque você espera encontrar problemas. Mas porque os problemas que você no encontra são os que eventualmente te derrubam.
O que vem a seguir
Você encontra a causa raiz, e agora? Antes de solucionar qualquer sistema Linux, execute um pequeno conjunto de comandos somente leitura para capturar o estado atual do sistema antes que qualquer intervenção perturbe as evidências. Compilamos uma lista de comandos recomendados para solução de problemas no link abaixo.
Esse guia explica o que verificar em um sistema Linux antes de tocar em qualquer coisa.
