TL;DR
- Observabilidade é diferente de monitorização: precisa de logs estruturados, métricas e traces distribuídos, não apenas alertas de CPU. Monitorização diz "o quê falhou", observabilidade diz "porque falhou".
- Começa a investir quando tens: 2+ serviços comunicando, taxa de erro > 0.5%, ou latência P99 degradada em produção. Antes disso, um bom logging estruturado com Postgres + visualização basta.
- O custo real é alto: DataDog, New Relic e similares custam €200-500/mês em startups pequenas (sem escala). Alternativas abertas (Grafana + Prometheus + Loki + Jaeger) requerem ops mas custam infra apenas.
- Armadilha comum: implementar observabilidade completa antes de ter problema em produção. Resultado: 20GB/dia de logs que ninguém lê, custo mensal desnecessário, e debugging ainda lento porque os traces estão desorganizados.
- Começa simples: logs estruturados em JSON, 3-4 métricas críticas (latência, erros, RPS, saturação de recursos), e trace distribuído apenas entre serviços que se chamam. Expande conforme cresce.
O Que É Observabilidade (E Não É)
Observabilidade é a capacidade de entender o estado interno de um sistema através da observação do seu comportamento externo. Isto é diferente de monitorização.
Monitorização é binária: o servidor está up ou down, CPU acima de 80%, resposta em menos de 200ms. Boa para alertar. Mas quando a tua API demora 5 segundos em produção e o CPU está normal, a monitorização tradicional não te diz nada.
Observabilidade tem três pilares.
Primeiro: logs estruturados. Não "erro ao processar pagamento". Mas {"timestamp": "2025-01-15T14:32:10Z", "level": "error", "service": "payments", "user_id": "1234", "method": "POST /charges", "error_code": "insufficient_funds", "duration_ms": 145}. Isto permite filtrar, agregar, correlacionar.
Segundo: métricas. Não snapshots de CPU. Mas séries temporais: latência P50, P95, P99 por endpoint; erros por tipo; throughput de requests. Assim vês padrões ao longo do tempo.
Terceiro: traces distribuídos. Um utilizador faz um request. Passa por load balancer, API gateway, serviço de autenticação, serviço de billing, base de dados. Um trace distribuído mostra o caminho completo e o tempo em cada passo. Sem isto, sabias que foi lento, mas não onde.
A diferença prática: monitorização diz "o P99 subiu para 2 segundos". Observabilidade diz "o P99 subiu porque o serviço de billing está a fazer 10 queries por request em vez de 1, porque uma migração de dados introduziu uma query sem índice".
Quando Começar a Investir
Há uma zona cinzenta. Startups de um mês com um só servidor não precisam de observabilidade sofisticada. Empresas com 50+ serviços em Kubernetes precisam. Onde está o ponto de viragem?
Fase 1: Monólito pequeno (até ~10M requests/mês)
Um único servidor Node.js ou Python. Uma base de dados. Um cache Redis.
Aqui, logging simples em ficheiro ou stdout, parser pelo terminal com grep e jq, basta. Podes fazer post-mortem de bugs em 10 minutos porque o código é teu, a história é linear. Custo: zero em ferramentas especializadas.
Exceção: se já enfrentas debugging difícil (concorrência, race conditions, timeouts intermitentes), um logging JSON estruturado em Postgres (uma tabela logs com JSONB) custa 2 horas a setup e poupar-te-á 40 horas/mês em debugging frustrado.
Fase 2: Microsserviços emergentes (10M a 100M requests/mês, 2-5 serviços)
Aqui aparecem os primeiros problemas: uma chamada de um serviço para outro demora mais que esperado. A taxa de erro no checkout subiu. Mas qual dos 3 serviços falhou?
Este é o momento para começar observabilidade séria. Não é opcional. Um erro que leva 2 dias a rastrear em produção custa mais que 6 meses de ferramentas.
Critérios concretos:
- Taxa de erro > 0.5% em produção (não esperado).
- P99 de latência degradou > 2x em 2 semanas.
- Tens 2+ serviços em produção comunicando entre si.
- Tens at least um "incident" por semana que levou > 30 minutos a resolver.
Fase 3: Escala alta (> 100M requests/mês, 10+ serviços)
Observabilidade é infraestrutura crítica, como databases. Não é opcional. Custos de ferramentas especializadas (DataDog, New Relic) tornam-se justificáveis porque ganhas na velocidade de resolução de incidents.
O Custo Real de Observabilidade
Isto é onde muitos enganam-se.
Uma solução SaaS como DataDog custa, realista, €200-500/mês para uma startup com 20M requests/mês. Inclui 5GB/dia de ingestão de logs, 15 dias de retenção, alguns traces. Escala? A €0.50 por GB de logs, em 100M requests/mês chegas a €1500+/mês rápido. Não é barato.
Alternativas abertas (Grafana Cloud + Prometheus + Loki + Jaeger):
- Prometheus/Grafana Cloud: €50-150/mês para métricas e dashboards (plano pro).
- Loki para logs: €30-100/mês ou self-hosted (custa infra: 1 servidor small, €20/mês).
- Jaeger para traces: €50-200/mês em managed ou self-hosted (mais 1 servidor).
- Total: €150-450/mês para infraestrutura, mas requer DevOps interno.
A verdade: se não tens DevOps dedicado, o tempo para setup e manutenção de stack aberto pode ser > custo de SaaS. Se tens, o ROI do open-source é melhor.
Para uma startup em Fase 2, recomendo: começa com um logging estruturado simples (JSON em stdout, parseado por um script Python em Postgres) + 3 métricas em Prometheus (tu instala o agent Prometheus node exporter num só servidor, custa 5 minutos). Custo: zero. Depois, conforme cresce, muda para stack mais robusta.
Setup Prático Começando do Zero
Assumi que tens uma API Node.js/Express em produção. Aqui está o mínimo viável sem gastar dinheiro.
Passo 1: Logs estruturados em JSON
Troca console.log("erro") por:
const logger = require('pino');
const l = logger({ level: process.env.LOG_LEVEL || 'info' });
app.post('/charges', (req, res) => {
const start = Date.now();
try {
// ... processamento
l.info({
method: 'POST',
path: '/charges',
user_id: req.user.id,
amount: req.body.amount,
duration_ms: Date.now(), start,
status: 200
});
} catch (err) {
l.error({
method: 'POST',
path: '/charges',
user_id: req.user.id,
error: err.message,
error_code: err.code,
duration_ms: Date.now(), start,
status: 500
});
}
});
Isto escreveJSON estruturado em stdout. Redireciona para ficheiro ou agregador.
Passo 2: 3 métricas em Prometheus
const promClient = require('prom-client');
const httpDuration = new promClient.Histogram({
name: 'http_request_duration_ms',
help: 'Duration of HTTP requests in ms',
labelNames: ['method', 'route', 'status_code'],
buckets: [50, 100, 200, 500, 1000, 2000, 5000]
});
const httpErrors = new promClient.Counter({
name: 'http_errors_total',
help: 'Total HTTP errors',
labelNames: ['method', 'route', 'error_code']
});
app.use((req, res, next) => {
const start = Date.now();
res.on('finish', () => {
const duration = Date.now(), start;
httpDuration.labels(req.method, req.route?.path || 'unknown', res.statusCode).observe(duration);
if (res.statusCode >= 400) httpErrors.labels(req.method, req.route?.path || 'unknown', res.statusCode).inc();
});
next();
});
app.get('/metrics', (req, res) => {
res.set('Content-Type', promClient.register.contentType);
res.end(promClient.register.metrics());
});
Instala Prometheus, aponta para http://localhost:3000/metrics, configure um gráfico simples. Custa 2 horas, custa zero euros.
Passo 3: Traces entre serviços (se tens 2+)
Usa OpenTelemetry com exportador para Jaeger local:
const opentelemetry = require('@opentelemetry/api');
const { NodeTracerProvider } = require('@opentelemetry/node');
const { JaegerExporter } = require('@opentelemetry/exporter-jaeger-http');
const jaegerExporter = new JaegerExporter({ endpoint: 'http://localhost:14268/api/traces' });
const tracerProvider = new NodeTracerProvider({ exporter: jaegerExporter });
opentelemetry.trace.setGlobalTracerProvider(tracerProvider);
const tracer = opentelemetry.trace.getTracer('api-service');
app.post('/charges', (req, res) => {
const span = tracer.startSpan('POST /charges');
span.setAttributes({ user_id: req.user.id, amount: req.body.amount });
// chamada para outro serviço propaga o trace automaticamente
const childSpan = tracer.startSpan('call-billing-service', { parent: span });
// ... código
childSpan.end();
span.end();
});
Jaeger local roda num contentor Docker. Vês o trace completo de um request entre serviços.
Armadilhas Comuns
1. Implementar observabilidade completa cedo de mais.
Vi startups a gastar €300/mês em DataDog com 5M requests/mês, coleccionando logs que ninguém lê. Resultado: 2 anos depois, factura acumulada de €7200, e debugging ainda tão lento quanto.
Começa simples. Expande conforme o problema aparecer.
2. Logs sem contexto.
error: timeout é inútil. error: timeout, user_id: 123, endpoint: POST /api/transfer, backend_service: payments-v2, duration_ms: 30000 é rastreável.
Estrutura sempre os logs. Custa 5% mais em performance (compressão JSON), poupa 95% do tempo de debugging.
3. Métricas demais.
Vi dashboards com 50 gráficos. Ninguém olha para 50 gráficos. Manténs 5-7 métricas críticas. Tudo o resto é logs.
4. Retenção indefinida de dados.
Guardar 2 anos de logs estruturados em Elasticsearch custa. Retenção tipicamente deve ser: logs com erro, 30 dias; logs normais, 7 dias; traces, 24 horas; métricas, 1 ano.
Quando Não Investir em Observabilidade Avançada
Ser honesto: há casos onde não vale a pena ainda.
Tens um dashboard SaaS com 50K utilizadores ativos, 5M requests/mês, tudo num monólito Ruby on Rails. Rails já vem com logging decente. A taxa de erro é < 0.1%. P99 é 150ms. Ninguém se queixa.
Aqui, investir em DataDog é desperdiço. Um logging estruturado simples em Rails (usar Lograge com JSON output) e um Prometheus scraper a fazer pull das métricas do Puma são mais que suficientes.
O custo de observabilidade sofisticada só se justifica quando o custo de downtime ou de debugging lento é > custo da ferramenta.
Roadmap Prático: Meses 1-12
Mês 1-2: Logging estruturado em JSON (Pino ou similar). Exporter para Postgres ou S3 para análise. Sem ferramentas externas.
Mês 3-4: 4 métricas críticas em Prometheus. Um dashboard Grafana (pode ser local). Time consegue fazer query SELECT COUNT(*) FROM logs WHERE error_code IS NOT NULL AND created_at > NOW(), INTERVAL '1 hour'.
Mês 5-6: Se já tens 2+ serviços, começa traces distribuídos com Jaeger local. DevOps instala numa single machine. Custo: ~€20/mês cloud instance.
Mês 7-12: Crescimento, aumenta a escala. Avalias: custo do stack aberto em DevOps vs custo de SaaS. Se tens 50M+ requests/mês, DataDog pode ser mais eficiente que manter infra.
Conclusão
Observabilidade não é um luxo de grandes empresas. Mas também não é necessária no dia 1. A métrica real: quando um incidente demora > 30 minutos a debugar, é hora de investir. Começa com logging estruturado (custa 2 horas, poupar-te-á semanas). Expande conforme o sistema cresce. Evita o cemitério de ferramentas caras que ninguém usa.
Se estás a enfrentar um problema parecido, marca uma conversa em https://impact-origin.com/agendamento.
