Configuring Metrics for the Monitoring Stack
The OpenTelemetry Collector can be integrated with the platform monitoring stack to expose its own operational metrics via Prometheus. As a cluster administrator, you can set up this integration to achieve the following:
- Automatically generate Prometheus
ServiceMonitorresources that scrape both the Collector's internal pipeline metrics and any configured Prometheus exporter endpoints. - Use the Prometheus receiver within the Collector to pull metrics from the cluster's built-in monitoring infrastructure.
TOC
Sending Metrics to the Monitoring StackEnabling Automatic ServiceMonitor CreationUsing a Custom PodMonitorSending Metrics to the Monitoring Stack
The OpenTelemetryCollector custom resource (CR) supports automatic creation of Prometheus ServiceMonitor or PodMonitor resources. These resources instruct the monitoring stack to collect metrics from the Collector's internal telemetry endpoint as well as from any Prometheus exporter endpoints defined in the pipeline.
Enabling Automatic ServiceMonitor Creation
When you enable the enableMetrics option in the Collector CR, the Alauda build of OpenTelemetry v2 Operator automatically provisions the necessary ServiceMonitor or PodMonitor resources for metric collection.
The following example shows a Collector CR configured with a Prometheus exporter and automatic metrics collection enabled:
prometheus=kube-prometheusis required in ACP prometheus.- Enables the Operator to automatically create
ServiceMonitororPodMonitorresources that target the Collector's metrics endpoints, including both internal telemetry and Prometheus exporter ports.
Turning on enableMetrics results in two separate ServiceMonitor resources being created:
- A
ServiceMonitortargeting the<instance_name>-collector-monitoringservice, which collects the Collector's own internal operational metrics. - A
ServiceMonitortargeting the<instance_name>-collectorservice, which collects metrics published by any Prometheus exporter configured in the pipeline.
Using a Custom PodMonitor
For scenarios that require more granular control over metric collection — such as filtering out duplicate labels introduced during Prometheus scraping — you can create a PodMonitor resource manually instead of relying on the automatic ServiceMonitor provisioning.
The following example demonstrates a PodMonitor that targets the Collector pods and applies relabeling rules to drop redundant labels:
prometheus=kube-prometheusis required in ACP prometheus.- Must match the name of your OpenTelemetry Collector CR, following the pattern
<cr_name>-collector. - The port exposing the Collector's internal operational metrics. This port is always named
metrics. - The port exposing metrics from the Prometheus exporter configured in the Collector pipeline.