Comando sar no Linux: um guia prático para monitorar e diagnosticar problemas de performance

O comando linux sar é a sua “caixa-preta” do sistema: ele coleta e guarda métricas de CPU, memória, disco e rede ao longo do tempo. Com isso, você consegue voltar a qualquer horário e entender por que o servidor ficou lento, travou ou saturou — em vez de depender apenas do “agora”.

O que é o sar e por que ele é diferente de “top” ou “htop”?

O sar (System Activity Reporter) pertence ao pacote sysstat e registra estatísticas periodicamente em arquivos binários. Ferramentas como top/htop mostram o presente; o sar permite analisar o passado (por exemplo, “o que aconteceu às 15:00 de ontem”). Isso é essencial para incidentes intermitentes, auditorias de capacidade e correlação de picos.

Instalação e configuração do sysstat

1. Instale o pacote
   Debian/Ubuntu:

sudo apt update && sudo apt install sysstat

sudo apt update && sudo apt install sysstat

RHEL/CentOS/Alma/Rocky/Fedora:

sudo dnf install sysstat

sudo dnf install sysstat

openSUSE:

sudo zypper install sysstat

sudo zypper install sysstat

Arch:

sudo pacman -S sysstat

sudo pacman -S sysstat

2. Habilite a coleta automática (histórico)

• Em muitas distros modernas, existem timers do systemd:

sudo systemctl enable --now sysstat-collect.timer sysstat-summary.timer

sudo systemctl enable --now sysstat-collect.timer sysstat-summary.timer

• Em Debian/Ubuntu, confirme se a coleta está ativada no arquivo:

/etc/default/sysstat     # defina: ENABLED="true"

/etc/default/sysstat     # defina: ENABLED="true"

e reinicie a coleta:

sudo systemctl restart sysstat || sudo service sysstat restart

sudo systemctl restart sysstat || sudo service sysstat restart

3. Ajuste a retenção

• Debian/Ubuntu: /etc/sysstat/sysstat (opção HISTORY= em dias).
• RHEL/Fedora: /etc/sysconfig/sysstat (opção HISTORY=).

4. Verifique onde os arquivos são gravados

• Geralmente em /var/log/sa/ (ex.: sa07 para dia 07). Em algumas distros: /var/log/sysstat/.

Dica: use systemctl list-timers '*sysstat*' para confirmar se os timers estão ativos.

Análise prática: os 4 principais relatórios do sar

A seguir, os comandos essenciais e como interpretar as colunas para diagnósticos reais.

CPU: sar -u (e -P ALL por CPU)

Objetivo: confirmar saturação de CPU, roubo de CPU em VMs e gargalos de I/O.

Tempo real (1 s por 10 amostras):

sar -u 1 10
# por CPU:
sar -P ALL 1 5

sar -u 1 10
# por CPU:
sar -P ALL 1 5

Colunas importantes:

• %user: carga em espaço de usuário (aplicações).
• %system: carga no kernel (syscalls, interrupções).
• %iowait: CPU ociosa esperando disco → alto e sustentado sugere gargalo de I/O.
• %steal: em VMs, tempo “roubado” pelo hypervisor → alto indica host sobrecarregado.
• %idle: ocioso (quanto menor, mais ocupada a CPU).

Sinais de alerta práticos

• %user ou %system > 80% por vários minutos → CPU no limite.
• %iowait > 10–20% de forma sustentada → disco lento travando a aplicação.
• %steal > 5% em VM → falta de CPU no host/hypervisor.

Memória: sar -r (uso) e sar -S/-W (swap/paging)

Objetivo: verificar pressão de memória e swapping.

Comandos:

sar -r 1 5      # uso de RAM
sar -S 1 5      # uso de swap
sar -W 1 5      # páginas trocadas por segundo (swap in/out)

sar -r 1 5      # uso de RAM
sar -S 1 5      # uso de swap
sar -W 1 5      # páginas trocadas por segundo (swap in/out)

Colunas que importam (saída de -r):

• kbmemfree, kbmemused, %memused: panorama de RAM.
• kbbuffers, kbcached: cache/buffers (não é “memória perdida”).
• kbcommit, %commit: memória “prometida” aos processos (compromisso).

Sinais de alerta práticos

• %memused muito alto junto com swap crescendo (veja -S) → pressão de memória.
• Em sar -W, pswpin/s e pswpout/s > 0 por longos períodos → swapping prejudicando desempenho.

Disco: sar -b (visão geral) e sar -d -p (por dispositivo)

Objetivo: confirmar gargalos de I/O e latência por dispositivo.

Comandos:

sar -b 1 5          # visão geral de I/O (tps, read/write)
sar -d -p 1 5       # por dispositivo (-p mostra nomes legíveis)

sar -b 1 5          # visão geral de I/O (tps, read/write)
sar -d -p 1 5       # por dispositivo (-p mostra nomes legíveis)

Colunas típicas:

• tps, rtps/wtps ou rkB/s, wkB/s: taxa de operações/leitura/escrita.
• avgqu-sz/avgqu: tamanho médio da fila → alto = fila acumulando.
• await: latência média (ms) por I/O → quanto maior, pior.
• %util: ocupação do dispositivo → perto de 100% indica saturação.

Sinais de alerta práticos

• await alto (dezenas/centenas de ms) + %util alto → disco/volume saturado.
• avgqu-sz crescendo continuamente → backlog de I/O.

Rede: sar -n DEV,EDEV,TCP,ETCP

Objetivo: checar throughput, erros e saúde do TCP.

Comandos:

sar -n DEV 1 5            # por interface (rx/tx)
sar -n EDEV 1 5           # erros por interface
sar -n TCP,ETCP 1 5       # estatísticas de TCP (conexões, resets, retransmissões)

sar -n DEV 1 5            # por interface (rx/tx)
sar -n EDEV 1 5           # erros por interface
sar -n TCP,ETCP 1 5       # estatísticas de TCP (conexões, resets, retransmissões)

Colunas úteis (DEV/EDEV):

• rxkB/s, txkB/s: tráfego.
• rxerr/s, txerr/s, coll/s: erros/colisões → problema físico/driver.
• fifo/frame/carr: indicadores de falhas na camada de enlace.

Sinais de alerta práticos

• Erros/collisions > 0 de forma contínua → cabo/porta/switch/driver com problema.
• Em TCP/ETCP, retrans/s ou reset/s elevados → perda/latência na rede ou na aplicação.

Lendo dados históricos: como investigar problemas do passado

Cenário: “meu site ficou lento ontem às 15:00”. Você quer ver CPU e memória exatamente naquele período.

1. Descubra o arquivo do dia
   Arquivos ficam em /var/log/sa/ (ou /var/log/sysstat/). O padrão é saDD, onde DD é o dia do mês (ex.: sa07).
2. Filtre por janela de tempo
   Use -f para apontar o arquivo, -s e -e para início/fim:

# CPU entre 15:00 e 15:10, dia 07:
sudo sar -u -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00

# Memória no mesmo intervalo:
sudo sar -r -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00

# CPU entre 15:00 e 15:10, dia 07:
sudo sar -u -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00

# Memória no mesmo intervalo:
sudo sar -r -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00

3. Inclua disco e rede, se necessário

sudo sar -d -p -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00
sudo sar -n DEV,EDEV -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00

sudo sar -d -p -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00
sudo sar -n DEV,EDEV -f /var/log/sa/sa07 -s 15:00:00 -e 15:10:00

4. Como tirar conclusões rápidas

• CPU alta (baixa %idle) e %iowait alto no mesmo horário → a aplicação esperava I/O: verifique disco (await/%util) e banco de dados.
• Memória pressionada: %memused alto + swap ativo em -S/-W → ajuste limits, otimize caches, considere mais RAM.
• Disco saturado: await e %util elevados → troque storage class, aumente IOPS, distribua carga, reveja queue depth.
• Rede com perdas: erros em EDEV ou retrans em ETCP → teste cabeamento, drivers, MTU, rota e latência.

Exportação: quando precisar de CSV/JSON para gráficos, use sadf (parte do sysstat), por exemplo:

sadf -d /var/log/sa/sa07 -- -u > cpu_07.csv

sadf -d /var/log/sa/sa07 -- -u > cpu_07.csv

Checklist rápido de uso eficaz

• Habilite a coleta (sysstat ativo e HISTORY configurado).
• Reproduza incidentes com janelas curtas (ex.: -s 14:55 -e 15:10).
• Comece por CPU (-u), depois memória (-r), disco (-b/-d) e rede (-n).
• Procure correlação temporal: todos os picos ocorreram juntos?
• Confirme hipóteses com métricas específicas (ex.: %iowait para disco, retrans para rede).