使用Prometheus、Grafana和OpenTelemetry实现统一可观测性：SRE实用指南

场景

某微服务应用在Kubernetes集群上运行，团队分别使用Prometheus（指标）、Elasticsearch（日志）和Jaeger（链路追踪），但指标、日志和追踪之间缺乏关联，排障时平均修复时间（MTTR）长达数小时。

症状

• 告警频繁但难以定位根因；
• 指标显示高延迟，但无法关联到具体服务或请求；
• 追踪数据不完整，缺失跨服务上下文。

诊断

核心问题在于缺乏统一的可观测性管道。OpenTelemetry作为CNCF标准，可以统一采集指标、日志和追踪，并通过导出器发送至Prometheus（指标）和Grafana Tempo（追踪）。Grafana作为统一仪表盘展示所有数据。

命令

1. 部署OpenTelemetry Collector

使用Helm安装OpenTelemetry Collector，配置为DaemonSet以采集每个节点的数据。

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install otel-collector open-telemetry/opentelemetry-collector \
  --set mode=daemonset \
  --set config.receivers.otlp.protocols.grpc.endpoint=0.0.0.0:4317 \
  --set config.exporters.prometheus.endpoint=0.0.0.0:8889 \
  --set config.exporters.otlp.endpoint=tempo.default.svc.cluster.local:4317

2. 配置Prometheus采集目标

在Prometheus配置中添加OpenTelemetry Collector的指标端点。

scrape_configs:
  - job_name: 'otel-collector'
    scrape_interval: 10s
    static_configs:
      - targets: ['otel-collector.default.svc.cluster.local:8889']

3. 部署Grafana Tempo（用于追踪）

helm install tempo grafana/tempo --set storage.trace.backend=local

4. 配置Grafana数据源

在Grafana中添加Prometheus和Tempo数据源，并使用OpenTelemetry作为Trace数据源。

风险控制

• 限制采集器资源（CPU/内存），避免影响业务容器。
• 使用TLS加密传输，避免敏感信息泄露。
• 设置采样率（例如10%），防止追踪数据爆炸。

回滚

若出现问题，删除Helm发布并恢复原配置：

helm uninstall otel-collector
helm uninstall tempo
# 恢复Prometheus配置

删除Grafana中新增的数据源。

验证

• 检查Prometheus目标：http://prometheus:9090/targets，确认状态为UP。
• 在Grafana中添加“Tempo”仪表盘，执行查询并查看追踪详情。
• 使用kubectl logs确认采集器日志无错误。

何时提交OpsGlobal工单

• 需要处理高基数指标或自定义采样策略。
• 集群规模超过100个节点，采集器性能瓶颈。
• 需要定制OpenTelemetry处理器或导出器。
• 集成现有告警与仪表盘的高级需求。 OpsGlobal提供7×24小时专家支持，加速可观测性建设。