LogHouse Editorial · Published 2026-08-01 · Updated 2026-09-05 · 10 min read
OpenTelemetry Logging: A Practical Guide
How to send vendor-neutral logs with OpenTelemetry—OTLP, collectors, and exporting to a managed log backend such as LogHouse.
The short answer
OpenTelemetry logs are records exported over OTLP (or translated by a collector) so your instrumentation is not owned by one vendor. A typical production setup is: SDKs or log bridges → OpenTelemetry Collector → one or more backends. LogHouse is a backend for that pipeline: send logs via documented HTTP ingest, keep querying in LogHouse, and optionally dual-export a slice to Datadog or Grafana.
Logs in the OpenTelemetry model
Traces and metrics had a head start in OTel. Logs caught up through log bridges, the Collector, and OTLP. The point is not a new log format for its own sake—it is a vendor-neutral path from process to backend.
Collector-first routing
Put policy in the Collector: batching, PII filters, and exporters. Application code should emit structured logs with resource attributes (service.name, deployment.environment) and let the Collector decide destinations.
From there, export high-volume logs to LogHouse over HTTP. Export a filtered subset to Datadog if monitors still live there. Grafana can query LogHouse without requiring a second copy of the data.
What to standardize
Severity, timestamp, service name, trace and span IDs when present, and a small set of indexed attributes. Unbounded high-cardinality fields belong in the message body, not as distinct columns you will never filter on.