---
title: OpenTelemetry Collector KPI reference
source: https://docs.newrelic.com/docs/opentelemetry/collector-observability/collector-observability-kpis
---

The [Collector Observability Summary page](https://docs.newrelic.com/docs/opentelemetry/collector-observability/collector-observability#summary-page) opens with six KPI (key performance indicator) tiles that give you an at-a-glance read on your collector's health. Click any tile to open a detail view with the underlying chart plus a set of related telemetry charts that help you investigate an unexpected change in the KPI. In most cases, the related telemetry can be faceted by signal type or component (exporter / processor / receiver) when selecting a specific signal type. This page explains what each KPI means and why each of its related telemetry charts is there.

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

## Items received [#items-received]

Amount of telemetry entering the collector via its receivers. Common causes of an unexpected change are upstream client issues — fewer or more instrumented applications sending data — or a receiver failing to scrape the data it's configured to pull.

Related telemetry:

-   **Receiver accepted**: breaks the total down by signal or receiver, so you can tell where exactly the change originates from.
-   **Receiver refused**: shows whether part of the drop is from refused telemetry (see also [Receiver refused](#receiver-refused)) rather than a drop in upstream traffic.
-   **Memory limiter drop ratio**: receivers refusing data could ultimately be due to the [memorylimiter](https://github.com/open-telemetry/opentelemetry-collector/tree/v0.161.0/processor/memorylimiterprocessor) blocking.

## Items sent [#items-sent]

Telemetry successfully sent by the collector's exporters to downstream destinations. Common causes of an unexpected change are upstream issues (processors dropping data, receivers refusing data, or clients feeding the collector less data) or exporter failures.

Related telemetry:

-   **Exporter sent**: breaks the total down by signal or exporter, so you can tell where exactly the change originates from.
-   **Exporter failures**: surfaces exporter failures (see [Export failure rate](#export-failure-rate)) as a cause of fewer items being sent.
-   **Exporter queue saturation**: shows whether a saturated send queue (see [Queue saturation](#queue-saturation)) is holding items back from being sent.

## Queue saturation [#queue-saturation]

How full each exporter's send queue is; a full queue leads to data loss. Common causes of a spike in saturation are exporter failures backing up the queue or a spike in traffic hitting an undersized queue.

Related telemetry:

-   **Exporter send failures**: failed exports often take longer, e.g. timeouts, and they lead to retries which cause backup in the queue.
-   **Exporter queue size vs. capacity**: shows the raw queue size against its configured capacity, so you can tell whether saturation is caused by a traffic spike or the queue simply being undersized.

## Receiver refused [#receiver-refused]

Upstream telemetry that receivers are actively rejecting. This should normally be zero; any sustained rate is an anomaly to diagnose via logs.

Related telemetry:

-   **Memory limiter drop ratio**: receivers start refusing telemetry once the [memorylimiter](https://github.com/open-telemetry/opentelemetry-collector/tree/v0.161.0/processor/memorylimiterprocessor) processor blocks which would be the actual root cause.
-   **Process memory RSS**: contextualizes the memorylimiter metrics by showing the collector's memory usage.
-   **Process runtime heap allocated**: a growing Go heap can lead to unhealthy garbage collection which in turn can hurt the collector's throughput.

## Export failure rate [#export-failure-rate]

The percentage of exporter requests that fail and get retried, if configured. Common causes are network issues or misconfiguration of exporters or destinations.

Related telemetry:

-   **Exporter failures**: shows the absolute number of failures (numerator) by signal or exporter, so you can tell where exactly the failures are occurring.
-   **Exporter sent**: shows the absolute number of exports (denominator) to put the failures and rate into perspective.

## Queue drops [#queue-drops]

Telemetry the collector couldn't queue for export because the queue was full. Data that didn't get queued is dropped, i.e. confirmed data loss.

Related telemetry:

-   **Exporter enqueue failures**: breaks the confirmed data loss down by signal or exporter.
-   **Exporter queue size vs. capacity**: shows whether the queue filled up rapidly, e.g. traffic spike, or gradually, e.g. undersized collector, undersized queue or persistent failures piling up.
-   **Exporter failures**: export failures often back up the queue until it's full, so this helps confirm whether that's the root cause.