前一篇讲的是监控项和触发器。触发器把数据解释成问题，告警配置则决定这个问题要不要通知、通知谁、什么时候通知、通过什么渠道通知、恢复时怎样收口。很多团队把告警建设理解成“接上邮件、企业微信、钉钉或短信”，这只是最后一公里。真正困难的是告警治理：让正确的问题在正确时间到达正确的人，并且不会把值班人员淹没。

本文以 Zabbix 7.x 当前官方通知机制为准，围绕事件、动作、媒介、用户、升级、恢复、抑制和验收展开。目标不是罗列界面按钮，而是给出一套可落地的告警设计方法。读完后，你应该能设计一条从触发器到通知渠道的完整链路，并能说明为什么某类告警立即通知、某类告警延迟通知、某类告警只进入工单、某类告警在维护窗口被抑制。

这条链路可以拆成四层。第一层是事件来源，通常来自触发器状态变化，也可能来自发现、自动注册或内部事件。第二层是动作规则，负责用条件筛选事件。第三层是操作，负责发送消息、升级、恢复通知或执行受控动作。第四层是媒介和用户，负责把消息真正送到邮箱、IM、工单系统或值班平台。

告警不是事件的同义词

在 Zabbix 里，触发器状态从 OK 变为 PROBLEM 会产生问题事件，问题恢复时会产生恢复事件。事件是系统事实，告警是动作规则对事件做出的通知行为。不是每个事件都必须通知，也不是每个通知都等于新的故障。这个区分非常重要。

如果把事件和告警混为一谈，平台会很快失控。比如磁盘增长趋势异常可以产生事件，但不一定需要半夜短信；测试环境服务重启可以产生事件，但可能只进入工作时间日报；生产核心数据库复制中断则需要立即通知并升级。告警设计的重点，是把事件按影响、紧急度、责任人和处置路径分流。

Zabbix 告警生命周期

一个告警生命周期通常包括问题产生、通知发送、确认、更新、升级、恢复和复盘。Zabbix 官方文档把通知建立在 media 和 action 之上：要发送和接收通知，需要先定义媒介，再配置把消息发送到某个媒介的动作。动作由条件和操作组成，条件满足后执行操作。

动作规则的核心是过滤

Zabbix Action 三段式配置

动作不是“所有问题都发出去”的开关，而是告警路由规则。动作条件可以基于严重级别、主机组、主机、触发器、标签、维护状态、时间等维度筛选。一个成熟环境通常不会只配置一个总动作，而是按生产环境、测试环境、业务系统、基础设施、网络、数据库和平台内部事件拆分。

设计动作时，先问三个问题。第一，这类问题由谁负责处理。第二，这类问题在什么时候需要通知。第三，这类问题需要什么渠道。比如生产数据库 High 级别问题应通知 DBA 值班组和平台组；测试环境 Warning 可以只在工作时间通知系统负责人；Zabbix Server 自身异常应通知平台管理员；自动注册事件可以只发到平台运维频道。

动作条件要避免过宽。以“严重级别 >= Warning”为条件发给所有人，短期很省事，长期会造成告警疲劳。更稳妥的做法是使用主机组和标签组合，例如 env=prod、team=network、service=erp、symptom=availability。这样告警路由可以跟随模板和主机标签，不需要为每个触发器单独维护通知规则。

动作还要考虑维护状态。计划变更、补丁窗口、批量重启和机房割接期间，如果告警动作没有正确处理维护窗口，值班渠道会出现大量已知噪音。Zabbix 操作中存在针对 suppressed problems 和 symptom problems 的暂停选项，实际配置时要明确：维护期间的问题是完全不通知，还是维护结束后补发，还是只发到变更频道。

媒介类型和用户媒介

Zabbix 通知渠道与媒介类型

媒介类型定义“怎么发”，用户媒介定义“发到哪里”。官方文档强调，即使动作配置了某个用户，如果该用户资料里没有对应媒介的发送目标，通知也会失败。例如动作要通过 Webhook X 发给 Admin，但 Admin 用户没有定义 Webhook X 的发送信息，消息不会成功投递。

Email 适合低紧急度、可归档、需要较完整上下文的通知。它的优势是保留历史和跨团队转发，缺点是实时性差，夜间值班依赖邮件并不可靠。短信或电话适合少量高优先级告警，不适合承载所有问题。企业微信、钉钉、飞书、Slack、Teams 等 IM 适合团队协作，但如果没有分频道、分严重级别和分业务系统，也会变成噪音池。

Webhook 是现代告警集成的主力。官方文档说明，Webhook 媒介可以使用自定义 JavaScript 发起 HTTP 调用，也可以导入 Zabbix 提供的集成模板，对接 Jira、ServiceNow、Opsgenie、PagerDuty、Slack、MS Teams 等系统。Webhook 的重点不是“能发出去”，而是要能处理失败、重试、鉴权、消息格式、事件更新和恢复。

用户媒介要按职责配置。个人用户用于个人通知，值班组用户用于团队通知，Webhook 机器人最好使用专门用户表示。对于会写入工单 ID 或消息 ID 的 Webhook，不建议把同一个媒介随意挂到多个用户上，否则事件更新和恢复时可能找不到正确上下文。专用用户还需要有对应主机的读权限，否则 Zabbix 不会向它发送相关主机的通知。

邮件通知的适用边界

Zabbix 邮件告警配置流程

邮件配置一般包括 SMTP 媒介、用户邮箱、动作操作和消息模板。Zabbix 当前版本支持 Generic SMTP、Gmail、Office365 等配置方式。生产环境要关注四件事：SMTP 认证安全、发件人可信度、邮件线程聚合、失败重试。

邮件主题要稳定，正文要包含足够上下文。最基本的信息包括事件状态、严重级别、主机名、主机组、触发器名称、当前值、发生时间、事件 ID、标签、处置提示和 Zabbix 链接。不要只发“CPU 过高”这种短消息，否则接收者还要回到平台查询上下文。也不要把大量无关宏全部塞进邮件，信息过多同样会降低可读性。

邮件适合审计和复盘，因此恢复通知也很重要。问题邮件和恢复邮件应该能通过事件 ID 对上，恢复邮件应说明恢复时间、持续时长和当前值。如果告警进入工单系统，邮件可以作为旁路归档，而不是主要处置入口。

Webhook 与企业协作平台

企业微信 Webhook 通知

Webhook 集成要按工程方式处理。首先，密钥和 token 不应写在文章、截图或公开模板里，应放在媒介参数、密钥管理系统或受控配置中。其次，Webhook 消息要区分 problem、recovery、update，不同状态使用不同标题和颜色。第三，发送失败要能在 Zabbix media test、alerter 日志或外部平台日志里定位。

官方 Webhook 测试功能要求测试时替换宏，否则宏不会解析，测试可能失败。这个细节在排障时很常见：媒介测试失败并不一定代表动作失败，可能是测试参数没有填写真实值；动作失败也不一定代表 Webhook 脚本错误，可能是用户媒介、权限、动作条件或外部 API 限流导致。

企业协作平台里的消息应该服务处置。建议包含：告警标题、环境、业务系统、主机、严重级别、当前值、开始时间、持续时间、事件链接、处置建议、负责人或值班组。对于恢复消息，建议明确“已恢复”并附持续时长。对于更新消息，建议说明是谁确认、谁评论、严重级别是否变化。

如果对接工单系统，事件 ID 是关键。创建工单时要把 Zabbix EVENT.ID 或等价标识写入外部系统，恢复或更新时再用这个 ID 找回原工单。否则同一个问题会不断创建新工单，恢复时也无法自动关闭。Webhook 脚本还要处理幂等性，避免 Zabbix 重试导致重复创建。

升级策略

Zabbix 告警升级策略

官方文档说明，escalation 可以创建自定义通知或远程命令场景，可以立即通知、重复通知、延迟通知、升级到更高用户组。升级基于步骤，每个步骤有持续时间，第一步用于立即动作，延迟动作可以放到后续步骤。升级只支持 problem operations，不支持 recovery 的逐级升级。

升级策略要和组织值班制度一致。一个常见设计是：第 1 步立即通知一线值班组；第 2 步问题持续十五分钟仍未确认，通知二线负责人；第 3 步问题持续三十分钟仍未恢复，通知业务负责人或管理升级渠道。这里的时间不是随便定的，应来自故障响应目标和团队容量。

不要把升级设计成惩罚机制。升级的目的是让长期未处理的问题获得更多资源，而不是制造更大的噪音。升级消息里要包含前序通知、确认状态、持续时间和当前负责人。否则二线人员收到升级通知后仍然不知道一线是否已经在处理。

重复通知也要控制。对于持续性问题，可以每隔一段时间重复提醒，但频率不能过高。对于已确认的问题，可以减少重复通知；对于进入维护窗口的问题，应按维护策略抑制。对灾难级故障，可以结合电话、短信或专业值班平台，但数量应严格控制，避免把所有 High 都变成电话轰炸。

恢复和更新操作

恢复通知不是可有可无。官方文档说明，recovery operations 用于问题解决时通知用户，可以通知指定用户，也可以通知所有曾经收到问题通知的人；恢复操作不支持 escalation，多个恢复操作会同时执行。这个行为要在设计时考虑清楚。

恢复通知的价值有三点。第一，告诉值班人员问题已经结束，避免继续排查。第二，给复盘提供持续时间和恢复路径。第三，关闭外部工单或更新 IM 消息状态。如果只发问题不发恢复，团队会不断回到 Zabbix 前端确认状态，外部协作系统也会留下大量未闭环消息。

Update operations 适合把确认、评论、手动关闭、严重级别变化等信息同步出去。比如值班人员确认问题并写下“数据库主库切换中”，这个更新可以发到同一个 IM 线程或工单系统，让其他人知道问题已有负责人。更新通知不应太泛滥，可以只对 High 以上问题或关键业务启用。

告警依赖和抑制

告警依赖与抑制

告警抑制不是简单静音，而是把已知上下文纳入通知规则。依赖关系可以减少下游症状告警，维护窗口可以抑制计划内变更噪音，动作条件可以排除测试环境或低优先级事件，标签可以把同类问题送到正确频道。

例如核心交换机故障时，下游几十台服务器不可达。此时应让交换机不可达作为根因告警，下游主机不可达作为症状问题被抑制或降低通知优先级。再例如数据库计划维护期间，应用连接失败可能是预期现象，动作应识别维护状态，避免把计划变更变成事故告警。

但抑制有风险。过宽的维护窗口会掩盖真实故障，错误的依赖关系会隐藏独立问题，动作条件写错会让关键告警没人收到。因此每条抑制规则都要可解释、可复审、可验证。维护窗口应有负责人、原因、时间范围和影响对象；依赖关系应有拓扑依据；动作条件修改后必须做模拟测试。

消息模板

消息模板决定接收者能否快速行动。一个好的 Problem 模板至少包含状态、严重级别、主机、业务标签、问题名称、当前值、发生时间、持续时间、事件 ID、触发器描述、Zabbix 链接和第一步处理建议。Recovery 模板应包含恢复时间、持续时长、恢复值和原事件链接。Update 模板应包含更新人、更新时间、更新内容和当前状态。

宏要谨慎使用。Zabbix 支持大量内置宏、用户宏和表达式宏，官方文档也提供了在消息中使用宏的说明。模板里要选择稳定、对处置有帮助的宏。不要把不确定是否有值的宏堆进去，也不要在外部平台消息里泄露敏感信息，例如内部 IP、密钥、账号、完整 URL token 或客户数据。

消息标题要适合搜索和聚合。建议包含状态、严重级别、业务系统和问题摘要，例如 [PROBLEM][High][MES] app-prod-001 订单接口错误率过高。恢复标题可以对应为 [RECOVERY][High][MES] ...。这样邮件线程、IM 搜索和工单列表都更容易管理。

验证和排障

告警验证与排障路径

告警配置完成后必须验证。验证不是点一下媒介 Test 就结束，而是要覆盖从触发器到外部渠道的全链路。至少要测试 Problem 通知、Recovery 通知、Update 通知、动作条件、用户媒介、用户权限、维护窗口、升级步骤和外部平台失败场景。

如果触发器已经 Problem 但没有通知，排查顺序是：动作是否启用；动作条件是否匹配；用户是否有主机读权限；用户媒介是否启用；媒介类型是否启用；媒介时间范围是否允许；严重级别是否被用户媒介勾选；外部渠道是否返回错误；Zabbix alerter 日志是否有失败记录。

如果媒介测试成功但真实告警失败，重点看动作和用户媒介。Webhook 测试成功只证明脚本和参数在测试场景可用，不代表动作条件、用户权限和宏解析都正确。如果真实告警中宏为空，说明事件上下文里没有该字段，或者宏用错了位置。

如果通知太多，先不要急着关闭动作。应该先看触发器质量、依赖关系、维护窗口、严重级别和标签路由。通知泛滥通常是上游设计问题，而不是媒介问题。直接静音会让真正重要的问题也消失。

生产落地清单

一套可交付的告警配置应包含：媒介类型清单、用户媒介清单、动作规则清单、严重级别策略、升级策略、恢复通知策略、维护窗口规则、依赖和抑制策略、消息模板、外部系统对接方式、测试记录、失败重试策略和复审周期。

交付时还要说明哪些告警会打扰人，哪些只进入工单，哪些只进入日报。值班团队最关心的是“我收到这条消息以后应该做什么”。如果告警消息不能回答这个问题，就算技术上发送成功，也不能算合格。

复审方法

告警复审建议按月或按季度进行。第一，统计告警数量、重复告警、夜间告警、无人认领告警和恢复耗时。第二，找出最吵的触发器，看它们是阈值问题、依赖问题、维护窗口问题还是系统真实不稳定。第三，检查动作规则是否仍符合组织结构，人员变动后用户媒介是否更新。第四，检查 Webhook token、SMTP 凭据和外部平台集成是否仍有效。

复审时不要只看平台数据，也要听值班人员反馈。哪些告警有帮助，哪些告警总是误报，哪些告警缺少处置上下文，哪些恢复通知没有发出，哪些工单没有自动关闭。这些反馈会反过来改进触发器、动作和消息模板。

告警分级矩阵

告警分级最好写成团队可执行的矩阵，而不是靠每个模板维护者主观判断。矩阵至少包含环境、业务影响、严重级别、通知渠道、响应时间和升级对象。这样触发器设计者、动作配置者和值班人员使用同一套语言。

例如生产环境核心业务完全不可用，可以定义为 Disaster，立即通过 IM、短信或值班平台通知一线和二线，并在十五分钟未确认时升级到业务负责人。生产环境单实例故障但有冗余，可以定义为 Average 或 High，先通知系统负责人和值班频道，观察是否自动恢复。测试环境服务异常可以定义为 Warning，只在工作时间通知系统负责人。容量趋势类问题可以先进入邮件或工单，给团队预留处理窗口。

矩阵里要明确“不通知”的场景。不是所有问题都需要实时打扰人。比如已知维护窗口内的重启、测试环境低严重级别异常、短生命周期主机退役过程中的无数据、已经被上游根因解释的症状问题，都可以不发实时通知。但不通知不等于不记录，事件仍然应该保留在 Zabbix 或进入日报，方便复盘。

分级矩阵还要和业务标签绑定。没有业务标签时，动作只能按主机组或严重级别粗分；有了 env、service、team、impact、symptom 这些标签，告警就能更准确地路由。标签维护不是告警阶段才做的，它应该从主机接入、模板设计和触发器创建阶段就开始。

工单系统联动

很多组织会把 Zabbix 告警接入 Jira、ServiceNow、GLPI、iTop、PagerDuty、Opsgenie 或内部工单系统。接入工单系统时，最重要的不是创建工单，而是事件闭环。一个问题事件应该对应一个工单，确认、更新、恢复和关闭都应该围绕同一个外部对象进行。

要做到这一点，Webhook 或脚本需要保存外部工单 ID。常见做法是把工单 ID 写入事件标签、外部系统字段或通过事件 ID 建立映射。恢复操作执行时，再根据事件 ID 找到原工单并关闭或更新状态。否则 Problem 时创建了工单，Recovery 时又找不到原工单，只能人工关闭，流程会很快失控。

工单内容也要控制粒度。一个主机 CPU 高并不一定值得创建工单，可能只需要 IM 提醒；数据库主从复制中断、备份失败、证书即将过期、核心接口不可用，则更适合进入工单系统。建议用动作条件决定哪些事件创建工单，用严重级别和标签决定工单优先级，用恢复操作决定自动关闭策略。

工单联动还要考虑重试和幂等。Zabbix 发送失败会按媒介配置重试，如果外部接口在创建成功后返回超时，重试可能创建重复工单。Webhook 设计时应使用事件 ID 做幂等键，外部系统也应支持查询已有工单。没有幂等设计的集成，在网络抖动时会制造大量重复对象。

值班协同

告警系统最终服务值班流程。值班人员收到消息后，需要知道是否自己负责、是否已经有人确认、是否需要升级、是否已有工单、是否处于维护窗口。Zabbix 的确认、评论、更新操作和外部 IM 线程可以配合使用，但前提是团队有统一规则。

建议明确四个动作。第一，确认告警，表示有人开始处理。第二，添加评论，说明初步判断或当前动作。第三，必要时升级，说明需要哪个团队介入。第四，恢复后补充结论，方便复盘。没有这些协同动作，告警消息会变成单向通知，其他人不知道处理状态。

对于跨团队问题，消息模板要提供足够上下文。网络团队需要看到源地址、目标地址、链路、设备和接口；数据库团队需要看到实例、库名、复制角色、连接数和慢查询线索；应用团队需要看到服务名、接口、错误率、发布版本和最近变更。一个通用模板无法满足所有团队，至少要通过标签和触发器说明补充专业上下文。

值班渠道也要分层。核心灾难级告警进入强打扰渠道，普通生产告警进入业务值班频道，低优先级趋势进入工单或邮件，平台内部状态进入平台运维频道。所有告警都进同一个大群，短期看透明，长期会导致每个人都学会忽略。

告警反模式

第一种反模式是“全量转发”。所有触发器都发到同一个群，所有人都能看到，表面上没有遗漏，实际责任不清、噪音巨大。解决办法是按标签、主机组、严重级别和团队拆分动作，并为每类告警设置明确负责人。

第二种反模式是“只发 Problem 不发 Recovery”。这样外部系统里看不到闭环，值班人员不知道问题是否结束，工单也无法自动关闭。恢复通知不是额外噪音，而是事件生命周期的一部分。

第三种反模式是“用通知渠道掩盖触发器问题”。触发器抖动、阈值错误、依赖缺失时，很多人会选择静音或降低通知级别。这样会把问题藏起来。正确做法是回到监控项和触发器设计，修正窗口、恢复条件、依赖和严重级别。

第四种反模式是“没有维护窗口”。计划变更期间大量告警冲击值班渠道，久而久之大家会忽略变更期间的所有告警。维护窗口应该是变更流程的一部分，并且要精确到对象、时间和原因。维护结束后还要检查是否有未恢复问题。

第五种反模式是“外部 token 无人维护”。Webhook token、SMTP 密码、机器人密钥过期后，Zabbix 仍然产生事件，但消息无法送达。媒介凭据应纳入密钥管理和定期轮换，轮换后要执行媒介测试和真实事件测试。

验收案例

以“生产订单数据库复制延迟过高”为例，可以设计一条完整告警链路。触发器来自数据库模板，条件是复制延迟持续超过阈值并达到 High。触发器标签包含 env=prod、service=mes-db、team=dba、symptom=replication。动作条件匹配生产环境、DBA 团队和 High 以上级别。

Problem 操作第一步立即发送 IM 到 DBA 值班频道，同时创建工单。消息里包含主库、从库、当前延迟、持续时间、最近采集时间、Zabbix 链接和第一步排查建议。第二步如果十五分钟未确认，通知 DBA 负责人。第三步如果三十分钟未恢复，通知业务负责人和平台负责人。Recovery 操作关闭或更新工单，并向曾经收到 Problem 的人员发送恢复消息。

验证时不能只修改触发器阈值看是否发消息。应该分别验证：标签是否匹配动作；DBA 专用用户是否有主机读权限；Webhook 是否能创建工单；恢复操作是否能关闭同一工单；维护窗口内是否按预期抑制；确认和评论是否同步到外部系统；升级步骤是否按时间执行。只有这些环节都通过，这条告警链路才算交付。

再看一个“测试环境磁盘使用率过高”的例子。触发器可以存在，事件可以记录，但动作不应夜间打扰值班人员。它可以在工作时间发邮件给系统负责人，或者进入每日报告。这样既保留了风险信息，又不会消耗高优先级响应能力。告警治理的价值就在于区分这些场景。

运行指标

告警系统本身也要被度量。建议长期观察几个指标：每日告警总量、按严重级别分布、重复告警占比、平均确认时间、平均恢复时间、无人确认告警数量、维护窗口内事件数量、通知失败数量、Webhook 失败率、工单自动关闭成功率。

这些指标能帮助团队判断告警是否健康。告警总量持续上升，可能是系统稳定性下降，也可能是新模板过重。重复告警占比高，通常说明触发器抖动或恢复条件不合理。确认时间过长，可能是责任人不清或渠道不合适。通知失败数量上升，可能是媒介凭据、外部 API 或权限变化。

运行指标不需要一开始就复杂，但必须有趋势。每次模板大改、动作规则调整、组织值班变更后，都要观察这些指标是否变化。好的告警体系不是配置一次就结束，而是持续校准。

权限和审计

Zabbix 通知受用户权限影响。官方文档说明，Zabbix 只会向至少拥有相关主机读权限的用户发送通知。这个机制经常被忽略：动作条件匹配了，用户媒介也配置了，但用户没有主机权限，最终收不到消息。因此新建专用 Webhook 用户或值班组用户时，必须同步检查用户组权限。

审计方面，媒介类型、动作、用户媒介、模板和触发器都属于关键配置。谁修改了动作条件，谁调整了严重级别，谁禁用了媒介，谁改了 Webhook token，都可能影响故障响应。重要环境应限制修改权限，并保留变更记录。对外部工单系统的写入也要有审计字段，能追溯由哪个 Zabbix 事件触发。

权限还涉及信息泄露。告警消息可能包含主机名、IP、业务系统、错误内容和链接。跨团队频道、外部 SaaS 平台和第三方短信服务都要考虑数据暴露范围。对于敏感系统，消息模板可以减少敏感字段，只保留事件链接和必要摘要，让有权限的人回到 Zabbix 查看详情。

动作设计工作表

每新增一条动作规则前，可以先用工作表把设计写清楚。第一项是事件来源，说明它来自触发器、自动发现、自动注册还是内部事件。第二项是匹配条件，列出环境、主机组、标签、严重级别和维护状态。第三项是接收对象，明确用户、用户组或专用 Webhook 用户。第四项是媒介类型，说明使用邮件、IM、短信、工单还是值班平台。

第五项是操作步骤，写清第几步发送什么消息、延迟多久、是否重复、是否升级。第六项是恢复操作，说明恢复时通知谁、是否关闭工单、是否通知所有曾经参与者。第七项是更新操作，说明确认、评论和手动关闭是否同步外部系统。第八项是验证方法，说明如何模拟 Problem、Recovery、维护窗口和外部接口失败。

这张工作表能避免动作规则在界面里越改越乱。尤其是多人维护 Zabbix 时，如果没有设计记录，后来者只能打开动作逐项猜测意图。动作规则不是孤立配置，它代表组织的响应流程，应该像模板和脚本一样纳入文档和版本管理。

上线检查点

告警动作上线前至少检查十项。媒介类型已启用；用户媒介已配置发送目标；用户有相关主机读权限；动作条件能匹配目标事件；严重级别和用户媒介勾选一致；消息模板里的宏能解析；Problem 通知能送达；Recovery 通知能送达；维护窗口表现符合预期；外部系统失败时 Zabbix 能记录错误。

上线后还要观察一个完整周期。对于生产业务，至少观察一个工作日和一个非工作时段；对于批处理和备份类告警，要覆盖一次任务执行周期；对于月结、巡检或低频任务，要安排专门测试。只在配置当天点一次 Test，不能证明真实事件链路稳定。

如果上线后发现噪音过大，先做分类而不是直接关闭。把告警分成真实故障、阈值过敏、维护窗口遗漏、依赖缺失、重复通知、消息不清六类。真实故障推动系统修复，阈值过敏回到触发器设计，维护窗口遗漏回到变更流程，依赖缺失回到拓扑建模，重复通知调整升级和恢复，消息不清修改模板。这样每一次噪音都会转化成体系改进。

恢复后还要保留复盘数据。至少记录事件开始时间、确认时间、恢复时间、通知渠道、参与人员、根因、处理动作和后续改进。没有这些字段，告警只能证明系统曾经响过，无法证明团队响应是否有效。对高优先级故障，复盘结论应反向更新触发器说明、消息模板和升级策略，并形成可追踪的改进任务事项清单。

小结

Zabbix 告警配置的目标不是“把消息发出去”，而是建立一套可解释、可验证、可复审的故障响应链路。触发器产生事件，动作筛选事件，操作决定升级和恢复，媒介负责投递，用户权限和媒介配置决定消息能否真正到达。

下一篇会进入可视化仪表盘。告警解决的是主动打扰，仪表盘解决的是持续观察。两者都依赖前面已经建立好的监控项、触发器、标签和业务语义。

参考资料