害怕我来，又害怕我不来

快猫运营团队 2025-03-18 12:11:09

你好，我是一条告警事件，很多研发、运维人员都害怕我来，因为这意味着线上出现了问题。但是，有时候我不来，反而更可怕，因为这意味着问题可能已经存在，只是没有被发现。很多人都苦恼一个问题：到底应该按照什么原则来配置告警，才能不漏报、不乱报？笔者做监控这个方向 10 年了，今天就来分享一下我的一点心得，希望对你有所帮助。

最最最重要的告警

最最最重要的告警，是站在用户角度，能否反应用户体验的告警。因为系统最终是为用户服务的，用户的功能体验、性能体验是最重要的。即便你有个底层机器宕机了，只要用户体验不受损，短期就无关痛痒，即便你所有机器都活着，但是用户体验受损，那就是大问题了。

不同的系统，用户不同，有的用户是互联网上的普通网民，有些系统的用户是你的上层业务系统。比如：

电商平台：用户是普通网民，网民的购物体验是最重要的。其浏览商品、下单、支付、退货等环节的体验，都是最重要的。
存储系统：用户是上层业务系统，上层业务系统的读写性能、数据一致性等，都是最重要的。
负载均衡：用户是上下游系统，上下游系统的请求转发、负载均衡等，都是最重要的。

一句话，最最最重要的告警，是站在用户角度，能否反应用户体验的告警。比如电商平台，用户浏览商品时响应速度太慢，就应该告警，因为这直接影响用户体验。下单、支付、申请退货等环节的相关 API 接口的成功率和响应时间，也是必须要监控的指标，有问题就应该告警。

这些指标来自哪里

这些体现用户体验的关键指标，可能来自多个数据源。比如 API 接口的成功率和延迟，可能是来自 RUM、APM、Prometheus 埋点、接入层的 Access Logs。不同公司情况各异，有的公司研发人员愿意配合改造有的就不愿意配合，所以要根据实际情况，选择合适的数据获取方式。

除了 Prometheus、ElasticSearch 这类数据源，很多关键指标可能是来自 OLTP 或者 OLAP 的库，比如：电商平台的订单量。

订单量是不是一个反映用户体验的指标？太是了。体验不好用户肯定就不下单了，体验好了才可能下单。而且订单量是个终局指标，不但跟用户的体验相关，还跟公司的营收相关，是公司老板最最看中的一类指标。

订单量这样的指标，很多公司是放在 Oracle、MySQL 等事务库里的，也可能是导入到 ClickHouse 这类分析库里的。所以，如果你要搞一个监控系统，只是监控 Prometheus、ElasticSearch 还不太够，还需要能够读取 Oracle、MySQL、ClickHouse 当中的数据。我们做的监控系统就是对接了各种各样的数据源：

数据源

这的确是个脏活累活，但也没办法，这些指标重要，值得 VIP 级别的对待。除了要支持各类数据源，我们还为这类指标做大屏呢，让老板一目了然看到公司各个关键指标的变化趋势，看到各个业务系统是否健康。运维人员经常抱怨老板不懂技术，看不到运维的付出，这样的大屏就能很好的让老板看到运维的部分价值。

北极星大屏

上面只是一个样例数据，人嘛，确实是视觉动物，好看的 UI 确实能让人心情愉悦，也能让人更愿意去理解数据。很多老板都希望挂这么一个大屏放到自己的办公室。普通研发、运维人员则更直接，喜欢那种简单的视图，比如总共有 6 个业务系统，只要哪个系统的关键指标异常，就飘红展示：

上文提到的这些指标，都是各个业务的核心关键指标，能否反应公司营收、用户体验的，那只有这些指标重要其他指标就不重要了吗？那倒也不尽然。

其他指标就不重要了吗？

上面提到的指标，我个人喜欢称之为结果类指标，与之对应的就是原因类指标。比如某个故障最底层是由于一块盘故障导致的，这块盘的 disk_write_error 指标就是典型的原因类指标。

结果类指标是可以枚举的，因为系统功能是可以枚举的，但是原因类指标，很难枚举。从业务角度来看，机器相关的各类指标，数据库、中间件相关的各类指标，都是原因类指标。如果极端一点，原因类指标不配置告警规则都是可以的，出了问题之后有个大盘，能够去查看这些指标也是可以的。

但是真正实践的时候，一些关键的原因类指标也会配置告警。有两个原因：

有些指标从业务角度是原因类指标，但是从底层系统角度是结果类指标。底层系统的运维人员，需要收这类告警。
出了问题排障，要看的信息太多。一些重要的原因类指标可以提前配置告警，这些指标出了问题会生成告警事件，这些告警事件可以看做是从海量数据中的一个精华洞察，加速排障过程。从这个角度出发，这些原因类指标是需要生成事件的，但未必要发送告警通知，需要的时候能够查到就行了。