Skip to main content
In this lesson we cover how to read and configure the OpenTelemetry Collector’s internal logs to help diagnose startup, pipeline loading, configuration issues, and runtime problems. By default the Collector writes internal logs to standard error (stderr) at the INFO level even if you do not configure service.telemetry.logs. These logs include startup/shutdown messages, pipeline readiness confirmations, component warnings, and metadata such as the Collector version and service instance ID.
By default the Collector logs internal activity at INFO to standard error (stderr). This provides immediate visibility into startup and runtime behavior without adding any telemetry configuration.

​
Minimal configuration example

A minimal Collector config without a service.telemetry.logs section still emits INFO logs to stderr:
When you run the Collector with this config, you will see internal logs like the example below printed to the console:
These messages indicate the Collector version, a unique service instance ID, and readiness confirmations.

​
Where to view Collector logs in production

Common ways to stream Collector logs by environment: Tip: in Kubernetes, replace <pod-name> with your actual Collector pod name or use a label selector with -l. See Kubernetes Logs for more details.

​
Configuring service.telemetry.logs

To control Collector internal logging (verbosity, format, sampling, and destinations), add a service.telemetry.logs block under service. The level field accepts DEBUG, INFO, WARN, and ERROR.
  • DEBUG: detailed component-level activity — useful for development and troubleshooting.
  • INFO: default operational messages.
  • WARN / ERROR: reduce output to only problematic events — recommended for production.
Example: enable debug-level logs to get more detailed initialization output:
YAML to set the level to DEBUG:
For production use a higher threshold such as ERROR:
Writing logs to local files or enabling DEBUG in production can increase disk usage and expose sensitive details. Review retention and access controls if you persist Collector logs.

​
Advanced logging options

Beyond level, the service.telemetry.logs block supports additional fields to fine-tune behavior: development, encoding, caller info, stack traces, sampling, and output paths. Example advanced configuration:
Notes:
  • Use encoding: json for structured logs that integrate with log aggregation systems.
  • Enable sampling to prevent repeated identical messages from flooding logs.
  • output_paths and error_output_paths let you persist logs to files in addition to stderr.
The image is a table outlining various logging settings, their default values, purposes, and typical use cases. It provides guidance on configuring logging for different scenarios such as debugging, development, and high-volume environments.

​
Structured logging and troubleshooting

When encoding: json is enabled, each log line is a JSON object which is much easier to ingest and query in centralized log systems. During debugging, keep disable_stacktrace: false and disable_caller: false to get file/line and stack traces for errors. Example pipeline + telemetry configuration — ensure the telemetry block is nested under service:
This setup validates pipelines and allows you to inspect telemetry data and internal Collector logs via the debug exporter.

​
Quick references

Log level summary: Commands to stream Collector logs (repeat):

​
Key takeaways

  • service.telemetry.logs.level controls the Collector’s internal log verbosity (this is separate from telemetry data you collect or export).
  • By default, the Collector emits INFO-level logs to stderr.
  • Use journalctl, docker logs, or kubectl logs to access Collector logs in common environments.
  • Tune level, encoding, sampling, and output_paths to balance visibility and performance.
  • Persist or forward internal logs to a centralized backend to aid cross-system troubleshooting and historical analysis.
The image outlines key takeaways related to service telemetry logs, including details on log control, verbosity, export, and debugging for centralized monitoring and troubleshooting.
This is the first place to inspect when validating pipeline initialization or diagnosing why telemetry data is not reaching its backend. For more details, see the Collector documentation and the OpenTelemetry specifications:

Watch Video