TL;DR: Pegamos um monólito PHP (Zend), aplicamos OpenTelemetry com foco em tracing, padronizamos spans/atributos, integramos com Grafana Tempo e Loki, e colhemos ganhos mensuráveis (redução de p95 e menos instabilidade). Aqui estão as decisões práticas, armadilhas e checklist para você repetir — sem pânico e sem reescrever o sistema.
Contexto: por que mexer no vespeiro?
Toda equipe tem aquele serviço que “funciona… até quando não funciona”. No nosso caso, um monólito PHP com dependências antigas, endpoints críticos e comportamento errático sob carga. Precisávamos de visibilidade de ponta a ponta para responder três perguntas simples: o que está lento, por que está lento e quanto custa acelerar. Em vez de um APM fechado, apostamos em OpenTelemetry (OTel) para capturar traces, métricas e logs de forma aberta e portátil.
Por que OpenTelemetry no PHP (e no legado)?
Padrão de mercado: SDKs e semântica compartilhada com outras linguagens.
Neutralidade: não nos amarrou a um fornecedor; pudemos enviar dados para Grafana Tempo sem fricção.
Custo-controlável: amostragem, filtros e enriquecimento nos deu autonomia para equilibrar ruído, latência e conta de storage.
“Mas é Zend, não Laravel…”
Sim, e tudo bem. Começamos pela auto‑instrumentação para HTTP, DB e alguns frameworks comuns; onde não havia gancho pronto, adicionamos spans manuais nos fluxos mais críticos. O segredo foi padronizar nomes/atributos para que os gráficos fizessem sentido para devs e SREs.
Custos, overhead e o que realmente importa
Overhead: aceitável quando a amostragem é bem calibrada. Endpoints “quentes” exigem sampling lower.
Armazenamento: retenção por criticidade. Incidentes ganham retenção maior via tags.
CPU/memória: atenção em serialização e flush do SDK; preferimos gRPC pelo footprint e backoff nativo.
Resultados: “quase APM”, com stack aberta
Queda de p95 em rotas críticas após identificar 2 queries N+1 e um cache mal configurado.
Menos incidentes fantasma: correlação log↔trace reduziu MTTR.
DX melhor: devs rodam o serviço com tracing em ambiente local e replicam problemas.
Armadilhas e como evitamos
Ruído: spans demais cansam. Use filtros por rota e limite atributos.
Cardinalidade: cuidado com atributos altamente variáveis (ex.: IDs longos). Faça hashing ou bucketização.
Fuga de dados: aplique redatores no Collector; trate cabeçalhos sensíveis como PII.
Dívida antiga: não tente “corrigir o mundo” em uma sprint; ataque os fluxos de maior impacto primeiro.
Links Importantes:
- Marcelo França - https://www.linkedin.com/in/marceloluizfranca
- Francisco Rodrigues - https://www.linkedin.com/in/fcoedno
- Artigo inspirador - https://medium.com/engenharia-arquivei/instrumente-sua-aplica%C3%A7%C3%A3o-php-com-opentelemetry-cb3460a64d04
- Conheça a Qive - https://qive.com.br/institucional/
- Opentelemetry PHP - https://opentelemetry.io/docs/languages/php/
- João Brito - https://www.linkedin.com/in/juniorjbn/
Conclusão
A moral da história é simples: observabilidade é produto, não projeto. Quando tratamos tracing, métricas e logs como parte do ciclo de desenvolvimento, decisões difíceis ficam mais baratas. E sim, dá para modernizar um legado sem reescrever tudo — uma span por vez.
Se curtiu, ouça o episódio completo do Kubicast #191 e conte para a gente como você está instrumentando seus serviços. Queremos suas histórias de guerra e, claro, suas vitórias!