场景
某微服务架构的电商平台,运行在 Kubernetes 集群上。客户反馈订单响应缓慢,但现有监控只显示 CPU 和内存,无法定位具体服务或代码瓶颈。团队决定引入 OpenTelemetry 进行统一 instrumentation,结合 Prometheus 和 Grafana 实现指标、链路、日志的关联分析。
症状
- 订单接口 P99 延迟从 200ms 上升至 2s
- 无错误率突增,但部分请求超时
- 现有监控无法追踪请求路径
诊断
通过 OpenTelemetry SDK 为 Java 微服务添加自动 instrumentation(如 Jaeger 导出器),并在 Kubernetes 中部署 OpenTelemetry Collector 作为代理。Collector 将指标导出到 Prometheus,链路导出到 Jaeger/Grafana Tempo。
命令
1. 部署 OpenTelemetry Collector
kubectl apply -f - <<EOF
apiVersion: v1
kind: ConfigMap
metadata:
name: otel-collector-conf
data:
config.yaml: |
receivers:
otlp:
protocols:
grpc:
http:
processors:
batch:
exporters:
prometheus:
endpoint: "0.0.0.0:8889"
logging:
loglevel: debug
service:
pipelines:
metrics:
receivers: [otlp]
processors: [batch]
exporters: [prometheus, logging]
---
apiVersion: v1
kind: Service
metadata:
name: otel-collector
spec:
selector:
app: otel-collector
ports:
- name: otlp-grpc
port: 4317
targetPort: 4317
- name: otlp-http
port: 4318
targetPort: 4318
- name: prometheus
port: 8889
targetPort: 8889
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: otel-collector
spec:
replicas: 1
selector:
matchLabels:
app: otel-collector
template:
metadata:
labels:
app: otel-collector
spec:
containers:
- name: otel-collector
image: otel/opentelemetry-collector-contrib:0.96.0
args: ["--config=/conf/config.yaml"]
ports:
- containerPort: 4317
- containerPort: 4318
- containerPort: 8889
volumeMounts:
- name: otel-collector-config
mountPath: /conf
volumes:
- name: otel-collector-config
configMap:
name: otel-collector-conf
EOF
2. 配置 Prometheus 抓取
在 prometheus.yml 中添加 scrape_config:
scrape_configs:
- job_name: 'otel-collector'
scrape_interval: 10s
static_configs:
- targets: ['otel-collector:8889']
3. Grafana 仪表盘
添加 Prometheus 数据源,导入示例仪表盘(如 Node Exporter Full 或自定义 OTel 仪表盘)。
风险控制
- 先在 staging 环境部署 Collector
- 限制 Collector 资源(CPU 200m, 内存 512Mi)
- 使用批处理处理器避免过载
- 启用日志导出器监控 Collector 输出
回滚
- 删除 OpenTelemetry Collector 部署:
kubectl delete deployment otel-collector - 还原 prometheus.yml 移除相应的 scrape_config
- 移除应用的 instrumentation 依赖(如删除 Jaeger agent sidecar)
验证
- Prometheus 目标页面(/targets)显示 UP 状态
- Grafana 中可查询到 openTelemetry 指标,如
http_server_duration_ms - 在 Jaeger UI 中查看完整链路和 span 详情
何时提交 OpsGlobal 工单
- 自定义 instrumentation 导致性能衰退或数据丢失
- 需要高基数指标(如用户 ID 标签)调优
- 链路与指标关联(exemplar)配置复杂
- Collector 处理瓶颈或内存溢出
适用场景
适合正在处理 Observability、Kubernetes, SRE, OpenTelemetry, Prometheus 相关问题的团队,用于快速建立排查路径和交付标准。
问题背景
本文通过真实场景,详解如何使用 OpenTelemetry 收集指标与链路,Prometheus 存储指标,Grafana 展示仪表盘,并附有完整操作步骤、风险控制及回滚方案。
排查步骤
先确认影响范围和最近变更,再收集日志、配置、指标和链路数据,最后按风险从低到高执行修复。
命令示例
示例命令请替换为你的真实资源名,并使用环境变量保存账号、密码、token 等敏感信息。
风险说明
生产环境操作前需要确认备份、权限边界、变更窗口和回滚路径,避免扩大故障影响。
回滚方案
保留原配置和发布版本;如修复后指标异常,立即回退配置、镜像或数据库变更并复核日志。
交付清单
问题定位记录、关键命令、修复步骤、验证结果、后续优化建议。
遇到类似技术问题?
如果你的服务器、K8s、Docker、CI/CD、数据库或监控系统出现类似问题,可以提交日志和配置文件,我们帮你远程诊断。