Monitor the OpenTelemetry Collector separately from application telemetry

A healthy application does not prove that its collection service can receive and export observations.

Source facts

OpenTelemetry Collector exposes internal telemetry for monitoring and troubleshooting its own operation. By default it exposes internal metrics through a Prometheus interface and emits logs to stderr. Exporter queue capacity and queue size are among the documented operational measures. The internal telemetry configuration schema is under development and can undergo breaking changes.

Source: OpenTelemetry documentation — Internal telemetry.

Applicability

Review Collector self-observation and internal-telemetry configuration using the current internal telemetry guide.

DSE recommendation

DSE recommends monitoring each Collector instance’s availability, resource use, queue behavior, and export failures through an intentional management path. Keep instance identity so a healthy replica cannot hide a failing peer. Avoid relying entirely on the same broken export route to report its own outage. Review metric names and configuration during upgrades rather than copying an old endpoint example blindly. Assign alert ownership and thresholds from observed behavior, including the difference between a brief queue spike and sustained failure to drain.

Verification

In an approved test pipeline, compare Collector internal signals with a controlled destination interruption and recovery. Confirm alerts identify the affected instance and resolve when export catches up. Verify that loss of the Collector’s own telemetry is also visible through an independent availability check. Retain the affected instance identifier and expected internal signal with the alert result. Have the telemetry owner demonstrate the independent missing-Collector check so the failure exercise does not rely entirely on the broken pipeline to report itself.

Official reference

OpenTelemetry documentation — Internal telemetry. Reviewed October 20, 2026.