如何基于OpenTelemetry Trace生成持久化指标？

核心思路 #

核心是在OTEL Collector层面实时从Trace中提取属性计算指标，将指标导出至专门的时序存储系统，实现指标与Trace存储的解耦——即使旧Trace被清理，指标依然能长期保留，完全满足业务决策的持久化需求。

具体实现步骤 #

1. 用官方spanmetricsprocessor生成基础指标 #

OTEL Collector内置的spanmetricsprocessor可以直接从Span（Trace的核心单元）中提取维度、计算聚合指标（请求数、延迟分位值、错误率等），全程在Collector内存实时处理，无需事后查询Trace。示例配置片段：

processors:
  spanmetrics:
    metrics_exporter: prometheus  # 指定指标导出目标
    latency_histogram_buckets: [100us, 1ms, 5ms, 10ms, 50ms, 100ms, 200ms, 500ms, 1s, 5s]
    dimensions:
      - name: http.method
      - name: http.status_code
      - name: service.name  # 可添加自定义业务维度，如接口名、租户ID
    dimensions_cache_size: 1000

2. 配置指标持久化Exporter #

要实现指标长期留存，需将生成的指标导出至支持持久化的存储：

• Elasticsearch：利用其时序索引+ILM（索引生命周期管理）策略，自动按周期滚动索引、管理数据生命周期
• Prometheus Remote Write：推送至Thanos、M3DB等分布式时序存储，实现跨集群、超长期的数据保留

示例ES指标导出配置：

exporters:
  elasticsearch/metrics:
    endpoints: ["http://elasticsearch:9200"]
    index: "otel-metrics-%{+yyyy.MM.dd}"
    ilm:
      enabled: true
      policy_name: "metrics-retention-policy"  # 提前在ES创建保留半年/一年的ILM策略

随后在Collector服务管道中串联处理器与Exporter，分离Trace和指标的流转路径：

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, spanmetrics]
      exporters: [jaeger, elasticsearch/traces]
    metrics:
      receivers: [otlp, spanmetrics]
      processors: [batch]
      exporters: [elasticsearch/metrics, prometheus]

3. 扩展自定义业务指标 #

如果官方处理器无法满足复杂业务需求（如按用户等级统计请求量），可通过组合处理器实现：

• 用filterprocessor过滤出目标Span
• 用metricstransformprocessor做自定义聚合、重命名

示例统计特定接口的成功请求数：

processors:
  filter/order-create:
    spans:
      include:
        match_type: regexp
        attributes:
          - key: http.path
            value: "/api/v1/order/create"
  metricstransform/success-count:
    transforms:
      - action: update
        include: "trace.server.request_count"
        new_name: "business.order.create.success_count"
        operations:
          - action: filter_value
            label: "http.status_code"
            value: "200"

4. 持久化保障措施 #

• 配置ILM策略：为ES指标索引设置热-温-冷阶段，热阶段存最近30天高频查询数据，温阶段存30-180天数据，冷阶段存超长期归档数据，自动迁移清理
• 选用分布式存储：如Thanos，将Prometheus指标做远程持久化，支持多副本存储，避免单点故障导致数据丢失

5. 展示层衔接 #

• Kibana：直接导入ES指标索引，利用可视化功能创建请求趋势、延迟分布、错误率等仪表盘
• Grafana：添加Prometheus/ES数据源，复用OpenTelemetry官方指标模板快速生成可视化面板

关键注意事项 #

• 绝对不要依赖事后查询Trace生成指标：既影响性能，又会因Trace清理丢失数据，必须在Collector实时处理
• 控制指标维度数量：过多维度会导致指标基数爆炸，仅保留业务决策必需的核心维度（如服务名、接口名、状态码）
• 测试验证逻辑：在测试环境验证指标生成准确性、ILM策略有效性，以及Trace清理后指标的可访问性

内容的提问来源于stack exchange，提问作者sergi