统一遥测：Prometheus、Grafana 和 OpenTelemetry 在 Kubernetes SRE 中的实用指南

场景： 你的组织在 Kubernetes 上运行基于微服务的平台。每个服务使用不同的格式发出指标、日志和追踪。最近，面向客户的 API 开始出现间歇性延迟峰值，但你当前的监控工具是孤立的。Prometheus 抓取指标，Grafana 可视化仪表板，但追踪仅在单独的 APM 工具中可用，日志也存储在另一个系统中。你需要一个统一视图来高效关联指标、追踪和日志。

症状： - 支付服务和产品目录 API 的 p99 延迟出现间歇性峰值。 - Prometheus 警报显示某些 Pod 的 CPU 被节流，但并不一致。 - 开发人员花费数小时交叉比对各仪表板、日志和追踪以定位根本原因。 - 由于 Kubernetes 组件的冗余警报过多，导致警报疲劳。 - 缺少遥测数据的单一事实来源。

诊断： 这些症状的根本原因在于缺乏标准的遥测产生和收集层。我们需要使用 OpenTelemetry 对服务进行插桩，将所有遥测数据通过 OpenTelemetry Collector 路由，并使用 Prometheus 和 Grafana 存储和可视化指标。统一的收集层将能够通过关联指标、追踪和日志来进行根本原因分析。

命令： 我们将实施步骤分解如下：

1. 使用 Helm 部署 OpenTelemetry Collector：

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm upgrade --install otel-collector open-telemetry/opentelemetry-collector \
  --namespace observability --create-namespace \
  -f otel-collector-config.yaml

otel-collector-config.yaml 示例：

receivers:
  otlp:
    protocols:
      grpc:
      http:
exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
    namespace: "otel"
  debug:
    verbosity: normal
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      exporters: [debug]

1. 使用 OpenTelemetry 对示例服务进行插桩（使用 Java agent 或 Python SDK）。对于 Java 服务：

java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=payments-service \
  -Dotel.exporter.otlp.endpoint=http://otel-collector.observability:4317 \
  -jar payments-service.jar

1. 配置 Prometheus 抓取 OpenTelemetry Collector 的指标端点。在 Prometheus 中添加 scrape 配置：

scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector.observability:8889']

1. 使用配置文件或通过 UI 导入 Grafana 仪表板。你还可以使用 Grafana 的 provisioning 方式：

apiVersion: 1
providers:
  - name: 'default'
    folder: 'SRE'
    type: file
    options:
      path: /var/lib/grafana/dashboards

风险控制： - 在修改生产可观测性技术栈之前，使用 API 对现有 Grafana 仪表板和 Prometheus 规则进行快照。 - 先在预发布环境中部署 OpenTelemetry Collector，并验证遥测数据是否正常流动。 - 使用独立的 observability 命名空间，并设置资源请求和限制（CPU/内存）。 - 切勿将 OpenTelemetry Collector 端点暴露到公网；使用内部网络。 - 对于关键服务，使用金丝雀部署：将一小部分流量路由到已插桩的 OpenTelemetry 服务，同时保持其余服务不变。

回滚： 如果 OpenTelemetry Collector 导致性能下降或转发问题，请快速回滚： 1. 移除 Prometheus 中 Collector 的 scrape 配置并重新加载 Prometheus。 2. 缩减 Collector 实例：kubectl scale deployment otel-collector -n observability --replicas=0 3. 如果你使用 Java agent 对服务进行了插桩，请重新部署之前未使用 agent 或禁用 agent 的版本。 4. 使用之前创建的快照恢复先前的 Grafana 仪表板。

验证： - 确认 Prometheus 正在抓取指标：curl -G http://prometheus:9090/api/v1/targets | grep otel-collector - 验证追踪是否流动：查看 Collector 日志中的导出 span，或使用 debug exporter。 - 创建 Grafana 仪表板并添加 Prometheus 查询，例如 histogram_quantile(0.99, sum(rate(http_server_duration_seconds_bucket{job="payments-service"}[5m])) by (le, service_name)) 来可视化 p99 延迟。 - 将延迟峰值与追踪关联：使用 Jaeger 或 Tempo 查询 span 数据（在后续指南中介绍）。 - 使用 top 命令检查 Collector Pod 资源占用，确保未被限制。

何时提交 OpsGlobal 工单： OpsGlobal 提供 24/7 远程 SRE 支持，可在以下情况下提供帮助： - 你的团队对 OpenTelemetry 经验有限，需要专家指导。 - 可观测性技术栈对生产环境至关重要，你需要全天候监控。 - 你正面临复杂事件，需要深入的专业知识来关联指标、追踪和日志。 - 你需要扩展可观测性设置以处理不断增长的遥测数据量，而无需额外招聘人员。