x

Glossary

Our Criblpedia glossary pages provide explanations to technical and industry-specific terms, offering valuable high-level introduction to these concepts.

Table of Contents

Related Terms

Return to Glossary

OpenTelemetry (OTel) Logs

Enterprises rely on ever more complex hybrid systems that combine legacy, on-premise applications with multiple cloud-based applications and services. However, siloed, incompatible log data from each infrastructure component makes it harder to optimize the applications they support.

What are OpenTelemetry Logs?

OpenTelemetry is an open-source framework that aims to produce tools, APIs, and SDKs to make it easier to instrument even complex, distributed applications. OpenTelemetry logs are one of the four types of telemetry signals about application and system performance generated by the OpenTelemetry observability framework.

Logs consist of structured or unstructured text that describes the activities and operations within an infrastructure component. This includes components such as an operating system, application, or server. Existing logging solutions for infrastructure such as applications and Web servers are able to accept the raw data from other observability signals.

What they usually cannot do is race the context of such signals, such as their time and origin, or the application or infrastructure element in which the application runs. This is because such attributes are often added to logs, traces, and metrics through different collection agents. The resulting disjointed set of logs collected from different components of the system makes it difficult to get a comprehensive view of a complex application required to optimize its performance and reliability.

The OTel standard is designed to substantially ease these challenges.

Key Features and Benefits of OTel Logs

OpenTelemetry’s integrated logging capabilities simplify the process of gathering and analyzing data from various technology components. This allows for better identification and prevention of potential slowdowns or bottlenecks that could impact employees, business partners, or customers.

Among the types of logs it supports are those describing events within applications, the operating systems that run them, Web servers that provide content on the internet, and the networks that connect applications to each other. OpenTelemetry defines 24 log levels in 6 categories, covering the definition of all types of log levels.

A key feature of OpenTelemetry logs is their integration with legacy logs and logging libraries in which enterprises have invested, and on which they rely for system troubleshooting. The OTel project aims to integrate different types of logs and standardize their correlation with other signals like traces and metrics in the future.

OTel incorporates trace context identifiers (like trace and span ids or user-defined baggage), enabling enhanced correlation between logs and traces. This correlation extends to logs emitted by various components of a distributed system, providing valuable insights for analysis.

Trace IDs correlate all the components of a distributed system as an event moves through them. Span IDs link the multiple units of logical work within a trace.

OpenTelemetry provides receivers and processors that collect both first-party and third-party directly into the OTely Collector using existing agents, minimizing the work required to get the benefits of the framework. Using the Collector further enriches the usefulness of the data by enriching and processing it in a uniform manner.

Logs from legacy applications can be used with OTel with little to no changes to the application code. A trace parser provided by OpenTelemetry allows users to add context IDs to logs to correlate them with other signals.

OpenTelemetry provides these features by defining a log data model which provides a common definition of a LogRecord and the data that must be recorded, transferred, stored, and interpreted by a logging system. It also allows existing log formats to be mapped to its data model.

How to implement OpenTelemetry Logs in Your Application?

Application logs can be collected using File or Stdout Logs, with logs directly collected by the OpenTelemetry receiver using a collector such as filelog receiver. Operators and processors parse the collected logs into the OpenTelemetry log data model for further processing and analysis.

Among other log processing functions, advanced parsing and collecting can be done using log aggregators such as FluentBit or Logstash, with the logs transmitted to the OpenTelemetry collector using protocols such as FluentForward or TCP/UDP.

Another approach is to modify the logging library used by the application to leverage the logging SDK to directly forward logs to OpenTelemetry. This has the advantage of removing the need for agents or other intermediaries but eliminates the simplicity of having the log file locally.

Logs from third-party applications, written to stdout, files, or other formats, are collected by the OpenTelemetry file receiver. Optionally, application trace context, known as execution context, can be added to log messages. Configuring this feature depends on the language and logging framework used by the application. Typically, it involves setting up the application to produce structured JSON logs and extract trace context into specified fields on available log messages.

OpenTelemetry Logs Best Practices

When it comes to logging in OpenTelemetry, developers are advised to avoid using the OpenTelemetry Logs Bridge API for emitting LogRecords. This API is specifically designed for library authors to create log appenders that connect existing logging libraries with the OpenTelemetry log data model. Instead, OpenTelemetry focuses on providing an SDK implementation of the Bridge API, allowing configuration of both processing and exporting LogRecords.

In addition to the Bridge API, the OpenTelemetry framework defines operators that perform pre-processing tasks before exporting data. These operators can modify attributes, apply sampling techniques, batch or retry data for successful transmission, and even parse or transform logs from multiple receivers. Each operator handles a specific task, such as adding attributes to log fields or parsing JSON data.

To effectively manage logs, enterprises require a robust back-end system capable of storing, querying, and analyzing logs. Advanced features to consider in such systems include a log query builder, the ability to search across multiple fields, and support for viewing logs in various formats like structured tables or JSON. One notable example is SigNoz, an open-source APM solution that seamlessly integrates with OpenTelemetry. Alternatively, some large enterprises opt for ClickHouse for their log analytics needs.

Telemetry Signals
To best understand system performance, information from logs must be analyzed along with three other telemetry signals:
  • Traces are used to track user requests across services such as authentication or order entry.
  • Metrics they measure values such as server response time or memory usage at specific intervals.
  • Baggage is a signal that provides a uniform way to store and propagate information across a trace and other signals.
Want to learn more?
Download the Gartner white paper title Innovation Insight: Telemetry Pipelines Elevate the Handling of Operational Data
Download

Resources

So you're rockin' Internet Explorer!

Classic choice. Sadly, our website is designed for all modern supported browsers like Edge, Chrome, Firefox, and Safari

Got one of those handy?