If you’ve been following OpenTelemetry for a while, you’ve probably heard a lot about logs. Log bridges, Logs API, events, you name it, we’ve talked about it. This blog post is intended to be a discussion of the rationale and current design direction of logging in OpenTelemetry.
Definitions Let’s get started with a basic definition of how OpenTelemetry thinks about logs. Broadly, logs are any telemetry that is emitted through a log pipeline, and are created by calling the Logs API. There are two ways we intend for users to do this –

OpenTelemetry's platform is an observability framework, offering insights into distributed tracing, metrics collection, and log management for cloud-native applications. Through documentation, tutorials, and community contributions, OpenTelemetry provides insights into instrumenting applications to monitor performance and troubleshoot issues. Developers and DevOps teams can learn about distributed tracing standards, telemetry data formats, and integration with observability tools to gain visibility into complex distributed systems.

OpenTelemetry

OpenTelemetry provides a comprehensive logging framework that includes logs, events, and spans. Logs are any telemetry data emitted through a log pipeline via the Logs API, while events are a specific type of log with a defined schema. Spans differ from events by having durations and hierarchical relationships. The design emphasizes correlating all telemetry signals through context for a cohesive observability solution.

OpenTelemetry Logging and You

How is this different from other signals?