Monitoramento e alertas de produção: o guia completo de configuração

O incidente médio de produção custa US$ 5.600 por minuto de inatividade. Empresas com monitoramento maduro detectam problemas em menos de 5 minutos, enquanto aquelas sem monitoramento levam em média 197 minutos para detecção – a diferença entre um pequeno problema e uma catástrofe com perda de clientes.

Este guia aborda a configuração completa do monitoramento da produção: o que medir, como coletar, onde visualizar e quando alertar.

Principais conclusões

• Os três pilares da observabilidade (métricas, registros, rastreamentos) servem a propósitos diferentes e todos os três são necessários
• Alerta sobre sintomas (taxa de erro, latência) não faz com que (uso da CPU) reduza o ruído em 80%
• Runbooks anexados a cada alerta garantem uma resposta consistente a incidentes, independentemente de quem está de plantão
• Comece com 5 alertas essenciais e expanda somente quando entender a linha de base

---

Os três pilares da observabilidade

Métricas

Medições numéricas amostradas ao longo do tempo. As métricas respondem "o que está acontecendo agora?"

Métricas de aplicação:

• Taxa de solicitação (solicitações por segundo)
• Taxa de erros (5xx respostas por segundo)
• Distribuição de latência (P50, P95, P99)
• Sessões ativas/usuários simultâneos

Métricas de infraestrutura:

• Utilização da CPU por serviço
• Uso de memória e coleta de lixo
• E/S de disco e espaço disponível
• Taxa de transferência de rede

Métricas de negócios:

• Pedidos por minuto
• Taxa de abandono do carrinho
• Receita por hora
• Chamadas de API por endpoint

Registros

Registros estruturados e com carimbo de data/hora de eventos discretos. Os registros respondem "por que isso aconteceu?"

{
  "timestamp": "2026-03-16T14:32:01.234Z",
  "level": "error",
  "service": "api",
  "requestId": "req_abc123",
  "userId": "usr_456",
  "message": "Payment processing failed",
  "error": "Stripe API timeout after 30000ms",
  "endpoint": "POST /billing/checkout",
  "duration": 30142
}

Registrar práticas recomendadas:

• Use registro JSON estruturado, não texto simples
• Incluir IDs de correlação (requestId) entre serviços
• Registrar em níveis apropriados (ERROR para falhas, WARN para degradação, INFO para eventos-chave)
• Nunca registre dados confidenciais (senhas, tokens, números completos de cartão de crédito)

Traços

Caminhos de solicitação ponta a ponta por meio de sistemas distribuídos. Os rastreamentos respondem "onde está o gargalo?"

Uma única solicitação de usuário para uma finalização de compra de comércio eletrônico pode afetar:

1. Nginx (2ms) para frontend Next.js (50ms) para NestJS API (120ms) para PostgreSQL (45ms) para Stripe API (800ms) para serviço de e-mail (200ms)

Sem rastreamento, você verá "a finalização da compra leva 1,2 segundos". Com o rastreamento, você vê "A API Stripe é responsável por 67% da latência de checkout".

---

Configuração da pilha de monitoramento

Prometheus + Grafana (auto-hospedado)

# docker-compose.monitoring.yml
services:
  prometheus:
    image: prom/prometheus:v2.50.0
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus-data:/prometheus
    ports:
      - "9090:9090"
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.retention.time=30d'
      - '--web.enable-lifecycle'

  grafana:
    image: grafana/grafana:10.3.0
    volumes:
      - grafana-data:/var/lib/grafana
    ports:
      - "3030:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=${GRAFANA_PASSWORD}
      - GF_USERS_ALLOW_SIGN_UP=false

  loki:
    image: grafana/loki:2.9.0
    volumes:
      - loki-data:/loki
    ports:
      - "3100:3100"

  alertmanager:
    image: prom/alertmanager:v0.27.0
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml
    ports:
      - "9093:9093"

volumes:
  prometheus-data:
  grafana-data:
  loki-data:

Configuração do Prometheus

# prometheus.yml
global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - "alerts/*.yml"

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: "api"
    metrics_path: /metrics
    static_configs:
      - targets: ["api:3001"]

  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "postgres"
    static_configs:
      - targets: ["postgres-exporter:9187"]

  - job_name: "redis"
    static_configs:
      - targets: ["redis-exporter:9121"]

---

Métricas de aplicação NestJS

Expondo métricas do Prometheus

// metrics.module.ts
import { Module } from '@nestjs/common';
import { PrometheusModule } from '@willsoto/nestjs-prometheus';
import {
  makeCounterProvider,
  makeHistogramProvider,
  makeGaugeProvider,
} from '@willsoto/nestjs-prometheus';

@Module({
  imports: [
    PrometheusModule.register({
      path: '/metrics',
      defaultMetrics: { enabled: true },
    }),
  ],
  providers: [
    makeCounterProvider({
      name: 'http_requests_total',
      help: 'Total HTTP requests',
      labelNames: ['method', 'path', 'status'],
    }),
    makeHistogramProvider({
      name: 'http_request_duration_seconds',
      help: 'HTTP request duration in seconds',
      labelNames: ['method', 'path'],
      buckets: [0.01, 0.05, 0.1, 0.25, 0.5, 1, 2.5, 5, 10],
    }),
    makeGaugeProvider({
      name: 'active_connections',
      help: 'Number of active connections',
    }),
  ],
  exports: [PrometheusModule],
})
export class MetricsModule {}

---

Configuração de alerta

Os cinco alertas essenciais

Todo sistema de produção precisa destes alertas desde o primeiro dia:

# alerts/essential.yml
groups:
  - name: essential
    rules:
      - alert: ServiceDown
        expr: up == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Service {{ $labels.job }} is down"
          runbook: "https://wiki.example.com/runbooks/service-down"

      - alert: HighErrorRate
        expr: |
          rate(http_requests_total{status=~"5.."}[5m])
          / rate(http_requests_total[5m]) > 0.01
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Error rate above 1% for 5 minutes"
          runbook: "https://wiki.example.com/runbooks/high-error-rate"

      - alert: HighLatency
        expr: |
          histogram_quantile(0.95,
            rate(http_request_duration_seconds_bucket[5m])
          ) > 2
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "P95 latency above 2 seconds"

      - alert: DiskSpaceLow
        expr: |
          node_filesystem_avail_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"} < 0.2
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Disk space below 20% on {{ $labels.instance }}"

      - alert: SSLCertExpiringSoon
        expr: |
          probe_ssl_earliest_cert_expiry - time() < 14 * 24 * 3600
        labels:
          severity: warning
        annotations:
          summary: "SSL certificate expires within 14 days"

Roteamento de alerta

# alertmanager.yml
global:
  slack_api_url: "${SLACK_WEBHOOK_URL}"

route:
  group_by: ['alertname', 'severity']
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  receiver: 'default'
  routes:
    - match:
        severity: critical
      receiver: 'pagerduty'
      repeat_interval: 15m
    - match:
        severity: warning
      receiver: 'slack'

receivers:
  - name: 'default'
    slack_configs:
      - channel: '#alerts'
        title: '{{ .GroupLabels.alertname }}'
        text: '{{ .CommonAnnotations.summary }}'

  - name: 'pagerduty'
    pagerduty_configs:
      - routing_key: "${PAGERDUTY_KEY}"
        severity: '{{ .GroupLabels.severity }}'

  - name: 'slack'
    slack_configs:
      - channel: '#alerts-warnings'
        title: '{{ .GroupLabels.alertname }}'

Regras de qualidade de alerta

---

Painéis Grafana

Hierarquia do painel

1. Painel de visão geral: integridade de alto nível em todos os serviços. Esta é a primeira tela que alguém olha durante um incidente.
2. Painéis de serviço: métricas detalhadas para cada serviço (API, web, trabalhadores).
3. Painéis de infraestrutura: métricas em nível de nó (CPU, memória, disco, rede).
4. Painéis de negócios: receita, pedidos, atividade do usuário.

O método RED para painéis de serviço

Para cada serviço, exiba:

• Rate: Solicitações por segundo
• Eerros: Taxa de erro como porcentagem
• Duração: Distribuição de latência (P50, P95, P99)

Isso fornece visibilidade instantânea da integridade do serviço sem sobrecarga cognitiva.

---

Rastreamento de erros com Sentry

// sentry.config.ts
import * as Sentry from '@sentry/nestjs';

Sentry.init({
  dsn: process.env.SENTRY_DSN,
  environment: process.env.NODE_ENV,
  tracesSampleRate: 0.1,
  profilesSampleRate: 0.1,
  integrations: [
    Sentry.postgresIntegration(),
  ],
  beforeSend(event) {
    // Strip sensitive data
    if (event.request?.headers) {
      delete event.request.headers['authorization'];
      delete event.request.headers['cookie'];
    }
    return event;
  },
});

Sentinela fornece:

• Agrupamento automático de erros e desduplicação
• Stack traces com mapas de origem
• Rastreamento de lançamento (qual implantação introduziu o erro)
• Monitoramento de desempenho (rastreamentos de transações)

---

Perguntas frequentes

Quanto custa uma pilha de monitoramento?

Auto-hospedado (Prometheus + Grafana + Loki): aproximadamente US$ 50-100/mês para recursos de hospedagem. Alternativas gerenciadas: Datadog começa em US$ 15/host/mês para infraestrutura, mais US$ 0,10/GB para logs. A nuvem Sentry custa US$ 26/mês para o plano de equipe. Um orçamento inicial razoável para uma pequena empresa é de US$ 100-200/mês no total.

Qual é a diferença entre monitoramento e observabilidade?

O monitoramento informa quando algo está errado. A observabilidade diz por quê. O monitoramento envolve painéis e alertas predefinidos para modos de falha conhecidos. Observabilidade é a capacidade de fazer perguntas arbitrárias sobre o comportamento do seu sistema usando métricas, logs e rastreamentos. Você precisa de ambos, mas o monitoramento é a base.

Como evitamos a fadiga do alerta?

Três regras: (1) todo alerta deve exigir ação humana, (2) definir limites com base em linhas de base reais e não em ideais teóricos, (3) revisar e ajustar os alertas mensalmente. Se um alerta for disparado mais de uma vez por semana sem exigir ação, corrija o problema subjacente ou aumente o limite. As equipes que sofrem de fadiga de alertas ignoram todos os alertas, inclusive os críticos.

Deveríamos monitorar nosso sistema ERP de maneira diferente?

Os sistemas ERP possuem requisitos de monitoramento exclusivos. Além das métricas padrão da web, monitore: uso do pool de conexões de banco de dados, profundidade da fila de trabalhos em segundo plano, status de sincronização de integração (Shopify, gateways de pagamento), tempo de execução de relatório programado e contagens de sessões de usuário por módulo. ECOSIRE fornece monitoramento Odoo gerenciado como parte de nossos pacotes de suporte.

---

O que vem a seguir

O monitoramento é os olhos e os ouvidos da sua infraestrutura de produção. Combine-o com automação de CI/CD para confiança na implantação e planejamento de recuperação de desastres para resiliência. Para obter um roteiro abrangente de DevOps, consulte nosso guia de DevOps para pequenas empresas.

Entre em contato com a ECOSIRE para monitorar a configuração e os serviços de infraestrutura gerenciados.

---

Publicado pela ECOSIRE – ajudando as empresas a ver o que é importante na produção.