OpenTelemetry: o padrão que mudou as regras
Antes do OpenTelemetry, instrumentar para observabilidade significava escolher um fornecedor (Datadog, New Relic, Dynatrace) e instalar o seu agente proprietário em cada serviço. Mudar de fornecedor significava reinstrumentar toda a aplicação. O custo desse lock-in era real e calculável, e levou muitas equipas a renovar contratos por inércia em vez de por valor.
O OpenTelemetry (OTel) quebra esse modelo ao separar a instrumentação do backend de destino. Instrumenta-se uma vez com as APIs e SDKs do OTel — disponíveis para todas as linguagens principais — e configura-se o Collector para enviar dados para qualquer backend compatível. Migrar do Datadog para o Grafana Tempo, ou adicionar um segundo backend para comparação, torna-se configuração, não código.
Em 2025, o OTel é o padrão de facto. Os três sinais principais — traces, métricas e logs — têm especificações estáveis e SDKs maduros. A instrumentação automática para os frameworks mais utilizados (Express, FastAPI, gRPC, Spring Boot, .NET) cobre a maioria dos casos sem modificar o código da aplicação. A adoção em novos projetos deve ser a opção por defeito, não uma decisão a avaliar.
SLOs: gerir a fiabilidade com contratos explícitos
Os Service Level Objectives são a ferramenta mais poderosa para alinhar equipas de engenharia com as expectativas do negócio sobre fiabilidade. Um SLO transforma 'o sistema tem de estar disponível' em '99,5% dos pedidos devem completar em menos de 500ms, medido numa janela de 28 dias'. Essa especificidade muda fundamentalmente a forma como a equipa prioriza o trabalho.
O conceito de error budget é a consequência mais valiosa dos SLOs: se o objetivo é 99,5% de sucesso, tem um orçamento de 0,5% de falhas. Enquanto esse orçamento não está esgotado, a equipa pode fazer deploy com confiança e aceitar algum risco. Quando o orçamento está perto de ser esgotado, os alertas mudam: não se alerta sobre erros individuais, alerta-se sobre o consumo do error budget. Esta distinção elimina o ruído de alertas de baixa gravidade a que ninguém presta atenção e foca a atenção no que importa.
Implementar SLOs corretamente requer escolher os SLIs (Service Level Indicators) certos — as métricas que representam verdadeiramente a experiência do utilizador, não as métricas de infraestrutura que são fáceis de medir mas proxies imperfeitos. Para serviços HTTP, a taxa de sucesso e a latência no percentil 95 são geralmente os indicadores certos. Para sistemas de processamento em batch, o throughput e o lag da fila. Escolher o indicador certo é mais difícil do que a implementação técnica.
Correlação de sinais: dos dados ao diagnóstico
Os três sinais de observabilidade — métricas, logs e traces — têm valor limitado em isolamento. Uma métrica que mostra latência elevada diz que há um problema. Um log com um erro diz onde está o problema. Um trace distribuído mostra o caminho completo percorrido pelo pedido falhado. A correlação automática entre estes três sinais é o que reduz o tempo de diagnóstico de horas para minutos.
A correlação funciona quando os três sinais partilham contexto comum: um trace ID que aparece tanto no span do trace como no log gerado durante esse pedido, e uma tag de serviço que liga a métrica de latência ao serviço específico que o trace identifica como bottleneck. Isso não acontece sozinho — requer que a instrumentação seja consistente e que o pipeline de dados (o OTel Collector, o agente de logs) propague estes identificadores sem os truncar.
As plataformas que melhor implementaram esta correlação em 2025 são o Grafana Stack (com Tempo para traces, Loki para logs e Mimir/Prometheus para métricas), o Honeycomb (com o seu modelo de wide-events que unifica os três tipos numa única estrutura), e o Datadog APM com o seu Log Management integrado. A escolha entre elas depende mais do tamanho da equipa, do volume de dados e do modelo económico do que de diferenças técnicas fundamentais.
AIOps: onde a IA entrega valor real nas operações
AIOps é um dos termos mais sobrecarregados da indústria. Na prática, existem três áreas onde os modelos de ML aplicados a operações demonstram valor real e repetível: redução de ruído de alertas (agrupamento de alertas relacionados num único incidente), deteção de anomalias em séries temporais (identificar padrões incomuns antes de se manifestarem como falhas) e análise assistida de causa raiz (correlacionar o timing do incidente com deployments recentes, alterações de configuração e eventos de infraestrutura).
A deteção de anomalias tem o maior impacto demonstrado em produção. Sistemas que geram milhões de métricas por minuto não podem ser monitorizados com thresholds manuais — há demasiadas variáveis e demasiados padrões sazonais (horas de pico, ciclos semanais, efeitos de campanhas de marketing) para definir thresholds estáticos que sejam sensíveis mas não gerem falsos positivos. Os modelos de séries temporais treinados no comportamento histórico do sistema detetam desvios estatisticamente significativos com uma taxa de falsos positivos consistentemente inferior à dos thresholds manuais.
A análise automatizada de causa raiz é a área com maior potencial e maior margem de maturação. As ferramentas atuais (Moogsoft, BigPanda, Dynatrace Davis AI) são úteis para incidentes com causas raiz numa alteração recente bem documentada, mas têm limitações significativas para incidentes com causas acumuladas ou em sistemas com alta interdependência. A direção de integrar LLMs com contexto de observabilidade para gerar hipóteses de causa raiz é promissora — os primeiros produtos nesta linha (Datadog Bits AI, Grafana Sift) estão em produção mas ainda em adoção inicial.
Quanto tempo demora a sua equipa a diagnosticar um incidente?
Desenhamos e implementamos o seu stack de observabilidade de raiz ou melhoramos o existente: OTel, SLOs, correlação e redução de ruído. Com métricas de melhoria mensuráveis desde o primeiro dia.