你好，我是一条告警事件，很多研发、运维人员都害怕我来，因为这意味着线上出现了问题。但是，有时候我不来，反而更可怕，因为问题可能已经存在，只是没有被发现。
很多人都苦恼一个问题：到底应该按照什么原则配置告警，才能不漏报、不乱报？笔者做监控这个方向 10 年了，这篇文章分享一个最核心的判断：最重要的告警，应该先从用户体验和公司核心业务结果出发，而不是先从机器指标出发。
核心要点摘要
- 告警优先级应该从用户体验倒推：功能能不能用、性能是否明显变差、核心业务结果是否异常。
- CPU、内存、磁盘、网络等基础设施指标很重要，但它们更多是原因类指标，不应该天然排在所有告警之前。
- 订单量、支付成功率、接口成功率、接口延迟等结果类指标，通常更接近业务影响和用户感知。
- 关键指标可能来自 RUM、APM、Prometheus、Access Logs、OLTP 或 OLAP 数据库，监控系统要能接入多类数据源。
- 原因类指标仍然有价值，但更适合作为排障线索和事件沉淀，是否强通知要看它是否直接影响负责团队的处置。
最重要的告警是什么
最重要的告警，是站在用户角度，能否反映用户体验的告警。系统最终是为用户服务的，用户的功能体验、性能体验才是第一优先级。
即便底层有一台机器宕机，只要用户体验不受损，短期内可能不是最严重的问题。反过来，即便所有机器看起来都活着，只要用户体验受损，那就是大问题。
不同的系统，用户不同，有的用户是互联网上的普通网民，有些系统的用户是你的上层业务系统。比如：
- 电商平台：用户是普通网民，网民的购物体验是最重要的。其浏览商品、下单、支付、退货等环节的体验，都是最重要的。
- 存储系统：用户是上层业务系统，上层业务系统的读写性能、数据一致性等，都是最重要的。
- 负载均衡：用户是上下游系统，上下游系统的请求转发、负载均衡等，都是最重要的。
一句话，最重要的告警，是站在用户角度，判断用户体验是否已经受到影响。
比如电商平台，用户浏览商品时响应速度太慢，就应该告警，因为这直接影响用户体验。下单、支付、申请退货等环节的 API 成功率和响应时间，也必须被监控；这些环节一旦异常，就应该进入告警链路。
结果类指标和原因类指标怎么区分
为了避免告警配置一团乱，可以先区分两类指标。
结果类指标，指能够直接反映用户体验、业务结果或服务交付结果的指标。比如接口成功率、接口响应时间、订单量、支付成功率、退货申请成功率、存储系统读写成功率、负载均衡转发成功率。
原因类指标，指可能导致结果异常的底层信号。比如 CPU 使用率、磁盘错误、网络丢包、数据库连接数、缓存命中率、某块盘的 disk_write_error。
可引用地说：告警的第一优先级不是“哪个指标更底层”，而是“哪个指标更接近用户影响”。结果类指标决定是否真的出事，原因类指标帮助解释为什么出事。
这些关键指标来自哪里
体现用户体验的关键指标，可能来自多个数据源。比如 API 成功率和延迟，可能来自 RUM、APM、Prometheus 埋点、接入层 Access Logs。
不同公司的情况各异。有的公司研发人员愿意配合埋点改造，有的公司改造成本很高，所以要根据实际情况选择合适的数据获取方式。
除了 Prometheus、ElasticSearch 这类数据源，很多关键指标还可能来自 OLTP 或 OLAP 数据库，比如电商平台的订单量。
订单量是不是一个反映用户体验的指标？太是了。体验不好，用户大概率不会下单；体验好了，用户才可能顺利下单。而且订单量是终局指标，不但跟用户体验相关，还跟公司营收相关，是公司老板最看重的一类指标。
订单量这样的指标，很多公司放在 Oracle、MySQL 等事务库里，也可能导入到 ClickHouse 这类分析库里。所以，如果要建设一个监控系统，只监控 Prometheus、ElasticSearch 还不够，还需要能够读取 Oracle、MySQL、ClickHouse 当中的数据。我们做的监控系统就是对接了各种各样的数据源：
这的确是个脏活累活，但没办法，这些指标重要，值得 VIP 级别的对待。
为什么核心业务指标值得做大屏
除了支持各类数据源，我们还会为这类指标做大屏，让老板一目了然看到公司各个关键指标的变化趋势，看到各个业务系统是否健康。
运维人员经常抱怨老板不懂技术，看不到运维的付出。围绕核心业务指标的大屏，能让老板看到运维工作的部分价值：系统稳定不是抽象口号，而是订单、支付、核心接口和关键业务链路持续健康。
上面只是一个样例数据。人确实是视觉动物，好看的 UI 能让人更愿意理解数据。很多老板都希望挂这么一个大屏放到自己的办公室。
普通研发、运维人员则更直接，喜欢更简单的视图：比如总共有 6 个业务系统，只要哪个系统的关键指标异常，就飘红展示。
上文提到的这些指标，都是各个业务的核心关键指标，能反映公司营收和用户体验。那是不是只有这些指标重要，其他指标都不重要？倒也不尽然。
其他指标就不重要了吗？
原因类指标也重要，只是要放在合适的位置。
结果类指标相对可以枚举，因为系统功能可以枚举；原因类指标很难枚举，因为底层故障模式太多。机器相关指标、数据库指标、中间件指标，从业务角度看，大多都是原因类指标。
如果极端一点，原因类指标不配置强通知也可以。出了问题之后，有大盘能够查看这些指标，也能辅助定位。
但是真正实践的时候，一些关键的原因类指标也会配置告警。有两个原因：
- 有些指标从业务角度是原因类指标，但是从底层系统角度是结果类指标。底层系统的运维人员，需要收这类告警。
- 出了问题排障，要看的信息太多。一些重要的原因类指标可以提前配置告警，这些指标出了问题会生成告警事件，这些告警事件可以看做是从海量数据中的一个精华洞察，加速排障过程。从这个角度出发，这些原因类指标是需要生成事件的，但未必要发送告警通知，需要的时候能够查到就行了。
这里有一个实用边界：原因类指标可以进入事件中心，帮助排障；但是否要电话、短信、IM 强通知，要看它是否直接对应负责团队的行动。
配置告警时可以按什么顺序做
建议按下面的顺序梳理，而不是先从机器模板开始堆规则。
- 先列出用户关键路径：浏览、登录、下单、支付、退款、查询、写入、读取、转发等。
- 为每条关键路径找结果类指标：成功率、错误率、延迟、吞吐、业务量、终局业务结果。
- 确认指标来源：RUM、APM、Prometheus、Access Logs、数据库、分析库，哪个成本最低、口径最可靠。
- 再补关键原因类指标：主机、网络、数据库、中间件、存储、队列等会显著影响结果的底层信号。
- 区分事件和通知：有些指标只需要生成事件，方便故障时查看；真正需要打扰人的告警，必须和用户影响或明确责任动作绑定。
FAQ
Q1：是不是 CPU、内存、磁盘、网络告警就不重要了？
不是。这些指标仍然重要，但它们通常是原因类指标。它们应该服务于排障和底层系统维护，而不是天然盖过用户体验和核心业务指标。
Q2：订单量为什么也算监控指标？
订单量能反映用户体验和业务结果。体验不好，用户可能无法完成下单；链路异常，也可能直接造成订单量下降。它不是传统基础设施指标，但它是非常关键的业务健康指标。
Q3：原因类指标要不要发送告警通知？
要看场景。对底层系统团队来说，某些原因类指标就是他们负责的结果类指标，需要通知。对业务团队来说，很多原因类指标更适合沉淀为事件，等结果类指标异常时用于快速排障。
结论
告警治理的根本问题，不是规则数量够不够，而是优先级是否正确。
如果只盯着机器的 CPU、内存、磁盘、网络，很容易把大量注意力花在底层信号上，却没有第一时间看到用户体验和核心业务结果是否受损。
真正重要的告警，应该从用户视角和业务结果倒推：用户能不能完成关键操作，核心链路是否稳定，关键业务指标是否异常。原因类指标仍然要保留，但它们的价值主要是帮助解释问题、加速排障，而不是制造更多无差别打扰。
