Prometheus+Alertmanager+Grafana监控系统企业级实战

很多人对监控的认知停留在「装个 Prometheus，配个 Grafana 面板」这一层。真正到了生产环境，问题会一个接一个冒出来：指标基数爆炸把内存吃满、告警风暴半夜把手机打爆、Grafana 面板画得漂亮但没人看得懂、采集目标掉了三天没人发现。这门课针对的正是这些缺口——它不是带你认识三个工具，而是带你把这三件东西拼成一套能在企业里跑得住、有人值守、出事能定位的监控系统。

先确认你缺的是哪一块

如果你属于下面几种情况，这门课的内容对你是有直接价值的：

• 会写 PromQL 的简单查询，但遇到 rate、increase、irate 的选取和 counter 重置就说不清；
• Prometheus 单机跑得挺好，一旦目标规模上来，就不知道抓取间隔、evaluation_interval、存储保留策略该怎么权衡；
• Alertmanager 只用过默认配置，分组、抑制、静默三者的关系没理清，导致告警要么漏要么炸；
• Grafana 面板能拼出来，但变量、模板、告警规则和面板之间的数据口径对不上；
• 接手了一套别人搭的监控，出故障时不知道该先看哪一层。

反过来，如果你连 Prometheus 是什么、指标抓取的基本模型都没接触过，建议先补基础再来，这门课不会从零讲 HTTP 拉取模型。

这门课真正要解决的三件事

一、指标准确，而不是指标很多

监控做不好，往往不是数据不够，而是数据不对。课程围绕指标类型、标签设计、直方图与摘要的取舍展开，重点在于让你能判断：哪些指标该埋、标签怎么打才不会导致高基数、聚合时哪些维度必须保留。这部分决定了你后面所有的查询和告警是不是建立在可靠的基础上。

二、告警要能被人处理，而不是把人吵醒

Alertmanager 常被当成一个转发器用，这是最大的浪费。课程会讲到路由树怎么按业务和严重级别拆分、group_wait 与 group_interval 如何影响告警到达时间、inhibit_rules 怎么避免同一故障引发连锁告警。目标是让值班的人收到告警时，能立刻知道是哪个系统、什么级别、该不该现在处理。

三、面板是给人用的，不是给截图用的

Grafana 部分不会停留在「怎么加一个 Panel」。它更关注变量与模板的配合、时间范围和刷新策略的选择、以及如何让一个面板同时服务于排障和容量评估。你会看到同一批指标，因为聚合方式和单位设置不同，得出的结论可能完全相反。

配套练习建议这样用

课程里的实战案例不建议只看不练。比较有效的做法是：先按课程配置跑通一遍，确认指标能采到、告警能触发；然后主动改坏一个环节——比如把抓取间隔调大、把某个标签去掉、把一条抑制规则注释掉——观察系统行为怎么变。这三种「反向操作」比顺着做一遍更能暴露你对机制的理解程度。另外，强烈建议把你手头正在维护的一台服务器或一个服务接进去，用真实的指标和真实的告警去验证配置，而不是只用演示数据。

看完你应该能回答这些问题

• 一条 PromQL 查询返回空结果，从采集、标签、时间范围三个方向，你的排查顺序是什么？
• 某类告警一天触发几百次但没人处理，你会从 Alertmanager 的哪个配置项入手，为什么？
• 指标数量增长导致 Prometheus 内存持续升高，你能想到哪几种治理手段，各自的代价是什么？
• 业务方问「昨天下午接口慢是不是系统问题」，你能用现有面板和查询在多长时间内给出结论？
• 如果让你重新设计一次告警分级，你会按什么维度分，和现在这套的区别在哪？

这几个问题答不上来，说明缺的不是工具操作，而是对监控链路的整体判断。这门课的价值，就是把这条链路从采集、存储、查询、告警到可视化的每一段，拆开讲清楚它们之间的因果关系。