📊 Observabilidade

Logs, métricas e traces — entenda o que acontece nos seus sistemas em produção

📊 Os 3 Pilares da Observabilidade

Observabilidade é a capacidade de entender o estado interno de um sistema a partir de suas saídas externas. Vai além do monitoramento tradicional — em vez de só saber "o sistema caiu", você consegue responder "por que caiu e onde".

📋

Logs

Registros de eventos discretos com timestamp. O "o que aconteceu" — erros, requisições, transações.

📈

Métricas

Valores numéricos ao longo do tempo. CPU, memória, latência, taxa de erros — o "quanto e quando".

🔍

Traces

Rastreamento de uma requisição por todos os serviços. O "caminho completo" em arquiteturas distribuídas.

FLUXO DE OBSERVABILIDADE Aplicação / Containers / Infra │ ├── 📋 Logs ──────────► CloudWatch Logs / ELK Stack ├── 📈 Métricas ──────► CloudWatch Metrics / Prometheus └── 🔍 Traces ────────► AWS X-Ray / Jaeger / Zipkin │ ▼ Dashboards (Grafana / CloudWatch) │ ▼ Alertas (SNS / PagerDuty / Slack)

☁️ AWS CloudWatch

O CloudWatch é o serviço central de observabilidade da AWS — coleta logs, métricas e eventos de praticamente todos os serviços AWS.

RecursoFunção
Log GroupsAgrupa logs de uma aplicação ou serviço
Log StreamsSequência de logs de uma instância específica
MetricsDados numéricos de serviços AWS (CPU, latência, etc.)
AlarmsDispara ações quando métrica ultrapassa threshold
DashboardsPainéis visuais com métricas e logs
InsightsQuery de logs com linguagem própria (CloudWatch Logs Insights)
Container InsightsMétricas de ECS e EKS automaticamente

Comandos CLI essenciais:

# Listar log groups
aws logs describe-log-groups --region us-east-1

# Ver logs em tempo real (tail)
aws logs tail /ecs/minha-app --follow --region us-east-1

# Query com Logs Insights (últimos 30 min)
aws logs start-query \
  --log-group-name /ecs/minha-app \
  --start-time $(date -d '30 minutes ago' +%s) \
  --end-time $(date +%s) \
  --query-string 'fields @timestamp, @message | filter @message like /ERROR/ | sort @timestamp desc | limit 20' \
  --region us-east-1

# Criar alarme de CPU alta
aws cloudwatch put-metric-alarm \
  --alarm-name "CPU-Alta-ECS" \
  --metric-name CPUUtilization \
  --namespace AWS/ECS \
  --statistic Average \
  --period 300 \
  --threshold 80 \
  --comparison-operator GreaterThanThreshold \
  --evaluation-periods 2 \
  --alarm-actions arn:aws:sns:us-east-1:123456789:alertas \
  --region us-east-1

Métrica customizada — enviar do código:

# Publicar métrica customizada via CLI
aws cloudwatch put-metric-data \
  --namespace "AegisCloud/App" \
  --metric-name "PedidosProcessados" \
  --value 42 \
  --unit Count \
  --region us-east-1

CloudWatch Agent — coletar logs de EC2:

# Instalar agente no EC2 (Amazon Linux)
sudo yum install -y amazon-cloudwatch-agent

# Configuração mínima /opt/aws/amazon-cloudwatch-agent/etc/config.json
# {
#   "logs": {
#     "logs_collected": {
#       "files": {
#         "collect_list": [{
#           "file_path": "/var/log/app/*.log",
#           "log_group_name": "/ec2/minha-app",
#           "log_stream_name": "{instance_id}"
#         }]
#       }
#     }
#   }
# }

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl \
  -a fetch-config -m ec2 -s \
  -c file:/opt/aws/amazon-cloudwatch-agent/etc/config.json

🔍 AWS X-Ray — Distributed Tracing

O X-Ray rastreia requisições através de múltiplos serviços AWS, mostrando onde ocorrem gargalos e erros em arquiteturas distribuídas e microserviços.

# Habilitar X-Ray no ECS — adicionar sidecar no task definition
# task-definition.json
{
  "containerDefinitions": [
    {
      "name": "minha-app",
      "image": "minha-app:latest",
      "environment": [
        {"name": "AWS_XRAY_DAEMON_ADDRESS", "value": "xray-daemon:2000"}
      ]
    },
    {
      "name": "xray-daemon",
      "image": "amazon/aws-xray-daemon",
      "portMappings": [{"containerPort": 2000, "protocol": "udp"}],
      "cpu": 32,
      "memoryReservation": 256
    }
  ]
}
💡 O X-Ray gera um Service Map visual mostrando todos os serviços e suas dependências, com latência e taxa de erros em cada conexão. Essencial para debugar microserviços.

🔥 Prometheus

O Prometheus é o padrão open-source para coleta de métricas em ambientes Kubernetes. Coleta métricas via scraping HTTP (pull model) em intervalos configuráveis.

Deploy no Kubernetes com Helm:

# Adicionar repositório Helm
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

# Instalar kube-prometheus-stack (Prometheus + Grafana + Alertmanager)
helm install monitoring prometheus-community/kube-prometheus-stack \
  --namespace monitoring \
  --create-namespace \
  --set grafana.adminPassword=aegis2026

# Verificar pods
kubectl get pods -n monitoring

# Acessar Prometheus localmente
kubectl port-forward svc/monitoring-kube-prometheus-prometheus 9090:9090 -n monitoring

# Acessar Grafana localmente
kubectl port-forward svc/monitoring-grafana 3000:80 -n monitoring
# Login: admin / aegis2026

PromQL — queries essenciais:

# CPU usage por pod (últimos 5 min)
rate(container_cpu_usage_seconds_total{namespace="default"}[5m])

# Memória em uso por container
container_memory_working_set_bytes{namespace="default"}

# Taxa de erros HTTP 5xx
rate(http_requests_total{status=~"5.."}[5m])

# Latência p99 das requisições
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

# Pods não prontos
kube_pod_status_ready{condition="false"}

📊 Grafana — Dashboards

O Grafana é a ferramenta de visualização padrão do mercado. Conecta a múltiplas fontes de dados (Prometheus, CloudWatch, Elasticsearch, etc.) e cria dashboards interativos.

Adicionar CloudWatch como datasource:

# grafana-datasource.yaml — via ConfigMap no K8s
apiVersion: v1
kind: ConfigMap
metadata:
  name: grafana-datasources
  namespace: monitoring
data:
  datasources.yaml: |
    apiVersion: 1
    datasources:
      - name: CloudWatch
        type: cloudwatch
        jsonData:
          defaultRegion: us-east-1
          authType: default  # usa IAM Role do pod
      - name: Prometheus
        type: prometheus
        url: http://prometheus-server:9090
        isDefault: true
💡 Dashboards prontos: O Grafana tem uma biblioteca com milhares de dashboards prontos em grafana.com/grafana/dashboards. Procure por "Kubernetes", "ECS" ou "Node Exporter" para começar.

🔔 Alertas

Alertas eficientes notificam a pessoa certa, no momento certo, com contexto suficiente para agir.

Alertmanager — regras de alerta no Prometheus:

# prometheus-rules.yaml
groups:
  - name: aplicacao
    rules:
      - alert: AltaTaxaDeErros
        expr: rate(http_requests_total{status=~"5.."}[5m]) > 0.05
        for: 2m
        labels:
          severity: critical
        annotations:
          summary: "Taxa de erros 5xx acima de 5%"
          description: "Serviço {{ $labels.service }} com {{ $value | humanizePercentage }} de erros"

      - alert: PodCrashLooping
        expr: rate(kube_pod_container_status_restarts_total[15m]) > 0
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Pod em CrashLoop: {{ $labels.pod }}"

Notificação no Slack via SNS + Lambda:

# Criar tópico SNS
aws sns create-topic --name alertas-producao --region us-east-1

# Assinar email
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123456789:alertas-producao \
  --protocol email \
  --notification-endpoint contato@aegiscloud.com.br \
  --region us-east-1

🎯 SLI, SLO e SLA

Esses três conceitos formam a base da engenharia de confiabilidade (SRE) e definem como medir e comprometer-se com a qualidade do serviço:

SiglaNomeO que éExemplo
SLI Service Level Indicator Métrica que mede o comportamento do serviço % de requisições com latência < 200ms
SLO Service Level Objective Meta interna para o SLI 99,5% das requisições < 200ms por mês
SLA Service Level Agreement Contrato externo com o cliente 99% de disponibilidade — penalidade se não cumprir
Error Budget Orçamento de erros Quanto "erro" ainda é permitido no período SLO 99,5% → 0,5% de budget = ~3,6h/mês
💡 Error Budget na prática: Se o error budget está alto (pouco consumido), o time pode fazer deploys mais agressivos. Se está baixo, congela deploys e foca em estabilidade. É o equilíbrio entre velocidade e confiabilidade.

✅ Boas Práticas de Observabilidade

  • Logs estruturados: use JSON nos logs — facilita queries e parsing automático
  • Correlation ID: propague um ID único por toda a cadeia de serviços para correlacionar logs e traces
  • Alertas acionáveis: só alerte quando há ação humana necessária — alertas sem ação viram ruído
  • Dashboards por audiência: dashboard de negócio (pedidos/min) separado do técnico (CPU/latência)
  • Retenção de logs: defina políticas de retenção no CloudWatch — logs antigos custam caro
  • Baseline de métricas: conheça o comportamento normal antes de definir thresholds de alerta
  • Runbooks: cada alerta deve ter um runbook linkado — o que fazer quando disparar
💡 Stack recomendada para o time: CloudWatch para infra AWS + Prometheus/Grafana para Kubernetes + X-Ray para tracing de microserviços. As três ferramentas se complementam.