Observabilidade nasce by design — não na ferramenta

Uma pergunta para quem já esteve numa war room

Quanto tempo do último incidente você passou procurando dados que simplesmente não existiam?

Não falo de dashboard mal configurado. Falo daquele momento específico em que o engenheiro de plantão percebe que o span não foi criado, que o log não tem o trace_id, que o erro foi engolido por um catch silencioso três deploys atrás. O incidente não é resolvido com a ferramenta certa — ele é resolvido com a instrumentação que deveria estar lá, mas não está.

O Splunk State of Observability 2025, com 1.855 profissionais entrevistados, mostrou que 82% dos times levam mais de uma hora para resolver incidentes em produção. A diferença raramente está na plataforma de observabilidade escolhida. Está no que foi instrumentado antes do incidente acontecer.

Gaps de observabilidade são invisíveis até o pior momento

A natureza dos gaps de instrumentação é traiçoeira: eles não aparecem em code review, não quebram testes, não são detectados por linters tradicionais. Eles só se manifestam quando você precisa deles — e aí já é tarde.

Os padrões mais comuns que vemos em postmortems:

O endpoint crítico sem span. A rota /checkout/confirm processa milhões em transações por dia, mas o handler nunca foi envelopado por um tracer.start_as_current_span. Quando a latência explode, não há como saber se o gargalo é DB, fila ou chamada externa.
O erro silenciado no catch. Um try/except: pass em um worker assíncrono que processa pagamentos. O job falha em produção há semanas. Ninguém sabe porque não há log, não há métrica de erro, não há alerta.
A dependência externa sem timeout instrumentado. Uma chamada HTTP para um serviço de terceiros sem timeout explícito e sem span — quando o serviço degrada, sua aplicação degrada junto, e o gráfico que mostra isso não existe.
O SLO que existe no conceito mas não na prática. O time definiu "99.9% de disponibilidade no checkout", mas a métrica que sustentaria esse SLO nunca foi emitida. O SLO vive no Notion, não no Prometheus.
A label de alta cardinalidade que ninguém percebeu. Alguém adicionou user_id como label de uma métrica. Três meses depois, o custo de observabilidade triplicou e o time não sabe por quê.

Esses gaps não são falhas de competência. São consequências naturais de prazos apertados, rotação de time, refatorações que esqueceram um detalhe, e da impossibilidade humana de revisar instrumentação em todo PR com a mesma rigor que se revisa lógica de negócio.

Observabilidade não mora só na ferramenta

Um grupo de especialistas — gente que viveu war rooms, escreveu postmortems, e cansou de descobrir o mesmo padrão dezenas de vezes — se reuniu para mudar esse paradigma.

A premissa do Horion é simples: observabilidade nasce by design, do produto ao código. Ela precisa ser tratada como uma propriedade do software, validada continuamente, com a mesma seriedade que se trata segurança ou performance.

O Horion analisa seus repositórios e pull requests buscando exatamente o que escapa do code review humano:

Funções que afetam dados críticos (pagamentos, estoque, autenticação) sem cobertura de spans
Chamadas de I/O sem instrumentação adequada (DB, HTTP clients, message brokers)
Logs não estruturados em hot paths
Métricas com cardinalidade explosiva (trace_id, user_id, request_id como labels)
Spans criados dentro de loops (N+1 span pattern)
Health checks sendo traçados a 100% (custo desnecessário, ruído puro)
Contexto de trace perdido em goroutines, threads ou tarefas assíncronas
IaC sem alarmes correspondentes (SQS sem CloudWatch Alarm, Lambda sem layer de observabilidade)
Falta de tags obrigatórias (env, service, team, cost-center)

Cada finding vem com a sugestão de código exata, posicionada no arquivo e linha corretos, usando o SDK do OpenTelemetry (vendor-neutral). Quando aplicável, o impacto mensal estimado em USD acompanha o finding — porque observabilidade mal feita não é só ruim para SRE, é cara.

Vendor-agnóstico não é detalhe, é princípio

Não importa qual stack você usa: Datadog, New Relic, Grafana, Honeycomb, Splunk, ou um setup self-hosted com Jaeger e Tempo. O Horion gera código baseado em OpenTelemetry — o padrão da indústria — porque sua instrumentação deve sobreviver à decisão sobre qual backend você usa hoje, amanhã, e daqui a três anos.

Para nós, o que importa não é onde sua telemetria mora. É a confiabilidade que sua aplicação precisa entregar.

O que isso muda na prática

Em vez de descobrir gaps de instrumentação no meio de um incidente às 3 da manhã, você os recebe:

Em cada PR, como um review comment automático com a sugestão de diff aplicável
Em análises manuais sob demanda, quando você quer auditar um serviço inteiro
Em análises agendadas, semanais ou diárias, para manter a saúde da telemetria do seu repositório como um indicador contínuo

Cada análise produz um score por pilar (métricas, logs, traces) e por dimensão (custo, sinal/ruído, pipeline, compliance) — não para gamificar, mas para dar a você uma leitura objetiva da maturidade de observabilidade do seu código, e do que mudou entre um deploy e outro.

Acesso antecipado — vagas limitadas

Estamos abrindo o Horion para usuários e empresas que queiram contribuir com nossa evolução, e que vivam, no dia a dia, as dores que nossa missão endereça.

Neste primeiro momento, oferecemos um número limitado de planos Free e Beta.

👉 Acesse https://horion.pro

⚠️ Disclaimer: estamos em fase inicial de testes, validando a plataforma com um grupo seleto de times parceiros e refinando precisão dos findings, UX e pricing com base em feedback real. Se você toparia trocar acesso antecipado por feedback honesto e crítico, é exatamente com você que queremos conversar.