3. 指标数据生命周期：从采集、聚合、导出到存储的完整链路与成本热点分析

理解指标数据的完整生命周期，是实施降采样与成本控制的前提。指标从被采集到最终存储，经历了采集、预处理、聚合、导出、存储五个核心阶段。每个阶段都会产生不同的计算与存储开销，且成本热点分布极不均匀。本章将逐段拆解这条链路，定位成本瓶颈。

3.1 指标数据生命周期的五阶段模型

一个典型的 OpenTelemetry 指标从产生到落盘，遵循以下流水线。每个阶段的数据形态、处理方式和资源消耗差异显著。

3.2 各阶段成本热点深度分析

以下表格从数据形态、计算开销、存储开销、网络开销四个维度，逐一拆解每个阶段的成本特征。

3.3 采集阶段：高基数与网络带宽的博弈

采集阶段是数据进入系统的第一道关口，也是成本控制的第一个关键节点。OpenTelemetry SDK 在应用进程中采集指标，并通过 OTLP 协议批量发送到 Collector 或后端。

• 高基数问题： 每个唯一的标签组合（如 pod、instance、endpoint）都会产生一条独立的时间序列。当标签基数达到百万级时，采集的数据量会指数级增长。
• 网络带宽成本： 原始数据未经压缩时，每秒可能产生数 MB 到数百 MB 的传输量。云环境下的跨 AZ 或跨 Region 传输会产生显著的网络费用。
• 采集频率： 默认 10s 或 15s 的采集间隔，在高基数场景下会放大数据总量。降低采集频率是成本控制的第一道防线。

# OpenTelemetry Collector 配置示例：限制采集频率与批量大小
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        max_recv_msg_size_mib: 16  # 限制单次接收大小
exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
    add_metric_suffixes: false
    resource_to_telemetry_conversion:
      enabled: true
processors:
  batch:
    timeout: 5s           # 批量等待时间
    send_batch_size: 10000 # 每批最大指标数
    send_batch_max_size: 20000
  memory_limiter:
    check_interval: 1s
    limit_mib: 512
service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [prometheus]

3.4 聚合阶段：降采样的核心战场

聚合阶段是降采样策略实施的主阵地。OpenTelemetry Collector 的 metrics_transform 和 filter 处理器，以及 Prometheus 的 recording rules，都是常用的聚合工具。

3.5 导出与存储阶段：序列化与持久化的成本陷阱

导出阶段将聚合后的指标序列化为 OTLP、Prometheus Remote Write 或 JSON 格式。序列化格式的选择直接影响传输效率和存储压缩率。

3.6 成本热点总结与行动清单

基于以上分析，以下是针对每个阶段的成本控制行动清单：

1. 采集阶段： 降低采集频率（从 15s 改为 30s 或 60s）；限制高基数标签（如 pod、container_id）；启用批量发送。
2. 预处理阶段： 在 Collector 中尽早过滤无用指标；裁剪冗余标签；使用 filter 处理器丢弃低价值指标。
3. 聚合阶段： 实施时间窗口降采样（1m→5m→1h）；使用 recording rules 预计算常用聚合；对分位数指标使用 T-Digest 或 HDR Histogram。
4. 导出阶段： 优先使用 OTLP Protobuf 格式；启用 gzip 或 Snappy 压缩；调整批量大小以减少请求次数。
5. 存储阶段： 设置数据保留策略（热数据 7 天，温数据 30 天，冷数据归档）；使用对象存储（S3/GCS）存储历史数据；启用 TSDB 的压缩与合并功能。