Skip to main content
This lesson explains the key OpenTelemetry logging components, how they connect to your existing logging libraries, and how logs are structured, enriched, and exported. You’ll learn where to initialize logging, how logs are correlated with traces, and common deployment patterns (for example, sending logs to an OpenTelemetry Collector). Log data in OpenTelemetry flows from your existing logging library through an appender/bridge into the OpenTelemetry SDK, and then out via one or more exporters.
A diagram titled "Log Appender/Bridge" showing a flow from a Logging Library (e.g., Java Log4j, Python logging) → Appender/Bridge → OpenTelemetry SDK → LogRecordExporter. It explains this component connects existing logging libraries to OpenTelemetry without changing your code.
Overview table Log appender / bridge A log appender (also called a bridge) hooks your existing logging framework into OpenTelemetry. Your application continues to call its usual logging APIs (for example, log.info() or logger.error()); the appender intercepts those calls and forwards standardized, enriched log records to the OpenTelemetry SDK. This lets you adopt OpenTelemetry logging without changing application code. The exporter commonly sends logs to an OpenTelemetry Collector or directly to an OTLP-compatible backend such as a hosted observability platform. LoggerProvider The LoggerProvider is created once per application lifecycle and acts as a centralized factory and manager for all logger instances. Its responsibilities include:
  • Creating logger instances used by application code (e.g., log.info, log.error).
  • Configuring resource metadata such as service.name, service.version, and deployment.environment.
  • Wiring exporters that will deliver logs to your backend(s).
  • Serving as part of the Log Bridge API to help library authors integrate frameworks consistently with OpenTelemetry.
A logger instance is what your code uses to produce log records; the LoggerProvider ensures all loggers share consistent resource and exporter configuration.
Initialize the LoggerProvider once per application. Treat it as an application-wide singleton so all loggers inherit the same resource and exporter configuration.
A simple diagram of a logging system: a Logger Provider supplies a Logger that your code calls (e.g., log.info / log.error) to generate log entries.
LogRecord exporter Once a logger produces a LogRecord, the configured exporter(s) take over. Exporters typically implement:
  • Batching to reduce overhead and improve throughput.
  • Retry logic to handle transient failures.
  • Error handling and backpressure strategies.
Exporters can route logs to multiple targets — for local debugging you may write to stdout, for aggregation and enrichment you commonly send logs to an OpenTelemetry Collector, and for long-term storage or analysis you send logs to an observability backend.
A flow diagram titled "Log Record Exporter" showing a LogRecord input feeding into an exporter box with Batching, Retry, and Error handling. The exporter then routes outputs to three targets labeled stdout, Collector, and o11y backends.
Note: exporters are pluggable so you can change backends without modifying application code. In production, sending logs to the OpenTelemetry Collector is common because the Collector can perform additional processing, routing, and enrichment before forwarding to final backends. Log record structure A LogRecord is the core unit of log data in OpenTelemetry. It is analogous to a Span in tracing or a datapoint in metrics. Typical fields include:
  • Timestamp: when the event occurred.
  • Severity: severity text and numeric level (e.g., INFO, ERROR).
  • Body: the main log message.
  • Trace and span IDs: present when a log is emitted during an active span to enable correlation.
  • Attributes: structured key/value pairs storing business or contextual metadata.
  • Resource: information identifying where the log originated (e.g., service.name, host.name, Kubernetes metadata).
  • Instrumentation scope: the library or module that produced the log.
A slide showing a "Log Record" diagram with a boxed LogRecord header and labeled fields like Timestamp, Severity, Body, TraceId & SpanId, Attributes, Resource, and InstrumentationScope. It visually represents the components of a log entry.
Example: structured log record (JSON) Below is a sampled, structured log record showing typical enriched fields, including trace/span linkage and resource metadata:
Trace/span IDs are not typically part of the original plain-text log message. The OpenTelemetry logging integration inspects the current execution context and attaches trace and span identifiers when a log is emitted while an active span exists. This correlation makes it simple to pivot from traces to relevant logs in your observability backend. Console and indexed logs (example outputs) Exported logs may appear as plain-text console entries or as structured documents indexed into a search engine (for example, Elasticsearch). The following examples show both a compact console-style log and an indexed _source document to illustrate how fields and resource metadata are preserved. Plain-text log entries (shortened for readability):
Indexed document (example _source from a search result):
Observed timestamp vs event timestamp
  • Observed timestamp (ingestion timestamp): when the collector or ingest pipeline captured the log.
  • Event/timestamp: when the event actually occurred at the source.
Both timestamps are useful: event timestamp is used for accurate timeline analysis, and observed timestamp helps debug ingestion delays or pipeline issues. Resource attributes and enrichment The Collector and SDK frequently enrich logs with resource attributes (service, pod, node, host, container, etc.). These attributes make it straightforward to filter and query logs by service, deployment, or infrastructure metadata in your observability backend. Summary
  • The log appender/bridge integrates existing logging libraries with OpenTelemetry without requiring application code changes.
  • Initialize the LoggerProvider once per application so all loggers share the same resource and exporter configuration.
  • LogRecord exporters handle batching, retries, and delivery to stdout, an OpenTelemetry Collector, or an observability backend.
  • Log records are structured and often include timestamps, severity, body, trace/span correlation (when available), attributes, resource metadata, and instrumentation scope.
  • Exporters are pluggable—swap backends without changing application code. Sending logs to the OpenTelemetry Collector is a common production pattern.
Links and references That’s it for this lesson.

Watch Video