OpenObserve

Um único backend para os três sinais do OpenTelemetry — traces, métricas e logs — consultados com o mesmo SQL. A aplicação exporta OTLP direto para o OpenObserve, com um service.name que junta os três, e cada linha de log carrega o trace_id do span ativo: do log de erro se chega ao trace que mostra onde o tempo foi gasto, e as métricas de negócio mostram quantas vezes aquilo aconteceu.

passos: 6
arquivos: 7
testes: 0
tecnologias: 6

Infraestrutura realTypeScriptBunElysiaOpenTelemetryOpenObserveDocker

Cenário Relações Comparar

Baixar cartão

Cenário

O motor de pagamentos liquida doze PIX: sete liquidados, três com timeout no PSP e dois sem saldo. No OpenObserve, o SQL de logs devolve as falhas com o trace_id; seguindo um deles, o trace mostra pix.settle e psp.settle em ERROR com a exceção registrada. O SQL de traces aponta as chamadas ao PSP mais lentas, e o de métricas conta as liquidações por resultado — sem que o id da conta ou da transferência vire dimensão de métrica.

Planta

Fluxo

6/6

6 passos — reproduza para seguir o fluxo

chamada
resposta ou assíncrono
falha
passo
toque num nó para focar
Outras plantas de fluxo

Como funciona

6 passos

Três sinais OTel num backend.

Esconde cada passo: lembre antes de tocar para revelar.

Vocabulário compartilhado

service.name+3

@elysiajs/opentelemetry+3

instrumentation.ts+2

trace_id+2

span_id+2

Resource+1

Distributed Tracing

record()+1

Distributed Tracing

psp.settle+1

SigNoz — Observabilidade OpenTelemetry-nativa

01
instrumentation.ts é pré-carregado (bun --preload): um Resource com service.name e três exportadores OTLP, um por sinal, autenticados com HTTP Basic
02
O plugin @elysiajs/opentelemetry abre o span da requisição com a rota em template; record() abre pix.settle e psp.settle, e marca ERROR quando lançam
03
logInfo/logError emitem registros de log OTel com trace_id e span_id do span ativo
04
settlementMeasure incrementa pix_transfers_total e registra pix_transfer_duration_ms só por outcome e canal — ids ficam no span e no log
05
telemetryShutdown esvazia os lotes antes de o processo sair; sem ele o último lote, o do erro, se perde
06
search consulta traces, logs e métricas pela mesma API de SQL

Trade-offs

O que se ganha, o que se paga

4 vantagenscada ganho tem um preço4 custos

Vantagens

Um backend e uma linguagem de consulta para os três sinais
trace_id no log liga as falhas aos traces
Exporta direto por OTLP, sem Collector
Métricas por resultado custam poucas séries

Custos

Troca três ferramentas especializadas por uma generalista
Todo log precisa sair dentro de um span para carregar o trace_id
Trocar de backend exige mudar a aplicação; com Collector, só a configuração dele
Id de conta ou transferência como dimensão explodiria o armazenamento

apps/observability/openobserve

7 arquivos

src/

instrumentation.tsSDK com Resource único e exportadores OTLP de traces, métricas e logs
api_settlement.tsMotor de pagamentos: spans de negócio, log e métrica por liquidação
telemetry_log.tsLog OTel com trace_id e span_id, espelhado em JSON no stdout
metrics_pix.tsContador e histograma de liquidações por resultado
openobserve_search.tsSQL sobre os três sinais pela API de busca
config_openobserve.tsConfiguração validada do ambiente
demo.tsdemoDoze PIX e as três consultas, do log ao trace