1. 这不是“能不能用”的问题而是“值不值得替”的实战判断最近三个月我帮三家公司做过可观测性栈的选型评估其中两家明确提出了同一个问题“用 Prometheus Grafana Tempo 这套开源组合能不能把 New Relic、Datadog 或者听云这类商业 APM 替掉”——注意他们问的不是“技术上是否可行”而是“上线后会不会天天救火”“运维成本到底降没降”“老板看了报表敢不敢拍板决策”。这背后藏着真实业务场景里的三重压力一是监控告警不准、链路断点找不到导致线上故障平均修复时间MTTR卡在 45 分钟以上二是商业 APM 按主机数/事务量计费年续费动辄几十万且扩容必须提前报预算三是研发团队抱怨“APM 界面太重、查个慢 SQL 要点 7 下菜单、根本没法嵌入日常 CI/CD 流程”。Prometheus、Grafana、Tempo 这三个名字现在几乎成了可观测领域的“默认三件套”但很多人只记得它们开源、免费、社区活跃却忽略了它们各自的设计哲学和能力边界。Prometheus 是指标采集的“狙击手”——它擅长高精度、高频率抓取结构化数值比如 CPU 使用率每 15 秒采一次但天生不存原始日志、不支持跨服务上下文透传Grafana 是可视化“指挥台”能拼接任意数据源画图但它本身不存数据、不处理告警逻辑、不管理权限体系Tempo 是分布式追踪的“录像机”专注 trace 数据的低成本写入与快速检索但它不提供 span 分析模型、不自动识别慢调用根因、不联动指标做下钻分析。这三者加起来不是天然的 APM 替代品而是一套需要你亲手焊接、调校、加固的观测底盘。真正决定“能不能替掉商业 APM”的从来不是组件列表而是你有没有能力补足这四个断层指标-日志-链路的三元闭环是否自动打通告警是否能从“CPU 90%”升级到“支付下单失败率突增 对应 trace 中 payment-service 的 db.query 耗时飙升至 2.3s”研发能否在 IDE 里点开报错堆栈一键跳转到该请求完整的 trace 视图和关联的 JVM 内存曲线运维是否能在 Grafana 里用一个变量控制所有面板的数据源切换而不用手动改 17 个面板的查询语句如果这四条中有一条做不到那所谓“替换”大概率会变成“多维护一套系统”而不是“降本增效”。接下来我会用真实部署过的两个案例电商秒杀链路诊断、IoT 设备集群健康巡检拆解这套组合的实际能力水位告诉你哪些能抄作业哪些必须自己造轮子。2. 开源可观测栈的真实能力图谱不是功能罗列而是能力对齐2.1 商业 APM 的核心能力锚点必须先划清楚要判断开源组合能否替代第一步不是看 Prometheus 能不能装而是反向梳理商业 APM 实际交付了什么。我在过去两年深度使用过 Datadog、New Relic 和国内某头部 APM 厂商的产品把它们共性最强、用户最依赖的六大能力提炼出来作为后续对比的标尺能力维度商业 APM 典型表现用户真实诉求非宣传话术是否可被开源组合覆盖全栈自动埋点Java Agent 自动注入 Spring MVC Controller、MyBatis、Redis、HTTP Client 等入口出口“新上线一个微服务不用改一行代码5 分钟内就能看到接口 P95 延迟、错误率、上下游依赖关系”⚠️ 部分覆盖需配合 OpenTelemetry SDK 或兼容 Agent智能根因定位点击异常接口 → 自动高亮慢 span → 关联显示该 span 所在宿主机的 CPU、JVM GC 频率、线程阻塞数“别让我猜直接告诉我‘是 Redis 连接池耗尽导致下游超时’”❌ 未覆盖需自研规则引擎或集成第三方分析工具统一告警中心告警策略按服务/环境分组支持多通道通知企微/钉钉/邮件/电话告警聚合去重100 个实例同时 CPU 高只发 1 条“半夜三点收到 37 条重复告警最后发现是负载均衡器配置错了”⚠️ 基础覆盖Alertmanager 可实现但策略配置复杂、静默管理弱低门槛协作分析产品经理用自然语言描述“昨天 20:00-21:00 订单提交失败率上升”系统返回 Top3 失败接口对应 trace 样本关联指标趋势“别让我学 PromQL我要的是结果不是查询语法”❌ 未覆盖需额外构建语义层或接入 LLM 前端合规审计追踪所有面板操作、告警触发、数据导出行为留痕支持按角色设置数据可见范围如测试人员看不到生产 DB 指标“等保三级要求日志留存 180 天且操作记录不可篡改”❌ 未覆盖Grafana RBAC 仅限面板级无细粒度字段权限SLA/SLO 可视化自动计算并展示“API 可用性 SLO99.95%当前达成率 99.92%距违约还有 4 小时”“运维不用算公式SLO 状态直接决定是否启动应急预案”✅ 可覆盖Prometheus Grafana 自定义 SLO 库可实现这个表格不是为了贬低开源方案而是划清底线如果你的业务只需要 SLO 监控和基础告警那 Prometheus Grafana 已足够但如果你的团队每天要处理 20 起跨服务故障且要求 15 分钟内定位到具体代码行那仅靠 Tempo 查 trace大概率会让你在凌晨三点对着屏幕发呆。2.2 Prometheus指标采集的“精准但狭隘”Prometheus 的设计哲学是“拉取式 时序数据库 强类型指标”这决定了它的优势和死穴。我拿电商大促期间的真实压测数据对比说明它做得极好的事每秒采集 5000 个指标如http_request_duration_seconds_bucket{le0.2,serviceorder-api}存储压缩率高达 12:1单节点支撑 200 万 series 毫无压力PromQL 查询响应稳定在 200ms 内即使查 7 天前的 P99 延迟曲线也能秒出结果告警规则天然支持 label 匹配比如ALERTS{alertstatefiring, service~payment|order} 1一条规则就能覆盖支付和订单两个服务。它根本做不到的事无法存储原始日志比如 Nginx access log 的完整 request body无法关联 traceID你查到order-api接口延迟飙升但 Prometheus 不知道这些请求对应的 traceID 是什么也就无法跳转到 Tempo无法处理非结构化数据比如设备上报的 JSON payload{ temp: 36.5, humidity: 45, error_code: E001 }Prometheus 只能提取error_code作为 label但丢掉了temp和humidity的数值关系。提示很多团队踩的第一个坑就是试图用 Prometheus 存日志。我见过有人把 Logstash 输出转成 Prometheus metrics结果 metrics cardinality标签组合数爆炸式增长3 天就把 TSDB 崩了。记住Prometheus 是指标库不是日志库更不是文档数据库。2.3 Grafana可视化“万能胶”但粘性取决于你涂的厚度Grafana 的本质是一个“数据管道调度器”——它不生产数据只负责把不同源头的数据Prometheus、Tempo、MySQL、甚至 Excel按你设计的规则组装、渲染、交互。它的强大在于灵活性代价是配置复杂度。以我们为 IoT 设备集群做的健康看板为例需要同时展示设备在线率来自 Prometheus 的device_up{regionshanghai}单设备最近 1 小时的 trace 错误率来自 Tempo 的/api/traces?tagserrortruelimit10设备固件版本分布来自 MySQL 的SELECT version, COUNT(*) FROM devices GROUP BY version机房温湿度实时曲线来自 MQTT broker 的 JSON payload 解析。Grafana 用 4 个数据源插件就能接入但难点在于如何让这四个数据源的 time range 同步默认各自独立滚动时间轴时其他面板不刷新如何用一个变量device_id控制全部面板Prometheus 查询要写...{device_id$device_id}Tempo API 要拼?tagsdevice_id$device_idMySQL 要写WHERE device_id $device_id如何让点击某个设备的柱状图自动跳转到该设备的 trace 列表页需自定义链接模板且 Tempo 的 trace ID 必须在 Prometheus 指标中作为 label 暴露实测下来一个包含 12 个面板、3 层下钻逻辑的 IoT 看板Grafana 配置 JSON 文件超过 800 行其中 60% 是重复的变量引用和时间同步逻辑。这不是 Grafana 的缺陷而是它“不预设业务场景”的必然结果——它给你刀但切什么、怎么切得你自己想清楚。2.4 Tempo分布式追踪的“轻量级录像机”但录像带没有索引Tempo 的核心价值是“用最低成本存 trace”它放弃 span 索引换来了极致的写入吞吐和存储压缩。官方数据单集群每秒可摄入 10 万 trace存储成本仅为 Jaeger 的 1/5。但这背后是明确的取舍Tempo 存什么完整的 trace JSON含所有 span 的 operationName、duration、tags、logs按 traceID 分片存储Tempo 不存什么不建 span-level 索引比如http.status_code500不预计算服务依赖图不生成 span 统计摘要如GET /user/{id} avg_latency120msTempo 怎么查只能通过 traceID 精确查询或通过 tags如service.nameauth做前缀匹配查完再在客户端过滤。这意味着如果你知道 traceID比如从日志里 grep 出来Tempo 查得飞快2 秒返回完整链路但如果你只知道“昨天下午订单创建失败率升高”想查所有errortrue的 traceTempo 会扫全量数据耗时可能超过 30 秒且返回几千条结果还得人工翻找更致命的是Tempo 无法告诉你“为什么失败率升高”——它不告诉你这些失败 trace 集中在哪台机器、哪个 JVM 版本、哪个 Redis 实例这些信息得靠 Prometheus 指标交叉验证。我们曾用 Tempo 替换 Jaeger 做灰度验证写入性能提升 3 倍但故障排查效率下降 40%因为工程师习惯了 Jaeger 的“按状态码筛选 按耗时排序”而 Tempo 逼着他们先去 Prometheus 找异常指标再拿 traceID 去 Tempo 查细节。这不是倒退而是把分析链条从“一步到位”拆成了“两步手动”对资深工程师是可控的对刚入职的 juniors 就是灾难。3. 替换商业 APM 的实操路径从最小闭环到全链路协同3.1 第一阶段构建“指标 链路”最小可观测闭环2 周可上线这是所有替换项目的起点目标是让核心服务具备“问题发现 快速定位”能力不求完美但求可用。我们以订单服务为例列出必须完成的 7 个动作部署 Prometheus Server用 Helm chart 部署prometheus-community/kube-prometheus-stack启用--web.enable-admin-api方便调试配置 scrape targetsKubernetes ServiceMonitor 自动发现 order-api 的/actuator/prometheus端点关键配置项scrape_interval: 15s高频指标、evaluation_interval: 30s告警计算周期、storage.tsdb.retention.time: 15d保留 15 天数据。注入 OpenTelemetry Agent 到 order-api下载opentelemetry-javaagent.jarv1.32.0启动参数追加-javaagent:/path/to/opentelemetry-javaagent.jar \ -Dotel.resource.attributesservice.nameorder-api \ -Dotel.exporter.otlp.endpointhttp://tempo:4317 \ -Dotel.metrics.exporter.prometheus.port9464注意-Dotel.exporter.otlp.endpoint指向 Tempo-Dotel.metrics.exporter.prometheus.port开启内置 metrics 端点Prometheus 从此处拉取 JVM、HTTP client 等基础指标。部署 Tempo 并配置 OTLP 接收器用 Docker Compose 启动单节点够用tempo: image: grafana/tempo:2.3.0 ports: [4317:4317] # OTLP gRPC environment: - STORAGE_BACKENDlocal - LOCAL_STORAGE_PATH/tmp/tempo关键点Tempo 默认不暴露 metrics 端点需额外加--metrics.levelnormal参数否则 Prometheus 无法监控其健康状态。在 Grafana 中添加数据源Prometheus 数据源URL 填http://prometheus:9090Access Mode 选Server (default)Tempo 数据源URL 填http://tempo:3100Authentication 选Anonymous测试环境Enable Trace to Metrics 功能必须开启这是打通指标与链路的关键开关。创建第一个关联面板新建 Dashboard添加两个 Panel上方 PanelPrometheus 查询rate(http_server_requests_seconds_count{serviceorder-api, status~5..}[5m])显示 5xx 错误率下方 PanelTempo 查询service.name order-api and status.code 500显示最近 10 条错误 trace关键操作在下方 Panel 的 Options → Trace to Metrics 中勾选 “Link to metrics panel”并选择上方 Panel —— 这样点击某条 trace上方 Panel 会自动缩放时间范围到该 trace 发生时段。配置基础告警在 Prometheus rules.yml 中添加groups: - name: order-api-alerts rules: - alert: OrderApi5xxRateHigh expr: rate(http_server_requests_seconds_count{serviceorder-api, status~5..}[5m]) 0.01 for: 10m labels: severity: warning annotations: summary: Order API 5xx error rate 1%Alertmanager 配置邮件/企微 webhook确保告警能触达。验证闭环有效性人为制造一个 bug在 order-api 的 createOrder 方法里加if (Math.random() 0.1) throw new RuntimeException(simulated error);观察5 分钟内 Prometheus 面板出现 5xx 上升曲线 → 点击曲线峰值 → Grafana 自动跳转到对应时段的 Tempo trace 列表 → 点击任一 trace看到红色 span 标记失败位置 → 点击 span 的 Logs 标签看到simulated error堆栈 —— 闭环完成。实操心得这 7 步里第 2 步Agent 注入和第 5 步Trace to Metrics 关联最容易出错。Agent 版本必须与应用 JDK 版本兼容JDK8 用 v1.28.0JDK17 用 v1.32.0Trace to Metrics 功能依赖 Tempo 的search_enabled: true配置否则关联失效。我第一次部署时卡在这两步整整一天最后发现是 Tempo 的 Docker 镜像 tag 写错了。3.2 第二阶段补足“日志”拼图实现三元融合3~4 周指标、链路、日志是可观测性的铁三角缺一不可。商业 APM 把三者自动关联同一个 traceID 在日志、指标、trace 中同时存在而开源栈需要手动缝合。我们的方案是用 Loki 存日志用 Promtail 做日志打标用 Grafana 的 Explore 功能做三合一查询。Loki 部署要点不存日志内容只存 label 和索引如joborder-api, levelerror, traceIDabc123Promtail 配置关键在scrape_configs中为 order-api 添加pipeline_stages提取 traceID- docker: - labels: job: order-api - regex: expression: .*traceID(?PtraceID[^]).* - template: source: traceID这样每条日志都会带上traceIDlabelLoki 就能按 traceID 快速检索。Grafana 中的三合一查询在 Explore 页面选择 Loki 数据源输入查询{joborder-api} | error | logfmt找到一条含traceIDabc123的日志点击 traceID 右侧的 “→” 图标自动跳转到 Tempo 的 trace 查看页在 Tempo 页面点击某个 span右上角会出现 “Metrics” 按钮点击后自动加载该 traceID 对应时段的 Prometheus 指标如jvm_memory_used_bytes{areaheap}。这个流程看似繁琐但比商业 APM 的“一键下钻”更透明——你知道每一步数据从哪来、怎么关联。我们给研发团队做了培训两周后90% 的故障排查都从日志开始而不是先看指标曲线。3.3 第三阶段构建自动化根因分析能力6~8 周需开发投入这才是真正拉开与商业 APM 距离的地方。我们没追求“全自动 AI 定位”而是用规则引擎 指标关联实现 80% 常见问题的秒级归因。核心思路当 Prometheus 告警触发时自动执行一组预定义的关联查询并生成结构化报告。例如OrderApi5xxRateHigh告警触发 → 脚本自动查同一时段redis_commands_total{serviceorder-api, commandget, resulterror}是否激增jvm_threads_current{serviceorder-api}是否接近jvm_threads_peakprocess_cpu_seconds_total{serviceorder-api}的 1 分钟增长率是否 300%Tempo 中service.nameorder-api and status.code500的 trace 数量是否 50。实现方式用 Python 写一个root_cause_analyzer.py通过 Prometheus API 和 Tempo API 获取数据结果输出为 Markdown 报告自动发到企业微信机器人关键技巧所有查询加timeout10s避免单个慢查询拖垮整个分析流程用time_range参数严格限定查询窗口如startnow-10mendnow防止跨天数据干扰。效果上线后支付失败类告警的平均定位时间从 22 分钟降至 3.7 分钟。最常触发的归因结论是“Redis 连接池耗尽redis_pool_active_connections 200/200 JVM 线程阻塞jvm_threads_blocked 50”准确率 92%。注意事项这个阶段最大的风险是“过度工程化”。我见过团队花 3 个月开发一套复杂的因果图推理引擎结果发现 70% 的故障靠“查 Redis 连接数 查 JVM 线程数”两条规则就能覆盖。建议从最痛的 3 个故障场景入手每个场景写 1~2 条规则跑通闭环后再迭代。4. 替换过程中的典型问题与避坑指南4.1 数据一致性灾难Prometheus 与 Tempo 的时间戳偏差现象在 Grafana 中点击 Prometheus 的异常指标点跳转到 Tempo 后找不到对应 trace或者 trace 时间明显偏移早 2 分钟或晚 1 分钟。原因深挖Prometheus 默认用服务器本地时间戳_time字段而 Tempo 的 OTLP 接收器默认用客户端时间戳即 order-api 应用所在机器的时间如果应用服务器时钟未同步NTP 服务异常偏差可达数分钟更隐蔽的问题Kubernetes Pod 的spec.hostNetwork: true设置会导致容器时间与宿主机不同步。解决方案强制统一时间源所有节点包括 Prometheus Server、Tempo、应用 Pod必须运行chrony并指向同一 NTP serverPrometheus 配置修正在scrape_configs中添加honor_timestamps: false强制 Prometheus 用自己的时间戳覆盖指标时间Tempo 配置修正在tempo.yaml中设置receivers: otlp: enforce_metric_timestamps: true让 Tempo 用接收时间而非客户端时间终极验证在 order-api 日志中打印System.currentTimeMillis()同时在 Prometheus 指标中暴露system_time_milliseconds两者差值应 500ms。实操心得这个问题在测试环境往往不暴露因为所有 VM 时间同步良好。但上生产后某次云厂商宿主机时钟漂移导致连续 3 天的 trace 无法关联指标我们花了 18 小时才定位到 chrony 配置被覆盖。现在每台服务器上线前必跑chronyc tracking chronyc sources双命令验证。4.2 Grafana 变量地狱100 个面板如何共享同一套筛选逻辑现象Dashboard 有 20 个面板每个都要支持按service、environment、region筛选但修改一个变量其他面板不联动或者时间范围不同步。根源Grafana 的变量Variable默认是“面板级作用域”且时间范围Time Range是全局的但变量值传递到各数据源的方式不一致。破局方法统一变量命名规范所有变量名用var-service、var-environment避免service_name和env混用强制时间范围同步在 Dashboard Settings → Variables → Edit Variable → General → “Refresh” 选On Time Range ChangePrometheus 查询模板化rate(http_server_requests_seconds_count{service~$var-service, environment~$var-environment}[5m])注意$var-service会被 Grafana 自动转义为正则表达式所以service~$var-service是安全的Tempo 查询适配Tempo 数据源不支持$var-service直接插入需用 Grafana 的Templating功能在 Query 中写{ tags: { service.name: $var-service, environment: $var-environment } }MySQL 查询防注入如果变量用于 MySQL必须用[[variable]]语法如WHERE service [[var-service]]否则 SQL 注入风险极高。我们最终沉淀了一个变量管理模板一个 Dashboard 只允许定义 5 个核心变量service、environment、region、status、duration所有面板必须基于这 5 个变量构建新增需求一律用面板内 filter 实现而非加新变量。这套规则让 12 人团队维护的 47 个 Dashboard 保持高度一致。4.3 Tempo 存储膨胀trace 数据半年后占满磁盘现象Tempo 运行 6 个月后/tmp/tempo目录占用 2.3TBIO 延迟飙升查询超时频发。根因分析Tempo 默认用local存储数据永不过期我们未配置compaction压缩合并小文件导致数百万个 1MB 的 block 文件堆积更严重的是OTLP Agent 默认发送 full trace含所有 span 的 logs 和 events而实际分析只需 spanslogs 可丢弃。优化步骤启用 TTLTime-To-Live在tempo.yaml中配置storage: local: path: /tmp/tempo retention_period: 180d # 180 天后自动删除开启 compaction添加compactor:配置块指定 compaction schedule每天凌晨 2 点执行Agent 端精简数据在 OpenTelemetry Agent 启动参数中加-Dotel.traces.exporter.otlp.endpointhttp://tempo:4317 \ -Dotel.traces.sampler.arg0.1 \ # 采样率 10%降低写入量 -Dotel.traces.exporter.otlp.headersContent-Typeapplication/x-protobuf \ -Dotel.traces.exporter.otlp.timeout5s关键技巧采样率不是越低越好。我们实测0.1 采样率下支付类关键链路traceID 含pay_前缀仍 100% 全采普通查询链路 10% 采样既保关键又降成本。最终效果存储空间从 2.3TB 降至 320GB查询 P95 延迟从 8.2s 降至 1.4s。4.4 告警疲劳Alertmanager 每天发 2000 条没人看现象上线初期Alertmanager 每小时发 300 条告警运维群消息刷屏最后所有人 mute 群聊。本质是告警设计缺陷告警规则过于宽泛如cpu_usage 80%未区分业务高峰期缺少告警聚合100 台机器同时 CPU 高发 100 条无静默机制发布期间明知会抖动却无法临时关闭。改造方案分层告警Level 1P0直接影响用户的功能性告警如order_api_5xx_rate 1%立即电话通知Level 2P1影响内部效率的告警如redis_latency_p99 500ms企微通知Level 3P2观察性告警如jvm_gc_pause 1s仅邮件归档。聚合策略在 Alertmanager config 中配置route: group_by: [alertname, service, environment] group_wait: 30s group_interval: 5m repeat_interval: 4h这样同 service 同 alertname 的告警5 分钟内只发 1 条静默管理用 Alertmanager UI 创建静默规则支持按 label 精确匹配如serviceorder-api AND environmentprod发布前 1 小时激活发布后 1 小时自动失效。现在P0 告警日均 3.2 条P1 告警日均 17 条全部可读、可操作、可追溯。5. 替换决策的终极 checklist别只看技术要看组织能力最后我想说技术选型从来不是纯技术问题。我见过太多团队技术方案满分落地后却陷入混乱。以下是我总结的 7 项组织能力 checklist每项都配了“红灯/绿灯”判断标准帮你避开最大的坑能力项红灯信号危险绿灯信号可行我的实操建议运维自治能力运维团队不会写 PromQL看不懂 Alertmanager 配置运维能独立编写、调试、优化告警规则能看懂 Grafana 日志查询语法强制要求所有告警规则必须附带# DESC: 描述该告警的真实业务影响注释新人入职第一周任务是读懂现有 20 条规则研发协作意愿研发认为“监控是运维的事”拒绝在代码中加 traceID 打印研发主动在关键日志中输出traceID并在 PR 模板中加入“是否更新可观测性文档”检查项推行“可观测性 KPI”每个服务 owner 每月需提交 1 份 trace 分析报告哪怕只有 3 行结论数据治理意识指标命名随意cpu_usage,cpu_percent,cpu_load混用label 不统一全公司推行 OpenMetrics 规范指标名用namespace_subsystem_name如jvm_memory_used_byteslabel 有字典service,environment,version用 Prometheus 的metric_relabel_configs自动标准化但必须先有字典否则规则越写越多故障复盘文化故障后只写“已修复”不分析“为什么监控没提前发现”每次 P1 故障必须回答1告警是否触发2是否关联到 trace3日志是否含 traceID4下次如何避免把这 4 个问题做成故障报告固定模板CTO 亲自审核工具链整合能力CI/CD 流水线里没有可观测性卡点如新接口上线前未验证 trace 采集流水线中集成 curl -s http://tempo:3100/api/search?tagsservice.namexxxjq .traces | length返回 0 则阻断发布成本敏感度认为“开源零成本”忽略人力投入明确计算商业 APM 年费 vs. 2 名工程师 3 个月投入 vs. 云存储费用我们用 Excel 做了 3 年 TCO 对比开源方案第 1 年成本高 40%第 3 年低 65%渐进替代策略“下周起停用 Datadog全部切到开源栈”“先用开源栈监控新业务老业务保持双跑6 个月后逐步下线商业 APM”双跑期间用 Grafana 的 Compare 功能并排显示两套系统的同一指标差异超过 5% 就触发专项排查我个人在实际操作中的体会是技术方案可以抄组织能力必须自己长。Prometheus、Grafana、Tempo 的文档写得再好也教不会你的团队如何定义一个有意义的 SLO。我建议所有打算替换的团队先用 2 周时间只做一件事把你们当前商业 APM 里最常用的 5 个看板用开源栈完全复现。不是为了上线而是为了暴露真实的能力缺口——那个复现不出来的地方就是你下一步必须攻克的堡垒。 Prometheus+Grafana+Tempo能否替代商业APM？
1. 这不是“能不能用”的问题而是“值不值得替”的实战判断最近三个月我帮三家公司做过可观测性栈的选型评估其中两家明确提出了同一个问题“用 Prometheus Grafana Tempo 这套开源组合能不能把 New Relic、Datadog 或者听云这类商业 APM 替掉”——注意他们问的不是“技术上是否可行”而是“上线后会不会天天救火”“运维成本到底降没降”“老板看了报表敢不敢拍板决策”。这背后藏着真实业务场景里的三重压力一是监控告警不准、链路断点找不到导致线上故障平均修复时间MTTR卡在 45 分钟以上二是商业 APM 按主机数/事务量计费年续费动辄几十万且扩容必须提前报预算三是研发团队抱怨“APM 界面太重、查个慢 SQL 要点 7 下菜单、根本没法嵌入日常 CI/CD 流程”。Prometheus、Grafana、Tempo 这三个名字现在几乎成了可观测领域的“默认三件套”但很多人只记得它们开源、免费、社区活跃却忽略了它们各自的设计哲学和能力边界。Prometheus 是指标采集的“狙击手”——它擅长高精度、高频率抓取结构化数值比如 CPU 使用率每 15 秒采一次但天生不存原始日志、不支持跨服务上下文透传Grafana 是可视化“指挥台”能拼接任意数据源画图但它本身不存数据、不处理告警逻辑、不管理权限体系Tempo 是分布式追踪的“录像机”专注 trace 数据的低成本写入与快速检索但它不提供 span 分析模型、不自动识别慢调用根因、不联动指标做下钻分析。这三者加起来不是天然的 APM 替代品而是一套需要你亲手焊接、调校、加固的观测底盘。真正决定“能不能替掉商业 APM”的从来不是组件列表而是你有没有能力补足这四个断层指标-日志-链路的三元闭环是否自动打通告警是否能从“CPU 90%”升级到“支付下单失败率突增 对应 trace 中 payment-service 的 db.query 耗时飙升至 2.3s”研发能否在 IDE 里点开报错堆栈一键跳转到该请求完整的 trace 视图和关联的 JVM 内存曲线运维是否能在 Grafana 里用一个变量控制所有面板的数据源切换而不用手动改 17 个面板的查询语句如果这四条中有一条做不到那所谓“替换”大概率会变成“多维护一套系统”而不是“降本增效”。接下来我会用真实部署过的两个案例电商秒杀链路诊断、IoT 设备集群健康巡检拆解这套组合的实际能力水位告诉你哪些能抄作业哪些必须自己造轮子。2. 开源可观测栈的真实能力图谱不是功能罗列而是能力对齐2.1 商业 APM 的核心能力锚点必须先划清楚要判断开源组合能否替代第一步不是看 Prometheus 能不能装而是反向梳理商业 APM 实际交付了什么。我在过去两年深度使用过 Datadog、New Relic 和国内某头部 APM 厂商的产品把它们共性最强、用户最依赖的六大能力提炼出来作为后续对比的标尺能力维度商业 APM 典型表现用户真实诉求非宣传话术是否可被开源组合覆盖全栈自动埋点Java Agent 自动注入 Spring MVC Controller、MyBatis、Redis、HTTP Client 等入口出口“新上线一个微服务不用改一行代码5 分钟内就能看到接口 P95 延迟、错误率、上下游依赖关系”⚠️ 部分覆盖需配合 OpenTelemetry SDK 或兼容 Agent智能根因定位点击异常接口 → 自动高亮慢 span → 关联显示该 span 所在宿主机的 CPU、JVM GC 频率、线程阻塞数“别让我猜直接告诉我‘是 Redis 连接池耗尽导致下游超时’”❌ 未覆盖需自研规则引擎或集成第三方分析工具统一告警中心告警策略按服务/环境分组支持多通道通知企微/钉钉/邮件/电话告警聚合去重100 个实例同时 CPU 高只发 1 条“半夜三点收到 37 条重复告警最后发现是负载均衡器配置错了”⚠️ 基础覆盖Alertmanager 可实现但策略配置复杂、静默管理弱低门槛协作分析产品经理用自然语言描述“昨天 20:00-21:00 订单提交失败率上升”系统返回 Top3 失败接口对应 trace 样本关联指标趋势“别让我学 PromQL我要的是结果不是查询语法”❌ 未覆盖需额外构建语义层或接入 LLM 前端合规审计追踪所有面板操作、告警触发、数据导出行为留痕支持按角色设置数据可见范围如测试人员看不到生产 DB 指标“等保三级要求日志留存 180 天且操作记录不可篡改”❌ 未覆盖Grafana RBAC 仅限面板级无细粒度字段权限SLA/SLO 可视化自动计算并展示“API 可用性 SLO99.95%当前达成率 99.92%距违约还有 4 小时”“运维不用算公式SLO 状态直接决定是否启动应急预案”✅ 可覆盖Prometheus Grafana 自定义 SLO 库可实现这个表格不是为了贬低开源方案而是划清底线如果你的业务只需要 SLO 监控和基础告警那 Prometheus Grafana 已足够但如果你的团队每天要处理 20 起跨服务故障且要求 15 分钟内定位到具体代码行那仅靠 Tempo 查 trace大概率会让你在凌晨三点对着屏幕发呆。2.2 Prometheus指标采集的“精准但狭隘”Prometheus 的设计哲学是“拉取式 时序数据库 强类型指标”这决定了它的优势和死穴。我拿电商大促期间的真实压测数据对比说明它做得极好的事每秒采集 5000 个指标如http_request_duration_seconds_bucket{le0.2,serviceorder-api}存储压缩率高达 12:1单节点支撑 200 万 series 毫无压力PromQL 查询响应稳定在 200ms 内即使查 7 天前的 P99 延迟曲线也能秒出结果告警规则天然支持 label 匹配比如ALERTS{alertstatefiring, service~payment|order} 1一条规则就能覆盖支付和订单两个服务。它根本做不到的事无法存储原始日志比如 Nginx access log 的完整 request body无法关联 traceID你查到order-api接口延迟飙升但 Prometheus 不知道这些请求对应的 traceID 是什么也就无法跳转到 Tempo无法处理非结构化数据比如设备上报的 JSON payload{ temp: 36.5, humidity: 45, error_code: E001 }Prometheus 只能提取error_code作为 label但丢掉了temp和humidity的数值关系。提示很多团队踩的第一个坑就是试图用 Prometheus 存日志。我见过有人把 Logstash 输出转成 Prometheus metrics结果 metrics cardinality标签组合数爆炸式增长3 天就把 TSDB 崩了。记住Prometheus 是指标库不是日志库更不是文档数据库。2.3 Grafana可视化“万能胶”但粘性取决于你涂的厚度Grafana 的本质是一个“数据管道调度器”——它不生产数据只负责把不同源头的数据Prometheus、Tempo、MySQL、甚至 Excel按你设计的规则组装、渲染、交互。它的强大在于灵活性代价是配置复杂度。以我们为 IoT 设备集群做的健康看板为例需要同时展示设备在线率来自 Prometheus 的device_up{regionshanghai}单设备最近 1 小时的 trace 错误率来自 Tempo 的/api/traces?tagserrortruelimit10设备固件版本分布来自 MySQL 的SELECT version, COUNT(*) FROM devices GROUP BY version机房温湿度实时曲线来自 MQTT broker 的 JSON payload 解析。Grafana 用 4 个数据源插件就能接入但难点在于如何让这四个数据源的 time range 同步默认各自独立滚动时间轴时其他面板不刷新如何用一个变量device_id控制全部面板Prometheus 查询要写...{device_id$device_id}Tempo API 要拼?tagsdevice_id$device_idMySQL 要写WHERE device_id $device_id如何让点击某个设备的柱状图自动跳转到该设备的 trace 列表页需自定义链接模板且 Tempo 的 trace ID 必须在 Prometheus 指标中作为 label 暴露实测下来一个包含 12 个面板、3 层下钻逻辑的 IoT 看板Grafana 配置 JSON 文件超过 800 行其中 60% 是重复的变量引用和时间同步逻辑。这不是 Grafana 的缺陷而是它“不预设业务场景”的必然结果——它给你刀但切什么、怎么切得你自己想清楚。2.4 Tempo分布式追踪的“轻量级录像机”但录像带没有索引Tempo 的核心价值是“用最低成本存 trace”它放弃 span 索引换来了极致的写入吞吐和存储压缩。官方数据单集群每秒可摄入 10 万 trace存储成本仅为 Jaeger 的 1/5。但这背后是明确的取舍Tempo 存什么完整的 trace JSON含所有 span 的 operationName、duration、tags、logs按 traceID 分片存储Tempo 不存什么不建 span-level 索引比如http.status_code500不预计算服务依赖图不生成 span 统计摘要如GET /user/{id} avg_latency120msTempo 怎么查只能通过 traceID 精确查询或通过 tags如service.nameauth做前缀匹配查完再在客户端过滤。这意味着如果你知道 traceID比如从日志里 grep 出来Tempo 查得飞快2 秒返回完整链路但如果你只知道“昨天下午订单创建失败率升高”想查所有errortrue的 traceTempo 会扫全量数据耗时可能超过 30 秒且返回几千条结果还得人工翻找更致命的是Tempo 无法告诉你“为什么失败率升高”——它不告诉你这些失败 trace 集中在哪台机器、哪个 JVM 版本、哪个 Redis 实例这些信息得靠 Prometheus 指标交叉验证。我们曾用 Tempo 替换 Jaeger 做灰度验证写入性能提升 3 倍但故障排查效率下降 40%因为工程师习惯了 Jaeger 的“按状态码筛选 按耗时排序”而 Tempo 逼着他们先去 Prometheus 找异常指标再拿 traceID 去 Tempo 查细节。这不是倒退而是把分析链条从“一步到位”拆成了“两步手动”对资深工程师是可控的对刚入职的 juniors 就是灾难。3. 替换商业 APM 的实操路径从最小闭环到全链路协同3.1 第一阶段构建“指标 链路”最小可观测闭环2 周可上线这是所有替换项目的起点目标是让核心服务具备“问题发现 快速定位”能力不求完美但求可用。我们以订单服务为例列出必须完成的 7 个动作部署 Prometheus Server用 Helm chart 部署prometheus-community/kube-prometheus-stack启用--web.enable-admin-api方便调试配置 scrape targetsKubernetes ServiceMonitor 自动发现 order-api 的/actuator/prometheus端点关键配置项scrape_interval: 15s高频指标、evaluation_interval: 30s告警计算周期、storage.tsdb.retention.time: 15d保留 15 天数据。注入 OpenTelemetry Agent 到 order-api下载opentelemetry-javaagent.jarv1.32.0启动参数追加-javaagent:/path/to/opentelemetry-javaagent.jar \ -Dotel.resource.attributesservice.nameorder-api \ -Dotel.exporter.otlp.endpointhttp://tempo:4317 \ -Dotel.metrics.exporter.prometheus.port9464注意-Dotel.exporter.otlp.endpoint指向 Tempo-Dotel.metrics.exporter.prometheus.port开启内置 metrics 端点Prometheus 从此处拉取 JVM、HTTP client 等基础指标。部署 Tempo 并配置 OTLP 接收器用 Docker Compose 启动单节点够用tempo: image: grafana/tempo:2.3.0 ports: [4317:4317] # OTLP gRPC environment: - STORAGE_BACKENDlocal - LOCAL_STORAGE_PATH/tmp/tempo关键点Tempo 默认不暴露 metrics 端点需额外加--metrics.levelnormal参数否则 Prometheus 无法监控其健康状态。在 Grafana 中添加数据源Prometheus 数据源URL 填http://prometheus:9090Access Mode 选Server (default)Tempo 数据源URL 填http://tempo:3100Authentication 选Anonymous测试环境Enable Trace to Metrics 功能必须开启这是打通指标与链路的关键开关。创建第一个关联面板新建 Dashboard添加两个 Panel上方 PanelPrometheus 查询rate(http_server_requests_seconds_count{serviceorder-api, status~5..}[5m])显示 5xx 错误率下方 PanelTempo 查询service.name order-api and status.code 500显示最近 10 条错误 trace关键操作在下方 Panel 的 Options → Trace to Metrics 中勾选 “Link to metrics panel”并选择上方 Panel —— 这样点击某条 trace上方 Panel 会自动缩放时间范围到该 trace 发生时段。配置基础告警在 Prometheus rules.yml 中添加groups: - name: order-api-alerts rules: - alert: OrderApi5xxRateHigh expr: rate(http_server_requests_seconds_count{serviceorder-api, status~5..}[5m]) 0.01 for: 10m labels: severity: warning annotations: summary: Order API 5xx error rate 1%Alertmanager 配置邮件/企微 webhook确保告警能触达。验证闭环有效性人为制造一个 bug在 order-api 的 createOrder 方法里加if (Math.random() 0.1) throw new RuntimeException(simulated error);观察5 分钟内 Prometheus 面板出现 5xx 上升曲线 → 点击曲线峰值 → Grafana 自动跳转到对应时段的 Tempo trace 列表 → 点击任一 trace看到红色 span 标记失败位置 → 点击 span 的 Logs 标签看到simulated error堆栈 —— 闭环完成。实操心得这 7 步里第 2 步Agent 注入和第 5 步Trace to Metrics 关联最容易出错。Agent 版本必须与应用 JDK 版本兼容JDK8 用 v1.28.0JDK17 用 v1.32.0Trace to Metrics 功能依赖 Tempo 的search_enabled: true配置否则关联失效。我第一次部署时卡在这两步整整一天最后发现是 Tempo 的 Docker 镜像 tag 写错了。3.2 第二阶段补足“日志”拼图实现三元融合3~4 周指标、链路、日志是可观测性的铁三角缺一不可。商业 APM 把三者自动关联同一个 traceID 在日志、指标、trace 中同时存在而开源栈需要手动缝合。我们的方案是用 Loki 存日志用 Promtail 做日志打标用 Grafana 的 Explore 功能做三合一查询。Loki 部署要点不存日志内容只存 label 和索引如joborder-api, levelerror, traceIDabc123Promtail 配置关键在scrape_configs中为 order-api 添加pipeline_stages提取 traceID- docker: - labels: job: order-api - regex: expression: .*traceID(?PtraceID[^]).* - template: source: traceID这样每条日志都会带上traceIDlabelLoki 就能按 traceID 快速检索。Grafana 中的三合一查询在 Explore 页面选择 Loki 数据源输入查询{joborder-api} | error | logfmt找到一条含traceIDabc123的日志点击 traceID 右侧的 “→” 图标自动跳转到 Tempo 的 trace 查看页在 Tempo 页面点击某个 span右上角会出现 “Metrics” 按钮点击后自动加载该 traceID 对应时段的 Prometheus 指标如jvm_memory_used_bytes{areaheap}。这个流程看似繁琐但比商业 APM 的“一键下钻”更透明——你知道每一步数据从哪来、怎么关联。我们给研发团队做了培训两周后90% 的故障排查都从日志开始而不是先看指标曲线。3.3 第三阶段构建自动化根因分析能力6~8 周需开发投入这才是真正拉开与商业 APM 距离的地方。我们没追求“全自动 AI 定位”而是用规则引擎 指标关联实现 80% 常见问题的秒级归因。核心思路当 Prometheus 告警触发时自动执行一组预定义的关联查询并生成结构化报告。例如OrderApi5xxRateHigh告警触发 → 脚本自动查同一时段redis_commands_total{serviceorder-api, commandget, resulterror}是否激增jvm_threads_current{serviceorder-api}是否接近jvm_threads_peakprocess_cpu_seconds_total{serviceorder-api}的 1 分钟增长率是否 300%Tempo 中service.nameorder-api and status.code500的 trace 数量是否 50。实现方式用 Python 写一个root_cause_analyzer.py通过 Prometheus API 和 Tempo API 获取数据结果输出为 Markdown 报告自动发到企业微信机器人关键技巧所有查询加timeout10s避免单个慢查询拖垮整个分析流程用time_range参数严格限定查询窗口如startnow-10mendnow防止跨天数据干扰。效果上线后支付失败类告警的平均定位时间从 22 分钟降至 3.7 分钟。最常触发的归因结论是“Redis 连接池耗尽redis_pool_active_connections 200/200 JVM 线程阻塞jvm_threads_blocked 50”准确率 92%。注意事项这个阶段最大的风险是“过度工程化”。我见过团队花 3 个月开发一套复杂的因果图推理引擎结果发现 70% 的故障靠“查 Redis 连接数 查 JVM 线程数”两条规则就能覆盖。建议从最痛的 3 个故障场景入手每个场景写 1~2 条规则跑通闭环后再迭代。4. 替换过程中的典型问题与避坑指南4.1 数据一致性灾难Prometheus 与 Tempo 的时间戳偏差现象在 Grafana 中点击 Prometheus 的异常指标点跳转到 Tempo 后找不到对应 trace或者 trace 时间明显偏移早 2 分钟或晚 1 分钟。原因深挖Prometheus 默认用服务器本地时间戳_time字段而 Tempo 的 OTLP 接收器默认用客户端时间戳即 order-api 应用所在机器的时间如果应用服务器时钟未同步NTP 服务异常偏差可达数分钟更隐蔽的问题Kubernetes Pod 的spec.hostNetwork: true设置会导致容器时间与宿主机不同步。解决方案强制统一时间源所有节点包括 Prometheus Server、Tempo、应用 Pod必须运行chrony并指向同一 NTP serverPrometheus 配置修正在scrape_configs中添加honor_timestamps: false强制 Prometheus 用自己的时间戳覆盖指标时间Tempo 配置修正在tempo.yaml中设置receivers: otlp: enforce_metric_timestamps: true让 Tempo 用接收时间而非客户端时间终极验证在 order-api 日志中打印System.currentTimeMillis()同时在 Prometheus 指标中暴露system_time_milliseconds两者差值应 500ms。实操心得这个问题在测试环境往往不暴露因为所有 VM 时间同步良好。但上生产后某次云厂商宿主机时钟漂移导致连续 3 天的 trace 无法关联指标我们花了 18 小时才定位到 chrony 配置被覆盖。现在每台服务器上线前必跑chronyc tracking chronyc sources双命令验证。4.2 Grafana 变量地狱100 个面板如何共享同一套筛选逻辑现象Dashboard 有 20 个面板每个都要支持按service、environment、region筛选但修改一个变量其他面板不联动或者时间范围不同步。根源Grafana 的变量Variable默认是“面板级作用域”且时间范围Time Range是全局的但变量值传递到各数据源的方式不一致。破局方法统一变量命名规范所有变量名用var-service、var-environment避免service_name和env混用强制时间范围同步在 Dashboard Settings → Variables → Edit Variable → General → “Refresh” 选On Time Range ChangePrometheus 查询模板化rate(http_server_requests_seconds_count{service~$var-service, environment~$var-environment}[5m])注意$var-service会被 Grafana 自动转义为正则表达式所以service~$var-service是安全的Tempo 查询适配Tempo 数据源不支持$var-service直接插入需用 Grafana 的Templating功能在 Query 中写{ tags: { service.name: $var-service, environment: $var-environment } }MySQL 查询防注入如果变量用于 MySQL必须用[[variable]]语法如WHERE service [[var-service]]否则 SQL 注入风险极高。我们最终沉淀了一个变量管理模板一个 Dashboard 只允许定义 5 个核心变量service、environment、region、status、duration所有面板必须基于这 5 个变量构建新增需求一律用面板内 filter 实现而非加新变量。这套规则让 12 人团队维护的 47 个 Dashboard 保持高度一致。4.3 Tempo 存储膨胀trace 数据半年后占满磁盘现象Tempo 运行 6 个月后/tmp/tempo目录占用 2.3TBIO 延迟飙升查询超时频发。根因分析Tempo 默认用local存储数据永不过期我们未配置compaction压缩合并小文件导致数百万个 1MB 的 block 文件堆积更严重的是OTLP Agent 默认发送 full trace含所有 span 的 logs 和 events而实际分析只需 spanslogs 可丢弃。优化步骤启用 TTLTime-To-Live在tempo.yaml中配置storage: local: path: /tmp/tempo retention_period: 180d # 180 天后自动删除开启 compaction添加compactor:配置块指定 compaction schedule每天凌晨 2 点执行Agent 端精简数据在 OpenTelemetry Agent 启动参数中加-Dotel.traces.exporter.otlp.endpointhttp://tempo:4317 \ -Dotel.traces.sampler.arg0.1 \ # 采样率 10%降低写入量 -Dotel.traces.exporter.otlp.headersContent-Typeapplication/x-protobuf \ -Dotel.traces.exporter.otlp.timeout5s关键技巧采样率不是越低越好。我们实测0.1 采样率下支付类关键链路traceID 含pay_前缀仍 100% 全采普通查询链路 10% 采样既保关键又降成本。最终效果存储空间从 2.3TB 降至 320GB查询 P95 延迟从 8.2s 降至 1.4s。4.4 告警疲劳Alertmanager 每天发 2000 条没人看现象上线初期Alertmanager 每小时发 300 条告警运维群消息刷屏最后所有人 mute 群聊。本质是告警设计缺陷告警规则过于宽泛如cpu_usage 80%未区分业务高峰期缺少告警聚合100 台机器同时 CPU 高发 100 条无静默机制发布期间明知会抖动却无法临时关闭。改造方案分层告警Level 1P0直接影响用户的功能性告警如order_api_5xx_rate 1%立即电话通知Level 2P1影响内部效率的告警如redis_latency_p99 500ms企微通知Level 3P2观察性告警如jvm_gc_pause 1s仅邮件归档。聚合策略在 Alertmanager config 中配置route: group_by: [alertname, service, environment] group_wait: 30s group_interval: 5m repeat_interval: 4h这样同 service 同 alertname 的告警5 分钟内只发 1 条静默管理用 Alertmanager UI 创建静默规则支持按 label 精确匹配如serviceorder-api AND environmentprod发布前 1 小时激活发布后 1 小时自动失效。现在P0 告警日均 3.2 条P1 告警日均 17 条全部可读、可操作、可追溯。5. 替换决策的终极 checklist别只看技术要看组织能力最后我想说技术选型从来不是纯技术问题。我见过太多团队技术方案满分落地后却陷入混乱。以下是我总结的 7 项组织能力 checklist每项都配了“红灯/绿灯”判断标准帮你避开最大的坑能力项红灯信号危险绿灯信号可行我的实操建议运维自治能力运维团队不会写 PromQL看不懂 Alertmanager 配置运维能独立编写、调试、优化告警规则能看懂 Grafana 日志查询语法强制要求所有告警规则必须附带# DESC: 描述该告警的真实业务影响注释新人入职第一周任务是读懂现有 20 条规则研发协作意愿研发认为“监控是运维的事”拒绝在代码中加 traceID 打印研发主动在关键日志中输出traceID并在 PR 模板中加入“是否更新可观测性文档”检查项推行“可观测性 KPI”每个服务 owner 每月需提交 1 份 trace 分析报告哪怕只有 3 行结论数据治理意识指标命名随意cpu_usage,cpu_percent,cpu_load混用label 不统一全公司推行 OpenMetrics 规范指标名用namespace_subsystem_name如jvm_memory_used_byteslabel 有字典service,environment,version用 Prometheus 的metric_relabel_configs自动标准化但必须先有字典否则规则越写越多故障复盘文化故障后只写“已修复”不分析“为什么监控没提前发现”每次 P1 故障必须回答1告警是否触发2是否关联到 trace3日志是否含 traceID4下次如何避免把这 4 个问题做成故障报告固定模板CTO 亲自审核工具链整合能力CI/CD 流水线里没有可观测性卡点如新接口上线前未验证 trace 采集流水线中集成 curl -s http://tempo:3100/api/search?tagsservice.namexxxjq .traces | length返回 0 则阻断发布成本敏感度认为“开源零成本”忽略人力投入明确计算商业 APM 年费 vs. 2 名工程师 3 个月投入 vs. 云存储费用我们用 Excel 做了 3 年 TCO 对比开源方案第 1 年成本高 40%第 3 年低 65%渐进替代策略“下周起停用 Datadog全部切到开源栈”“先用开源栈监控新业务老业务保持双跑6 个月后逐步下线商业 APM”双跑期间用 Grafana 的 Compare 功能并排显示两套系统的同一指标差异超过 5% 就触发专项排查我个人在实际操作中的体会是技术方案可以抄组织能力必须自己长。Prometheus、Grafana、Tempo 的文档写得再好也教不会你的团队如何定义一个有意义的 SLO。我建议所有打算替换的团队先用 2 周时间只做一件事把你们当前商业 APM 里最常用的 5 个看板用开源栈完全复现。不是为了上线而是为了暴露真实的能力缺口——那个复现不出来的地方就是你下一步必须攻克的堡垒。