很多团队做告警治理时，都会遇到一个问题：告警到底应该配在哪里？
配在 Prometheus 指标规则上？配在日志查询规则上？配在云监控和中间件监控上？配在 APM 的接口和服务规则上？还是配在 Flashcat 灭火图卡片上？
这个问题不能简单回答“只配底层规则”或“只配灭火图”。更准确的说法是：
底层规则适合发现局部技术异常。
灭火图对象告警适合驱动故障响应。
北极星告警适合发现业务真故障。
三者不是替代关系，而是分层关系。
很多团队告警噪音大，不是因为规则引擎不够强，而是因为告警没有按照对象和响应路径组织。CPU 高、磁盘满、接口 5xx、日志 error、Pod 重启、连接池打满、数据库慢查询，每条规则单独看都有道理。但事故现场不是一条规则一条规则处理。
值班人真正需要知道的是：哪个业务或系统对象异常？影响范围有多大？该谁处理？下一步从哪里下钻？这次告警和其他告警是什么关系？
如果告警只停留在底层规则，就很难回答这些问题。灭火图对象告警的价值，不是再造一套阈值系统，而是把告警挂到可理解、可下钻、可分责的观测对象上。
底层告警的问题不是“没用”，而是太碎
底层告警不是错的。它很有必要。
主机磁盘快满、数据库主从延迟过高、Redis 内存接近上限、Kafka 消费堆积、核心接口错误率上升、服务进程异常退出，都应该告警。没有这些底层规则，很多问题会被发现得太晚。
但底层告警有一个天然问题：它们描述的是技术现象，不一定描述故障对象。
比如“CPU 使用率 > 90% 持续 5 分钟”。这条告警告诉你某台机器忙，但没有直接告诉你：这台机器属于哪个业务，运行了哪些服务，是否影响核心接口，是不是正常批任务导致，应该通知基础设施团队还是业务研发团队。
再比如“接口 5xx 数量超过阈值”。它告诉你某个接口出错，但如果告警消息没有对象上下文，值班人还要继续判断：这是哪个系统的接口，是否属于核心交易链路，关联哪些服务和组件，能不能直接看到日志和 Trace，是否已经影响订单量或支付成功率。
底层告警越多，这个问题越明显。每个规则都在喊，但没人告诉你这些声音对应的是同一个故障，还是多个独立问题。这就是告警疲劳的来源之一。
不是告警没有价值，而是告警缺少对象化组织。
灭火图对象告警解决的是响应入口
灭火图把系统拆成观测对象。这些对象可以是接口、微服务、中间件实例、数据库集群、网络链路、Kubernetes 工作负载、业务系统、基础设施区域。
每个对象有自己的健康状态。绿色代表健康，红色代表异常，灰色代表未知或无数据。底层详情卡片的异常会向上聚合到分组卡片和首页卡片。
普通底层规则问的是：某个指标是否超过阈值？
灭火图对象问的是：这个观测对象当前是否健康？
一条“支付接口卡片飘红”的告警，比一条“http_requests_error_rate > 5%”更适合故障响应。因为它已经告诉值班人：异常对象是支付接口，它属于哪个系统和分层，它关联哪些健康指标，它可以下钻到哪些日志、Trace、仪表盘和事件，它的上层系统和上下游对象是否也被影响。
底层规则发现信号，对象告警组织信号。故障响应更需要后者作为入口。
Flashcat 灭火图告警不是重复写阈值
很多人第一次理解灭火图告警时，会以为又要在告警规则里重新配置一遍阈值。不是这样。
Flashcat 灭火图告警由两部分共同决定。
第一，卡片的异常条件。异常条件配置在详情卡片上，通常来自卡片规则。比如接口卡片的成功率低于 95%、P99 高于 2 秒、流量低于某个阈值，MySQL 卡片的连接数、慢查询、可用性指标异常。这些条件决定卡片是否飘红。
第二，告警规则。告警规则不再重复配置异常条件，而是选择要关联哪些灭火图卡片，以及告警的生效时间、通知规则、发送控制等。
卡片负责判断对象是否异常。
告警规则负责决定异常时是否通知、通知谁、什么时候通知。
这个设计很重要。如果阈值散落在大量独立告警规则里，团队很难维护“对象健康”的统一定义。同一个支付接口，可能有成功率告警、延迟告警、日志错误告警、Trace 错误告警、流量告警。它们各自触发，但没人维护“支付接口这个对象是否健康”。
灭火图把这些条件收敛到卡片上。告警规则只围绕卡片树选择通知范围。选中某个父节点时，它下面的所有子卡片都生效，后续新增的子卡片也会自动纳入告警范围。
服务会新增，接口会新增，Pod 会变化，数据库实例会扩缩容，Kubernetes 工作负载会调整。如果每新增一个对象都手工复制告警规则，很快就会失控。用卡片规则生成对象，用异常条件定义健康，用告警规则选择对象范围，才是可维护的方式。
哪些告警适合继续留在底层规则
对象告警有价值，但不是要删掉所有底层规则。下面几类告警仍然适合保留在底层：
平台级基础设施：监控系统不可用、采集链路中断、存储集群异常、NTP 时钟异常。
资源容量和安全边界：磁盘空间、证书过期、云资源配额、备份失败、安全策略异常。
底层组件强故障信号：数据库主库不可用、Redis 切换失败、Kafka broker 掉线。
采集和数据质量：采集器离线、日志写入中断、Trace 采样异常、指标数据延迟。
平台团队运维规则：数据库、网络、Kubernetes 团队自己的专业维护规则。
判断原则很简单：它是否需要在对象健康变化前被处理？是否属于平台团队的专业职责？是否能明确指向一个底层风险？如果是，保留底层规则合理，但它不一定适合作为业务故障响应的主入口。
哪些告警更适合配置在灭火图对象上
面向业务和系统稳定性的告警，更适合配置在灭火图对象上，尤其是这些对象：
接口和服务：下单接口、支付接口、登录接口、订单服务、库存服务。
标准组件：MySQL、Redis、Kafka、Elasticsearch、Doris。
Kubernetes 工作负载：deployment、statefulset、pod group、namespace 下的核心服务。
业务系统：交易系统、支付系统、会员系统、门店系统、风控系统。
核心链路：支付通道、库存扣减、订单创建、消息消费、第三方依赖。
判断原则是：值班人收到告警后，能不能直接知道影响对象？能不能进入统一排障入口？能不能看到上下游和影响范围？能不能下钻到指标、日志、链路和事件？如果能，就应该优先考虑灭火图对象告警。
告警分层：北极星、灭火图和底层规则
一个成熟的 Flashcat 告警体系，可以分成三层。
第一层，北极星告警。它关注业务或系统的核心指标，比如订单量、支付成功率、在线用户数、设备在线率、报单量、行情延迟。北极星告警意味着业务可能出现真故障，适合通知业务值班、SRE 负责人和相关技术团队。
第二层，灭火图对象告警。它关注接口、服务、组件、基础设施对象是否健康。灭火图告警是技术排障的主入口，适合通知对象负责人、系统值班人和一线 SRE。
第三层，底层规则告警。它关注具体技术指标、日志模式、平台组件和资源风险。底层告警适合通知专业团队，或作为对象健康判断的输入。
比如支付成功率下降。北极星先告警，说明业务受影响。支付接口和第三方支付通道灭火图卡片飘红，说明异常对象在哪里。底层规则显示某个通道超时、日志返回码异常、Trace 耗时升高，说明技术证据是什么。
这时团队收到的不是一堆互不相关的告警，而是一条有层次的故障链：业务异常、对象异常、底层证据。
对象告警可以减少噪音，但前提是对象建模正确
把告警配到灭火图对象上，不会自动解决所有噪音。如果对象建模不合理，噪音仍然会存在：对象太粗，告警很难定位；对象太细，值班人仍会被淹没；异常条件太敏感，低峰期 P99 抖动和短暂数据缺失都会飘红；级别不区分，轻微延迟和核心不可用都发 Critical，团队迟早会麻木。
对象告警要配好，关键不只是“告警规则选哪些卡片”，而是卡片本身要设计好：
对象边界要清楚：一张详情卡片对应一个能被理解、负责、排查的对象。
健康指标要聚焦：只放能判断该对象健康的关键指标。
异常条件要有业务含义：成功率、请求量、P99、可用性、堆积、错误率、延迟、存活状态。
阈值要考虑波动：周期性强的指标可以用动态阈值。
层级要合理：详情卡片异常能上浮到分组卡片和首页卡片。
Flashcat 灭火图支持基于历史数据计算动态阈值，延迟类指标还可以关联流量指标减少低峰期抖动误报。对象建模做好以后，告警噪音才有机会真正下降。
告警规则应该围绕负责人和响应路径配置
灭火图告警规则选择的是卡片范围。这意味着告警规则应该围绕责任边界配置。
交易系统接口层卡片通知交易值班群，支付通道卡片通知支付团队和 SRE，MySQL 组件层卡片通知数据库团队，Kubernetes 基础设施层卡片通知平台团队，核心首页卡片通知稳定性值班。
不要把所有卡片都绑定到一个大群，也不要为每张卡片单独建规则。前者会把对象告警重新变成噪音，后者会让维护成本失控。
更好的方式是按分层、业务线、团队责任、告警等级配置：
核心交易链路 Critical 告警，通知 7x24 值班。
普通接口 Warning 告警，通知业务研发群。
组件层 Critical 告警，同时通知业务值班和平台团队。
基础设施 Warning 告警，只通知平台团队。
北极星业务指标异常，通知业务负责人、SRE 和相关系统负责人。
告警治理的本质不是少发消息，而是把正确的异常，在正确的时间发给正确的人，并带上正确的排障入口。
生效时间和屏蔽机制要分清
告警噪音里有一部分来自时间。Flashcat 灭火图里有两类时间控制：
异常条件生效时间：控制卡片是否飘红。
告警规则生效时间：控制卡片飘红后是否通知。
如果某个对象在非服务时间内不需要被认为异常，就调整异常条件生效时间。如果对象仍应记录异常，只是不需要夜间通知某些人，就调整告警规则生效时间。
维护、压测、演练或已知故障，应该使用异常屏蔽。灭火图支持按卡片或规则屏蔽；屏蔽对象可以选择父节点，后续新增子节点也会生效，也可以按异常等级或指标名称屏蔽特定元素。
这些机制能减少很多无效告警，但前提是团队把它们当成告警治理的一部分，而不是事故发生后临时手工静音。
告警消息应该带排障入口
告警消息如果只有一句“某指标超过阈值”，价值很有限。值班人还要自己打开平台、找空间、找图、找卡片、查时间范围、搜日志、找 Trace，每一步都会消耗时间。
灭火图对象告警应该直接带出排障入口：对象名称、所属空间和分层、异常条件、触发时值、告警级别、详情链接、指标趋势截图、AI 分析入口。
Flashcat 灭火图告警支持在 IM 消息中附带卡片指标截图，也可以附带 AI 分析按钮。点击后，FlashAI 可以基于异常卡片的指标、日志、链路等下钻数据输出原因和建议。
告警不应该只是“提醒你出事了”。它应该是“把你带到排障现场”。对象上已经挂好下钻路径，告警消息只要把人带到对象，就能继续进入指标、日志、Trace、事件、仪表盘和 AI 分析。
一个电商系统的告警设计示例
假设要为一个电商系统设计告警，可以按三层来做。
第一层，北极星。配置实时下单量、支付成功率、订单创建成功率、核心接口成功率、在线用户数等指标。这些指标异常时，说明业务可能受影响。告警应该通知业务值班、SRE 负责人和核心系统负责人。
第二层，灭火图。按功能接口、微服务、标准组件、基础设施四层建对象：下单接口、支付接口、订单服务、库存服务、MySQL、Redis、Kafka、Kubernetes 集群、网关、DNS、CDN、机房网络。
告警规则按责任范围配置：接口和服务告警给业务研发与 SRE，组件告警给平台团队并抄送受影响系统负责人，基础设施告警给平台团队，核心首页卡片 Critical 告警给稳定性值班。
第三层，底层规则。保留磁盘容量、证书过期、采集器离线、数据库主从异常、消息队列 broker 异常、监控平台自身异常等规则。这些规则不一定都进业务群，但应该通知对应平台负责人。
这样做以后，事故现场的告警链路会更清楚：支付成功率下降，北极星告警；支付接口卡片飘红，灭火图告警；第三方支付通道卡片飘红，指向可能根因；底层规则补充通道超时、日志返回码异常、Trace 耗时升高等证据。
值班人不是从几十条底层告警里猜，而是从业务影响进入对象，再从对象进入证据。
怎么判断告警应该放哪一层
可以用几个问题判断。
第一，这条告警是否直接代表业务受影响？如果是，优先放北极星，比如订单量下降、支付成功率下降、在线用户数异常、设备在线率下降。
第二，这条告警是否代表一个可负责、可排查的系统对象不健康？如果是，优先放灭火图对象，比如支付接口异常、订单服务异常、Redis 集群异常、某个网络链路异常。
第三，这条告警是否是底层平台风险，需要专业团队提前处理？如果是，保留底层规则，比如磁盘容量、证书过期、采集器离线、数据库复制异常。
第四，这条告警收到后，值班人能否直接行动？如果不能，就要补对象上下文、负责人、下钻链接或调整规则。
第五，这条告警是否经常与其他告警同时出现？如果是，要考虑它是不是应该被对象告警聚合，或者作为对象健康条件之一，而不是单独通知所有人。
第六，这条告警是否在低峰、维护、已知活动期间频繁误报？如果是，要调整动态阈值、生效时间、服务日历或屏蔽规则。
告警位置只是手段，真正的目标是让告警能驱动正确响应。
告警治理的验收标准
告警治理不能只看数量有没有减少。数量减少不一定代表治理成功。有些团队为了降噪，直接关掉大量规则，短期安静了，故障发现能力也下降了。
更好的验收标准是：
核心业务异常是否能被北极星及时发现。
业务告警是否能下钻到对应灭火图对象。
灭火图对象告警是否能清楚表达影响对象和责任团队。
告警消息是否带指标截图、详情链接和 AI 分析入口。
底层告警是否按平台责任收敛，而不是全部推给业务值班。
重复发送、级别抑制、生效时间、异常屏蔽是否被正确使用。
新对象上线后，是否能通过卡片规则和父节点告警自动纳入告警范围。
复盘时能否从告警链路还原业务异常、对象异常和底层证据。
如果这些都做到了，告警数量可能不一定最少，但告警质量会明显提高。值班人不再是被规则轰炸，而是沿着对象和排障路径处理问题。
结语：告警不是阈值集合，而是响应体系
监控告警不应该只理解成“某个指标超过阈值就发消息”。这是最基础的一层。
真正有效的告警体系，要能回答：谁受影响？哪个对象异常？该通知谁？下一步看哪里？这条告警和业务影响、上下游对象、底层证据是什么关系？
底层规则能发现很多技术信号，但它们太碎。灭火图对象告警把这些信号组织成系统对象，让告警变成排障入口。北极星再从业务健康层面判断是否出现真故障。
所以，监控告警不是应该“配在底层”还是“配在灭火图”二选一。更好的答案是：
底层规则保留专业信号。
灭火图对象承接故障响应。
北极星指标发现业务影响。
Flashduty 或告警值班流程负责通知、升级和闭环。
如果你正在治理告警，建议拿最近一周的 Critical 告警做一次梳理：哪些是真正业务影响？哪些应该变成北极星指标告警？哪些应该收敛到灭火图对象？哪些只是底层平台团队内部规则？哪些缺少下钻路径、截图或 AI 分析入口？哪些需要动态阈值、生效时间或屏蔽规则？
梳理完以后，再决定规则放在哪里。
可以预约一次告警治理评估，带上现有告警规则列表、核心系统灭火图、最近几次故障告警记录和通知群配置，一起设计哪些告警该保留在底层，哪些该迁移到灭火图对象，哪些该上升为北极星业务健康告警。
