Skip to main content

Overview

The OpenTelemetry Logs Bridge API provides the foundation for connecting existing logging libraries to OpenTelemetry. This API is not intended for direct use by application developers—instead, it’s designed for logging library authors to build log appenders.
Application developers should use logging libraries like log or tracing along with the provided appenders, not the Bridge API directly.

Core Traits

The Bridge API defines three main traits in the opentelemetry::logs module:

Logger

The Logger trait provides methods to create and emit log records:
Key methods:
  • create_log_record() - Creates a new log record that can be populated with data
  • emit() - Sends the log record to the logging pipeline
  • event_enabled() - Allows early filtering to skip expensive logging operations
When emit() is called within an active trace context, the logger automatically attaches the current trace ID, span ID, and trace flags to the log record.

LoggerProvider

The LoggerProvider trait creates Logger instances:
Usage example:

LogRecord

The LogRecord trait provides methods to populate log record fields:

Core Types

Severity

The Severity enum defines 24 log severity levels:
Most appenders map standard log levels to the base severity:
Get the severity name:

AnyValue

The AnyValue enum represents values that can be stored in log attributes or body:
Automatic conversions:
Collections:
Performance consideration: The log and tracing crates only support basic types (i64, f64, strings, bool). Complex types like ListAny and Map are available for custom appenders but involve heap allocations.

SDK Implementation

The opentelemetry-sdk crate provides the concrete implementation:

SdkLogRecord

The SDK’s SdkLogRecord implements the LogRecord trait and stores:
  • Timestamps (event time and observed time)
  • Severity (number and text)
  • Body (the log message)
  • Attributes (structured key-value data)
  • Trace context (trace ID, span ID, flags)
  • Target (module/component identifier)
  • Event name (optional event identifier)

Building a Log Appender

Here’s how to build a custom log appender using the Bridge API:
1

Get a Logger

Obtain a logger from the provider:
Note: Log appenders typically use an empty scope name. See the semantic conventions issue.
2

Create a LogRecord

When a log event occurs:
3

Populate the LogRecord

Map fields from the logging library to the log record:
4

Emit the LogRecord

Send the log record to the pipeline:

Example: Simple Appender

Performance Optimization

event_enabled Check

Always check event_enabled() before expensive operations:
This allows processors to filter logs early, avoiding unnecessary work for logs that would be dropped anyway.

Target Field

The target field serves a special purpose:
  • Used for filtering and routing logs
  • Exporters may use this as the instrumentation scope name
  • Both log and tracing appenders default to the module path

Noop Implementation

For testing or when logging is disabled, use the noop provider:

See Also

log Appender

Implementation using the log crate

tracing Appender

Implementation using the tracing crate

Log Processors

Processing and exporting log records

Overview

Return to logs overview