前面十三篇从零把 Prometheus 拉起来一路装了 node_exporter、Spring Boot 的 Actuator、Nginx、Blackbox、SQL Exporter中间复盘了指标怎么选RED / USE / 黄金信号、告警怎么治理、Grafana 怎么做下钻和统一面板、报告怎么写、高可用和长期存储怎么落地最后把安全这扇门也顺手关上了。本篇目标把前 13 篇收敛成一张能挂在墙上的体系地图提供一套可参考的演进路线让现在这套 Prometheus 体系平滑地长成可观测性平台而不是推倒重来。一句话前面是怎么建本篇是建完了怎么用、怎么长。一、先复盘前十三篇建了什么一张表整理篇号主题解决的问题所在层1体系全景与基础环境搭建把 Prometheus / Grafana / Alertmanager 跑起来采集层·地基2服务发现动态目标管理实例 IP 漂移不用手工改配置采集层·地基3主机层监控node_exporter主机 CPU / 内存 / 磁盘 / 网络采集层·对象4Spring Boot 应用监控应用 HTTP / JVM / 连接池采集层·对象5Nginx 监控流量 / 连接 / 性能三条线采集层·对象6依赖服务探活Blackbox Exporter外部视角拨测补内部盲区采集层·对象7业务数据监控SQL Exporter库里的业务数据变成指标采集层·对象8关键指标分析方法RED / USE / 黄金信号几百条曲线收敛到几十条方法层9告警体系设计Alertmanager让每条通知都值得处理响应层10Grafana 可视化进阶变量、下钻、统一面板呈现层11监控报告SLO / SLI 与数据分析把数据变成决策决策层12高可用与长期存储采集不断、告警不哑、数据存得久生产化13监控安全与权限治理把默认敞开的门锁上生产化串起来就是一个闭环采集1~7 ──► 方法收敛8 ──► 告警响应9 ▲ │ │ ▼ 优化采集 ◄── 决策改进11 ◄── 可视化呈现10 │ 生产化保障高可用12 安全13⚠️ 注意很多团队只建了闭环的一条边。采集做得挺全“告警配了一堆但没人做方法收敛和决策改进”结果就是采集量每年涨、告警量每年涨、真正被处理的问题却不见少。监控的完备性从来不取决于采集量而取决于这个闭环有没有转起来。二、散落在各篇里的六条地基有六条原则在前面文章中反复出现可参考制定进监控规范里1标签规范是所有聚合、抑制、下钻的索引svc和type这两个标签是作为命名约定埋下的但真正的重量在后面几篇才显出来第 8 篇跨层抑制靠它第 9 篇分组和抑制主键靠它第 10 篇下钻链路靠它。改一次标签规范上面所有规则会悄悄失效而且不报错。2采集—展示—告警必须成环第 5 篇和第 8 篇都强调了同一句话监控的完备性不取决于采集量而取决于闭环是否成立。采集保证可追溯、展示保证可感知、告警保证可执行。缺任何一环监控就退化成事后翻日志的工具。3先做减法再做加法第 8 篇把几百条曲线砍到几十条关键项第 12 篇反复算账存储压力的大头往往是基数而不是天数与其急着上 Thanos不如先分层抓取、先裁掉不看的序列。很多需要新架构的场景其实是列表没做减法。4阈值要贴着业务基线走别静态钉死静态阈值是告警疲劳的头号来源。第 3、5、8 篇都提到QPS 这类指标看环比/同比波动没有绝对阈值磁盘、CPU 的阈值也要结合业务基线动态校准。5监控组件要独立部署、隔离故障域第 7 篇那条独立部署是底线值得单独拎出来业务数据 Exporter 绝不内嵌进业务应用共享资源、共享故障域最后监控反而会拖垮被监控的对象。6默认即不安全最小权限第 13 篇的结论Prometheus、Grafana、exporter 出厂几乎都是敞开或弱口令的。第一个动作永远是关默认、收端口、上认证凭据绝不进配置文件。三、监控 ≠ 可观测性先理清概念最直白的分法维度监控Monitoring可观测性Observability回答的问题已知的已知未知的未知工作方式预设指标 阈值超了就告警拿到底层原始数据临场提问、自由组合依赖你事先猜到要监控什么不需要事先猜全数据够原生就能事后推断典型场景磁盘会不会满、QPS 多少“为什么欧洲用户周三下午下单变慢”举个例子。磁盘快满、CPU 飙高、5xx 上涨这些是监控能覆盖的因为在第 3、4 篇就把这些指标预设好了。但如果是某个新上线的功能只在特定机型 特定时段偶发超时事前根本想不到要配什么指标这时候就轮到可观测性指标看到异常日志能下钻到具体报错链路能追到是哪一次调用、哪一个依赖慢。行业里常说的三支柱Three Pillars就是这个意思Metrics指标——聚合的数值。便宜、适合看趋势和告警。Logs日志——离散的事件。细节最全适合下钻根因。Traces链路——一次请求跨服务的完整轨迹。适合定位分布式系统里慢在哪一跳。⚠️ 注意本系列只聚焦介绍了 Metrics 一根柱子。监控是可观测性的子集往可观测性演进不是推翻监控而是补上另外两根柱子再用统一的上下文标签、trace_id把它们串成一张网。四、演进路线从一根柱子到三根柱子演进这件事最怕两种失败一种是一步到位直接奔着大平台去预算和人力都跟不上半年后烂尾另一种是原地打转一直停在指标阶段遇到指标说不清的问题只能靠猜。正确的姿势是痛点驱动、分阶段走。每一阶段都先问一句我们现在是不是真的被这件事卡住了卡住了再上不卡就别上。下面是一条参考路线从阶段 0 到阶段 4对应不同成熟度。阶段 0指标监控现状即本系列 113 篇所涉及的东西Prometheus 采集 方法收敛 告警治理 Grafana 可视化 报告决策 高可用 安全。本阶段已经能满足个人和中小企业的绝大部分需求。如果团队规模不大、系统不复杂到本阶段已经够了不必为了可观测性三个字强行上马。继续演进的触发信号出现指标看到了异常但说不清为什么的情况越来越多比如 5xx 涨了指标只能告诉你哪个接口、哪个实例但告诉不了你具体报的什么错、慢在哪一步。阶段 1把日志集中起来Loki第一根补上的柱子是日志。原因很简单当指标指向异常之后大家的第一反应永远是去翻日志。别小看集中这两个字。如果日志还散在各台机器的/var/log里出了事就得挨个 SSH跨实例还拼不起来时间线。集中到 Loki 之后Grafana 里就能和指标放在同一块屏上看。选 Loki 而不是 ELK 的理由也很实际Loki不对日志内容建全文索引只索引标签存储成本比 ES 低一个量级正好和已有的 Grafana 复用。代价是全文检索没 ES 那么强但对按 svc、按时间、按 trace_id 捞一段日志这种最常见的场景完全够用。⚠️ 注意别重新设计一套日志标签。Loki 也是靠标签组织数据的svc、type、env这套命名要和第 2 篇对齐否则指标和日志永远串不到一起。触发信号排查一个问题需要登录 3 台以上机器捞日志或者需要跨实例对齐时间线。阶段 2补上链路追踪Tempo / Jaeger Exemplar第二根柱子是链路追踪。解决的是分布式系统里最难受的一个问题一个请求经过网关、应用 A、应用 B、数据库到底慢在哪一跳。这里有个能立刻提升体验的巧劲Exemplar示例。它能在指标曲线上挂一个点点开直接跳到对应的那条 trace。相当于从指标发现异常一步跨到链路看到现场中间不用再人肉找时间戳。用法大致是这样应用侧Micrometer 从 1.12 起支持在打点直方图时把当前的trace_id作为 exemplar 塞进去查询时在 PromQL 里加上exemplarsGrafana 面板上就会出现可点击的点# 在 P95 延迟曲线上叠加 exemplar点开即跳 Tempohistogram_quantile(0.95,sumby(le, svc)(rate(http_server_requests_seconds_bucket[5m])))# 应用侧开启 exemplarMicrometer Prometheus registrymanagement:metrics:distribution:percentiles-histogram:http.server.requests:true# 要直方图才有桶才能挂 exemplar⚠️ 注意这里要翻回第 4 篇和第 12 篇的老账。开percentiles-histogram会让指标基数暴涨直方图一开账立刻变成另一个量级第 12 篇那张算账表里90,000 序列 / 1 GB 每天就是这么来的。所以 exemplar 不是所有接口都开挑核心入口接口开就够否则还没吃到可观测性的红利先把 Prometheus 撑爆了。触发信号一次调用跨了多个服务光看指标定位不到慢在哪一跳。阶段 3统一采集与语义OpenTelemetry到了这一步就会发现一个新麻烦指标一套 SDK、日志一套 agent、链路一套 SDK三套东西各自定义标签、各自上报配起来又碎又容易不一致。OpenTelemetryOTel就是用一套规范 一个 Collector把 metrics / logs / traces 三路信号收进来再分别导出到 Prometheus、Loki、Tempo。数据源头带上统一的service.name、trace_id这类上下文三根柱子天然就能对上。一个最小可用的 Collector 配置长这样# otel-collector-config.ymlreceivers:otlp:protocols:grpc:endpoint:0.0.0.0:4317http:endpoint:0.0.0.0:4318processors:batch:resource:attributes:-key:envvalue:prodaction:upsertexporters:prometheusremotewrite:endpoint:http://prometheus:9090/api/v1/writeotlp/tempo:endpoint:tempo:4317tls:insecure:trueloki:endpoint:http://loki:3100/loki/api/v1/pushservice:pipelines:metrics:receivers:[otlp]processors:[resource,batch]exporters:[prometheusremotewrite]traces:receivers:[otlp]processors:[resource,batch]exporters:[otlp/tempo]logs:receivers:[otlp]processors:[resource,batch]exporters:[loki]prometheusremotewrite那个 exporter 正好接的是第 12 篇讲过的remote_write接口。⚠️ 注意别一上来就OTel 改造全公司。存量应用改用 OTel SDK 是实打实的代码改造成本不小。务实的做法是新项目直接上 OTel老项目先只用 Collector 收 OTLP 做聚合转发SDK 慢慢换。演进是加法不是革命。阶段 4统一查询与关联Grafana 一个入口三根柱子都有了后最后一步是让人别再自己来回切工具。Grafana 早就不只是画指标了它现在可以同时接 Prometheus、Loki、Tempo 作为数据源并且支持三向跳转指标面板发现异常 → 点 exemplar 跳到 Tempo 看链路链路的某个 span 慢 → 从 span 上直接跳 Loki 看那段日志日志里出现某个trace_id→ 反过来定位到具体那次 trace。数据源之间的关联靠的是一个统一的标注Grafana 里的 “Data links” 或 derivied fields# 让日志里的 trace_id 变成可点击链接字段trace_id 链接http://tempo:3000/explore?query${__value.raw}到这一步从告警到根因的跳转才真正闭环告警通知里附一个链接值班的人点开就是现场而不是从零开始查。五、按团队规模选一条务实的路线仅供参考团队规模 / 系统复杂度建议停在理由个人 / 中小企业系统简单阶段 01指标 集中日志已覆盖 90% 场景别过度设计中型团队服务 10有分布式调用阶段 02链路追踪是定位跨服务慢问题的刚需大型 / 云原生 / 多团队阶段 04三支柱 OTel 统一入口才能撑住规模和协作⚠️ 一句话可观测性是有成本的而且是持续成本。Loki、Tempo 都要存数据、都要运维第 12 篇那笔存储账一条都跑不掉。为了显得先进而上一堆组件最后只会多养几套需要被监控的系统。 选择永远应该由痛点决定而不是由名词决定。六、演进路上最容易踩的几个坑为了可观测性而上可观测性。团队里指标还没理清楚就急着上三支柱。结果三套数据、三套标签、三套告警比原来更乱。先把阶段 0 的地基标签规范、闭环、减法做扎实再谈演进。标签/上下文不统一。三根柱子能不能串起来全看svc、type、trace_id这些共同上下文有没有对齐。这跟第 9、10 篇里标签规范是隐藏地基是同一个道理柱子越多地基不牢的代价越大。exemplar 直方图一起用力过猛。第 4、12 篇的基数坑会在这里集中爆发。所有接口无脑开直方图 exemplarPrometheus 内存和磁盘先扛不住。把新平台变成新的故障源。“监控的价值是早知道但前提是它自己没有变成新的故障源”在可观测性阶段同样成立。采集、存储、查询组件都要独立部署、独立监控别让它们和业务抢资源。忘了数据保留与成本。日志和链路的体量比指标大得多上线第一天就要定好保留策略和采样策略比如链路按比例采样、日志分级保留。七、小结至此整个 Prometheus 系列十四篇就正式收尾了。回望一遍前 13 篇把能采集、能看、能告警、能出报告、扛得住、守得住这套监控体系完整建了起来本篇则把它当成一个整体重新审视并指向了下一步。本篇核心要点体系是闭环不是清单。采集 → 方法收敛 → 告警响应 → 可视化呈现 → 决策改进 → 回头优化采集环转起来才有价值只堆采集和告警等于只建了闭环的一条边。六条地基要进规范。标签规范、闭环思维、先做减法、阈值贴业务、独立部署、默认即不安全。监控 ≠ 可观测性。监控回答已知的已知可观测性回答未知的未知指标是可观测性里性价比最高的一根柱子但只有一根柱子撑不起可观测三个字。演进要痛点驱动、分阶段走。指标阶段 0→ 日志 Loki1→ 链路 Tempo Exemplar2→ 统一采集 OTel3→ 统一查询关联4。每一步都先问是不是真被卡住了卡住再上。OTel 与新体系不是推倒重来。通过remote_write写回已有的 Prometheus老资产全部保留这才是平滑演进的正确姿势。规模和成本要匹配。个人 / 中小企业停在阶段 01 就够了可观测性是持续成本别让先进变成负担。最后一句监控不是一次性的配置工作而是一项需要持续打磨的基础设施。前面十三篇教会你怎么把它建起来本篇希望帮你知道它建成了什么样、以及该往哪长。工具会迭代名词会更新但让数据服务于决策这件事不会变。