{
  "id": 9207151,
  "title": "The Hard Part of an OpenTelemetry Logs Bridge Wasn't Encoding",
  "url": "https://urgent.news/2026/09/22/the-hard-part-of-an-opentelemetry-logs-bridge-wasnt-encoding",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-22T21:37:24.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/admilsoncossa/the-hard-part-of-an-opentelemetry-logs-bridge-wasnt-encoding-29j1"
  },
  "original_language": "en",
  "account": "The challenge in creating an OpenTelemetry Logs bridge was not encoding data but maintaining the contracts between APIs, such as context usage, ownership after pooling, masking precedence, and provider lifecycle. These aspects determine whether the bridge emits the correct record, leaks masked values, retains unowned memory, or loses logs before a process exits. The measurements excluded HaloLog's public logger and builder path, masking, console/file output, OpenTelemetry SDK, processors, exporters, collector, network, and backend. Instead, they focused on adapter microbenchmarks, not production throughput or comparisons with other bridges. HaloLog initially provided an optional Bind helper for correlation fields but did not send logs through the OpenTelemetry Logs pipeline. Daniel Loader's external pull request added an output adapter mapping the HaloLog LogEntry into an OpenTelemetry LogRecord, including timestamp, severity, body, structured fields, and context. The resulting path involved the HaloLog LogEntry, console/file adapter, otelbridge.Adapter, OpenTelemetry LogRecord, API Logger, SDK/processor/exporter, collector/backend. Fan-out is sequential and best-effort, without atomic delivery across sinks or propagating per-adapter write errors to the logging caller. The OpenTelemetry Logs API distinguishes Timestamp, ObservedTimestamp, trace identifiers, flags, severity, Body, Resource, InstrumentationScope, Attributes, and EventName. HaloLog maps these fields; the provider and SDK supply observed time, resource, and scope handling. Contract 1 required enabling and emitting with the same correlation context, while Contract 2 ensured masking remained authoritative at the export boundary. HaloLog mapped fields, but correctness required using the same context before Enabled.",
  "summary": "Part 2 of Engineering HaloLog: making high-performance telemetry claims reproducible and falsifiable. Part 1 examined what a 23.9 ns logging benchmark does and does not prove. The implementation and measurements discussed here are pinned to otelbridge/v1.0.3 . An OpenTelemetry Logs bridge looks like a mapping problem. Message becomes Body. Level maps to Severity. Ordinary fields become…",
  "key_points": [
    "Maintaining API contracts was harder than encoding data",
    "HaloLog provided optional Bind helper but didn't send logs through pipeline",
    "Adapter microbenchmarks focused on correctness, not production throughput"
  ],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}