Grafana 生产落地案例

生产落地案例

案例一：从「几个大而全的大盘没人看」到三层大盘加告警分级

背景。某团队最初只有三张大盘：一张把所有服务的指标全塞进去，两百多个面板；一张全是主机 CPU 与内存；一张是数据库。结果是谁都不看——开发找不到自己的服务，运维嫌加载太慢，出故障时还是靠人肉问「谁那边有报警」。告警只有零星几条，且全部发到同一个群，噪声大、响应慢。

怎么做。先按角色把大盘拆成三层。第一层业务总览：面向值班与管理，只放核心业务指标（下单成功率、支付成功率、首页可用性）与服务整体健康度，面板控制在十几个以内，用 Stat 加大号数字与阈值颜色，一眼能看出「今天有没有问题」。第二层服务详情：面向各服务负责人，一张大盘对一个服务，包含 RED 三件套（请求量、错误率、延迟分位数）、依赖的下游调用、以及该服务的日志与关键事件标注。用 service 与 env 两个变量做切换，通过 Repeat 按实例或按接口复制面板行。第三层实例排查：面向具体故障定位，包含单实例的 CPU、内存、GC、线程池、连接池、以及该实例最近的错误日志。

告警同步做分级：P1 走电话加值班群，P2 走工单系统，P3 只在大盘上标红不通知。每条告警规则都必须写清楚「触发后第一步做什么」，这段说明直接放进告警的 Annotation 里，值班的人不需要再去翻文档。

关键配置。所有大盘通过 Provisioning 从 Git 加载，文件夹按团队划分并设置 Folder 权限；变量用 label_values() 动态取标签值，避免新增服务时还要手改大盘；告警的 Notification Policy 按 severity 与 service 两个标签分组，保证一次故障只发一条聚合通知。

效果。值班的人只在第一层大盘上盯几分钟就能判断是否需要介入；服务负责人打开第二层大盘就能看到自己服务的全部上下文；故障定位从「先问是谁的服务」变成「从总览点进去一路下钻」。告警量显著下降，且每条通知都有明确的处理指引。

坑与解决。（1）告警风暴：一次数据库抖动触发了几十条规则的告警，群里刷屏。解决方式是正确使用 group_wait（首次触发后先等一小段时间，把同组告警攒到一起）、group_interval（同组后续更新的最小间隔）、repeat_interval（重复提醒间隔），并把分组标签设为 service 与 severity，让同一服务的同类问题聚成一条。（2）for 设为 0：网络抖一下、采集丢一个点就触发告警，半夜被叫醒后发现一切正常。改成 for: 5m，并确保 for 明显长于采集间隔与一次抖动的时间尺度。（3）大盘刷太勤加查询范围太大把数据源打挂：默认 30 秒自动刷新、时间范围选了 30 天、面板数量上百，Prometheus 被查询压垮。缓解方式是把刷新间隔与时间范围设成合理默认值、把能用 Recording Rule 预聚合的重查询提前算好、并给大盘加上显式的时间范围变量，别让每个人都去查三个月的数据。（4）Dashboard 手改丢版本：有人在界面上调了阈值，没人知道改了哪里，也没法回滚。改走 Provisioning 加 Git 之后，大盘的每次变更都有提交记录，界面上的临时改动不再作为事实来源。（5）No Data 未配置导致夜里静默漏告警：采集端挂掉后查询返回空，规则默认不触发，故障被完美地隐藏了。核心规则必须显式配置 No Data 的行为并让它发出通知，否则「没有告警」和「没有数据」会被混为一谈。

案例二：用统一大盘把「发布」和「指标变化」对齐

背景。团队每周发布多次，每次发布后都有人怀疑「指标好像变了，是不是这次发布引起的」，但缺少客观依据，排查往往靠回忆。

怎么做。把发布系统接成 Annotation 数据源，每次发布自动往 Grafana 打一个标注；同时在公司统一大盘模板里预留发布时间轴。大盘设计上做了三件小事：命名统一为「层级 - 对象 - 关注点」，比如「业务总览 - 首页 - 可用性」；颜色与阈值语义全站统一，绿色是健康、黄色是待观察、红色是越界，同一种颜色在任何面板里含义一致；所有面板的单位显式声明，禁止「裸数字」。

效果。发布后指标出现变化时，能在同一个时间轴上立刻看出是不是与发布对齐；新人打开任一大盘都能按命名找到自己要找的东西，不再需要口口相传哪个面板在哪。

坑与解决。统一模板初期没人遵守，问题出在「规范写在文档里但做起来麻烦」；后来把规范做成 Provisioning 里的模板 JSON，新建大盘从模板复制，默认就带上了命名规范、阈值颜色与单位设置，遵守成本降到接近零。