#配置 Collector 指标

OpenTelemetry Collector 会暴露内部指标，这些指标可为其性能和运行状况提供有价值的洞察。借助这些指标，你可以监控 Collector 的行为，并有效排查潜在问题。

#概述

Collector 提供覆盖以下几个关键领域的指标：

• Collector 内存使用情况
• CPU 利用率
• 已处理的活动 trace 和 span 数量
• 丢弃的 span、日志或指标
• exporter 和 receiver 统计信息

当你部署一个 Collector 实例时，operator 会提供一个专用的监控服务（<instance_name>-collector-monitoring），该服务会在端口 8888 上提供这些内部指标。你可以将 Prometheus 或任何兼容的抓取工具指向该服务以收集这些指标。

#启用 Collector 指标

操作步骤

通过在 CR 中将 spec.observability.metrics.enableMetrics 设置为 true，为 Collector 实例启用指标收集：

apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  name: <name>
  labels:
    prometheus: kube-prometheus
spec:
  observability:
    metrics:
      enableMetrics: true
  config:
    service:
      telemetry:
        metrics:
          readers:
          - pull:
              exporter:
                prometheus:
                  host: 0.0.0.0
                  port: 8888

验证

你可以使用 Prometheus web 控制台来验证配置是否成功：

1. 在你的 Alauda Container Platform 集群中访问 Prometheus web 控制台。

2. 导航到 状态 → 目标。

3. 检查 <instance_name>-collector 格式的 ServiceMonitors 或 PodMonitors 是否处于 Up 状态。

#标识产生某个指标的 Collector

Collector 不再将 service_name、service_instance_id 和 service_version 标记到每一条内部指标序列上。这些属性只通过 target_info 指标暴露，该指标是 Prometheus 和 OpenTelemetry 中表示资源标识的标准方式。

要将某个指标归因到特定 Collector，请基于共享的 job 和 instance 标签，将该指标与 target_info 进行 join：

otelcol_receiver_accepted_spans
  * on (job, instance) group_left ("service.name", "service.version")
  target_info{endpoint="monitoring"}

这个查询有两个细节是不可省略的。省略任意一个都会得到错误结果，因此下面会分别说明。

#始终将 target_info 限定在监控端点

target_info 并不只属于 Collector 的内部 telemetry。任何携带 OpenTelemetry 资源属性的抓取目标都会发布一个同名指标，而 Collector 自身的 Prometheus exporter 端口（Configuration Example 中的 8889）会针对其接收到的每个上游应用发布一个 target_info 序列。所有这些序列都来自同一个抓取目标，因此它们共享同一组 job 和 instance：

found duplicate series for the match group {instance="10.3.6.73:8889", job="my-collector"}
on the right hand-side of the operation: [...];
many-to-many matching not allowed: matching labels must be unique on one side

Prometheus 会在匹配左侧之前，先检查 group_left 右侧是否唯一。otelcol_* 指标只存在于端口 8888，不会与这些序列发生冲突，但由于右侧向量中存在重复项，查询仍然会失败。

将选择器限定到监控端点可以移除这些重复项。operator 会将内部 telemetry 端口命名为 monitoring，Prometheus operator 会把该名称复制到 endpoint 标签中，因此 target_info{endpoint="monitoring"} 会为每个 Collector 精确选择一条序列。如果你的 Prometheus 没有设置 endpoint 标签，则可以改为按监控服务的 job 名称匹配，该名称由 operator 根据 Collector 名称派生：

target_info{job=~".*-collector-monitoring"}

#确认 Prometheus 对属性名称的写法

Collector 会以其原始 OpenTelemetry 名称暴露资源属性——service.name、service.instance.id 和 service.version。这些点号是否会保留到存储中，取决于 Prometheus 版本：

先单独查询 target_info{endpoint="monitoring"}，并在编写 join 之前从结果中读取标签名。本页中的示例使用带点号的名称，这也是 Alauda Container Platform 的存储方式。

#在多个监控面板中复用该 join

如果逐条重写每个查询不现实，可以定义一条记录规则，先执行一次 join，然后改为查询记录后的序列：

groups:
  - name: otelcol-internal-metrics
    rules:
      - record: otelcol:receiver_accepted_spans:with_identity
        expr: |
          otelcol_receiver_accepted_spans
            * on (job, instance) group_left ("service.name", "service.version")
            target_info{endpoint="monitoring"}