使用Prometheus、Grafana和OpenTelemetry实现统一可观测性：实用应急手册

场景

你的Kubernetes平台运行着数十个微服务，每个服务都会产生指标、日志和追踪。Prometheus抓取指标，Grafana可视化指标，但你混合使用了多种追踪工具。当事故发生时，你经常在仪表盘、日志查询和追踪视图之间切换，试图拼凑出发生了什么。这是典型的可观测性孤岛问题。

在本文中，我们将使用OpenTelemetry (OTel)进行仪器化和遥测数据收集，使用Prometheus存储指标，使用Grafana进行仪表盘和告警，构建一个统一的观测管道。我们还将使用exemplars（示例）直接从指标跳转到追踪，大幅缩短平均诊断时间（MTTD）。

症状

• checkout服务的p99延迟超过500ms，违反SLO。
• payments API的错误率攀升至2%，快速消耗错误预算。
• CPU和内存仪表盘没有明显异常，但用户报告系统变慢。
• 运维工程师手动跨日志和追踪关联时间戳，每次事故浪费30分钟。

诊断

首先使用PromQL定位问题。查询checkout服务的延迟直方图：

histogram_quantile(0.99,
  sum(rate(http_request_duration_seconds_bucket{service="checkout"}[5m])) by (le, route)
)

这将揭示哪些路由是慢的。假设/api/checkout是罪魁祸首。接下来，使用同一个直方图找到exemplar（示例）——一个具有代表性的trace ID。在Grafana中，在查询编辑器中启用exemplars。单击数据点上的火花图标，打开关联的追踪（例如Tempo）。

如果你还没有exemplars，仍可以通过时间戳关联追踪。但exemplars能让你快得多。

命令与配置

1. 部署OpenTelemetry Collector

OTel Collector是厂商中立的网关。创建ConfigMap：

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-conf
  namespace: observability
data:
  otel-collector-config.yaml: |
    receivers:
      otlp:
        protocols:
          grpc:
          http:
    processors:
      batch:
        timeout: 5s
    exporters:
      prometheusremotewrite:
        endpoint: http://prometheus:9090/api/v1/write
        retry_on_failure:
          enabled: true
      otlp:
        endpoint: tempo:4317
        tls:
          insecure: true
    service:
      pipelines:
        metrics:
          receivers: [otlp]
          processors: [batch]
          exporters: [prometheusremotewrite]
        traces:
          receivers: [otlp]
          processors: [batch]
          exporters: [otlp]

应用配置：

kubectl create ns observability
kubectl apply -f otel-collector.yaml

同时，将collector作为DaemonSet部署，以收集节点级指标并接收来自服务的OTLP。为简单起见，我们使用单个Deployment。

2. 使用OpenTelemetry仪器化服务

使用OpenTelemetry Operator注入自动仪器化：

kubectl apply -f https://github.com/open-telemetry/opentelemetry-operator/releases/latest/download/opentelemetry-operator.yaml

然后给部署添加注释：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: checkout
  namespace: prod
spec:
  template:
    metadata:
      annotations:
        instrumentation.opentelemetry.io/inject-java: "true"

或者手动使用SDK。对于Python服务：

from opentelemetry import trace
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor

trace.set_tracer_provider(TracerProvider())
trace.get_tracer_provider().add_span_processor(
    BatchSpanProcessor(OTLPSpanExporter(endpoint="otel-collector:4317"))
)

3. 配置Prometheus远程写入

启动Prometheus时启用远程写入接收器：

prometheus --web.enable-remote-write-receiver

在Prometheus配置中，确保有collector的抓取任务：

scrape_configs:
  - job_name: 'otel-collector'
    static_configs:
      - targets: ['otel-collector:8888']

4. 设置Grafana数据源和Exemplars

在Grafana中，添加Prometheus和Tempo作为数据源。对于Prometheus，在数据源设置中启用“Exemplars”，并添加一个派生字段用于trace ID查找：

• TraceID字段: traceID
• 数据源: Tempo
• 查询: {traceID="${__value.raw}"}

现在，你可以在任何Prometheus图表中点击exemplar打开完整追踪。

5. 构建仪表盘和告警

创建仪表盘，包含延迟、错误率和饱和度面板（USE方法）。对于告警，定义Prometheus规则：

groups:
  - name: checkout-slo
    rules:
      - alert: CheckoutP99High
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{service="checkout"}[5m]))
            by (le, route)
          ) > 0.5
        for: 10m
        annotations:
          summary: "Checkout服务p99延迟过高"

风险控制

• 金丝雀发布collector： 先启动一个实例，监控资源使用情况。
• 设置资源限制： 为collector设置内存和CPU限制，避免干扰其他服务。
• 限制远程写入速率： 使用queue_size和retry_on_failure避免淹没Prometheus。
• 备份配置： 在上线前将Prometheus、Grafana和OTel配置存储在Git中。
• 生产环境启用TLS，使用商业证书或mTLS保护OTLP端点。

回滚

如果OTel collector导致不稳定，可以快速回滚：

kubectl delete deployment otel-collector -n observability

这将停止所有OTLP摄取。Prometheus仍会查询现有的抓取目标。对于自动仪器化，从部署中移除注释：

kubectl annotate deployment checkout instrumentation.opentelemetry.io/inject-java-

对于Prometheus配置更改，使用之前的配置文件：

cp prometheus.yml.bak prometheus.yml
kill -HUP $(pidof prometheus)

验证

部署后，验证每一层：

1. Collector： 检查日志是否有错误：kubectl logs <otel-collector-pod>
2. Prometheus： 查询仅通过OTLP远程写入存在的指标，如otelcol_exporter_sent_metric_points。
3. Grafana： 打开仪表盘，确认新数据出现。
4. Exemplars： 在Grafana Explore中，运行PromQL查询，悬停数据点，点击“Exemplar”打开追踪。
5. 告警： 使用curl生成高延迟，验证10分钟内触发告警。

何时提交OpsGlobal工单

如果出现以下情况，你应该考虑聘请OpsGlobal：

• 团队每周花费超过10小时维护观测栈。
• 你需要为不支持OTel的传统服务提供高级仪器化。
• 你想要对观测基础设施本身进行7x24小时监控。
• 你即将迁移到服务网格，需要集成遥测数据的帮助。

OpsGlobal的远程SRE可以设计、部署和运维你的Prometheus、Grafana和OpenTelemetry栈，确保你达成SLO并获得所需的可见性。