Skip to main content

Bring the senders you already run — and keep writing to the backend you already have

avuru obs team
Maintainers

Trying a new observability backend used to mean re-pointing or re-instrumenting every sender first. The gateway now speaks the protocols your fleet already emits, and can forward everything to your current backend at the same time.

Four more ways in​

The drop-in promise stopped at OTLP. A fleet already emitting Jaeger, Zipkin, Prometheus remote-write or Loki push had work to do before it could even try avuru obs. The gateway now accepts all four natively:

ProtocolPortEndpoint
Jaeger14250 (gRPC), 14268 (thrift/HTTP)avuruobs-gateway:14250, /api/traces
Zipkin9411/api/v2/spans
Prometheus remote-write9291/api/v1/write
Loki push3100/loki/api/v1/push
  • One values flag per protocol, every one off by default. An install that wants none renders byte-for-byte as it did before — no new ports, no new pipeline. See the OTLP bridge page for the per-protocol recipes.
  • No protocol gets a side door. Every enabled receiver joins the same tenant stage as OTLP, so per-project ingest keys are checked identically whatever wire format the data arrived on. Turning on a receiver never widens what an unauthenticated sender can do.
  • A receiver follows its signal's module. Remote-write needs infra metrics, Loki push needs logs — enabling one for a signal you do not store is quietly a no-op rather than a surprise later.
  • Two limits, stated rather than hidden. Jaeger over UDP is not offered: it carries no authentication hook, and the agent it belongs to is deprecated upstream. Remote-write is protocol v2 only — a v1 sender is refused with 415 instead of having its samples dropped in silence.

Dual-write while you make up your mind​

Adopting a backend should be a reversible decision, and evaluating one usually means running two at once. gateway.forward.otlp and gateway.forward.kafka send everything the gateway ingests to a second destination as well — the backend you run today, or a Kafka topic another team owns.

  • A dead target cannot hurt the live one. Forwarders always render with a bounded sending queue and retry, so a second backend going down can never backpressure the write path into storage. That failure is precisely what makes people distrust dual-write.
  • Credentials stay out of config. Kafka SASL comes only from an existing Secret, never inline, so it never lands in a ConfigMap.
  • Misconfiguration fails loudly. A forwarder enabled with no endpoint or no brokers stops the render instead of quietly forwarding nowhere.

The claim is tested, not asserted​

Every protocol above is exercised for real in CI: a genuine Jaeger batch, a Zipkin span, a snappy-framed remote-write sample and a Loki push are sent through the receivers a real Helm install renders, then the rows are asserted in storage and the forwarded trace is checked arriving at a stand-in second backend. The compatibility claim is a gate, like the five-minute wedge, rather than a sentence in a README.