Observabilidade: quando vale a pena investir a sério

Observabilidade não é “ter logs”. É conseguir responder a perguntas novas sobre produção sem lançar código novo.
Começa cedo com o básico: logs estruturados, métricas de negócio críticas, erros centralizados e identificadores de correlação.
Investe a sério quando já tens utilizadores reais, integrações externas, pagamentos, SLAs internos ou incidentes repetidos sem causa clara.
OpenTelemetry é hoje a escolha sensata para instrumentação, porque reduz dependência de fornecedor e suporta métricas, traces e logs.
O maior erro é recolher tudo sem critério. Observabilidade sem orçamento de cardinalidade, retenção e alertas vira ruído caro.

Observabilidade não é monitorização com outro nome

Monitorização responde a perguntas que já conheces: “a API está de pé?”, “a CPU passou dos 80%?”, “há erros 500?”. É útil, mas limitada. Observabilidade responde a perguntas que ainda não sabias que ias precisar: “porque é que os clientes de um determinado plano têm checkout lento?”, “qual integração externa aumentou o p99?”, “que fila está a acumular jobs depois do deploy?”.

A diferença prática está no tipo de dados e na forma como os ligas.

Os quatro sinais que costumo considerar obrigatórios são:

Métricas: séries temporais agregadas. Exemplo: latência p95, p99, taxa de erros, pedidos por segundo, jobs processados por minuto.
Logs estruturados: eventos discretos com campos pesquisáveis, não texto solto.
Traces distribuídos: percurso de um pedido por API, filas, bases de dados e serviços externos.
Erros e excepções: stack traces agrupadas, com versão da aplicação, utilizador afectado quando permitido e contexto operacional.

Perfis de CPU e memória também entram na conversa, mas normalmente não são o primeiro investimento. São valiosos quando a aplicação já tem carga suficiente para justificar análise contínua de performance.

A definição que uso em equipas pequenas é simples: se um cliente reportar “está lento”, deves conseguir descobrir em menos de 15 minutos se o problema está no browser, API, base de dados, fila, serviço externo ou dados específicos daquele cliente. Se não consegues, não tens observabilidade suficiente.

O mínimo viável para começar bem

Não recomendo começar com uma plataforma cara, dashboards bonitos e 40 alertas. Isso dá uma falsa sensação de controlo. O mínimo viável deve ser pequeno, consistente e aplicado desde o início.

Para uma aplicação SaaS B2B típica em Node.js 22 LTS, PostgreSQL 16 e uma API HTTP, eu começaria por isto:

Logs em JSON, com request_id, user_id quando permitido, tenant_id se for multi-tenant, route, status_code, duration_ms e service_version.
Métricas RED para APIs: rate, errors, duration. Isto vem da prática da Google SRE e continua a ser uma base excelente.
Métricas USE para infra-estrutura: utilisation, saturation, errors. CPU, memória, disco, conexões à base de dados e filas.
Captura centralizada de excepções. Sentry é muitas vezes suficiente no início.
Health checks reais. Não basta responder 200 OK; verifica base de dados, Redis, filas e dependências críticas.
Um identificador de correlação que acompanha o pedido entre frontend, backend, jobs e webhooks.

Um exemplo curto em Express mostra a ideia. Não é a ferramenta que interessa, é a disciplina de contexto:

app.use((req, res, next) => {
  const startedAt = performance.now();
  req.requestId = req.header("x-request-id") ?? crypto.randomUUID();

  res.setHeader("x-request-id", req.requestId);

  res.on("finish", () => {
    logger.info({
      event: "http_request",
      request_id: req.requestId,
      method: req.method,
      route: req.route?.path ?? req.path,
      status_code: res.statusCode,
      duration_ms: Math.round(performance.now(), startedAt)
    });
  });

  next();
});

Isto parece básico, mas é aqui que muita equipa falha. Se os logs não tiverem campos consistentes, vais acabar a fazer pesquisa por texto durante um incidente. Pesquisa por texto em produção, às 02:00, é uma forma cara de descobrir que faltou disciplina técnica.

Em projectos numa fase muito inicial, como clientes ainda sem billing definido ou em validação de produto, não faz sentido vender uma stack pesada de observabilidade. Faz sentido deixar a aplicação preparada: logs estruturados, erros centralizados e métricas essenciais. O custo marginal é baixo e evita reescrita quando a aplicação começar a ter tráfego real.

Quando começar a investir mais a sério

A resposta curta: antes do primeiro incidente caro. A resposta honesta: quase ninguém faz isso. Portanto, uso sinais concretos.

Começa a investir a sério quando pelo menos dois destes pontos forem verdade:

Tens clientes pagantes e uma falha de produção já tem impacto comercial.
Tens integrações externas críticas: pagamentos, ERP, CRM, transportadoras, bancos, serviços de saúde, autenticação externa.
Tens jobs assíncronos, webhooks ou sincronizações onde o erro não aparece imediatamente ao utilizador.
Tens mais do que uma aplicação ou serviço em produção.
O p95 ou p99 de endpoints críticos já interessa. Por exemplo, checkout acima de 2 segundos ou pesquisa acima de 500 ms.
Tens incidentes em que a equipa demora mais de 30 minutos a perceber a causa.
Tens deploys frequentes e precisas de saber rapidamente se uma versão piorou latência, erros ou consumo de recursos.
Tens obrigações contratuais, mesmo que informais. Por exemplo, responder a problemas de clientes empresariais em horário útil.

Para uma aplicação interna com 20 utilizadores, logs bons e Sentry podem chegar durante muito tempo. Para um SaaS com multi-tenancy, billing, permissões e integrações, traces começam a pagar-se depressa. Para eCommerce, onde um problema de checkout tem impacto imediato, eu colocaria métricas de funil e alertas de erro muito cedo.

A métrica que muda a conversa é MTTR, mean time to recovery. Se cada incidente demora 2 horas a diagnosticar, e tens 2 incidentes por mês, estás a perder tempo técnico que podia estar em produto. Observabilidade não elimina incidentes. Reduz o tempo em que andas às cegas.

Ferramentas: comprar, alojar ou misturar

Não há uma resposta universal. Há compromissos.

Sentry é uma escolha muito boa para erros de aplicação. Agrupa excepções, mostra releases, browser, stack trace e impacto por utilizador. Para equipas pequenas, costuma trazer valor em horas. O limite é que não substitui métricas de infra-estrutura nem traces completos em sistemas mais distribuídos.

Grafana, Prometheus e Loki são atractivos quando queres controlo e custo previsível. Prometheus 2.x continua excelente para métricas. Grafana 11 é uma interface madura para dashboards e alertas. Loki é interessante para logs quando aceitas o modelo de labels com cuidado. O custo escondido está na operação: retenção, backups, actualizações, storage, tuning e alertas. Uma VM de 20 a 80 euros por mês pode parecer barata, mas se alguém gastar meio dia por mês a manter a plataforma, esse custo já mudou.

Datadog, New Relic, Honeycomb e Grafana Cloud reduzem operação e aceleram adopção. São fortes em traces, APM, dashboards e correlação. O problema é custo variável. Logs com 10 GB por dia, cardinalidade alta em métricas ou traces sem sampling podem tornar a factura desagradável. Consulta sempre a página de preços actual e testa com tráfego real durante uma ou duas semanas.

OpenTelemetry, documentado em opentelemetry.io, é hoje a camada que eu tentaria pôr entre a aplicação e o fornecedor. A especificação W3C Trace Context também é importante, porque define como propagar contexto entre sistemas através de headers como traceparent.

Comparação prática:

Sentry mais Prometheus: bom para começar. Baixo esforço, boa cobertura de erros e métricas. Menos forte em traces distribuídos complexos.
Grafana stack auto-alojada: bom controlo e custo previsível. Exige conhecimento operacional e disciplina de retenção.
Datadog ou New Relic: excelente tempo até valor. Pode ficar caro se mandares logs e traces sem política.
OpenTelemetry com fornecedor gerido: boa portabilidade e instrumentação moderna. Exige desenho inicial mais cuidado.

Se estás em SaaS B2B pequeno, eu começaria por Sentry, logs estruturados e métricas essenciais. Quando integrações e jobs crescerem, adicionaria OpenTelemetry e traces. Só depois decidiria se vale a pena uma plataforma completa.

O desenho técnico que evita arrependimentos

A pior observabilidade é a que cresce por acidente. Cada biblioteca manda logs num formato diferente, cada serviço inventa nomes de métricas, cada alerta grita por razões diferentes.

Define convenções cedo:

Nome do serviço: billing-api, customer-portal, worker-sync.
Ambiente: production, staging, preview.
Versão: commit SHA ou versão semântica.
Tenant ou organização: apenas se for seguro e necessário.
Rotas normalizadas: /customers/:id, não /customers/123.
Unidades explícitas: duration_ms, payload_bytes, queue_lag_seconds.

A normalização de rotas é mais importante do que parece. Se criares uma série temporal por cada URL com ID, destróis a cardinalidade. Cardinalidade alta significa demasiadas combinações de labels. Em Prometheus, isto aumenta memória e pode degradar queries. Em fornecedores geridos, aumenta custo.

Uma configuração mínima de OpenTelemetry em Node.js mostra o ponto principal: serviço, versão, exportador e instrumentações automáticas. Não é preciso encher a base de código de spans manuais no primeiro dia.

import { NodeSDK } from "@opentelemetry/sdk-node";
import { getNodeAutoInstrumentations } from "@opentelemetry/auto-instrumentations-node";
import { OTLPTraceExporter } from "@opentelemetry/exporter-trace-otlp-http";
import { resourceFromAttributes } from "@opentelemetry/resources";

const sdk = new NodeSDK({
  resource: resourceFromAttributes({
    "service.name": "customer-api",
    "service.version": process.env.GIT_SHA ?? "unknown",
    "deployment.environment": process.env.NODE_ENV ?? "development"
  }),
  traceExporter: new OTLPTraceExporter({
    url: process.env.OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
  }),
  instrumentations: [getNodeAutoInstrumentations()]
});

sdk.start();

Depois adicionas spans manuais apenas nos pontos que importam: chamadas a ERP, pagamentos, geração de PDFs, sincronização de stock, jobs de importação, queries críticas. Instrumentar tudo manualmente é desperdício e aumenta ruído.

Também deves separar métricas técnicas de métricas de produto. http_requests_total não substitui checkout_completed_total. Se uma plataforma de retail tem API saudável mas checkouts a cair, a infra-estrutura está “verde” e o negócio está a arder.

Alertas que prestam e alertas que só acordam pessoas

Um alerta bom obriga a acção. Um alerta mau informa que o mundo é imperfeito.

Não faças alertas por CPU acima de 80% durante 1 minuto, a menos que saibas que isso causa impacto real. CPU alta pode ser normal em batch jobs. Também não alertes por cada erro 500 isolado. Um erro pode ser irrelevante; uma taxa de erro de 5% durante 10 minutos num endpoint crítico já é outra conversa.

Alertas úteis:

Taxa de erro 5xx acima de 2% durante 5 minutos em endpoints críticos.
p95 acima de 1 segundo durante 10 minutos na API principal.
p99 acima de 3 segundos no checkout ou pagamento.
Fila com lag acima de 5 minutos.
Webhooks falhados consecutivamente para o mesmo fornecedor.
Base de dados com conexões acima de 80% do limite durante 10 minutos.
Certificado TLS a expirar em menos de 14 dias.
Espaço em disco acima de 85% com tendência de crescimento.

Também gosto de alertas por sintomas, não só por causas. “Clientes não conseguem pagar” é melhor do que “CPU alta no worker 3”. A causa interessa para resolver; o sintoma interessa para priorizar.

A documentação de Prometheus sobre alerting rules e Alertmanager é uma boa base. Mas a parte difícil não é a sintaxe. É decidir quem recebe, quando recebe e o que faz. Cada alerta deve ter dono, severidade e runbook curto. Se ninguém sabe o que fazer, o alerta ainda não está pronto.

Armadilhas comuns em produção

A armadilha mais comum é confundir volume com visibilidade. Equipas mandam todos os logs para uma plataforma, sem estrutura, sem amostragem e sem retenção pensada. Durante o incidente têm milhões de linhas e pouca informação.

Outra armadilha: meter user_id, email, payloads completos ou dados pessoais em logs. Em Portugal e na União Europeia, isto toca em RGPD. Logs devem seguir minimização de dados. Guarda identificadores internos quando necessário, evita dados sensíveis, aplica retenção curta e controla acessos. Em healthtech ou fintech, isto deixa de ser detalhe técnico e passa a ser risco sério.

Terceira: dashboards para impressionar, não para operar. Um dashboard com 30 gráficos é bonito numa reunião e inútil num incidente. Prefiro três ecrãs simples:

Saúde do produto: logins, checkouts, pagamentos, sincronizações, erros por cliente.
Saúde da API: tráfego, latência p50, p95, p99, erros, saturação.
Saúde dos workers e integrações: filas, retries, webhooks, tempos por fornecedor.

Quarta: não ligar deploys a métricas. Se não consegues ver que o deploy abc123 aumentou o p95 de 180 ms para 650 ms, vais perder tempo a discutir opiniões. Liga releases, commits e feature flags à observabilidade.

Quinta: ausência de sampling em traces. Traçar 100% dos pedidos pode ser aceitável com 1000 pedidos por dia. Com 300 pedidos por segundo, pode ficar caro e desnecessário. Uma abordagem prática é manter 100% dos traces com erro, uma amostra dos pedidos normais e amostragem maior em endpoints críticos.

Quanto investir em cada fase

Pensa em fases, não em maturidade abstracta.

Fase 0, protótipo ou validação: logs estruturados locais, Sentry ou equivalente, health check simples. Custo baixo. Não compliques.

Fase 1, primeiros clientes reais: logs centralizados, métricas RED, dashboard de API, alertas básicos, releases associadas a erros. Objectivo: diagnosticar incidentes simples em menos de 30 minutos.

Fase 2, produto com integrações e jobs: traces com OpenTelemetry, métricas de filas, webhooks, fornecedores externos, dashboards de negócio, runbooks. Objectivo: perceber falhas assíncronas e degradações parciais.

Fase 3, escala e equipa maior: SLOs, error budgets, on-call formal, retenção por tipo de dado, sampling, revisão mensal de alertas, testes de carga. Aqui já faz sentido discutir p99 abaixo de 100 ms em endpoints internos específicos, ou throughput de 300 RPS com margem conhecida.

Observabilidade é investimento técnico com retorno operacional. Não deve nascer de medo, nem de moda. Deve nascer de perguntas concretas que a equipa precisa de responder depressa.

Conclusão

Observabilidade boa começa pequena, mas tem de começar com disciplina. Logs estruturados, métricas certas, erros centralizados e contexto de correlação resolvem mais problemas do que uma plataforma cara mal configurada.

Investe mais quando o impacto de não saber é maior do que o custo de instrumentar. Se estás a enfrentar um problema parecido, marca uma conversa em https://impact-origin.com/agendamento.