OpenTelemetry Logs—Data Model, Collector & Examples

OpenTelemetry logs are timestamped records that represent events from applications, services, hosts, and infrastructure components. They use a common data model so logs from different sources can be parsed, enriched, correlated with traces and metrics, and exported through OpenTelemetry-compatible pipelines.
In practice, OpenTelemetry logging usually works with your existing logging libraries, the OpenTelemetry Collector, and an observability backend like SigNoz.

OpenTelemetry is a Cloud Native Computing Foundation (CNCF) incubating project that standardizes how applications generate telemetry data. The OpenTelemetry specification defines cross-language requirements for traces, metrics, logs, and baggage, so teams can collect telemetry without being locked into one vendor.

What are OpenTelemetry Logs?

Unlike traces and metrics, OpenTelemetry logs are designed to support the logging libraries and log formats teams already use. You can collect logs from files, stdout, syslog, existing agents, or language SDKs, then process them with the OpenTelemetry Collector.

A log usually captures an event and stores it as a text record. Developers use log data to debug applications. There are many types of log data:

• Application logs
  Application logs contain information about events that have occurred within a software application.

• System logs
  System logs contain information about events that occur within the operating system itself.

• Network logs
  Devices in the networking infrastructure provide various logs based on their network activity.

• Web server logs
  Popular web servers like Apache and NGINX produce log files that can be used to identify performance bottlenecks.

Most of these logs are either computer generated or generated by using some well-known logging libraries. Most programming languages have built-in logging capabilities or well-known logging libraries. Using OpenTelemetry Collector, you can collect these logs and send it to any observability backend that performs log analysis like SigNoz, which supports the OpenTelemetry logs data model.

OpenTelemetry's log data model provides a unified framework to represent logs from various sources, such as application log files, machine-generated events, and system logs.

OpenTelemetry log data model

The primary goal of OpenTelemetry's log data model is to provide a common structure for log records across languages, libraries, agents, and backends. This makes logs easier to parse, enrich, correlate, store, and query consistently.

Key fields in an OpenTelemetry log record

OTLP representation of OpenTelemetry log records

The OpenTelemetry log data model defines the fields in a log record. OTLP is the protocol used to transmit those records, commonly encoded as Protocol Buffers over gRPC or HTTP. OTLP also supports a JSON Protobuf encoding, which is useful for examples and debugging.

An example of a log record following the OpenTelemetry log data model in JSON format might look like this:

{
  "Timestamp": "1634630400000",
  "ObservedTimestamp": "1634630401000",
  "TraceId": "abcd1234",
  "SpanId": "efgh5678",
  "SeverityText": "ERROR",
  "SeverityNumber": "17",
  "Body": "An error occurred while processing the request.",
  "Resource": {
    "service.name": "web-backend",
    "host.name": "web-server-1"
  },
  "InstrumentationScope": {
    "Name": "JavaLogger",
    "Version": "1.0.0"
  },
  "Attributes": {
    "http.method": "GET",
    "http.status_code": "500"
  }
}

This example represents a log record from a backend service, indicating an error during request processing. The log is associated with a specific trace and span, has a severity of "ERROR", and includes additional attributes related to the HTTP request.

OpenTelemetry logs vs traditional logging

Traditional logging is usually tied to application-specific formats, local files, or vendor-specific agents. OpenTelemetry logging keeps those existing logs useful, but maps them into a common telemetry model that can move through vendor-neutral pipelines.

OpenTelemetry logs vs events, traces, and metrics

For a deeper comparison, see OpenTelemetry events vs logs.

Why log correlation matters in OpenTelemetry

Correlating logs with traces and metrics helps teams move from symptoms to root cause faster. An error log with a TraceId can point to the exact distributed trace for that request, while related metrics can show whether the issue is isolated or part of a wider pattern.

Is OpenTelemetry logging stable?

Logs are a stable signal in the OpenTelemetry specification, but language SDK support varies. As of May 2026, the OpenTelemetry language status table lists logs support as Stable for Java, .NET, C++, and PHP, Beta for Go and Rust, and Development for Python, JavaScript, Ruby, Swift, Erlang/Elixir, and Kotlin.

For production rollouts, check the status and usage patterns of your language SDK and logging bridge before choosing a direct SDK approach. Collector-based file/stdout collection is often the safest path when you want minimal application changes or when logs support in your language is still evolving.

Collecting log data with OpenTelemetry

OpenTelemetry provides various receivers and processors for collecting first-party and third-party logs directly via OpenTelemetry Collector or via existing agents such as FluentBit so that minimal changes are required to move to OpenTelemetry for logs.

Collecting legacy first-party application logs

These applications are built in-house and use existing logging libraries. The logs from these applications can be pushed to OpenTelemetry with little to no changes in the application code. OpenTelemetry provides trace_parser and related parser configuration to extract or map existing trace and span IDs from logs so they can be correlated with traces and other signals.

In OpenTelemetry, there are two important context IDs for context propagation.

• Trace IDs
  A trace is a complete breakdown of a transaction as it travels through different components of a distributed system. Each trace gets a trace ID that helps to correlate all events connected with a single trace.

• Span IDs
  A trace consists of multiple spans. Each span represents a single unit of logical work in the trace data. Spans have span IDs that are used to represent the parent-child relationship.

Correlating your logs with traces can help drive deeper insights. If you don’t have request context like traceId and spanId in your logs, you might want to add them for easier correlation with metrics and traces.

There are two ways to collect application logs:

• Via File or Stdout Logs
  Here, the logs of the application are directly collected by the OpenTelemetry receiver using collectors like filelog receiver. Then operators and processors are used for parsing them into the OpenTelemetry log data model.

For advanced parsing and collecting capabilities, you can also use something like FluentBit or Logstash. The agents can push the logs to the OpenTelemetry collector using protocols like FluentForward/TCP/UDP, etc.

OpenTelemetry Collector logs example: filelog receiver

The filelog receiver is a good starting point when your application already writes logs to files. The Collector tails the file, parses each line, and exports the records through your logs pipeline.

receivers:
  filelog/app:
    include: [/var/log/myapp/*.log]
    start_at: end
    operators:
      - type: json_parser
        parse_from: body

processors:
  resource:
    attributes:
      - key: service.name
        value: myapp
        action: upsert
  batch:

exporters:
  otlp:
    endpoint: ingest.<your-region>.signoz.cloud:443
    headers:
      signoz-ingestion-key: ${SIGNOZ_INGESTION_KEY}

service:
  pipelines:
    logs:
      receivers: [filelog/app]
      processors: [resource, batch]
      exporters: [otlp]

For more configuration options, see the SigNoz guide to collect logs from a file.

• Directly to OpenTelemetry Collector with SDK
  In this approach, you can modify your logging library that is used by the application to use the logging SDK provided by OpenTelemetry and directly forward the logs from the application to OpenTelemetry. This approach removes any need for agents/intermediary medium but loses the simplicity of having the log file locally. Let's explore it in greater detail.

Generating Context Aware Logs with OpenTelemetry SDK

While collecting logs from files is necessary for legacy systems, the most powerful approach for modern applications is to generate logs directly using the OpenTelemetry SDK. This method ensures that logs are "born" with full trace context, making correlation effortless.

To understand how this works, you first need to know about OpenTelemetry's core design: the separation of its API from its SDK.

• The API: A set of abstract interfaces that library authors use to add instrumentation. It defines what can be done (e.g., get a logger, emit a log) but has no real implementation.

• The SDK: The concrete implementation of the API. You, the application developer, adds the SDK to your project to turn on telemetry. The SDK is responsible for actually creating, processing, and exporting the logs.

Now, let's see how to use this combination in practice.

Example 1. Instrumenting Python with a Logging Handler

Here's an example of using OpenTelemetry's LoggingInstrumentor to instrument the logging library to automatically add trace context in a Python application.

import logging
from opentelemetry.instrumentation.logging import LoggingInstrumentor

# Instrument the logging library to automatically add trace context
LoggingInstrumentor().instrument(set_logging_format=True)

# Now, any log created within an active trace will automatically
# include trace_id and span_id in its record.
logging.basicConfig(level=logging.INFO)
logging.info("User login successful.")

For SigNoz setup details, see Python logs with OpenTelemetry.

Example 2. Instrumenting in Java with a Log Appender

For Java applications, which commonly use logging frameworks like Logback or Log4j, OpenTelemetry integrates by providing a custom Log Appender.

An Appender is a component within these frameworks responsible for sending log events to a destination (like the console or a file). The OpenTelemetryAppender is a special appender that captures all logs your application creates and forwards them to the OpenTelemetry SDK (the destination). The SDK then automatically enriches them with the active TraceId and SpanId before exporting them.

To configure it, you simply add the OpenTelemetryAppender to your log4j2.xml (or logback.xml) file, requiring no changes to your application's source code as shown in the below example.

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN" packages="io.opentelemetry.instrumentation.log4j.appender.v2_17">
  <!-- The appender is configured via standard OpenTelemetry environment variables or system properties -->
  <Appenders>
      <OpenTelemetry name="OpenTelemetryAppender"/>
  </Appenders>
  <!-- Attach the OpenTelemetryAppender to the root logger -->
  <Loggers>
      <Root>
          <AppenderRef ref="OpenTelemetryAppender" level="All"/>
      </Root>
  </Loggers>
</Configuration>

As you can see, while the mechanism differs by language ecosystem (Handlers in Python, Appenders in Java), the underlying idea is the same, i.e, integrate the OpenTelemetry SDK with your existing logging framework to automatically enrich all your logs with invaluable trace context.

For SigNoz setup details, see Java logs with OpenTelemetry.

Collecting third-party application log data

Logs emitted by third-party applications running on the system are known as third-party application logs. The logs are typically written to stdout, files, or other specialized mediums. For example, Windows event logs for applications.

These logs can be collected using the OpenTelemetry file receiver and then processed.

A practical example - Collecting syslogs with OpenTelemetry

You will need OpenTelemetry Collector (otel collector) to collect syslogs. In this example, we will illustrate collecting syslogs from your VM and sending it to SigNoz.

• Add otel collector binary to your VM by following this guide.

• Add the syslog receiver to config.yaml to otel-collector.

  receivers:
    syslog:
      tcp:
        listen_address: "0.0.0.0:54527"
      protocol: rfc3164
      location: UTC
      operators:
        - type: move
          from: attributes.message
          to: body
  

  Here we are collecting the logs and moving message from attributes to body using operators that are available. You can read more about operators for parsing and manipulating logs.

  For more configurations that are available for the syslog receiver, check the OpenTelemetry syslog receiver documentation.

• Next we will modify our pipeline inside config.yaml of otel-collector to include the receiver we have created above.

  service:
      ....
      logs:
          receivers: [otlp, syslog]
          processors: [batch]
          exporters: [otlp]
  

• Now we can restart the otel collector so that new changes are applied and we can forward our logs to port 54527.

• Modify your rsyslog.conf file present inside /etc/ by running the following command:

  sudo vim /etc/rsyslog.conf
  

  and adding the this line at the end

  template(
    name="UTCTraditionalForwardFormat"
    type="string"
    string="<%PRI%>%TIMESTAMP:::date-utc% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
  )
  
  *.* action(type="omfwd" target="127.0.0.1" port="54527" protocol="tcp" template="UTCTraditionalForwardFormat")
  

  For production use cases it is recommended to use something like below:

  template(
    name="UTCTraditionalForwardFormat"
    type="string"
    string="<%PRI%>%TIMESTAMP:::date-utc% %HOSTNAME% %syslogtag:1:32%%msg:::sp-if-no-1st-sp%%msg%"
  )
  
  *.*  action(type="omfwd" target="127.0.0.1" port="54527" protocol="tcp"
          action.resumeRetryCount="10"
          queue.type="linkedList" queue.size="10000" template="UTCTraditionalForwardFormat")
  

  So that you have retries and queue in place to de-couple the sending from the other logging action. Also we are assuming that you are running the otel binary on the same host. If the OpenTelemetry Collector runs on a different host, replace 127.0.0.1 with that host's IP address or DNS name.

• Now restart your rsyslog service by running sudo systemctl restart rsyslog.service

• You can check the status of service by running sudo systemctl status rsyslog.service

• Generate a test syslog entry by running logger "SigNoz syslog test message", then search for SigNoz syslog test message in SigNoz Logs Explorer.

• If there are no errors your logs will be visible on SigNoz UI. For a more detailed walkthrough, see the SigNoz guide to collect syslogs with OpenTelemetry Collector.

Log processing with OpenTelemetry

OpenTelemetry provides operators to process logs. An operator is the most basic unit of log processing. Each operator fulfills a single responsibility, such as adding an attribute to a log field or parsing JSON from a field. Operators are then chained together in a pipeline to achieve the desired result.

For example, a user may parse log lines using regex_parser and then use trace_parser to parse the traceId and spanId from the logs.

OpenTelemetry also provides processors for processing logs. Processors are used at various stages of a pipeline. Generally, a processor pre-processes data before it is exported (e.g. modify attributes or sample) or helps ensure that data makes it through a pipeline successfully (e.g. batch/retry).

Processors are also helpful when you have multiple receivers for logs and you want to parse/transform logs collected from all the receivers. Some well-known log processors are:

• Batch Processor
• Memory Limit Processor
• Attributes Processor
• Resource Processor

Querying and Correlating OpenTelemetry Logs in SigNoz

Once you have configured OpenTelemetry to collect your logs, you need a backend to analyze, query, and visualize them. This is where the value of structured logging is truly unlocked. As an OpenTelemetry-native platform, SigNoz Logs Explorer is designed to work with the OTel data model. Let's explore how you can perform log analytics. The logs tab in SigNoz has advanced features like a log query builder, search across multiple fields, structured table view, JSON view, etc.

Searching and Filtering with the Query Builder

Your key step in any investigation during an escalation is to find the right logs. Instead of manually searching through tons of logs, you can use a query builder to filter logs based on any field in the OpenTelemetry log data model. We have recently overhauled the Query Builder. You can read more in our Query Builder v5 announcement.

For example, you can quickly find all logs with SeverityText = ERROR from your web-backend service that occurred in the last hour as shown in the below screenshot.

Real-Time Analysis with Live Tail

When you're debugging a live issue, you need to see logs as they happen. Live tailing provides a real-time stream of logs from your applications, allowing you to see the immediate impact of your changes as demonstrated in the below screenshot.

Correlating Logs with Traces

As mentioned previously, this is an important benefit of using OpenTelemetry for logs, because your logs are enriched with TraceId and SpanId. Let's see how this pans out in SigNoz.

In SigNoz, the TraceId in a log record is a clickable link. Meaning, when you find an interesting error log, you can click its TraceId to instantly pivot to the full distributed trace view for that specific request. This allows you to discover more important insights like:

• The exact user request that produced the error.
• The full journey of the request across all microservices.
• Latency breakdowns for each step, helping you pinpoint the root cause.

Getting started with SigNoz

SigNoz Cloud is the easiest way to run SigNoz. Sign up for a free account and get 30 days of unlimited access to all features.

You can also install and self-host SigNoz yourself since it is open-source. With 24,000+ GitHub stars, open-source SigNoz is loved by developers. Find the instructions to self-host SigNoz.

OpenTelemetry logs are the way forward!

The goal of OpenTelemetry is to make log data have a richer context, making it more valuable to application owners. With OpenTelemetry you can correlate logs with traces and correlate logs emitted by different components of a distributed system.

Standardizing log correlation with traces and metrics, adding support for distributed context propagation for logs, unification of source attribution of logs, traces and metrics will increase the individual and combined value of observability information for legacy and modern systems.
Source: OpenTelemetry website

To get started with OpenTelemetry logs, install SigNoz and start experimenting by sending some log data to SigNoz. SigNoz also provides traces and metrics. So you can have all three telemetry signals under a single pane of glass.

FAQs

What are OpenTelemetry logs?

OpenTelemetry logs are timestamped event records represented with the OpenTelemetry log data model. They can include severity, body, attributes, resource information, instrumentation scope, and trace context such as TraceId and SpanId.

What type of log is OpenTelemetry?

OpenTelemetry is not a single log format like JSON, syslog, or plain text. It defines a log data model and telemetry pipeline that can collect existing logs, enrich them with context, and export them through OTLP or other supported exporters.

What is the difference between OpenTelemetry logs and events?

In OpenTelemetry, events are a specific kind of log record with a defined name and structure. Logs are broader and can include flexible diagnostic records from applications, systems, infrastructure, and logging libraries.

What is the difference between OpenTelemetry logs and traces?

Traces show the path and timing of a request across services. Logs capture detailed events at specific points in time. When logs include TraceId and SpanId, you can correlate a log entry with the exact trace and span where it happened.

Does OpenTelemetry replace logging libraries?

Usually, no. Most teams keep their existing logging libraries and use OpenTelemetry instrumentation, logging bridges, or the Collector to add context, parse logs, and export them to an observability backend.