What is an OTEL Collector?

Proactively manage modern hybrid environments with predictive insights, intelligent automation, and full-stack observability.
Explore solutionsExplore our resource library for IT pros. Get expert guides, observability strategies, and real-world insights to power smarter, AI-driven operations.
Explore resourcesOur observability platform proactively delivers the insights and automation CIOs need to accelerate innovation.
About LogicMonitorGet the latest blogs, whitepapers, eGuides, and more straight into your inbox.
Your video will begin shortly
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 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]
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.
What is the primary advantage of using the OTel Collector?
The primary advantage is its vendor-neutral approach, allowing organizations to switch between telemetry backends without re-instrumenting their applications.
Can I use multiple receivers in a single pipeline?
Yes, you can configure multiple receivers within a single pipeline to ingest data from various sources, optimizing your data collection strategy.
How do I ensure the OTel Collector scales with my system?
Implement best practices for configuration files and continuously monitor performance to adjust resource attributes as needed based on the signal types using the most resources, ensuring the collector deployment scales efficiently with your system.
What are the security considerations for deploying the OTel Collector?
Ensure data is encrypted in transit and at rest, and apply access controls to maintain the security and integrity of your telemetry data.
© LogicMonitor 2025 | All rights reserved. | All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Blogs
See only what you need, right when you need it. Immediate actionable alerts with our dynamic topology and out-of-the-box AIOps capabilities.