Skip to content

Where the data goes

Level: 201 → 301 · deep dive

One line: Your process should hand telemetry to something local as fast as it can and forget about it; retries, buffering, redaction and routing belong outside the program.

Stub — an outline, not a lesson. There is no runnable example behind this page yet, so nothing on it has been through the check that backs every other claim in this library. The bullets below are the questions the finished page has to answer.

What it has to cover

  • The path, once, concretely: instrumentation → a batch processor in the SDK → an OTLP exporter → a collector ↗ → one or more backends (traces, metrics and logs usually land in different stores) → whatever UI the team actually opens.
  • Why a collector rather than exporting straight to the vendor: your program stops knowing endpoints and API keys, sampling and redaction change without a redeploy, and one agent per host replaces one exporter per process.
  • The failure that matters more than any of it — telemetry that can take the service down. Bounded queues, batching, and dropping on overflow. Dropping spans is correct behaviour, and the finished page has to say where the drop count shows up, because a silent drop is indistinguishable from an instrumentation bug.
  • Shutdown, which is where the most interesting spans are lost: the process ends, the queue still holds the batch describing the crash, and nothing flushed it. What a flush-on-exit looks like, and why the last trace before a restart is the one you wanted.
  • What the Rust page must show concretely: where the batch processor is configured, what its queue bound is, and what the program does when the collector is simply not there.

The trap it exists for

The exporter in the request path. A synchronous send, an unbounded queue, or a blocking flush turns your observability stack into a dependency of every request — and the first thing you learn from it is that it went down with you.

See also

Po polsku

Reguła jest jedna i po polsku daje się powiedzieć w pół zdania: oddaj telemetrię czemuś lokalnemu tak szybko, jak potrafisz, i zapomnij o niej — ponawianie, buforowanie, redakcja i trasowanie należą do collectora, poza twoim procesem, bo dopiero tam da się je zmienić bez ponownego wdrożenia i bez trzymania w kodzie adresów oraz kluczy dostawcy. Wynika z tego zdanie, które budzi opór, a jest prawdziwe: porzucanie spanów przy przepełnionej kolejce to zachowanie poprawne, pod jednym warunkiem — licznik porzuceń musi być widoczny, bo ciche porzucenie jest nie do odróżnienia od błędu w instrumentacji. Pułapka jest dokładnie odwrotna: eksporter w ścieżce żądania (synchroniczna wysyłka, kolejka bez ograniczenia, blokujący flush) robi ze stosu obserwowalności zależność każdego żądania, a pierwsze, czego się z niego dowiesz, to że padł razem z tobą. Zapamiętaj też moment, w którym gubi się najciekawsze spany — zamknięcie procesu: kolejka trzyma wtedy właśnie tę paczkę, która opisuje awarię, więc opróżnienie jej na wyjściu jest różnicą między znanym a nieznanym powodem restartu.

Szukaj po polsku: eksport telemetrii · kolejka i porzucanie spanów · opróżnianie bufora przy zamknięciu · otel collector · batch span processor queue size