Como monitorizar o desempenho de um servidor Linux: comandos, métricas e ferramentas

Para monitorizar o desempenho de um servidor Linux, verifique quatro recursos: CPU, memória, E/S de disco e rede. Use comandos nativos como top, vmstat, free, iostat e ss para diagnósticos em tempo real, e uma ferramenta baseada em agente, como o Prometheus com node_exporter, o Zabbix ou o agente CloudWatch, para guardar o histórico e enviar alertas.

Pontos principais

• Para cada recurso, verifique a utilização, a saturação e os erros (o método USE). Uma utilização elevada, por si só, não é um problema; as filas e os erros são.
• Compare a carga média (load average) com o número de núcleos de CPU e vigie %wa (espera de E/S) e %st (steal time) em VM na cloud.
• Quanto à memória, leia a coluna available do free, e não free. O Linux usa a memória livre como cache de propósito.
• A informação de pressão (pressure stall information) em /proc/pressure/ mostra diretamente quanto tempo as tarefas esperam por CPU, memória ou E/S.
• Os comandos mostram o presente. Para tendências e alertas precisa de um agente de monitorização e de um armazenamento de séries temporais.

Que métricas de desempenho do Linux importam?

Comece pelo método USE do engenheiro de desempenho Brendan Gregg: para cada recurso, verifique a utilização, a saturação e os erros. Dá-lhe uma lista de verificação em vez de palpites.

Como verificar a utilização de CPU e a carga no Linux?

Execute top (ou htop) e leia a linha de CPU; depois compare a carga média com o número de núcleos indicado por nproc.

top # vista em tempo real; prima 1 para mostrar cada núcleo
nproc # número de núcleos de CPU
uptime # carga média a 1, 5 e 15 minutos
mpstat -P ALL 1 # utilização por núcleo a cada segundo (pacote sysstat)

Segundo a página de manual proc_loadavg, a carga média conta os trabalhos que estão em execução ou à espera de E/S de disco, em média ao longo de 1, 5 e 15 minutos. Uma carga de 6 num servidor de 8 núcleos está bem. Uma carga de 6 num servidor de 2 núcleos significa que há trabalho em fila. Como a carga inclui processos à espera de disco, uma carga elevada com pouca utilização de CPU aponta normalmente para um problema de armazenamento.

Na linha de CPU do top, dois campos importam em servidores na cloud:

• wa: tempo em que o CPU esteve inativo à espera de E/S. Valores elevados e persistentes apontam para discos lentos ou armazenamento em rede.
• st: segundo a página de manual do top, "time stolen from this vm by the hypervisor" (tempo roubado a esta VM pelo hypervisor). Um steal persistente numa VM na cloud significa que o anfitrião está ocupado ou que uma instância burstable ficou sem créditos de CPU.

Como verificar a utilização de memória no Linux?

Execute free -h e leia a coluna available. A página de manual do free define-a como uma estimativa da memória disponível para novas aplicações sem recorrer a swap, tendo em conta a cache de páginas.

free -h # resumo da memória em formato legível
vmstat 1 5 # as colunas si/so mostram swap in/out por segundo
journalctl -k | grep -i "out of memory" # eventos do OOM killer

Um servidor com pouca memória "livre" mas muita memória "disponível" está saudável: o Linux preenche a RAM sobrante com cache de disco e liberta-a quando os programas precisam. Os sinais de alerta são a memória available a descer ao longo de dias (uma possível fuga), atividade de swap constante no vmstat e entradas do OOM killer no registo do kernel.

Como verificar o desempenho e o espaço em disco?

Use iostat -xz 1 para o desempenho de E/S e df para o espaço e os inodes.

iostat -xz 1 # utilização, fila e latência por dispositivo (sysstat)
df -h # espaço em disco por sistema de ficheiros
df -i # utilização de inodes: muitos ficheiros pequenos podem esgotá-los primeiro
du -sh /var/log/* | sort -h # descobrir o que está a ocupar espaço

No iostat, vigie r_await e w_await (milissegundos médios por pedido) e aqu-sz (comprimento da fila). A página de manual do iostat refere que, em dispositivos que servem pedidos em paralelo, como matrizes RAID e SSD modernos, o %util não reflete os seus limites de desempenho. O aumento da latência e do comprimento da fila são melhores indicadores de saturação.

Como monitorizar o desempenho da rede?

sar -n DEV 1 # débito por interface
sar -n TCP,ETCP 1 # ligações TCP e retransmissões
ss -s # resumo de sockets
ip -s link # erros e descartes por interface

Retransmissões, descartes ou erros de interface em aumento indicam problemas de rede mesmo quando o débito parece normal. Em VM na cloud, compare o débito com o limite de rede do tipo de instância.

O que é a pressure stall information (PSI)?

A PSI é uma funcionalidade do kernel que indica quanto tempo as tarefas passam à espera de CPU, memória ou E/S. A documentação do kernel explica que cada ficheiro em /proc/pressure/ tem uma linha "some" (a percentagem de tempo em que pelo menos algumas tarefas estão bloqueadas) e, para memória e E/S, uma linha "full" (todas as tarefas não inativas bloqueadas em simultâneo, o que o kernel descreve como thrashing).

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

A PSI responde diretamente à pergunta "este recurso está a atrasar o trabalho?", o que a torna um bom sinal de alerta. Se os ficheiros não existirem, o seu kernel foi compilado ou iniciado sem suporte para PSI.

Que ferramentas usar para monitorização contínua?

Os comandos mostram o que acontece agora. Para detetar problemas durante a noite, ver tendências e alertar a pessoa certa, instale um agente de monitorização que envie métricas para um armazenamento de séries temporais.

Que alertas definir primeiro?

1. Espaço em disco e inodes acima de 80–85% em qualquer sistema de ficheiros, com um alerta de previsão para "cheio em 24 horas".
2. Memória disponível baixa durante mais de 10 minutos, ou qualquer evento do OOM killer.
3. Carga média acima do número de núcleos durante mais de 15 minutos, ou pressão de CPU a aumentar.
4. Latência de disco ou pressão de E/S muito acima da referência normal do servidor.
5. Verificações de serviço: a porta da aplicação responde e um URL de estado devolve sucesso.
6. Cópias de segurança e expiração de certificados, que falham em silêncio.

Estes limiares são pontos de partida. Ajuste-os ao comportamento normal de cada servidor, para que os alertas continuem a ser acionáveis. O nosso guia sobre monitorização do desempenho de servidores abrange o Windows e as boas práticas gerais, e monitorização de infraestrutura cloud abrange os serviços geridos para lá do servidor.

Como a Opsio ajuda

A Opsio monitoriza e opera servidores Linux na AWS, no Azure e on-premises no âmbito dos nossos serviços de TI geridos, incluindo resposta a alertas 24/7, aplicação de patches e revisões de capacidade, com Prometheus e Grafana ou ferramentas nativas da cloud. Por exemplo, a plataforma AWS que construímos para a WorkBuster corre em instâncias EC2 num grupo de auto-scaling, com dashboards e alarmes CloudWatch para as operações diárias.

Perguntas frequentes

Qual é o melhor comando para verificar o desempenho de um servidor Linux?

Comece com top para uma visão geral em tempo real, depois vmstat 1 para tendências de CPU, memória e swap, e iostat -xz 1 para os discos. Em conjunto, mostram a maioria dos estrangulamentos em menos de um minuto.

Qual é uma boa carga média para um servidor Linux?

Depende do número de núcleos de CPU. Uma carga média igual ou inferior ao número de núcleos significa normalmente que não há filas. Uma carga persistente acima do número de núcleos significa que as tarefas estão à espera de CPU ou de disco.

Porque é que o Linux mostra quase nenhuma memória livre?

O Linux usa a RAM não utilizada como cache de disco e devolve-a quando as aplicações precisam. Verifique antes a coluna available do free -h; essa é a memória realmente disponível para novo trabalho.

Como vejo que processo está a usar mais CPU ou memória?

No top, prima P para ordenar por CPU e M para ordenar por memória. A partir de um script, use ps aux --sort=-%cpu | head ou ps aux --sort=-%mem | head.

Como monitorizo um servidor Linux remotamente?

Instale um agente como o node_exporter, o agente Zabbix ou o agente CloudWatch e envie as métricas para um servidor central ou um serviço cloud. Assim obtém histórico, dashboards e alertas sem ter de iniciar sessão em cada máquina.