统一可观测平台

摘要：四套系统、四个账号、四种查询语言，是排查效率最大的敌人。本文给出统一平台的选型维度，提出"采集层用 OTel 收口、存储层可替换"的分层架构，并给出分阶段落地路线。

适用环境

bash

# 盘点现有可观测组件（有多少套、各自在哪）
kubectl get svc -A 2>/dev/null | grep -E 'prometheus|loki|tempo|jaeger|elastic|grafana'
ps -ef | grep -E 'prometheus|loki|tempo|jaeger' | grep -v grep | head

# 现有数据规模（决定选型的关键输入）
curl -s http://127.0.0.1:9090/api/v1/status/tsdb | python3 -c \
 "import sys,json;print('series:',json.load(sys.stdin)['data']['headStats']['numSeries'])"

操作步骤

1. 明确选型的六个维度

维度	关注点
数据规模	日增数据量、保留时长、序列数
查询体验	是否支持跨信号跳转、语言是否统一
成本模型	按主机、按数据量还是按用户计费
部署形态	SaaS 托管 / 自建 / 混合
生态兼容	是否原生支持 OTLP、PromQL
合规要求	数据能否出境、是否需本地化存储

2. 采用分层架构：采集收口，存储可替换

应用埋点(OTel SDK)
      ↓ OTLP
OTel Collector  ← 收口层：统一采样、脱敏、路由、降基数
      ↓
存储后端：Prometheus/Mimir（指标）+ Loki（日志）+ Tempo（链路）+ Pyroscope（剖析）
      ↓
统一展示：Grafana（跨信号跳转、统一告警）

核心原则：采集层用 OTel 统一，存储层保持可替换。这样换后端时只需改 Collector 的 exporter，不用动一行业务代码。

3. 部署 Collector 作为统一入口

yaml

receivers:
  otlp:
    protocols:
      grpc: {endpoint: 0.0.0.0:4317}
      http: {endpoint: 0.0.0.0:4318}

processors:
  memory_limiter:            # 必须最先配置，防止 Collector OOM
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 20
  batch:
    send_batch_size: 8192
  resource:
    attributes:
      - key: deployment.environment
        value: production
        action: upsert

exporters:
  prometheusremotewrite:
    endpoint: http://mimir:9009/api/v1/push
  otlp/tempo:
    endpoint: http://tempo:4317
    tls: {insecure: true}
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    metrics: {receivers: [otlp], processors: [memory_limiter, resource, batch], exporters: [prometheusremotewrite]}
    traces:  {receivers: [otlp], processors: [memory_limiter, resource, batch], exporters: [otlp/tempo]}
    logs:    {receivers: [otlp], processors: [memory_limiter, resource, batch], exporters: [loki]}

4. 统一展示层配置数据源关联

指标数据源开启 exemplar，指向链路数据源；
日志数据源配置 derivedFields，从 trace_id 跳链路；
链路数据源配置 traces-to-logs，从 span 跳回日志。

5. 统一告警入口

yaml

# 所有告警收敛到 Alertmanager，避免多套通知渠道
alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

6. 分阶段落地路线

bash

# 阶段1：指标先行（Prometheus + Grafana），覆盖核心服务 RED 指标
# 阶段2：链路接入（OTel SDK + Tempo），打通 trace_id 与日志
# 阶段3：日志统一（结构化 + Loki），废弃零散的 grep 式排查
# 阶段4：剖析与前端（Pyroscope + RUM），补齐最后两块拼图
# 每阶段结束都做一次真实故障复盘，验证投入产出

DANGER

"一次性替换全部可观测系统"是高风险变更：迁移期间会出现监控盲区，而盲区恰恰最容易发生事故。请按信号类型分阶段迁移，并保证每阶段都有回退方案。

验证

bash

# 1) Collector 三条 pipeline 均正常
curl -s http://127.0.0.1:8888/metrics | grep -c 'otelcol_exporter_sent'

# 2) 各后端都能查到数据
curl -s 'http://127.0.0.1:9009/prometheus/api/v1/query' --data-urlencode 'query=up' | head -c 200
curl -s http://127.0.0.1:3100/ready
curl -s http://127.0.0.1:3200/ready

# 3) 从指标 exemplar 跳链路可用（人工在 Grafana 点一次）

# 4) 告警统一出口
curl -s http://127.0.0.1:9093/api/v2/status | head -c 200

常见坑

WARNING

先买平台再想"要什么数据"，会导致采集一堆没人看的指标。正确顺序是先定义 SLO 与排查场景，再倒推需要哪些信号。

WARNING

Collector 没有配置 memory_limiter 或 batch，在高负载下会 OOM，且会以极高频率小包发送，拖垮后端。这两个 processor 是生产必备。

DANGER

多套平台并行期间，告警规则会重复触发，导致告警风暴和"到底该看哪个"的混乱。迁移期请明确主备关系，并临时静默备用系统的告警。

统一可观测平台 ​

适用环境 ​

操作步骤 ​

验证 ​

常见坑 ​

参考资料 ​

统一可观测平台

适用环境

操作步骤

验证

常见坑

参考资料