Hanzo Telemetry
The collector that sits between your app and wherever the data goes
Your services talk to it instead of talking to a backend. It receives OTLP, batches it, holds a memory ceiling so a traffic spike cannot take the host down with it, and forwards onward. Change where the data goes by editing its config — not by redeploying every service that produces the data.
One hop you control
The last place your telemetry is yours before it goes anywhere.
OTLP in, OTLP out
Receives over gRPC and HTTP, exports the same way. OTLP is the format the OpenTelemetry SDKs already speak, so nothing in your code changes to point at it.
Traces, metrics and logs
All three move through the same process, so there is one thing to run, one config to read and one place to look when telemetry stops arriving.
Batching
Spans arrive one at a time and leave in batches. That is the difference between a request per span and a request per few thousand, and your backend feels it.
A memory ceiling
Tell it how much memory it may use and it refuses work rather than exceeding it. Telemetry is the thing that should degrade during an incident, not the thing that causes one.
Assembled, not installed
This is the collector itself. Build a distribution with the receivers, processors and exporters you actually want, and ship one binary containing those and nothing else.
It runs where you run
A binary in your own network. Whatever you decide not to forward, you decide before the data has left — which is the only point where that is still your call.