Durante anos, monitorar sistemas significava acompanhar gráficos de CPU, métricas de disponibilidade e alguns logs soltos de aplicação. Esse modelo funcionava quando a infraestrutura era centralizada e as aplicações eram monolíticas. Em 2026, ele não funciona mais. As empresas operam em ambientes distribuídos, multicloud, cheios de microsserviços, funções serverless, integrações externas e tráfego imprevisível. A experiência do usuário depende de centenas de pontos ao longo do caminho. E, nesse novo cenário, “monitorar” é insuficiente, o que importa agora é observar.
A transição para o que chamamos de Observabilidade 2.0 não é moda, é maturidade. Ela nasce da necessidade de entender sistemas complexos de dentro para fora, correlacionando sinais, contexto e comportamento de maneira contínua. E é impulsionada por três forças: o avanço de OpenTelemetry, a centralidade dos SLIs e SLOs baseados em percentis (p95/p99) e a visão real da experiência obtida com RUM (Real User Monitoring). Juntas, essas práticas mudam como as equipes detectam incidentes, como investigam problemas e como medem a confiabilidade.
OpenTelemetry e o fim da telemetria fragmentada
O primeiro grande elemento da Observabilidade 2.0 é o abandono definitivo do modelo de telemetria fragmentada. No passado, logs ficavam num lugar, métricas em outro, traces em um terceiro. Não havia correlação natural, e investigar um incidente envolvia uma longa dança entre telas, ferramentas e suposições.
Com OpenTelemetry, a telemetria ganha um padrão aberto, consistente e independente de fornecedor. A mesma instrumentação gera logs, métricas e traces conectados por IDs comuns, seguindo convenções semânticas compartilhadas. Isso muda tudo. Ao investigar a latência de um endpoint crítico, por exemplo, a equipe consegue navegar do SLO que estourou para o span exato que degradou, e dali para os logs específicos daquela operação. Não é mais necessário adivinhar, a telemetria aponta, com precisão, onde e por que o sistema se comportou daquela maneira.
Em ambientes multicloud, OTel elimina outro problema recorrente: a dependência de agentes proprietários. Em vez de instrumentar cada nuvem com uma abordagem diferente, a empresa ganha portabilidade. E isso reduz custos, evita lock-in e aproxima engenharia, operação e segurança de uma mesma fonte de verdade.
RUM: quando a saúde real vem do lado do usuário
O segundo alicerce dessa nova fase é o Real User Monitoring. Em vez de medir apenas o que acontece no backend, o RUM captura a experiência real no navegador ou no aplicativo do usuário: tempo de carregamento, interatividade, erros de frontend, latência percebida e até variações regionais.
Por que isso importa? Porque, na prática, a experiência do cliente é determinada por uma cadeia de fatores (CDNs, redes móveis, caches, scripts, integrações, dispositivos, navegadores) que não aparecem quando olhamos apenas o servidor. É comum ver times celebrando “99,9% de uptime” enquanto usuários enfrentam telas travadas, carregamentos lentos e falhas esporádicas. Com RUM, esse descompasso desaparece. Os SLOs passam a refletir o que realmente importa: o que o usuário sentiu, e não o que a infraestrutura reportou.
SLOs p95/p99: a verdadeira medida de confiabilidade
Se existe um símbolo da Observabilidade 2.0, ele é a migração do “tempo médio” para os percentis.
A média sempre foi uma métrica confortável, fácil de calcular, bonita no gráfico, mas pouco fiel. Ela esconde a cauda de latência, dilui picos e suaviza problemas graves. Já os percentis p95 e p99 fazem exatamente o oposto: expõem a realidade.
Eles mostram o comportamento das requisições que mais importam: as mais lentas, mais sujeitas a erros e mais impactantes para o negócio. Em muitos casos, é justamente esse pequeno percentual que afeta clientes corporativos, horários de pico, fluxos financeiros ou integrações de alta sensibilidade. Medir confiabilidade por p95/p99 não é preciosismo técnico, é alinhamento com impacto real.
Com SLOs bem definidos, times passam a enxergar o serviço como um organismo vivo e guiado por objetivos. Se o p95 do checkout começa a degradar, a equipe age antes que se torne incidente. Se o p99 explodiu após um deploy, o problema é identificado em minutos, não horas. E, com o conceito de error budget, a empresa ganha um mecanismo claro de decisão entre lançar novas funcionalidades ou priorizar a saúde operacional.
A redução expressiva do MTTx: detectando antes, investigando mais rápido
Quando logs, métricas e traces estão unificados, quando RUM mostra a perspectiva do usuário e quando os SLOs apontam desvios estruturais, a redução de MTTx (MTTD, MTTI e MTTR) é inevitável.
A detecção melhora porque a equipe recebe sinais antecipados baseados em degradação e não apenas quedas totais. A investigação acelera porque os traces revelam onde o problema está, eliminando suposições. E a resolução se torna objetiva, porque o time sabe exatamente qual serviço, rota, dependência ou integração precisa de atenção.
Esse é o ponto da Observabilidade 2.0: menos incêndio, mais engenharia.
Um caso prático: rastreando a origem da lentidão “invisível”
Imagine uma empresa com forte operação digital, dezenas de microsserviços e presença multicloud. Tudo parecia estável nos dashboards: CPU normal, banco saudável, fila estável, mas o time de atendimento recebia um aumento constante de reclamações de lentidão no checkout.
Com Observabilidade 2.0, o diagnóstico deixou de ser mistério:
RUM mostrava que usuários de algumas regiões experimentavam picos de latência altos especificamente no momento de concluir a compra.
O SLO do checkout (p95) passou a ser violado de forma intermitente.
Os traces revelaram que a maior parte do tempo se perdia em uma integração com um serviço externo de antifraude, invisível no monitoramento tradicional.
Os logs correlacionados indicavam que, sob alta carga, essa dependência externa aumentava a latência em cascata, degradando a experiência mesmo quando o backend interno estava perfeito.
A solução é ajustar o fluxo: estratégias de caching, fallback controlado e revisão da dependência. Resultado: o p95 estabilizado, o SLO volta a ser cumprido e as reclamações cessam, tudo sem mudança estrutural de infraestrutura.
Esse tipo de clareza só existe quando a telemetria conversa, quando a experiência do usuário é medida de fato e quando as metas de confiabilidade são definidas com rigor.
Conclusão: saúde digital é resultado de visibilidade, não de intuição
Observabilidade 2.0 muda a forma como as empresas entendem seus sistemas. Ela não é apenas uma evolução técnica, mas uma mudança cultural.
Significa aceitar que:
- sistemas distribuídos falham de formas distribuídas;
- confiabilidade não é afetada apenas por CPU, mas por dependências, redes e usuários reais;
- métricas médias escondem problemas que percentis revelam;
- telemetria fragmentada produz investigação lenta e cara;
- e que sem SLOs claros, nenhuma decisão sobre estabilidade é verdadeiramente estratégica.
Na Hylink, tratamos a observabilidade como infraestrutura essencial. É ela que permite que times de engenharia, NOC, SRE e negócios conversem na mesma linguagem, a linguagem dos dados, não da percepção.
Se você deseja evoluir sua visibilidade operacional, reduzir MTTx e estruturar SLOs que façam sentido para o seu negócio, ajudamos você a construir essa nova camada de confiabilidade digital.
Fontes
CNCF / OpenTelemetry – Documentação oficial do projeto OpenTelemetry.
Google SRE – Site Reliability Engineering / The SRE Workbook.
Google Cloud – SLOs, SLIs and Error Budgets (Documentação oficial).
Dynatrace, New Relic, Datadog – Relatórios e guias de Observability / State of Observability.
W3C & Web Performance Working Group – Web Vitals e métricas de experiência no frontend.
