Introdução à Observabilidade em Projetos Pequenos

No universo do desenvolvimento de software, especialmente em pequenos projetos, a tentação de pular etapas de monitoramento e observabilidade é grande. Acreditamos que, por serem menores, os projetos são mais fáceis de gerenciar e menos propensos a falhas críticas. No entanto, a realidade é que mesmo projetos enxutos podem enfrentar problemas inesperados que afetam a experiência do usuário e a eficiência da equipe. Adotar práticas de observabilidade desde o início não precisa ser complexo ou caro. Trata-se de implementar ferramentas e processos que nos permitam entender o estado interno do nosso sistema e diagnosticar problemas rapidamente.

Por que Observabilidade é Crucial, Mesmo para Projetos Pequenos?

Projetos de pequena escala, muitas vezes desenvolvidos por equipes enxutas ou até mesmo por um único desenvolvedor, se beneficiam enormemente de uma boa observabilidade. Ela permite:

Detecção Proativa de Problemas: Identificar falhas antes que os usuários as percebam.
Diagnóstico Rápido: Reduzir o tempo médio para resolver incidentes (MTTR - Mean Time To Resolution).
Melhoria Contínua: Entender como o sistema se comporta sob carga e identificar gargalos de performance.
Confiança no Deploy: Ter mais segurança ao lançar novas versões, sabendo que há mecanismos para monitorar seu impacto.

Ignorar a observabilidade em projetos pequenos é como dirigir um carro sem painel de instrumentos: você pode até chegar ao destino, mas estará cego para qualquer sinal de problema até que seja tarde demais.

Os Pilares da Observabilidade: Métricas, Logs e Traces

A observabilidade moderna se apoia em três pilares principais:

Métricas

Métricas são valores numéricos que representam o estado do sistema em um determinado momento. Elas são agregadas e permitem visualizar tendências. Exemplos comuns incluem:

Uso de CPU e memória do servidor.
Latência de requisições HTTP.
Taxa de erros (HTTP 5xx, exceções não tratadas).
Tamanho da fila de processamento.

Para pequenos projetos, ferramentas como Prometheus e Grafana formam uma combinação poderosa e popular. O Prometheus coleta as métricas e o Grafana as visualiza em dashboards intuitivos.

Logs

Logs são registros de eventos discretos que ocorreram no sistema. Eles fornecem contexto detalhado sobre o que aconteceu. Diferentemente das métricas, os logs são mais úteis para investigar um problema específico. Exemplos:

Mensagens de erro detalhadas com stack traces.
Registros de acesso de usuários.
Eventos de inicialização e desligamento de serviços.

Ferramentas como ELK Stack (Elasticsearch, Logstash, Kibana) ou Loki (integrado com Grafana) podem ajudar a centralizar e buscar logs de forma eficiente.

Traces (Rastreamentos Distribuídos)

Traces acompanham uma requisição através de múltiplos serviços em um sistema distribuído. Eles são ideais para entender o fluxo de uma operação e identificar onde ocorrem atrasos ou falhas em arquiteturas de microsserviços, mas também podem ser úteis em aplicações monolíticas que interagem com serviços externos.

Ferramentas como Jaeger ou Zipkin são amplamente utilizadas para tracing.

Implementando Monitoramento de Infraestrutura com `node_exporter` e `Prometheus`

Para começar a coletar métricas de infraestrutura, uma abordagem comum é usar o Prometheus como o sistema de coleta e armazenamento, e o `node_exporter` como um agente que expõe métricas do sistema operacional (CPU, memória, disco, rede) de forma que o Prometheus possa coletá-las. Este é um ponto de partida excelente e de baixo custo para qualquer projeto.

Instalação e Configuração Básica

1. Instale o Prometheus: Baixe o binário apropriado para o seu sistema operacional do site oficial do Prometheus. Execute-o.

./prometheus --config.file=prometheus.yml

O arquivo prometheus.yml precisa ser configurado para descobrir e coletar métricas dos seus alvos. Um exemplo simples para coletar do `node_exporter` rodando em localhost:9100 seria:

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'node' # Nome do job para identificar o alvo
    static_configs:
      - targets: ['localhost:9100'] # Onde o node_exporter está rodando

2. Instale o `node_exporter`: Similarmente, baixe o binário do `node_exporter`. Ele expõe métricas em /metrics na porta 9100 por padrão.

./node_exporter

Com essa configuração, o Prometheus buscará métricas do `node_exporter` a cada 15 segundos. Você pode acessar a interface web do Prometheus (geralmente em http://localhost:9090) para verificar se o alvo está ativo e para começar a consultar suas métricas.

Exemplo de Consulta no Prometheus

Para ver o uso de CPU:

node_cpu_seconds_total{mode="idle"}

Esta consulta retorna o tempo total em segundos que a CPU passou no modo idle. Você pode usar funções como rate() para calcular o uso percentual em um intervalo de tempo.

100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle", job="node"}[5m])) * 100)

Este comando calcula a porcentagem de uso da CPU nos últimos 5 minutos.

Configurando Alertas com `Alertmanager`

Coletar métricas é apenas metade da batalha; ser notificado quando algo está errado é a outra. O Alertmanager é o componente do ecossistema Prometheus responsável por gerenciar alertas. Ele recebe alertas do Prometheus, os agrupa, silencia e roteia para os canais de notificação corretos (email, Slack, PagerDuty, etc.).

Configuração Básica do Alertmanager

Você precisará baixar e executar o binário do Alertmanager. O arquivo de configuração alertmanager.yml define as rotas e os receptores (receivers).

route:
  group_by: ['alertname', 'job']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default-receiver'

receivers:
- name: 'default-receiver'
  slack_configs:
  - api_url: ''
    channel: '#seu-canal-de-alertas'
    send_resolved: true

No Prometheus, você configura para enviar alertas ao Alertmanager:

alerting:
  alertmanagers:
  - static_configs:
    - targets:
      - 'localhost:9093' # Onde o Alertmanager está rodando

Definindo Regras de Alerta (Alerting Rules)

As regras de alerta são definidas em arquivos YAML separados e carregadas pelo Prometheus. Elas especificam as condições sob as quais um alerta deve ser disparado. Exemplo:

groups:
- name: HostAlerts
  rules:
  - alert: HighCpuUsage
    expr: 100 - (avg by (instance) (rate(node_cpu_seconds_total{mode="idle", job="node"}[5m])) * 100) > 85
    for: 5m
    labels:
      severity: warning
    annotations:
      summary:Foto de Wolfgang Weiser no Pexels.