Como monitorar performance de servidores em tempo real

1. Fundamentos do Monitoramento em Tempo Real

Monitoramento em tempo real difere do monitoramento histórico por sua natureza contínua e imediata. Enquanto o monitoramento histórico analisa dados passados para identificar tendências, o monitoramento em tempo real oferece visibilidade instantânea sobre o estado atual do servidor, permitindo respostas rápidas a incidentes. As métricas críticas incluem:

  • CPU: Utilização percentual, carga média (load average) e tempo de espera por I/O
  • Memória: RAM usada, swap, buffers e cache
  • Disco: I/O operations per second (IOPS), latência de leitura/escrita e espaço disponível
  • Rede: Throughput, pacotes perdidos e conexões ativas
  • Processos: Consumo de recursos por processo, número de threads e file descriptors

A latência (tempo de resposta), throughput (taxa de transferência) e taxa de erros (códigos 4xx/5xx) são métricas essenciais para servidores web e de aplicação.

2. Ferramentas e Stack Tecnológico para Coleta de Dados

Agentes de monitoramento são responsáveis por coletar métricas do servidor. Exemplos práticos:

Node Exporter (Prometheus) — coleta métricas do sistema operacional:

# Exemplo de métricas expostas pelo Node Exporter na porta 9100
node_cpu_seconds_total{cpu="0",mode="idle"} 2837492.34
node_memory_MemTotal_bytes 16759791616
node_disk_io_time_seconds_total{device="sda"} 12345.67

Telegraf — agente flexível que suporta múltiplos inputs:

# Configuração básica do Telegraf para coletar CPU e memória
[[inputs.cpu]]
  percpu = true
  totalcpu = true
[[inputs.mem]]
  fieldpass = ["used_percent", "available"]

Protocolos como SNMP (para equipamentos de rede), JMX (para aplicações Java) e APIs customizadas (REST/HTTP) complementam a coleta. A integração com sistemas de logging (ELK Stack) e tracing distribuído (Jaeger, Zipkin) enriquece a análise.

3. Arquitetura de Pipeline de Dados em Tempo Real

A arquitetura de pipeline define como os dados fluem do servidor até a visualização. Dois modelos principais:

Pull (Prometheus) — o servidor Prometheus faz scraping periódico nos endpoints dos exporters:

# Configuração do prometheus.yml para coletar a cada 15 segundos
scrape_configs:
  - job_name: 'node'
    scrape_interval: 15s
    static_configs:
      - targets: ['servidor1:9100', 'servidor2:9100']

Push (Telegraf + InfluxDB) — o agente envia métricas para o banco:

# Telegraf envia para InfluxDB a cada 10 segundos
[[outputs.influxdb]]
  urls = ["http://influxdb:8086"]
  database = "metrics"
  retention_policy = "autogen"
  write_consistency = "any"

Para alta frequência, bancos de séries temporais como InfluxDB ou TimescaleDB são ideais. Bufferização com Kafka ou Redis evita perda de dados durante picos.

4. Dashboards e Visualização de Performance

Grafana é a ferramenta padrão para criar painéis dinâmicos. Exemplo de query para um gráfico de CPU:

# Query para Grafana usando Prometheus como fonte
100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100)

Tipos de visualização recomendados:
- Gráficos de séries temporais: para CPU, memória e rede ao longo do tempo
- Gauges: para valores atuais como espaço em disco ou conexões ativas
- Heatmaps: para latência de requisições, mostrando distribuição percentual

Configuração de alertas visuais com thresholds dinâmicos:

# Alerta no Grafana para CPU > 80% por 5 minutos
Alert condition: avg() of query (A) > 80
Evaluate every: 1m
For: 5m

5. Alertas e Notificações Proativas

Regras de alerta no Prometheus usam expressões baseadas em percentis e médias móveis:

# Regra de alerta para alta latência de disco (percentil 95 > 100ms)
groups:
  - name: disk_alerts
    rules:
      - alert: HighDiskLatency
        expr: rate(node_disk_io_time_seconds_total[5m]) > 0.1
        for: 10m
        annotations:
          summary: "Latência de disco alta em {{ $labels.instance }}"

Canais de notificação no Alertmanager:

# Configuração para enviar alertas ao Slack
receivers:
  - name: 'slack'
    slack_configs:
      - api_url: 'https://hooks.slack.com/services/TOKEN'
        channel: '#alertas-servidores'
        send_resolved: true

Estratégias de escalonamento: notificar equipe técnica em 5 min, supervisor em 15 min, gerente em 30 min. Silenciamento de falsos positivos com base em janelas de manutenção programadas.

6. Análise de Gargalos e Diagnóstico em Tempo Real

Ferramentas de linha de comando para diagnóstico imediato:

Monitoramento de CPU e memória com top e htop:

# Comando top mostrando processos por uso de CPU
top -b -n 1 | head -20
# Saída simplificada:
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
  1234 mysql     20   0  1.2g  456m   12m S  45.0  2.8   5:32.45 mysqld
  5678 nginx     20   0  125m   18m    8m S   8.5  0.1   1:12.33 nginx

Análise de I/O de disco com iostat:

# iostat mostrando utilização e latência de disco a cada 2 segundos
iostat -x 2 3
Device:  rrqm/s wrqm/s   r/s   w/s  rkB/s  wkB/s avgrq-sz avgqu-sz await r_await w_await  svctm  %util
sda        0.00   0.00  12.5  8.2  256.0  164.0    40.0     0.05   2.5    1.8    3.2   0.40   0.83

Conexões de rede ativas com ss:

# Listar conexões TCP estabelecidas
ss -t state established | wc -l
# Verificar conexões por porta
ss -tlnp | grep :80

Correlacione métricas de servidor com logs de aplicação usando journalctl ou grep em arquivos de log para identificar a causa raiz de anomalias.

7. Boas Práticas e Otimização do Monitoramento

Definição de intervalos de coleta adequados:
- Métricas de infraestrutura (CPU, memória): a cada 15-30 segundos
- Métricas de aplicação (latência, taxa de erro): a cada 5-10 segundos
- Métricas de negócio (usuários ativos): a cada 1 minuto

Redução de overhead com amostragem inteligente:

# Exemplo de amostragem no Telegraf: coletar apenas 50% das amostras
[[inputs.cpu]]
  percpu = true
  totalcpu = true
  fielddrop = ["time_*"]  # Remover campos desnecessários
  sample = 0.5  # 50% das amostras

Documentação e automação de playbooks para resposta a incidentes:

# Playbook para alta utilização de CPU (exemplo em YAML)
- name: Alta utilização de CPU
  symptoms:
    - CPU > 90% por mais de 5 minutos
  actions:
    - Verificar processos com top
    - Analisar logs do aplicação em /var/log/app/
    - Escalar para equipe de desenvolvimento se necessário
  escalation:
    - time: 5 min
      contact: time_plantao
    - time: 15 min
      contact: supervisor_infra

Referências