---
title: OpenTelemetry Collector monitoring
source: https://docs.newrelic.com/docs/opentelemetry/collector-observability/collector-observability
---

> #### 💡 PREVIEW
>
> We're still working on this feature, but we'd love for you to try it out!
>
> This feature is currently provided as part of a preview pursuant to our [pre-release policies](https://docs.newrelic.com/docs/licenses/license-information/referenced-policies/new-relic-pre-release-policy/).

Monitor your [OpenTelemetry collector](https://opentelemetry.io/docs/collector/) health and performance with a dedicated APM UI experience. When your collector fails or misbehaves, it can cause a blackout of observability data, permanent data loss, or distorted insights. That's why we built Collector Observability—an APM experience tailored to the streaming work collectors perform. You can leverage the collector's [internal telemetry](https://opentelemetry.io/docs/collector/internal-telemetry/) to see at a glance how each component of your collector is performing, so you can spot issues before they impact your observability pipeline.

This experience adapts to how your collector is deployed. A collector running on its own gets a streamlined, collector-focused view. A collector attached to an instrumented application—sharing the same `service.name` (and thus entity)—gets the full APM experience plus collector insight. See [Choose your collector's view mode](#view-modes) for details.

Go to [Get started with collector observability](https://docs.newrelic.com/docs/opentelemetry/collector-observability/collector-observability-setup) to make sure your collector is configured correctly for this new experience.

## View your collector in the UI [#view-ui]

### Explore the internal telemetry in the APM UI [#explore-ui]

To view your collector's internal telemetry, navigate to **APM & Services > Services - OpenTelemetry > your_collector_service_name** to explore the collector's entity.

Depending on the components your collector uses, some charts might not be populated. For example, if you don't process logs in your collector, the charts related to that signal will be empty.

### Choose your collector's view mode [#view-modes]

Collector Observability supports two view modes: **Standalone Collector** and **Attached Collector**.

-   **Standalone Collector (recommended)**: a streamlined, collector-focused experience for a collector running on its own, represented by its own entity. It hides the standard **APM Summary** page and replaces it with a [view](#summary-page) focused on native collector telemetry.
-   **Attached Collector**: the full APM experience plus collector capability. In this mode the APM experience continues to treat the application as the primary entity but adds a second tab on the **APM Summary** page for the **Collector**. This mode is intended for collectors that run together with the monitored application and share its `service.name`, regardless of how they're deployed (for example, as a sidecar or in the same VM). If your collector has a different `service.name`, which we recommend, we synthesize a dedicated entity for it and you can use **Standalone Collector** mode instead. See [Limitations for Attached Collectors](#attached-limitations) for more details.

![Screenshot showing the Collector tab on the APM Summary page in 'Attached Collector' mode.](https://docs.newrelic.com/images/otel_collector_o11y-attached-tabs.webp "Screenshot showing the Collector tab on the APM Summary page in 'Attached Collector' mode.")

#### Set the mode

Go to **your collector's entity > Settings > Collector mode** and choose one of:

-   **Automatic** (default): the mode follows the `otelCollector.viewModeIac` tag described below; if that tag isn't set, the mode defaults to **Standalone Collector**.
-   **Standalone Collector** or **Attached Collector**: pins the entity to that mode, overriding the tag.

If you manage a large fleet of collectors, set the entity tag `otelCollector.viewModeIac` to `standalone` or `attached` instead of visiting each entity's settings individually. This only takes effect while the entity's **Collector mode** setting is **Automatic** — that way, you can always override this setting from within the UI, so you don't have to wait for a change in your infrastructure to access the view you prefer. There are a few ways to set tags at scale:

-   **Option 1**: Set `otelCollector.viewModeIac` as a [resource attribute](https://github.com/newrelic/nrdot-collector-releases/blob/2.5.0/examples/internal-telemetry-config.yaml#L67), so that New Relic [synthesizes](https://github.com/newrelic/entity-definitions/blob/92417f8cbd88d957032150e58ee28c644361e2ca/entity-types/ext-service/definition.yml#L121) the tag on ingest for you. This is often the easiest option, but it does contribute to your ingest volume. Instead of modifying your config file, you can also pass the argument `--config=yaml:service::telemetry::resource::otelCollector.viewModeIac: standalone` (or `attached`) to the collector.
-   **Option 2**: Use the [Terraform provider](https://registry.terraform.io/providers/newrelic/newrelic/latest/docs/resources/entity_tags).
-   **Option 3**: Use the [New Relic CLI](https://github.com/newrelic/newrelic-cli/blob/55467e869862b4a3baa6bbb62efadf35bc34d79a/docs/cli/newrelic_entity_tags_create.md).

![Screenshot showing the Collector mode setting](https://docs.newrelic.com/images/otel_collector_o11y-settings.webp "Screenshot showing the Collector mode setting")

### Summary page [#summary-page]

The **Collector** view opens with six KPI (key performance indicator) tiles that give you an at-a-glance read on your collector's health: **Items received**, **Items sent**, **Queue saturation**, **Receiver refused**, **Export failure rate**, and **Queue drops**. Each tile shows the current value and its trend versus one hour ago.

![Screenshot showing the KPI tiles](https://docs.newrelic.com/images/otel_collector_o11y-kpi-tiles.webp "Screenshot showing the KPI tiles")

Click any KPI tile to open a detail view with its full chart, broken down by telemetry signal (metrics, logs, spans), plus related telemetry charts for additional context. See the [KPI reference](https://docs.newrelic.com/docs/opentelemetry/collector-observability/collector-observability-kpis) for details on each KPI and related charts.

In case you are wondering what happened to the standard summary view that you are used to: The standard view is driven by transaction-scoped `apm.*` metrics and with the collector and its telemetry still in active development, we haven't been able to come up with a solid notion of a transaction that would provide an intuitive experience. Instead we rely on the native telemetry emitted by the collector and put it front and center with our KPI tiles.

Below the KPI tiles, the rest of the collector's telemetry is organized into collapsible sections you can expand as needed:

-   **Collector and Errors**: error logs and running instances.
-   **Receivers** and **Exporters**: per-component charts for each pipeline stage.
-   **Processors**: per-processor charts, including a dedicated chart for [memorylimiter](https://github.com/open-telemetry/opentelemetry-collector/tree/v0.161.0/processor/memorylimiterprocessor) due to its unique failure mode.
-   **Batch**: batching behavior, requires [batchprocessor](https://github.com/open-telemetry/opentelemetry-collector/tree/v0.161.0/processor/batchprocessor).
-   **Process**: the collector process's own resource usage—CPU, RSS memory, and heap.
-   **Infrastructure**: infrastructure relationships and metrics, if configured (see [configuration examples](https://docs.newrelic.com/docs/opentelemetry/collector-observability/collector-observability-setup#examples)).

![Screenshot showing the Summary page with its collapsible sections](https://docs.newrelic.com/images/otel_collector_o11y-summary.webp "Screenshot showing the Summary page with its collapsible sections")

![Screenshot showing the Summary page with the Infrastructure section expanded](https://docs.newrelic.com/images/otel_collector_o11y-summary-infra.webp "Screenshot showing the Summary page with the Infrastructure section expanded")

## Limitations [#limitations]

-   **Collector telemetry isn't stable yet**:
    -   The supported version of internal telemetry is implicitly defined by the [core collector version](https://github.com/open-telemetry/opentelemetry-collector) we use to build NRDOT, see version of the otlpreceiver in [manifest of nrdot-collector](https://github.com/newrelic/nrdot-collector-releases/blob/main/distributions/nrdot-collector/manifest.yaml).
    -   If the emitted telemetry changes during Public Preview, we reserve the right to only support the most recent version.

-   **Export format**: We fully support telemetry emitted via the internal `otlpexporter` and recommend adopting this format. We do not provide official support for metrics exported via Prometheus, but we do our best to ensure the experience still works as expected. We rewrote the queries to support the differing metric names, and as of now there are no known limitations for Prometheus.

-   **Custom component metrics**: Internal telemetry that isn't listed in the [internal telemetry documentation](https://opentelemetry.io/docs/collector/internal-telemetry/) isn't supported. Custom or [contrib components](https://github.com/open-telemetry/opentelemetry-collector-contrib) emit standard metrics but can also define their own metrics which are not surfaced in the experience.

-   **Golden metrics for OTel containers**: Not fully supported yet, which means some columns in the infrastructure panel might not be populated for containers.

### Limitations for Attached Collectors [#attached-limitations]

As mentioned [above](#view-modes), while we support it, we do recommend against collector and application sharing the same `service.name` as there are inherent limitations. This is because a collector is a fully-fledged application that emits telemetry adhering to the OTel semantic conventions and by choosing the same `service.name`, the boundaries between application and collector can become impossible to distinguish from the perspective of telemetry, thus leading to unintended side effects in the experience:

-   Aggregate metrics like throughput or error rate become less meaningful as they are calculated from a blend of application and collector metrics.
-   Capabilities like transactions and external services show a union of both application and collector data, requiring knowledge about implementation details to interpret the data displayed. As an example, transaction names are often driven by the names of HTTP routes, so in order to know which transactions belong to the application or the collector, you need to know which routes are implemented by each.