← Guia Completo: Diagnóstico de Desempenho em VMs Linux

🐧 Componente: Kernel, Logs e Sistema. O dmesg e os logs de sistema são frequentemente o primeiro lugar onde aparecem sinais de problemas — antes de qualquer queixa do utilizador. Este artigo cobre como filtrar eficientemente os logs mais relevantes, ajustar parâmetros de kernel e usar o atop para análise histórica.

1. dmesg — Mensagens do Kernel

# Mensagens recentes do kernel com timestamps
dmesg -T | tail -50

# Filtrar apenas erros e avisos
dmesg -T --level=err,warn

# Erros de disco, filesystem e controladores de armazenamento
dmesg -T | grep -E 'error|fail|warn|I/O|EXT4|XFS|BTRFS|ata|sd[a-z]|nvme' -i | tail -30

# Seguir mensagens em tempo real
dmesg -Tw
💡 Primeiro passo: Após qualquer evento de lentidão repentina, o dmesg -T --level=err,warn | tail -30 deve ser o primeiro comando a executar — regista erros de driver, hardware, OOM Killer e problemas de rede ao nível do kernel, muitas vezes com o timestamp exato do incidente.

Padrões críticos a identificar no dmesg

Padrão no dmesg Significado Ação
oom-kill / killed process OOM Killer eliminou processo por falta de RAM Aumentar RAM ou otimizar consumo
I/O error / blk_update_request Erro de leitura/escrita em disco Verificar SMART e fsck
EXT4-fs error / XFS error Erro de filesystem Verificar e reparar filesystem
NVRM / nvidia / drm error Erro de driver gráfico ou de dispositivo Atualizar driver
TCP: out of memory Memória de rede esgotada Ajustar net.ipv4.tcp_mem
WARN_ON / BUG / kernel panic Erro crítico de kernel Atualizar kernel ou abrir bug report
nf_conntrack: table full Tabela de conexões do firewall cheia Aumentar nf_conntrack_max

2. journalctl — Logs Centralizados (systemd)

# Logs das últimas 2 horas
journalctl --since '2 hours ago' --no-pager

# Apenas erros e críticos (mais útil para triagem)
journalctl -p err -n 50 --no-pager

# Logs do arranque atual
journalctl -b

# Logs do arranque anterior (falha/crash)
journalctl -b -1

# Logs em tempo real do sistema inteiro
journalctl -f

# Espaço ocupado pelos logs
journalctl --disk-usage

# Limpar logs com mais de 30 dias
journalctl --vacuum-time=30d
💡 journalctl -b -1: Ver os logs do arranque anterior é especialmente útil quando o sistema reiniciou inesperadamente — permite ver o que estava a acontecer imediatamente antes do crash sem precisar de um dump de kernel.

3. Logs Clássicos por Distribuição

# Debian / Ubuntu
tail -f /var/log/syslog
tail -f /var/log/kern.log
tail -f /var/log/auth.log

# RHEL / CentOS / Rocky Linux
tail -f /var/log/messages
tail -f /var/log/secure

# Pesquisar erros críticos (ambas as distros)
grep -E 'error|critical|fail|panic|oops|segfault' /var/log/syslog -i | tail -30
grep -E 'error|critical|fail|panic|oops|segfault' /var/log/messages -i | tail -30

4. Parâmetros sysctl — Ajuste de Kernel

# Ver parâmetros críticos de memória e swap
sysctl vm.swappiness         # default: 60 — reduzir para 10 em servidores
sysctl vm.dirty_ratio         # % RAM que pode estar dirty antes de forçar escrita
sysctl vm.dirty_background_ratio  # % RAM para iniciar escrita em background

# Ver parâmetros de rede relevantes
sysctl net.ipv4.tcp_syn_retries
sysctl net.ipv4.tcp_fin_timeout
sysctl net.core.somaxconn

# Parâmetros de kernel
sysctl kernel.panic           # segundos até reboot após panic (0 = não reiniciar)
sysctl kernel.dmesg_restrict  # controla acesso ao dmesg por utilizadores não-root
# Alterações temporárias (perdem-se após reboot)
sysctl -w vm.swappiness=10

# Alterações permanentes
echo 'vm.swappiness=10'           >> /etc/sysctl.conf
echo 'vm.dirty_ratio=15'          >> /etc/sysctl.conf
echo 'vm.dirty_background_ratio=5' >> /etc/sysctl.conf

# Aplicar alterações sem reboot
sysctl -p
⚠️ Cuidado com ajustes de sysctl em produção: Alguns parâmetros podem ter efeitos colaterais significativos. Testar em ambiente de desenvolvimento antes de aplicar em produção. Documentar todas as alterações e o motivo.

5. atop — Monitor Histórico Completo

# Instalar: apt install atop  /  yum install atop

# Monitorização em tempo real (interface interativa)
atop

# Ler dados históricos do dia de hoje
atop -r /var/log/atop/atop_$(date +%Y%m%d)

# Ler dados de ontem
atop -r /var/log/atop/atop_$(date -d yesterday +%Y%m%d)

# Extrair dados de CPU dos registos históricos
atop -r /var/log/atop/atop_$(date +%Y%m%d) -P CPU

Dentro do atop interativo, teclas úteis:

  • c — ordenar por CPU
  • m — ordenar por memória
  • d — ordenar por I/O de disco
  • n — ordenar por rede
  • b — recuar no tempo (nos dados históricos)
  • t — avançar no tempo
💡 Caso de uso: O utilizador diz “ontem às 14h o sistema estava impossível de usar”. Com atop -r /var/log/atop/atop_$(date -d yesterday +%Y%m%d), é possível “rebobinar” para as 14h e ver exactamente o que estava a acontecer — CPU, memória, disco e rede nesse momento exacto.

6. Verificação de Integridade do Sistema

# Debian / Ubuntu — verificar pacotes corrompidos
dpkg --verify 2>&1 | grep -v '^$'

# RHEL / CentOS / Rocky — verificar integridade de RPMs
rpm -Va 2>&1 | grep -v '^$' | head -20

# Verificar agendamentos cron ativos
crontab -l
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/

# Atividade recente de login
last | head -20
lastlog | grep -v 'Never logged'

# Comandos recentes com sudo
grep sudo /var/log/auth.log | tail -20       # Debian/Ubuntu
grep sudo /var/log/secure | tail -20         # RHEL/Rocky

7. Checklist — Kernel, Logs e Sistema

  • ✅ dmesg -T --level=err,warn | tail -30 — erros de kernel recentes?
  • ✅ dmesg -T | grep -i oom — OOM Killer ativado?
  • ✅ journalctl -p err -n 50 — erros no sistema nas últimas horas?
  • ✅ journalctl -b -1 — logs do arranque anterior (se houve crash)?
  • ✅ sysctl vm.swappiness — configuração adequada para o workload?
  • ✅ ls /etc/cron.d/ — cron jobs ativos na janela temporal do problema?
  • ✅ atop com dados históricos — estado do sistema no momento exato do problema?
← Processos e Serviços
Próximo: Ferramentas Avançadas →

Este artigo foi útil?

Duarte Spínola

Artigos  

Deixe um Comentário