Logging is an essential component of applications today. OpenTelemetry (OTel), the open source observability framework made up of a collection of tools, APIs, and SDKs, has stabilized logging as another available "signal" within the project. Other OTel signals include tracing, metrics, and baggage.
OpenTelemetry Logging offers improvements to traditional logging, including:
- Sharing of a common agent for observability data
- Extending correlation via context propagation across telemetry signals
- Leveraging the semantic conventions of commonly observed concepts, protocols, and operations
- Enabling the use of an OTel protocol to reduce logging computation overheard
Additionally, unlike approaches taken with OpenTelemetry metrics and tracing, where a clean sheet approach was used, OTel Logging makes working nicely with existing logging frameworks and libraries a first-class concern.
"We're announcing that OpenTelemetry Logging hit 1.0." Morgan McLean, co-creator of OpenTelemetry, said earlier this month at KubeCon NA 2023. McLean went on to describe what this means. "For logging, the core functionality has been there for quite a while (almost two years with various enhancements being made). What’s changed now is that [OpenTelemetry Logging] has been declared stable as well. Additionally, the configuration is not going to change."
OpenTelemetry Logging consists of four core components. The components are the Protocol, describing the encoding, transport, and delivery mechanism of telemetry data between telemetry sources; Logs Bridge API, the log backend API; and Logs SDK, which is an implementation of the OpenTelemetry API for users to interact with OTel.
Each of these three components is now marked "stable" (a core state that OpenTelemetry uses for component maturity). A fourth component, the Event API, allows log records to be emitted and conform to event semantic conventions. In contrast to the Log Bridge API, which allows for writing appenders which bridge logs from existing log frameworks into OpenTelemetry and is not designed for end users, the Event API is intended to be called by end users. It is still experimental and under active development.
OTel components follow a development lifecycle, which includes Draft, Experimental, Stable, Deprecated, and Removed tags.
- Draft components are under design and have not been added to the specification.
- Experimental components are released and available for beta testing.
- Stable components are backwards compatible and covered under long-term support.
- Deprecated components are stable but may eventually be removed.
OpenTelemetry now enables a single agent to collect core observability instrumentation (logs, metrics, and traces) on top of context propagation, a shared mechanism for correlating data across distributed systems. In typical observability collection scenarios, logging is done separately (usually using OS collection of files and an agent such as FluentBit), tracing uses another agent (such as the Jaeger Agent), and metrics often another (such as the OpenCensus Agent). With the addition of OTel Logging, the OpenTelemetry Collector can collect each of those sources (along with a fourth called Baggage for additional name/value pair data) and is backed by a specification data model to support each.
By leveraging the common collector, logs can be correlated with the rest of the observability data to enhance the interoperability of traces, metrics, and logs. Additionally, all instrumentation shares the same semantic conventions to ensure that the signals produce the same data when observing common operations, such as HTTP requests.
"One of the other benefits is that logs are relatively computationally expensive to capture," McLean said. "A logging agent tends to use more CPU than people think it should, and secondly, logs tend to be formatted in wildly different ways."
The new lower CPU-intensive log collection approach and the defined logs data model aim to address these concerns. For applicable languages and frameworks, auto-instrumentation or simple configuration of a logging library to use an OpenTelemetry log appender emits context-enriched logs and offers a low friction path for collection. In addition to the new First-Party Application Log, OpenTelemetry Logging supports legacy and modern log sources, including system logs, infra logs, third-party application logs, legacy first-party logs, file/stdout logs, and direct to the collector.
OpenTelemetry is an open source observability framework created when the Cloud Native Computing Foundation (CNCF) merged the OpenTracing and OpenCensus projects. OpenTelemetry has a vision of unifying telemetry data through a set of available signals. It is the second most active CNCF project.
