OpenTelemetry (OTEL) provides vendor-neutral ways of application instrumentation so that customers can switch between Telemetry backends without re-instrumentation. It enhances observability by adding valuable data alongside other monitoring systems. OpenTelemetry consists of the OpenTelemetry SDK, the OpenTelemetry API, and the OpenTelemetry Collector. This approach ensures flexibility and standardization for monitoring systems.
This article will cover OTel and its architecture (receivers, processors, exporters, extensions, and service config). You’ll also learn key practices to help you deploy and maintain your OTel Collector so you can meet your organization’s needs.
As a core component of OpenTelemetry, OTel collectors are deployed as pipeline components between instrumented applications and telemetry backends. With an OTel Collector, telemetry signals are ingested in multiple formats, translated to OTel-native data formats, and exported to backend-native formats. They are part of the three pillars of observability (metrics, logs, and traces), with traces for API being the most mature and metrics and logs in different stages of development.
The OTEL Collector empowers organizations with vendor-neutral observability, allowing seamless integration with any telemetry backend.
The OpenTelemetry collector consists of three main components: Receivers, processors, and exporters. These collector components are used to construct telemetry pipelines.
Receivers are responsible for transferring data to the collector. They can be push-based or pull-based. Receivers accept data in specified formats, translate it into an internal format, and then pass it to batch processors and exporters defined in applicable pipelines. The format of any trace data or metrics supported is receiver-specific.
Processors transform metrics and modify the names of spans before sending data to exporters. They also batch data before sending it out, retry when exporting fails, and add metadata and tail-based sampling. The order in which processors are configured dictates the sequence of data processing.
Exporters are tasked with exporting processed telemetry data to various observability backends, both open-source and commercial. They ensure that observability data reaches its intended destination in a compatible format, supporting seamless integration with different observability platforms.
Extensions add optional capabilities to the OTel Collector without directly accessing telemetry data. They are used primarily for managing and monitoring OTel collectors and offer optional enhancements for the collector’s core functionality.
The service section of the OTel Collector enables configured components within defined receivers, processors, exporters, and extensions sections. The section contains a list of extensions and pipelines of traces, metrics, and logs consisting of sets of receivers, processors, and exporters. Further information is available in Configurations for OpenTelemetry Collector Processors and LM OTEL Collector Logging.
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
exporters:
otlp:
endpoint: otelcol:4317
extensions:
health_check:
pprof:
zpages:
service:
extensions: [health_check,pprof,zpages]
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
metrics:
receivers: [otlp]
processors: [batch]
exporters: [otlp]
logs:
receivers: [otlp]
processors: [batch]
exporters: [otlp]By implementing best practices, users can optimize the OTEL Collector for performance, scalability, and security, maximizing its observability potential.
LogicMonitor offers a customized version of the OTel Collector, which is pre-configured to forward traces from instrumented applications to the LogicMonitor platform. With LogicMonitor’s central management offering, users and providers can streamline observability strategies with little troubleshooting.
For more information on integrating with LogicMonitor, visit OpenTelemetry Collector for LogicMonitor Overview.
The OTEL Collector is a separate process that receives, processes, and exports telemetry data. The SDK, on the other hand, resides inside your application and is responsible for generating and sending telemetry data to the Collector or directly to a backend.
Yes, the OpenTelemetry Collector can be deployed both as a sidecar (per app or service) for localized control or as a centralized service to collect telemetry across multiple sources. The choice depends on your observability strategy and infrastructure scale.
Yes. A working telemetry pipeline requires at least one receiver (to ingest data), one processor (optional but recommended for batching or sampling), and one exporter (to send data to a backend).
If a receiver isn’t set up properly or isn’t listed in the pipeline, the Collector won’t ingest any data from that source. Always validate configurations to avoid silent failures in your telemetry ingestion.
LogicMonitor offers a pre-configured OpenTelemetry Collector that automatically routes traces to its platform by reducing setup complexity and allowing users to focus on observability rather than infrastructure plumbing.
© LogicMonitor 2025 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
