Dominando o Desempenho: Um Guia Prático para Usar o Conjunto de Ferramentas Sysstat

O trabalho de desempenho fica confuso quando você só tem o momento atual. Um servidor está lento agora, mas estava lento há dez minutos? O disco começou a fazer backup antes do aumento da CPU? O problema começou após o cron job, o deploy ou a janela de backup? O conjunto de ferramentas sysstat é útil porque fornece leituras ao vivo e um registro histórico que você pode comparar.

A ferramenta principal é o sar, o Relator de Atividade do Sistema. Eu recorro a ele quando o top é muito breve, quando um incidente já passou ou quando preciso mostrar que um problema foi armazenamento, pressão de memória, tráfego de rede ou saturação de CPU, em vez de adivinhar a partir dos sintomas. O restante do conjunto, especialmente iostat e mpstat, preenche os detalhes quando o sar aponta para um gargalo provável.

Isso não substitui a observabilidade completa. Você ainda precisa de métricas de aplicação, logs, rastreamento e verificações externas. Mas em um host Linux, o sysstat é uma das maneiras mais rápidas de responder à primeira pergunta prática: o que a máquina estava realmente fazendo?

1. Instalação e Configuração Inicial do Sysstat

O pacote sysstat está normalmente disponível nos repositórios padrão de todas as principais distribuições Linux.

1.1 Comandos de Instalação

Use o comando do gerenciador de pacotes apropriado para o seu sistema:

Debian/Ubuntu:

sudo apt update
sudo apt install sysstat

RHEL/CentOS/Fedora:

sudo yum install sysstat
# ou use dnf para sistemas mais novos
sudo dnf install sysstat

1.2 Habilitando a Coleta de Dados Históricos

Para que o sar seja verdadeiramente útil, ele deve coletar dados historicamente. Por padrão, a instalação geralmente configura um cron job ou timer systemd, mas a verificação é crucial.

Em sistemas modernos, certifique-se de que o serviço sysstat esteja ativo:

sudo systemctl enable --now sysstat

Arquivo de Configuração

A frequência da coleta de dados é controlada por arquivos de configuração, normalmente localizados em /etc/default/sysstat (Debian/Ubuntu) ou /etc/sysconfig/sysstat (RHEL/CentOS). Procure pela configuração ENABLED ou HISTORY. Definir ENABLED="true" garante a coleta diária de dados.

Dica: Por padrão, os arquivos de dados do sysstat são armazenados em /var/log/sa/ com nomes de arquivo como saXX, onde XX é o dia do mês. Alguns sistemas baseados em Debian também expõem relatórios em /var/log/sysstat/. Verifique os padrões do seu pacote antes de assumir o caminho.

Após habilitar a coleta, aguarde pelo menos um intervalo e confirme se os arquivos estão aparecendo:

ls -lh /var/log/sa/

Se o diretório estiver vazio, verifique os timers do systemd:

systemctl list-timers | grep sysstat
systemctl status sysstat-collect.timer

Em sistemas mais antigos, a coleta ainda pode ser conduzida pelo cron. O empacotamento exato varia de acordo com a distribuição, então verifique em vez de confiar na memória de outro servidor.

2. A Utilidade Principal: Relator de Atividade do Sistema (`sar`)

O sar é a interface principal para visualizar estatísticas. Ele pode exibir dados em tempo real ou analisar dados históricos previamente coletados.

2.1 Sintaxe Básica para Monitoramento em Tempo Real

A sintaxe básica é projetada para relatar métricas específicas em um intervalo especificado por um número definido de vezes.

sar [opções] [intervalo] [contagem]

Exemplo: Para relatar estatísticas gerais de CPU a cada 3 segundos, 10 vezes:

sar -u 3 10

Esse comando é bom durante um incidente porque fornece uma amostra móvel curta em vez de um único instantâneo. Uma única linha pode capturar um segundo tranquilo e enganá-lo. Dez amostras ao longo de trinta segundos mostram se o padrão é estável, irregular ou já passou.

Opção	Descrição
`-u`	Utilização da CPU (padrão)
`-r`	Estatísticas de memória e paginação
`-d`	Atividade do dispositivo de bloco (E/S de disco)
`-n`	Estatísticas de rede (ex.: `-n DEV` para estatísticas de interface)
`-q`	Fila de execução e carga média
`-W`	Atividade de swapping (paginação)
`-A`	Todas as métricas (útil para instantâneos abrangentes)

Para arquivos históricos, a forma é a mesma. Você adiciona -f para escolher o arquivo de dados e frequentemente -s e -e para limitar o intervalo de tempo. Isso é importante porque ler um dia inteiro de saída durante uma interrupção é lento e ruidoso.

3. Principais Métricas de Desempenho e Exemplos Práticos de `sar`

Entender a saída do sar requer conhecimento de quais métricas indicam saúde ou estresse de desempenho.

3.1 Utilização da CPU (`sar -u`)

A utilização da CPU é frequentemente o primeiro lugar para procurar gargalos. Alta utilização em categorias específicas indica a natureza da carga de trabalho.

sar -u 5 3

Métrica	Descrição	Indicador de Gargalo
`%user`	Tempo de CPU gasto executando processos de nível de usuário.	Alto indica saturação da aplicação/serviço.
`%system`	Tempo de CPU gasto executando tarefas do kernel/sistema.	Alto sugere chamadas de sistema intensivas ou problemas de driver.
`%iowait`	Tempo de CPU ocioso aguardando operações de E/S (disco/rede).	Alto indica um gargalo de E/S, não falta de CPU.
`%idle`	Tempo de CPU gasto esperando por nada (disponível).	Baixo (ex.: < 5%) sugere saturação da CPU.

Tenha cuidado com %iowait. É comumente mal interpretado como "a CPU está ocupada com o disco". Na verdade, significa que a CPU estava ociosa enquanto pelo menos uma solicitação de E/S estava pendente. Um valor alto pode apontar para latência de armazenamento, mas precisa de confirmação com métricas de disco. Em um servidor de banco de dados, por exemplo, alto %iowait combinado com alto await de disco é um sinal muito mais forte do que %iowait sozinho.

Outra visão útil da CPU é a fila de execução:

sar -q 5 5

runq-sz mostra quantas tarefas estão esperando para executar. Se a carga média estiver alta, mas runq-sz for modesto e %iowait for alto, você pode estar olhando para E/S bloqueada em vez de pressão pura de CPU. Se runq-sz permanecer alto e %idle estiver próximo de zero, a máquina provavelmente precisa de menos processos executáveis, código mais rápido ou mais capacidade de CPU.

3.2 Memória e Paginação (`sar -r` e `sar -W`)

As estatísticas de memória revelam tanto o consumo quanto se o sistema está recorrendo a swapping ou paginação.

Utilização de Memória (sar -r):

sar -r 1 5

Concentre-se em kbavail (memória disponível). Se kbmemfree estiver baixo, mas kbcached e kbbuffers estiverem altos, a memória está sendo usada de forma eficiente pelo mecanismo de cache do kernel.

Atividade de Swapping (sar -W):

sar -W 1 5

Observe pswpin/s (páginas trocadas para dentro) e pswpout/s (páginas trocadas para fora). Quaisquer valores significativos diferentes de zero aqui indicam que o sistema está trocando agressivamente, sinalizando pressão de memória (um forte gargalo).

A saída de memória do Linux pode parecer alarmante até você lembrar que cache não é memória desperdiçada. Um servidor com muito pouco kbmemfree ainda pode estar saudável se kbavail estiver confortável e a atividade de swap estiver silenciosa. O padrão perigoso é diferente: a memória disponível cai, a atividade de swap-in e swap-out aparece e a latência da aplicação aumenta. Isso indica que os processos estão tocando em memória que não cabe mais na RAM.

Para um servidor web, isso pode acontecer após um deploy que acidentalmente dobra o número de workers. Para um host de lote, pode acontecer quando dois grandes jobs se sobrepõem. O sar não dirá qual processo causou isso, mas fornece a linha do tempo. Combine-o com ps, top, logs de serviço ou métricas de cgroup para identificar o responsável.

3.3 Atividade de E/S de Disco (`sar -d`)

Monitorar a atividade do disco é crucial para servidores de banco de dados ou sistemas de armazenamento fortemente utilizados.

sar -d 3 5

Esta saída requer a identificação dos dispositivos específicos (ex.: sda, vda). As principais métricas incluem:

tps: Transferências por segundo (um valor alto indica alta demanda de E/S).
rd_sec/s & wr_sec/s: Quantidade de dados lidos/escritos por segundo.
%util: Porcentagem de tempo em que o dispositivo esteve ocupado atendendo solicitações. Se %util permanecer perto de 100% em um dispositivo de bloco tradicional, o armazenamento pode estar saturado.

Em SSDs modernos e discos virtuais, %util merece contexto. Alguns dispositivos lidam bem com E/S paralela, e volumes em nuvem podem ser limitados por IOPS provisionados, throughput ou créditos de burst. Trate %util como um prompt para olhar mais de perto, não como um diagnóstico completo. Confirme com iostat -xd, latência da aplicação e métricas de armazenamento no nível da plataforma se você estiver na AWS, Azure, GCP ou outro ambiente virtualizado.

Um fluxo de trabalho prático é:

sar -d -f /var/log/sa/sa24 -s 09:00:00 -e 10:00:00
iostat -xd 2 5

Use sar para encontrar a hora ruim, depois use iostat durante uma recorrência ao vivo para inspecionar a latência no nível do dispositivo.

3.4 Estatísticas de Rede (`sar -n`)

O sar pode relatar atividade em várias camadas de rede. A verificação mais comum é a atividade da interface (DEV).

sar -n DEV 5 1

Este comando mostra métricas como rxpk/s (pacotes recebidos por segundo) e txkB/s (kilobytes transmitidos por segundo) para cada interface de rede. Use isso para identificar interfaces que estão sofrendo carga pesada ou erros potenciais.

Para contadores de erro, adicione EDEV:

sar -n EDEV 5 3

Isso pode mostrar erros de recebimento, erros de transmissão, descartes e colisões onde suportado pelo driver. Descartas são especialmente úteis quando um serviço reclama de timeouts intermitentes, mas CPU e disco parecem normais. Se os descartes aumentarem durante picos de tráfego, você pode precisar inspecionar filas de NIC, configurações de rede do kernel, rede de contêineres ou o caminho do balanceador de carga.

Para comportamento no nível TCP, tente:

sar -n TCP,ETCP 5 3

Retransmissões, resets e tentativas de conexão com falha podem transformar um relatório vago de "o site está lento" em um problema de rede ou upstream mais específico.

4. Análise Histórica e Criação de Linha de Base

O verdadeiro poder do sysstat reside em sua capacidade de analisar a atividade do sistema por longos períodos, o que é essencial para estabelecer linhas de base de desempenho (o que é normal para o seu sistema).

4.1 Analisando Dias Anteriores

Para visualizar dados coletados em um dia anterior, use a flag -f para especificar o caminho para o arquivo diário saXX.

Exemplo: Para visualizar estatísticas de CPU do 10º dia do mês atual:

sar -u -f /var/log/sa/sa10

Para revisar estatísticas em uma janela de tempo específica naquele dia, adicione as flags -s (hora de início) e -e (hora de término) (usando formato de 24 horas).

# Visualizar estatísticas de rede das 14:00 às 16:30 do dia 10
sar -n DEV -f /var/log/sa/sa10 -s 14:00:00 -e 16:30:00

4.2 Estabelecendo Linhas de Base

Colete Dados: Execute sysstat durante períodos normais de alta e baixa carga.
Identifique Normas: Analise dados históricos (sar -f) para determinar a utilização média da CPU (%user, %system), latência de E/S de pico (%util) e uso médio de memória.
Defina Limiares: Trate desvios sustentados de sua própria linha de base como gatilhos de investigação. Um host de banco de dados ocupado e um jump box tranquilo não devem compartilhar os mesmos limiares.

As linhas de base são mais úteis quando estão ligadas a ritmos reais de negócios. Uma importação em lote na segunda-feira de manhã, um backup noturno e um lançamento de produto criam diferentes formas de "normal". Mantenha anotações quando investigar: "backup começou às 01:00", "novo release às 14:30", "e-mail de marketing às 09:05". Essas anotações tornam a saída histórica do sar muito mais fácil de interpretar posteriormente.

5. Ferramentas de Suporte do Sysstat

Enquanto o sar é a ferramenta abrangente, o conjunto sysstat inclui utilitários especializados que oferecem relatórios focados e de alto detalhe.

5.1 iostat (Estatísticas de Entrada/Saída)

O iostat fornece métricas detalhadas focadas especificamente na utilização do dispositivo, particularmente útil ao diagnosticar gargalos de armazenamento.

# Relatar estatísticas de disco a cada 2 segundos, 4 vezes, incluindo estatísticas estendidas (x)
iostat -xd 2 4

Principais métricas do iostat:

%util: A porcentagem de tempo de CPU durante a qual as solicitações de E/S foram emitidas para o dispositivo (indicador crucial de saturação).
await: O tempo médio de espera (em milissegundos) para solicitações de E/S emitidas para o dispositivo. await alto indica baixa capacidade de resposta do armazenamento.

Se await saltar, mas a taxa de transferência não for alta, procure por E/S aleatória pequena, problemas de sistema de arquivos, vizinhos barulhentos em infraestrutura virtual ou uma aplicação fazendo gravações pesadas síncronas. Se a taxa de transferência for alta e a latência aumentar com ela, o dispositivo pode simplesmente estar em seu limite prático.

5.2 mpstat (Estatísticas de Multiprocessador)

Se você suspeitar de problemas de agendamento de CPU ou distribuição desigual de carga de trabalho entre os núcleos, o mpstat fornece estatísticas de uso por processador, algo que o sar -u agrega.

# Mostrar uso para todas as CPUs (A) a cada 2 segundos
mpstat -P ALL 2 1

Isso é inestimável para identificar aplicações de thread único que estão saturando um único núcleo enquanto outros permanecem ociosos, ou para diagnosticar a eficiência do hyperthreading.

5.3 sadf (Exportando Dados do Sysstat)

O sadf lê os mesmos dados coletados que o sar, mas pode imprimi-los em formatos que são mais fáceis de consumir por scripts e dashboards.

sadf -d /var/log/sa/sa24 -- -u
sadf -j /var/log/sa/sa24 -- -r

A saída -d é útil para processamento de texto delimitado. A saída -j é útil quando você quer JSON. Isso é útil quando você precisa anexar evidências a uma revisão de incidente ou comparar dois hosts sem copiar manualmente a saída do terminal.

6. Um Passo a Passo Prático de Incidente

Imagine um servidor de API que começou a dar timeout às 10:15. Os logs da aplicação mostram solicitações se acumulando, mas não explicam o porquê. Comece com a visão histórica da CPU:

sar -u -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Se %user estiver alto e %idle estiver baixo, a aplicação pode estar limitada pela CPU. Verifique o uso por núcleo:

sar -P ALL -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Se um núcleo estiver fixo enquanto outros estão quietos, suspeite de um worker de thread único, hot lock ou distribuição desigual de processos. Se todos os núcleos estiverem ocupados, observe a taxa de solicitação, deploys recentes e caminhos de código caros.

Se a CPU parecer principalmente ociosa, mas %iowait aumentar, mude para o disco:

sar -d -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

Alta utilização do dispositivo ou profundidade de fila crescente por volta do mesmo horário aponta para armazenamento. Em um serviço apoiado por banco de dados, a próxima parada são os logs do banco de dados e os dados de consultas lentas. Em um host de serviço de arquivos, verifique se um backup, job de compressão ou rotação de log foi executado ao mesmo tempo.

Se CPU e disco parecerem normais, inspecione memória e rede:

sar -r -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -W -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00
sar -n DEV,EDEV,TCP,ETCP -f /var/log/sa/sa24 -s 10:00:00 -e 10:30:00

O objetivo não é executar todos os comandos todas as vezes. O objetivo é seguir as evidências. O sar fornece uma linha do tempo entre classes de recursos, que é geralmente o que você precisa para parar de perseguir o sintoma mais alto.

Um Hábito Simples de Operação

A melhor maneira de aprender sysstat é usá-lo antes que algo quebre. Verifique um servidor saudável durante o tráfego normal. Verifique-o durante backups. Verifique-o após um deploy. Salve alguns padrões de comando que correspondam ao seu ambiente.

Quando um incidente acontecer, você já saberá como é o normal. Esse é o verdadeiro valor do conjunto de ferramentas. sar, iostat, mpstat e sadf não diagnosticam magicamente a aplicação para você, mas mantêm a conversa baseada em evidências: quando o problema começou, qual recurso mudou e se o host estava realmente sob pressão.