Skip to main content
It’s time to learn about logging in OpenTelemetry. This lesson explains what logs are, common formats, how OpenTelemetry integrates with your existing logging libraries, and where the Collector fits in a unified telemetry pipeline. Logs are one of the three primary telemetry signals (alongside metrics and traces). They provide free-form, human-readable context that is invaluable for debugging. That flexibility is powerful but also introduces risks: inconsistent formatting and clutter when teams lack logging discipline. To make logs searchable and actionable, prefer structured logging and consistent schemas.
Structured logs (JSON or schema-backed formats) are strongly recommended: they make logs easier to query, filter, and analyze across your observability stack.

​
What is a log?

A log is a timestamped text record of an event — something that happened in your system at a specific point in time. Logs may be:
  • Structured — follow a consistent schema (JSON is common). Predictable and machine-readable.
  • Unstructured — free text and stack traces. Easy for humans, but harder for programmatic analysis.
  • Semi-structured — key-value tokens or delimited fields (a compromise between the two).
Logs frequently include optional metadata to aid querying and correlation:
  • Level (debug, info, warn, error)
  • Source (service or component)
  • Context (trace_id, span_id, user identifiers, etc.)
These elements make logs more meaningful and easier for machines to join with traces and metrics.
An infographic titled "Defining a Log" that defines a log as "a timestamped text record of an event." It shows two types—Structured (recommended) and Unstructured—and a section of optional metadata fields like Level, Source, and Context.

​
Logging libraries and OpenTelemetry integration

OpenTelemetry does not replace your existing logging libraries or formats; it augments them. Common logging libraries by language include:
OpenTelemetry enriches and interoperates with logging frameworks — it does not seek to replace them. Use OTel to add context (trace/span IDs) and to export logs consistently.
A typical integration flow:
  1. Your application and its libraries emit log messages (info/warn/error) to a logging framework (e.g., Log4j).
  2. An OpenTelemetry appender/integration captures each log record and queries the OpenTelemetry Context API.
  3. If a log is produced while a span is active, the integration attaches trace_id and span_id to the log.
  4. The enriched record passes to the OpenTelemetry Log API/SDK, which uses a LoggerProvider to create logger instances, a LogRecordProcessor to batch/filter/transform, and a LogRecordExporter to convert/export the record (commonly using OTLP).
A diagram titled "OpenTelemetry Logs Integration" showing application libraries emitting logs (Info/Warn/Error). The logs flow through an OpenTelemetry Log Appender to the OpenTelemetry Context API and Log API/SDK components like LoggerProvider, Logger, LogRecordProcessor, and LogRecordExporter.

​
The OpenTelemetry Collector in the logging pipeline

The OpenTelemetry Collector can operate as an agent (sidecar/host) or gateway. It enables you to ingest logs from external sources (file systems, syslog, Fluentd, etc.), apply processing (parsing, transforms, enrichment), and export to your backend(s). Using the Collector lets you centralize processing and reduce per-application complexity. Common Collector pipeline elements for logs: This separation allows you to send logs to the Collector outside of application SDKs (e.g., tailing files), while still getting unified processing and export.
A simple flow diagram titled "Logs in OpenTelemetry Collector" showing a log pipeline: a File/Syslog source feeds into the OpenTelemetry Collector (with receivers, a filelog receiver/parser, a transform processor, and exporters) which then sends logs outward to Backends.

​
Correlating logs with traces

When your logging library is instrumented with OpenTelemetry (via SDKs or auto-instrumentation), each log entry can include the current trace_id and span_id. This cross-signal correlation enables richer troubleshooting inside observability platforms. Example log lines enriched with trace/span identifiers:
Attaching IDs at write-time (via the active context) is more robust than trying to reconstruct context later.

​
Common log formats and examples

Broadly, logs follow three styles: structured (preferred), semi-structured, and unstructured. Structured logs (JSON) — predictable and machine-readable:
Common Log Format (CLF) — text-based, widely used by web servers:
Extended / mixed formats — CLF plus a following JSON payload (requires parsing both lines):
Semi-structured examples — tokenized or key-value styles:
Unstructured logs are free text and stack traces. They remain useful for quick debugging but are harder to query without parsing and enrichment.

​
Best practices and recommendations

  • Prefer structured logs (JSON) with a consistent schema for services.
  • Always include levels and service/host identifiers.
  • Attach trace_id and span_id where possible to enable trace-log correlation.
  • Use the OpenTelemetry Collector to centralize parsing, enrichment, and export.
  • Avoid logging sensitive data (PII, credentials). Filter or redact at source or in Collector processors.
Summary
  • Logs complement metrics and traces by providing flexible, context-rich events.
  • Structured logs improve searchability and analysis; semi-structured logs are a useful compromise.
  • OpenTelemetry enriches existing logging frameworks by adding trace/span context and a consistent export pipeline.
  • The Collector can ingest logs from files/syslog, transform and enrich them, and export to backends without changing application code.
  • Adopt a consistent logging schema and discipline to keep logs actionable and searchable.
A presentation summary slide with a colorful vertical timeline and five numbered points outlining log handling and OpenTelemetry topics — including log formats, enrichment/standardization, collector processing, and best practices.

Watch Video