这篇可视化篇其实是整个可观测性系列里最后一块拼图。前几篇我写过服务拆分的流量治理、容器化改造的踩坑过程、日志链路追踪的建设很多朋友留言说前面都看懂了但最后卡在监控上——机器指标怎么采、业务指标怎么搭、告警怎么不吵死人、面板怎么做到一眼看出问题。这篇我就拿这一路从零搭起来的实际监控系统说话完整讲一遍 Prometheus Grafana 这套组合从选型到落地的全过程包括指标设计、采集配置、告警链路、面板思路以及那些跑了半年之后才发现的坑。内容偏实战没基础的朋友可以照着一步步来有基础的朋友可以直接跳到指标设计和告警治理两节那两节才是这半年运维下来真正值钱的经验。1. 为什么监控可视化放在第四步才做先想清楚这套系统到底要回答什么问题前面三篇文章分别解决了服务怎么拆、容器怎么编、请求怎么追踪但这些都属于让系统跑起来的范畴。跑起来之后真正让人睡不着觉的是另一件事出故障的瞬间你靠自己大脑去算流量、看负载、翻日志那就是火场里找开关。1.1 监控可视化不是装两个开源软件而是建立一套回答问题的能力我见过很多团队把 Prometheus 搭起来就完事了Grafana 上导入几个官方仪表板截个图发群里说我们上监控了。但这种监控体系撑不过第一次真实的大故障。原因很简单官方面板回答的是服务通不通、CPU 高不高这种通用问题而业务场景下我们需要回答的是哪台节点拖慢了整个集群的响应MySQL 连接池为什么被吃满某个接口在下午三点开始 P99 突然翻倍这种具体问题。通用面板给不了这些答案需要自己设计。所以这一篇我不打算只教你怎么 docker run 一个 Prometheus。重点要讲的是采集哪些指标指标怎么命名、怎么带标签才能支撑常见的故障定位告警规则怎么写才能做到只响真实问题不炸群仪表板怎么设计才能在凌晨三点被叫醒时手机打开第一屏就能猜出问题方向数据从采集到展示经过了哪几层每一层坏了会表现出什么症状。这个思路想清楚你再看下面这些具体内容就不会觉得只是装两个软件。1.2 白盒监控和黑盒监控的取舍一个偏根因一个偏体验在动手搭之前我先花两分钟讲一个有争议但特别重要的概念因为它直接决定你采集什么数据。监控界习惯把监控分为两类一类叫白盒监控一类叫黑盒监控。白盒就是进到系统里面看内部状态比如进程数、线程池的活跃线程数、JVM 堆内存、SQL 执行耗时这些指标只能通过应用暴露出来或者 Agent 注入进去拿。黑盒就是从外面打比如对着 HTTP 接口测响应时间、测状态码不知道里面怎么实现的只关心从用户角度来看是不是可用的。我见过不少团队只用黑盒理由是用户不关心你内部指标只关心访问是否顺畅。这句话对了一半但黑盒只能告诉你现在挂了很难告诉你为什么挂。反过来完全沉迷白盒也容易出问题因为内部指标堆成山却没法回答用户实际感受到卡顿没有。我的做法是两套并行黑盒用于核心链路入口的可达性探测白盒用于系统和应用内部的详细监控。Prometheus 在这两边都有成熟的生态后面会具体讲配置。2. 从零搭建这套监控链路组件选型、数据源接入和第一块仪表板的诞生监控链路的基础设施部分其实不复杂复杂的是把每个组件的用途和坏了之后怎么办想清楚。这一节从基础架构讲起再讲具体的搭建步骤每一步都带配置和验证方法。2.1 整体架构里每个组件负责什么别只知道 Prometheus 这个名字这套体系里最容易被忽视的不是 Prometheus 本身而是它周边的小兄弟们。我的监控链路长这样组件职责数据流向挂了会怎样node_exporter采集宿主机CPU、内存、磁盘、网络等系统指标被Prometheus拉取机器层指标缺失CPU打满时没法定位是哪台cAdvisor采集容器运行数据如CPU占用、内存限制、网络IO被Prometheus拉取容器资源看不了Pod被杀时很难提前预警业务Exporter应用自己暴露的/metrics端口含QPS、RT、连接池、业务量被Prometheus拉取业务状态变瞎子接口异常只能靠用户投诉Prometheus Server定时拉取所有目标数据存入TSDB执行告警规则存储 向Alertmanager推送告警核心存储挂了告警随之中断Alertmanager对告警做去重、分组、静默、路由最终推送IM向钉钉/飞书等发送消息告警发不出来故障只能靠人肉盯屏Grafana用SQL-like的PromQL从Prometheus读取数据绘制仪表板从Prometheus查询看板看不了但告警链路不受影响这个表格值得你保存一下尤其是挂了会怎样这列。很多团队只知道 Prometheus 挂了会没监控但容易忽略 node_exporter 的通断、cAdvisor 的指标口径变化同样会掩盖真实问题。2.2 部署步骤二进制和容器验收过的两套方案如果你在生产环境已经上了容器编排我建议 Prometheus、Alertmanager、Grafana 这些主控组件用容器跑但 node_exporter 这类宿主机采集器建议用二进制直接部署在宿主机上。原因是 node_exporter 要拿宿主机真实的系统指标在容器里跑需要挂载大量只读系统路径而且容器调度到别的节点时采集目标会漂移对采集宿主机全局状态这件事来说是干扰。下面这是我在测试环境和生产环境都跑过的最小可运行方案。主控组件我用 docker compose 管理先看目录结构monitoring/ ├── docker-compose.yml ├── prometheus/ │ └── prometheus.yml ├── alertmanager/ │ └── alertmanager.yml └── grafana/ └── provisioning/先看 Prometheus 的核心配置。这里是整个配置的骨架注意我把采集目标分成了三个 jobnode_metrics、container_metrics、business_metrics这样后面在 Grafana 里做面板和告警时可以快速用 job 标签过滤数据。# prometheus/prometheus.yml global: scrape_interval: 15s evaluation_interval: 15s external_labels: cluster: prod-main rule_files: - /etc/prometheus/rules/*.yml scrape_configs: - job_name: node_metrics static_configs: - targets: [10.0.0.11:9100, 10.0.0.12:9100, 10.0.0.13:9100] labels: env: prod - job_name: container_metrics static_configs: - targets: [10.0.0.11:9101, 10.0.0.12:9101, 10.0.0.13:9101] labels: env: prod - job_name: business_metrics metrics_path: /app-metrics static_configs: - targets: [10.0.0.21:8080, 10.0.0.22:8080, 10.0.0.23:8080] labels: env: prodscrape_interval 我为什么选 15 秒如果不差这点存储开销建议不要低于 15 秒。Prometheus 的告警规则里有个概念叫 for意思是持续一段时间才告警。如果采集间隔很短每 15 秒就能触发一次判定会导致某些瞬时抖动也被记入规则执行历史很容易把告警搞成抖动式触发。evaluation_interval 保持一致就好它会决定告警规则多久评估一次。这个配置在生产环境我建议用配置文件统一管理配合版本化部署别直接在 Web UI 里改方便回溯。接着看 docker-composeservices: prometheus: image: prom/prometheus:v2.53.0 volumes: - ./prometheus:/etc/prometheus - prometheus-data:/prometheus ports: - 9090:9090 command: - --config.file/etc/prometheus/prometheus.yml - --storage.tsdb.path/prometheus - --storage.tsdb.retention.time15d alertmanager: image: prom/alertmanager:v0.27.0 volumes: - ./alertmanager:/etc/alertmanager ports: - 9093:9093Grafana 部署起来更简单但有一点要提前做把数据源和仪表板的配置用 provision 的方式管理起来别每次上线一台机器都要手动去 Grafana 里点一遍。services: grafana: image: grafana/grafana:11.1.0 environment: - GF_SECURITY_ADMIN_PASSWORDyour-strong-password volumes: - ./grafana/provisioning:/etc/grafana/provisioning - grafana-data:/var/lib/grafana ports: - 3000:3000在 grafana/provisioning/datasources/ 下放一个 datasource.ymlGrafana 启动时会自动把 Prometheus 接进来不用人工操作apiVersion: 1 datasources: - name: Prometheus type: prometheus access: proxy url: http://prometheus:9090 isDefault: true第一块仪表板可以从 node_exporter 主机视角开始做这是最基础也最能说明这套链路通了的验证标准。Grafana 里新建仪表板加一个面板Queries 里选择 Prometheus 数据源输入 PromQL100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100)这个表达式表示计算每台节点最近 5 分钟的 CPU 平均使用率。等它出来一条有数字的线监控链路的第一个循环就已经通了。2.3 一个隐藏很深的坑进程级指标用白盒方式拿容器级指标别直接信运行一段时候后我发现一个很奇怪的问题节点上进程显示 CPU 使用率很正常但容器面板里看到的 CPU 曲线几乎贴到天花板。后来定位到是 cAdvisor 的采集口径问题它读取的是 cgroup 的数据而 cgroup 在没有设置 CPU 限额时默认展示的是当前可用 CPU 配额而不是整机物理核数。这个坑引发的直接后果是告警规则如果直接基于容器 CPU 百分比去设阈值未限制 CPU 限额的容器经常会触发假告警。我在生产环境绕过的办法是对容器 CPU 百分比做了归一化处理同时把容器 CPU 限额设置为物理核数的 50% 作为上限这样 cAdvisor 拿到的分母本身就是可控的。这个例子说明监控面板上你看到的数据和你以为看到的数据中间可能隔着一个采集器的翻译口径。后面遇到监控数据和现场表现对不上时优先怀疑口径不要先怀疑目标系统。3. 生产线上的数据会撒谎指标设计与 PromQL 查询策略统计归统计如果指标设计从一开始就不合理后面整个监控体系都会变成噪音制造机。很多人觉得 PromQL 难其实 PromQL 只是个查询语言真正难的是你怎么设计指标才让查询变得有意义。3.1 指标命名的第一原则能枚举才可聚合有单位才可比较Prometheus 的指标名不只是一个名字它会自动带上时间、标签、样本值所以命名本身就是数据结构设计的一部分。我给团队定的命名规范是四段式命名段 说明 示例 前缀 区分指标类型 http / redis / jvm 系统/模块名 标明对象 order / user / payment 行为名 标明是什么动作 request / connection / latency 单位 标明数值含义 total / seconds / bytes 最终指标名 http_order_request_total有个很容易被忽略的细节是业务指标在最后一定要带单位后缀比如 _total 表示“累计计数”_seconds 表示“秒”。因为 Prometheus 的很多函数对单位是有隐含假设的比如 rate 和 irate 就默认指标是 counter 类型的累加值。如果你的指标名叫 http_order_request_seconds但实际上存的是次数后续做 rate 时结果就会单位错乱面板上看数字莫名其妙。3.2 PromQL 里被你低估的两个函数rate 和 irate 的取舍这是查询层面最常见的误区。很多人做服务 QPS 时直接写sum(rate(http_requests_total[5m]))rate会计算区间内的平均每秒增量曲线平滑适合看整体趋势。但如果服务真的在一分钟内发生了突发流量rate 会把突起抹平。这时候要用iratesum(irate(http_requests_total[5m]))irate 计算的是区间内最后两个样本点的瞬时速率对突发更敏感适合看抖动场景。生产环境建议两个都要一个看趋势、一个看毛刺不要互相替代。再来讲一下 long-term 时间范围内的统计。因为 Prometheus 存储引擎对旧数据的精度会做下采样拉取一个 7 天范围的 QPS 曲线时如果直接用 5m 区间算 rate曲线会非常抖。合理做法是用increase 足够大的区间窗口比如sum(increase(http_requests_total[1d]))这种写法在周报、月报场景下最实用算的是今天一共处理了多少请求而不是每秒多少请求。很多朋友一上来就 rate结果做日报时数出来永远对不上就是因为 rate 是瞬时速率increase 是区间累加两者用途完全不同。3.3 别把所有标签都做成高基数一个查询卡死的真实案例有段时间我的仪表板突然慢到每次打开要等十几秒刷新一次能卡半分钟Prometheus 的 CPU 也一直飚高。排查下来发现是有个新手同事在业务指标里加了一个用户ID标签这个标签的取值是百万级以上的唯一值。Prometheus 的存储引擎按标签组合建立索引标签值越多写入和查询的开销越大这叫高基数问题。用户ID这种标签一进来整个时序数据库的索引就开始膨胀。凡是取值规模在百万级的标签都不应该作为指标维度应该用日志系统去承载或者将用户ID做分桶后再作为标签。在监控指标里标签维度的取值范围如果超过几千就需要警惕了。按这个原则去约束团队能帮你少交很多用监控系统给关系型数据库当日志表用的学费。4. 告警链路从 0 到 1Alertmanager 的静默与分组以及如何避免午夜连环轰炸仪标板是给人看的告警是给系统看的。如果没有人盯着屏幕面板做得再好看也没有意义。所以单独拿出一节讲告警链路这里面的坑我也踩过不少。4.1 告警规则编写的两条思维原则要设 for要避免用 判断告警规则的常见写法是groups: - name: node_alerts rules: - alert: NodeCPUHigh expr: 100 - (avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100) 85 for: 10m labels: severity: warning annotations: summary: 节点 CPU 持续高位这里最容易被忽略的是for: 10m。如果把这个持续条件去掉或者设成 0m那么 CPU 波动产生的瞬时尖峰就会立刻触发告警每晚你都会被毫无意义的警报吵起来。我现在的经验是基础资源类告警至少给 5 到 10 分钟的持续期先把偶发抖动滤掉业务类告警可以根据容忍度给 2 到 3 分钟因为业务指标高占用对用户的影响是即时可见的。另一个容易踩的坑是用 判断阈值。比如写container_restart_count 5这个表达式的问题在于如果容器从 5 次重启变成了 6 次、7 次告警反而会消失。因为 只在完全相等的那一瞬间成立。正确做法是用比较运算加 increase 函数increase(container_restart_total[15m]) 0含义是15 分钟内重启次数大于 0无论重启了几次都会命中而且不会出现超过阈值反而恢复的诡异现象。4.2 Alertmanager 的路由树与静默机制让告警找到正确的人Alertmanager 的核心配置是路由树route它决定告警消息往哪里送。最简单的方式是把所有告警发到同一个群但团队大了之后这会产生严重的告警疲劳刚毕业的运维每天上午第一件事是点掉 100 条消息。我目前的告警路由大概长这样route: receiver: default group_by: [alertname, cluster] group_wait: 30s group_interval: 5m repeat_interval: 4h routes: - match: severity: critical receiver: critical-im - match: env: prod receiver: prod-oncall与路由同等重要的是正确使用静默Silence机制。大规模发布的时候某类告警一定会因为发布动作而触发这时候应该主动去 Alertmanager 里创建一条静默规则而不是把告警规则临时关掉。两者看起来都是不想收告警但本质不同静默不会让你忘记恢复静默期一过会自动回到监控状态直接改规则很有可能第二天忘了恢复等于这部分监控永远失效了。我通常会在发布流程里加一个发布前静默核心链路告警 2 小时的自动步骤发布完成后静默自动过期风险大大降低。4.3 用 alertmanager-webhook 把告警推向 IM 群里一则真实的深夜告警这一节我举一个发生在半夜的实例。那天凌晨 2 点多努力睡觉时手机突然响了看着是某订单服务接口成功率跌到 50% 以下。腾地坐起来后我并没有直接切到服务器看日志而是先在手机上看 Grafana 的面板。第一屏看到的是订单服务所在一组节点的 CPU 曲线从 20% 突然爬到 85%同时网络发送字节快速上涨。节点层面出现了明显异常。再往下翻看到一个 Redis 面板里连接数比平时多了 3 倍此时我已经初步推断出问题方向不是代码逻辑而是这一组节点承受的流量突然暴涨。于是我切到日志系统搜订单超时相关关键字确认是上游的促销开关被误触发大量流量打到集群上。整个过程大概 5 分钟从接到告警到定位到方向最后只需要做一件事关闭促销开关。你可以试想一下没有这套链路的情况同事连夜起来先登录三台节点挨个看 CPU再看日志再看 Redis 连接。运气好半小时运气不好整夜都定位不到根因。这套体验背后的支撑其实就是一个精心设计的指标体系和选择合适的查询语句让第一屏的回答足够直接。5. Grafana 仪表板设计思路第一屏回答挂了没有第二屏回答挂在哪生产环境跑了大半年后我把仪表板分成了三层。这三层的目标完全不同看板的人也不同所以绝对不能混成一套。5.1 三层仪表板架构及各自的设计原则第一层是运维总览板用户是值班群里的所有人。目标是一眼知道当前有没有大面积故障不需要太细的指标放核心服务的平均响应时间、成功率、集群整体 CPU 水位、流量峰值就够了。设计原则是减少认知负担最多 6 到 8 个面板从上往下按先全局后局部排列。第一行是全局健康度第二行是四个核心服务的详情入口第三行如果出现异常直接标红色。跑不通的时候手机锁屏界面瞄一眼红色就能判断是全挂还是局部挂。第二层是服务专题板用户是服务负责人和值班开发者。这一层开始需要有业务属性某个具体服务的 QPS、P99、错误率、JVM 堆栈、连接池水位。设计的核心是关联指标并置让负责人在同一屏里完成因果推断。比如 QPS 涨了旁边就是 CPU 水位和内存曲线一眼能判断是流量问题还是资源问题。第三层是资源细查板用户是运维和 SRE。这一层看的是磁盘 IO、网络重传率、文件句柄数、GC 耗时等更底层的维度。平时很少打开但深挖问题时必须存在。5.2 变量与下钻为什么你不该给每个团队各建一套面板很多团队犯的低效错误是每个团队各建个独立看板然后到月底发现数据对不上因为两个看板用的指标口径不一样。我在 Grafana 里解决这个问题的手段是模板变量。新建仪表板时在 Settings 里添加一个 template variable把服务名做成下拉框。Query 里写成sum(rate(http_requests_total{service~$service}[5m]))这样同一个面板用同一个指标只是换个服务名就完成了一套面板适配所有服务。后续新增服务时不需要建新看板只需要让业务埋在代码里的指标名带上 service 标签下拉框里就会出现新选项。千万别觉得这是个多高级的功能它最大的价值是避免每个团队一套面板口径逐渐走样这种慢性问题。5.3 面板不是越花越好配色、阈值和单值图的正确用法Grafana 默认有很多花哨的图表类型但真正干活的时候我几乎只用四种时间序列Time series、状态历史State timeline、单值统计Stat、表格Table。时间序列图用来看趋势是绝对的主力。状态历史适合表达某项指标是否符合预期比如节点健康状态绿了又红、红了又绿一屏就能看出哪个时间段出了问题。单值图适合放关键里程碑数字比如今日请求总数当前排队数但要配合阈值设置超过阈值自动变红否则一个孤零零的数字放在那儿毫无意义。颜色配置上我建议全局统一绿色代表正常低于告警阈值的 70%黄色代表预警超过 70% 且低于告警值红色代表已触发告警。色彩含义一旦定了就不要改让肌肉记忆替你在紧急时刻争取几秒时间。6. 指标体系的实际搭建案例一套扣住业务场景的监控维度设计讲完通用的搭建和查询最后这部分回到业务本身。因为监控最终为业务服务指标设计如果脱离业务再炫酷的面板也是电子壁纸。6.1 黄金四指标落地从黑盒到白盒的完整映射业内常说的黄金四指标是延迟Latency、流量Traffic、错误Errors、饱和度Saturation。这四个指标的名称你可能听过但真正落到代码和监控里的时候很多团队就不知道从哪里下手了。我的拆分方式是三层映射用户侧延迟从网关层或接入层拿 HTTP 请求的耗时分布。这一层代表用户实际体验到的速度。服务侧延迟从应用内部的中间件层拿数据库查询耗时、外部调用耗时。这一层决定为什么慢。资源层饱和度拿 CPU、内存、连接池使用率。这一层决定还能不能支撑住流量。三层必须同时存在才能形成一个完整的因果链。只做用户侧延迟你能发现问题但找不到原因只做资源层饱和度你天天都在担心资源却不知道用户实际感受。6.2 用耗时分解类指标做慢请求定位一个实操案例我们曾经被一个慢接口困扰了很久。接口平均耗时 200ms不算太差但 P99 经常飙升到 5 秒用户体验很不好。一开始我加了通用的 HTTP 耗时指标只能确认接口慢却不知道慢在哪一段。后来我在业务代码里埋了一个全局耗时分解指标通过一个 gauges 类型指标或者 histogram 将一次请求拆分为“数据库查询时间、RPC 调用时间、业务逻辑时间、序列化时间”这样在 Grafana 里就能分别画出四条曲线。查到结果那天我看到数据库查询时间从 50ms 变成 4 秒而逻辑时间和 RPC 时间都很稳定于是直接定位到SQL 执行计划在某些参数组合下退化成全表扫描。后来在数据库里给对应表加了索引P99 直接从 5 秒降到了 300ms。这次问题让我意识到监控指标不能只停留在框架层面自带的那些通用指标还要肯花时间埋业务特有的过程指标哪怕只是几个 gauge 或 histogram排查问题时价值就出来了。6.3 业务指标的采集方式应用内埋点与独立 Exporter 的取舍最后聊一下业务指标到底怎么采集。如果服务本身就是 Java/Go/Python 写的最轻量的方式是直接在应用里引入 Prometheus 客户端库暴露一个 /metrics 接口让 Prometheus 来拉。这种方式的优点是代码里想加什么指标就加什么指标业务语义丰富缺点是需要开发配合改代码如果系统是遗留老系统改起来要评估成本。对于那些改代码代价太高的系统可以用独立 Exporter 做适配器。比如为 MySQL 单独拉一个 mysqld_exporter它可以直接采集慢查询数、连接数、缓存命中率等不需要业务代码参与。这两种方式不是互斥的实际部署时我通常两套并行基础中间件指标靠 Exporter 覆盖业务核心链路指标靠应用埋点覆盖。中间件指标用来保证底子没坏业务埋点用来回答业务是否正常。7. 这半年运维下来踩过的几个 Prometheus 深坑最后把我没有归到前面章节里的一些零散坑集中列出来这些都是真实影响过线上稳定性或者排查效率的教训值得单独记一笔。7.1 存储时长与数据精度15 天看起来够用但月末对账时会发现精度被下采样了Prometheus 的本地存储配置我设的是保留 15 天这个时长平时够用。但到了月末要做业务趋势分析想拉一个月的数据时发现超过 7 天的旧数据经过了下采样原本 15 秒一个点变成了 5 分钟一个点很多瞬时峰值消失在采样窗口里。所以如果你有月度分析需求建议提前想清楚两种方案要么将 Prometheus 的本地保留时间拉长到 30 天以上同时接受磁盘存储成本要么搭建一个单独的长期存储方案比如与对象存储对接的读路径方案把 30 天以上的数据归档。别等到月末刷报表时才发现数据失真。这意味着监控系统的容量规划从第一天就要跟保留时长绑定。存储磁盘的规格也要预留 1.5 到 2 倍余量因为指标数量会随着服务增长不断膨胀。7.2 告警疲劳的最大原因不是告警多而是恢复后没有自动清理你可能会遇到这样一种情况某条告警从凌晨响到早上 7 点你起来处理完故障但它还在那挂着。于是你开始怀疑是不是没恢复进一步不断打开监控软件反复确认把整夜的睡眠切成碎片。Alertmanager 的 repeat_interval 控制的是同一告警重复发送的间隔但它不影响告警状态是否恢复。恢复的动作是 Prometheus 根据规则表达式持续往下走表达式从触发条件成立变为不成立后才会生成 resolved 消息。关键是告警恢复的消息一定要推到同一个群里。如果只推触发的消息不推恢复的消息群里所有人都会在告警解除后保持紧张感。我会在告警模板里明确加上恢复消息并且把恢复标题写成xxx 已恢复让值班的人看到后真正安心。7.3 多环境复用时别把 external_labels 忽略了前面配置文件里写了 external_labels如果你只有一套生产环境这个参数确实可以忽略。但如果团队同时维护测试、预发、生产三套环境Prometheus 默认情况下会把所有环境的数据混在一起在 Grafana 下拉环境变量时你会分不清看到的指标到底来自哪套集群。external_labels 的作用就是允许你在写入 Prometheus 时就打好环境的标签。要保证每个环境一套 Prometheus并在配置里写上不同的 cluster 标签这样在 Graphana 的查询里随时加 cluster~prod|staging 就能做环境隔离。这个问题说大不大但一旦忘记做了等三套环境的数据混在一起后再回头拆分工作量会非常大。写在最后的实战心得这篇从组件搭建、指标设计、告警链路到仪表板分层都讲完了最后说几句不那么技术、但更重要的体会。监控系统是典型的做的时候没人看见出了故障大家才知道它的价值的基础设施。它最大的挑战不是部署几个开源组件而是如何持续地让指标和业务现状保持一致。我见过很多团队花一周把系统搭起来之后半年都没有再动过指标等到系统架构发生大变化时监控面板就成了对照历史而不是指导现在的摆设。我现在的习惯是每个迭代都要过一遍核心服务的关键指标确认它们仍然能回答这个服务现在健康吗如果它出问题第一块面板能告诉我方向吗这两个问题。这套 Prometheus Grafana 的方案陪我们度过了很多次故障演练和真实故障它不需要多聪明但需要你认真对待每一个指标的设计。如果这篇对你有帮助建议先从自己最关心的那个服务的黄金四指标开始搭起不用追求大而全。等跑到一个月再回头看哪些告警是噪音、哪些面板开完再也没打开过就知道下一步该优化什么了。
