Saltar para o conteúdo 
sar sysstat Fornece-me métricas históricas de servidores Linux, com as quais consigo acompanhar com precisão, ao longo do tempo, padrões de carga, pontos de estrangulamento e comportamentos anormais. Assim, analiso retrospectivamente a CPU, a RAM, as E/S e a rede, e identifico picos recorrentes que uma ferramenta exclusivamente em tempo real pode facilmente ignorar.
Pontos centrais
Resumo de forma sucinta e clara as seguintes ideias-chave.
- História Em vez de um instantâneo: o registo regular permite identificar os padrões de carga.
- Combinação A partir da recolha e análise: o sysstat recolhe os dados e o sar processa-os.
- Largura Métricas: CPU, RAM, swap, E/S de disco, rede e muito mais.
- Diagnóstico Causas: ajustar e comparar intervalos de tempo de forma específica.
- Planeamento com tendências: dimensionar as capacidades de forma realista.
O que é que o sar e o sysstat fazem no dia-a-dia?
Eu uso sar como o System Activity Reporter, que torna legíveis os dados armazenados pelo sysstat. O sysstat recolhe regularmente valores relativos à CPU, à memória, às E/S e à rede, enquanto eu, com o sar, obtenho relatórios específicos para determinados períodos. Isto permite-me identificar, sem ter de adivinhar, períodos de carga recorrentes causados por cópias de segurança, tarefas cron ou picos de tráfego. Ao contrário de Ferramentas ao vivo Tal como no top ou no htop, não avalio apenas o estado momentâneo, mas tenho em conta a evolução ao longo do tempo. Esta perspetiva evita diagnósticos errados, porque separa a causa do efeito e fornece-me indicações fiáveis.
Instalação e ativação nas distribuições mais comuns
Eu instalo sysstat Através do gestor de pacotes, ativa o registo e verifica os temporizadores do systemd. No Debian/Ubuntu, basta, na maioria das vezes, apt install sysstat e uma olhadela em /etc/default/sysstatseguido de systemctl enable --now sysstat. No RHEL/CentOS/Oracle Linux, utilizo dnf install sysstat e controlo os temporizadores através de systemctl. Depois disso, os ficheiros diários são normalmente guardados em /var/log/sa/ com nomes como sa10 para o dia 10 do mês. Verifico o registo com sar sem parâmetros ou com sar -u 1 3 para uma breve verificação pontual.
Explicação das principais chamadas sar
Para a CPU, utilizo sar -u e, se necessário, por núcleo sar -u -P ALLcom o objetivo de Dicas impossível ignorar. Considero a memória e o cache com sar -r e troca com sar -S. A atividade da placa leio com sar -d, a rede com sar -n DEV,ETCP,TCP,UDP. Abro os ficheiros históricos com sar -f /var/log/sa/sa10 e definir intervalos de tempo com -s HH:MM -e HH:MM . Para análises detalhadas sobre os tempos de espera, vou complementar o sar com Analisar esperas de E/S, porque assim consigo avaliar melhor as filas de espera e o rendimento e Estrangulamentos identifique claramente.
Como interpretar corretamente os valores medidos: CPU, memória, E/S, rede
Analiso alguns indicadores que me dão rapidamente uma visão fiável e que comparo ao longo do tempo. CPU-Inativo Valores próximos de 0 e um %iowait elevado indicam filas no disco. Um valor elevado de %steal revela escassez de CPU na virtualização. No que diz respeito à RAM, presto atenção às páginas de memória livres, ao comportamento do cache de páginas e às entradas e saídas do swap. No que diz respeito à rede, os erros de pacotes, as perdas e as retransmissões ajudam a identificar limites de capacidade ou perturbações.
| Métricas | interruptor sar | Valores anormais | medida imediata |
|---|---|---|---|
| CPU | sar -u [-P ALL] | %idle muito baixo, %iowait elevado | Verificar E/S, distribuir threads, validar os requisitos de CPU |
| Memória | sar -r | pouco espaço livre, grande perda de cache de páginas | Otimizar serviços, aumentar a memória RAM, avaliar o cache |
| Troca | sar -S | Substituições frequentes (entradas/saídas) | Aliviar a carga da memória de trabalho, ajustar os limites |
| E/S de disco | sar -d | Valores elevados de «await»/«svctm», a fila está a aumentar | Verificar o perfil de E/S, ajustar a hierarquia de armazenamento ou as janelas de processamento em lote |
| Rede | sar -n DEV,ETCP | Perda de pacotes, erros, retransmissões | Testar o MTU/descarregamento, analisar a largura de banda e a latência |
Analisar dados históricos e intervalos de tempo
Trabalho quase sempre com Janelas de tempo, por exemplo sar -u -f /var/log/sa/sa10 -s 01:00:00 -e 05:00:00 para trabalhos noturnos. Assim, comparo horários idênticos em dias diferentes e identifico tendências, em vez de casos isolados. Para a análise automática, guardo os dados com sadf -d em formato CSV e importo-os para um painel próprio. Em caso de picos invulgares, analiso os intervalos adjacentes para excluir efeitos colaterais. Considero este método simples, porque me fornece indicações rapidamente aproveitáveis sem um longo trabalho de preparação.
Análise de tendências e planeamento de capacidade
Utilizo os valores arquivados para Previsões e dimensiono os recursos com base em padrões reais, em vez de me basear na intuição. Se a utilização da CPU aumentar semana após semana, prevejo núcleos ou reservas de frequência. Se a necessidade de memória aumentar devido aos caches, comparo os benefícios com a expansão da RAM. Se o caminho de E/S apresentar tempos de espera crescentes, opto por um armazenamento mais rápido ou por janelas de processamento em lote desacopladas. Para a visualização, integro os dados alternativamente a Grafana e Prometheus e combina as tendências do SAR com as métricas dos exportadores.
Caso prático: servidor web com picos de carga
Vou descrever um caso em que os sites do WordPress demoram a responder todas as noites e Utilizadores Comunicar interrupções. Com sar -u -s 18:00:00 -e 20:00:00 e sar -d Deteto picos de E/S simultâneos durante as cópias de segurança. Paralelamente, mostra sar -n DEV aumento do débito da rede, o que completa o quadro da carga. O teste de verificação realizado no dia seguinte, sem cópia de segurança, confirma este padrão. Remeto a tarefa, otimizo as consultas à base de dados e reequilibro as caches, o que faz com que os picos noturnos desapareçam e os tempos de resposta voltem a ficar constantes.
Dicas para a gestão, rotação e conservação de dados
Verifico o Armazenamento em /etc/sysconfig/sysstat ou /etc/default/sysstat e defino o período de retenção consoante as necessidades. Para hosts críticos, guardo os dados durante 30 a 90 dias, para identificar efeitos sazonais. O tamanho dos ficheiros mantém-se razoável, desde que os intervalos sejam adequados e não esteja ativa uma frequência excessiva de atualização por segundo. Transfiro os arquivos mais antigos para um diretório central ou coloco-os num sistema simples de armazenamento de longo prazo. Desta forma, mantenho os dados disponíveis sem sobrecarregar o sistema nem abrandar a análise.
Integração com pilhas de monitorização e registos
Defino sar como Dados em bruto-fornecedor e combino-o com monitorização centralizada, análise de registos e alertas. Uma pilha de APM ou de registos fornece-me eventos, enquanto o sar ordena cronologicamente os valores da infraestrutura. Para hosts particularmente ruidosos, utilizo adicionalmente pidstat e iostat, para associar processos e percursos de E/S. Além disso, ajuda-me Contabilidade de processos, identificar com precisão os processos que consomem muitos recursos. Esta combinação da perspetiva de eventos e de métricas evita que se avance às cegas e reduz significativamente o tempo que demoro a resolver problemas.
Ajustar a configuração com precisão: intervalos, sa1/sa2 e temporizador
Coloquei o Intervalos de registo de forma a que se adaptem à dinâmica do sistema. Um intervalo de um minuto é o padrão recomendado, embora, no caso de hosts altamente voláteis, intervalos de 10 a 30 segundos também possam ser adequados. A recolha é efetuada sa1 (amostras frequentes), o resumo diário sa2 (Relatórios do dia). No systemd, verifico os temporizadores ou serviços correspondentes e ajusto a frequência. No Debian/Ubuntu, costumo ativar a recolha explicitamente com ENABLED="true" em /etc/default/sysstat. Registo os intervalos por ambiente, para que as comparações posteriores sejam corretas e ninguém tire conclusões erradas a partir de amostras de 5 segundos, em comparação com dados de 1 minuto.
Visão geral das opções avançadas do sar
Para além dos botões clássicos, os botões adicionais ajudam-me a... Visão geral: sar -b apresenta o débito de E/S em bloco agregado, sar -B o comportamento de paging do kernel e sar -W A atividade de swap em pormenor. Com sar -q Vejo a fila de espera (processos que aguardam a CPU) e a evolução da carga. sar -H fornece dados da Hugepage, quando relevante. No caso dos discos, utilizo, se necessário, sar -d -p, para analisar as partições separadamente. Tenho cuidado com svctm: Este valor pode, por vezes, não ser fiável ou ser igual a 0 nos kernels modernos; prefiro considerar aguardar (latência de ponta a ponta) e avgqu-sz/aqu-sz (tamanho da fila). E quando preciso de uma visão geral rápida, o sar -A uma visão geral abrangente, que depois vou aprofundar.
Avaliar corretamente as máquinas virtuais e os contentores
Em Virtualizações Presto especial atenção ao %steal: valores elevados de «steal» significam que o hipervisor retira tempo de CPU à VM. Isso pode facilmente levar a avaliações erradas se eu analisar apenas o %idle. Por isso, correlaciono a utilização da CPU, o «Steal» e a «Runqueue» (sar -q) em conjunto. Em ambientes de contentores, separo a perspetiva do anfitrião da da carga de trabalho: o sar monitoriza o anfitrião, não os contentores individuais. Se precisar de detalhes por serviço, complemento com pidstat (por processo) e tenho em conta os limites dos cgroups. Verifico também o escalonamento da frequência da CPU e os estados de energia (mudanças de frequência), pois podem causar latências de curta duração que, fora do contexto, parecem ser uma escassez de CPU.
Referência temporal: fusos horários, hora de verão e correlação fiável
Presto atenção a base de tempo constante, para que as comparações sejam precisas. O sar guarda, por predefinição, na hora local; no caso de clusters, convém utilizar um fuso horário uniforme (muitas vezes o UTC). Por altura da mudança para a hora de verão, verifico se existem intervalos de tempo duplicados ou em falta e, se necessário, utilizo a saída de sadf com carimbos de data/hora no formato ISO. Para estabelecer correlações com registos ou eventos APM, alinho os fusos horários para associar com precisão os picos nas métricas aos eventos (implementações, cópias de segurança, tarefas Cron). Referências temporais precisas reduzem significativamente os mal-entendidos nas análises pós-incidente.
Automatizar e exportar com o sadf
Para relatórios e painéis, exporto dados com sadf. No dia-a-dia, utilizo sadf -d (CSV) para análises simples, em alternativa sadf -j (JSON) para pipelines flexíveis. Uma exportação típica tem o seguinte aspeto: sadf -d /var/log/sa/sa10 -- -u -r -b -n DEV,ETCP -s 18:00 -e 20:00 > sar_abend.csv. É assim que crio um ficheiro com os indicadores de CPU, RAM, E/S em bloco e rede para um intervalo horário noturno. Nos scripts, utilizo esses dados para comparar automaticamente os dias da semana, calcular a mediana e o percentil 95 e identificar valores atípicos. Mantenho deliberadamente o conjunto de métricas reduzido, para preservar a legibilidade e evitar falsos alarmes.
Caso prático: servidor de base de dados com pressão no cache de páginas
Um servidor MySQL apresenta latências esporádicas nas consultas. sar -r mostra uma diminuição do cache de páginas ao fim da tarde, sar -S substituições pontuais. Paralelamente, cresce em sar -d o aguardar-Hora, e sar -b indica um aumento nos fluxos de gravação. A correlação com as rotações de registos e uma tarefa ETL explica este padrão: grandes ondas de gravação sequencial esvaziam a cache e forçam as leituras da base de dados a recorrerem à E/S. Distribuo as tarefas, aumentei moderadamente a RAM e aumentei de forma seletiva o tamanho do buffer da base de dados. Depois disso, os valores de «await» e de «swap» mantêm-se estáveis, as latências diminuem e o cache de páginas mantém os «hotsets» de forma fiável na memória.
Aspetos operacionais: despesas gerais, listas de equipamentos e filtros
Eu tenho o Despesas gerais pequena, ao selecionar amostras de forma proporcional. O Sysstat lê principalmente a partir de /proc e grava em binário; com intervalos de minutos, mal sinto a carga. Em hosts com um grande número de dispositivos ou dispositivos de bloco de curta duração (por exemplo, em instantâneos), filtro a saída de forma seletiva e avalio apenas os caminhos relevantes. No caso do dm-crypt, do MD-RAID ou de dispositivos multipath, verifico tanto o dispositivo lógico como — sempre que possível — o dispositivo subjacente, para identificar corretamente os pontos de estrangulamento. Ao fazê-lo, documento os nomes dos dispositivos, para que comparações posteriores não falhem devido a caminhos renomeados.
Metodologia: valores de referência e dias de comparação
Defino, por cada host, uma Linha de base por intervalo horário do dia (por exemplo, 01h–05h: Batch, 09h–18h: Office, 18h–22h: Pico). Para cada intervalo, anoto os valores medianos típicos e os percentis aceitáveis (por exemplo, CPU-%idle, aguardar, avgqu-sz, retransmissões). Em caso de desvios, procuro primeiro novos trabalhos, implementações ou padrões de tráfego – só depois é que penso em aumentos de capacidade. Esta sequência disciplinada evita decisões precipitadas: muitas vezes, uma pequena alteração no plano ou um ajuste de limites resolve mais do que a aquisição de hardware dispendioso. O sar fornece-me, para isso, uma base de dados fiável ao longo de semanas e meses.
Limites e complementos úteis
Não vejo o sar como um substituto para Alerta, porque, por predefinição, não monitoriza limiares nem envia notificações. Os alertas em tempo real devem ser tratados em sistemas dedicados que definam regras, escalas e fluxos de trabalho das equipas. Também abordo métricas detalhadas sobre aplicações, bases de dados ou JVMs através do Exporter e do Tracing. O sar destaca-se quando pretendo comparar historicamente os recursos do sistema e identificar pontos de estrangulamento no funcionamento. Em suma, utilizo-o de forma específica sempre que são necessárias respostas rápidas e repetíveis a questões relacionadas com a infraestrutura.
Brevemente resumido
Eu uso sar e o sysstat, para transformar os valores medidos num registo compreensível da carga do servidor. A combinação entre a recolha regular de dados e uma análise retrospectiva direcionada permite identificar as causas, em vez de adivinhar os sintomas. Com apenas alguns comandos, deteto problemas de CPU, memória, E/S e rede e registo-os cronologicamente. A partir daí, tomo decisões realistas em matéria de capacidade e identifico rotinas ineficientes, como cópias de segurança mal programadas. Quem é responsável por servidores Linux ganha, com este método, uma orientação fiável e poupa tempo na análise, no planeamento e na operação.
