前一篇完成 Agent 接入后，Zabbix 才真正有了稳定的数据来源。接下来要解决的问题不是“能不能采到值”，而是“采什么、多久采一次、怎样解释、什么时候算异常、异常是否值得通知”。这就是监控项和触发器的职责。

监控项决定数据进入 Zabbix 的方式，触发器决定数据变成问题事件的条件。很多监控平台后期变得难用，不是因为工具能力不够，而是因为监控项设计太随意、触发器表达式太粗糙、阈值无法解释、预处理缺失、依赖关系没有建立。结果就是数据很多，告警也很多，但真正能帮助定位故障的信息反而很少。

本文按照 Zabbix 7.x 的官方概念和当前生产实践来讲。重点不是把所有 item type 和函数逐个背一遍，而是建立一套可复用的设计方法：从目标开始定义指标，从数据类型决定保留周期，从预处理减少脏数据，从触发器表达式表达故障语义，从依赖和严重级别减少噪音，最后用验收方法证明配置有效。

这条链路里每一步都可能出错。采集项错了，后面再漂亮的触发器也没有意义；预处理错了，历史数据会变脏；触发器太敏感，告警会泛滥；依赖关系缺失，上游故障会变成告警风暴。设计监控项和触发器，本质上是在设计运维团队如何理解系统状态。

从监控目标开始

不要从“Zabbix 能采什么”开始，而要从“这个对象需要被怎样保障”开始。服务器、数据库、网络设备、业务接口、消息队列、备份任务，它们的监控目标并不一样。服务器关注资源余量和系统稳定性；数据库关注连接、锁、复制、慢查询和容量增长；网络设备关注端口状态、丢包、错误包和链路利用率；业务接口关注可用性、延迟、错误率和返回语义。

一个监控项只有能支撑判断或排障，才值得进入模板。比如 CPU 使用率本身只是一个现象，结合负载、进程数、上下文切换、I/O 等待和业务延迟，才可能解释系统压力来源。磁盘使用率也不是越多越好，根分区、数据分区、日志分区、临时目录的阈值和影响完全不同。把所有能采的值都采回来，只会增加数据库压力和维护成本。

实践中可以把指标分成四类。第一类是可用性指标，例如 Agent ping、端口连通、进程存活、HTTP 状态码。第二类是容量指标，例如磁盘空间、内存、连接数、队列长度。第三类是性能指标，例如延迟、吞吐、I/O 等待、数据库查询耗时。第四类是错误指标，例如日志错误数、接口失败率、复制中断、备份失败。不同类别的指标需要不同的采集周期和触发器策略。

监控项的结构

监控项的基本结构

一个监控项至少要明确名称、类型、key、数据类型、更新间隔、历史保留、趋势保留、单位、预处理和应用模板归属。官方文档说明，item 用于指定从主机采集哪类数据，key 用来定义具体指标，例如 system.cpu.load 采集处理器负载，net.if.in 采集网卡流入流量。key 可以带参数，参数放在方括号中。

名称面向人读，key 面向系统执行。名称应该让运维人员在告警里一眼知道对象和语义，例如“根分区使用率”比“vfs.fs.size[/,pused]”更适合显示；key 则必须严格、唯一、可执行。不要在名称里放太多临时说明，也不要让 key 承担解释职责。解释应放在模板描述、监控项说明和运维文档中。

数据类型决定后续处理方式。数值型指标可以做趋势、阈值、预测和图表；字符和文本适合状态描述，但不适合频繁触发复杂告警；日志型适合少量关键错误，不适合替代日志平台。采集周期要结合指标变化速度和处置时效决定。CPU、接口流量、队列深度可能需要一分钟级；容量增长和证书有效期可以低频；配置状态类指标不应高频采集。

历史和趋势保留也不是默认值越大越好。原始历史数据用于近期排障，趋势数据用于长期容量分析。高频 item 如果保留时间过长，会显著增加数据库体积。一个常见策略是：关键性能指标保留较短原始历史和较长趋势，低频容量指标保留更长历史，临时诊断指标在问题解决后禁用或删除。

Key 参数和命名规范

键值 Key 与 UserParameter

Zabbix 官方 key 格式要求 key 名称由数字、大小写字母、下划线、短横线和点组成，参数放在方括号里。参数可以是带引号字符串、不带引号字符串或数组。参数中如果包含逗号或特殊字符，就要按官方规则使用双引号和转义。这个细节在文件路径、Windows 服务名、日志匹配和自动发现宏里很常见。

内置 key 应优先使用官方模板和官方 key，不要为已有能力重复写 UserParameter。比如 CPU、内存、磁盘、网络、进程数、服务状态，官方模板通常已经覆盖。自定义 key 应只用于业务语义明确、官方模板无法覆盖、返回值稳定的场景。每个自定义 key 都要有负责人、脚本路径、返回类型、超时策略和测试方法。

命名上建议使用分层语义，例如 app.health、app.queue.depth[name]、backup.last_status[job]。不要使用 test1、check.sh、custom.value 这类无法解释的 key。key 一旦进入模板并产生历史数据，后续改名会影响图表、触发器和历史连续性，所以命名要在上线前审查。

预处理不是装饰

数据预处理流水线

官方文档说明，预处理会在值写入数据库前对 item value 进行转换，步骤由 Server 或 Proxy 执行，多个步骤按配置顺序执行。它可以用于单位换算、每秒变化率、正则提取、JSONPath、JavaScript、自定义失败处理、丢弃未变化值等场景。

预处理的第一类价值是把原始数据转换成可判断的数据。比如接口返回 JSON，真正需要的是 $.status 或 $.latency_ms；网络计数器不断递增，真正需要的是每秒速率；磁盘容量返回字节，图表和阈值更适合使用百分比或统一单位。没有预处理时，触发器往往会写得复杂，而且不同模板之间口径不一致。

第二类价值是减少脏数据。很多脚本在异常时会返回空字符串、错误文本或 HTML 错误页，如果直接入库，后续触发器会出现不可预测行为。预处理可以检查类型、提取字段、在失败时丢弃值或设置自定义错误。这里要谨慎：丢弃值能减少噪音，但也可能掩盖真实故障。关键指标应保留一个能反映采集失败的状态 item。

第三类价值是控制数据库压力。对于不频繁变化的状态值，可以考虑丢弃未变化值；对于一次 HTTP 或脚本调用返回多个字段的情况，可以使用一个 master item 加多个 dependent item，用预处理拆分字段。官方文档说明 dependent item 依赖 master item，master item 新值会自动填充 dependent item，这对 API 类采集非常有用。

预处理也会带来成本。复杂 JavaScript、频繁 JSONPath、大量 dependent item 都会消耗 Server 或 Proxy 的预处理能力。模板设计时要看预处理队列和 worker 负载，尤其是在大规模 Proxy 场景里。不要把本该在采集端做的复杂计算全部推给 Zabbix 预处理。

触发器表达式表达故障语义

触发器表达式结构

官方文档说明，触发器是对 item 数据进行评估的逻辑表达式，用于表示当前系统状态。简单表达式的形式类似 function(/host/key,parameter)<operator><constant>。例如 min(/Zabbix server/net.if.in[eth0,bytes],5m)>100K 表示五分钟窗口内的最小值仍然超过阈值。

写触发器时，不要只问“阈值是多少”，要问“什么现象足以代表需要处理的问题”。last()>90 很容易写，但它只看最新值，容易被瞬时尖峰触发。min(5m)>90 表示五分钟内持续高于阈值，语义更接近“持续异常”。avg(10m)>80 适合平滑负载类指标，max(5m)>95 适合捕捉短时峰值，nodata(5m)=1 适合判断数据中断。

触发器表达式应尽量使用时间窗口，而不是单点值。单点触发适合明确状态，例如服务进程为 0、备份状态失败、接口返回不可用；资源类和性能类指标更适合时间窗口。窗口长度要结合业务容忍度，不能为了减少告警随意拉长。五分钟窗口对普通服务器可能合理，对核心支付接口可能太慢，对证书过期则完全没有必要。

恢复条件也要认真设计。很多抖动来自触发和恢复使用同一个阈值，例如 CPU 大于 90 告警，小于等于 90 恢复，指标在 89 到 91 之间抖动就会反复通知。可以使用恢复表达式或滞后设计，例如超过 90 持续五分钟告警，低于 80 持续十分钟恢复。这样告警状态更贴近真实处置过程。

严重级别要和响应动作绑定

触发器严重级别

严重级别不是颜色标签，而是响应策略的输入。Information、Warning、Average、High、Disaster 等级如果没有和通知渠道、值班规则、升级策略、SLA 绑定，就只是前端显示差异。一个好的严重级别设计应该让团队看到告警后知道“谁处理、多久处理、是否需要升级、是否影响业务”。

建议把严重级别和影响范围对应起来。信息类用于记录可观察但不需要立即处理的状态；警告类用于提前干预，例如磁盘增长趋势异常；一般故障用于单机或非关键服务问题；高危故障用于影响业务冗余或核心组件；灾难级用于明确业务中断或大范围不可用。不要把所有阈值越界都设成 High，否则值班团队会失去优先级判断。

严重级别还应结合主机标签和业务标签。相同的 CPU 阈值，在测试环境和生产核心环境的通知策略不同；相同的磁盘使用率，在临时缓存分区和数据库数据分区的影响不同。Zabbix 的动作条件可以基于严重级别、主机组、标签和维护状态做路由，因此触发器设计时要提前考虑后续告警动作。

依赖关系减少告警风暴

触发器依赖关系

依赖关系用于表达“一个问题可能由另一个上游问题导致”。如果交换机下联端口断开，下面多台服务器都不可达；如果数据库主库宕机，依赖它的应用接口会失败；如果区域 Proxy 到 Server 的链路中断，一批主机都会停止上报。没有依赖关系时，运维人员会收到大量症状告警，而不是根因告警。

触发器依赖不是为了隐藏问题，而是为了让告警聚焦。上游故障未恢复时，下游触发器可以保持问题状态但不发送重复通知。依赖关系要谨慎使用，不能把真实独立问题压掉。设计依赖时要确认拓扑关系稳定、上游触发器可靠、下游问题确实可由上游解释。

依赖关系的维护成本也要考虑。静态拓扑适合手工配置或模板化配置；动态环境更适合通过自动发现、CMDB 或 API 维护。网络、虚拟化、数据库主从和应用调用链都可能需要依赖关系，但不要试图一次性把所有依赖建满。先从告警风暴最明显的链路开始，例如主机依赖机房网关、应用依赖数据库、虚拟机依赖宿主集群。

创建流程

监控项与触发器创建流程

创建监控项和触发器可以按七步走。第一步，说明监控目标，明确这个指标用于可用性、容量、性能还是错误判断。第二步，选择采集方式，优先官方模板和内置 key，必要时使用 HTTP agent、SNMP、JMX、ODBC、UserParameter 或 trapper。第三步，定义数据类型、单位、采集周期和保留策略。第四步，配置预处理，把原始值变成稳定可判断的数据。

第五步，设计触发器表达式，包含触发条件、恢复条件、时间窗口和阈值来源。第六步，设置严重级别、标签、依赖关系和说明。第七步，做验证：人为制造正常值、异常值、恢复值和无数据场景，确认事件产生、恢复和通知行为符合预期。没有验证过的触发器，只能算配置完成，不能算交付完成。

阈值来源要能解释。可以来自厂商建议、系统容量设计、历史基线、SLA、业务负责人确认或压测结果。不要把“网上常见阈值”直接复制到生产环境。比如磁盘 80% 告警对小分区可能太晚，对大容量对象存储挂载可能太早；CPU 90% 对批处理机器可能正常，对低延迟接口可能已经严重。

低级自动发现

低级自动发现

低级自动发现适合处理对象数量变化的场景，例如磁盘分区、网络接口、数据库实例、容器、队列、服务列表。通过发现规则生成 item prototype、trigger prototype 和 graph prototype，可以减少手工维护成本。

LLD 的关键不是“自动发现越多越好”，而是过滤。网络接口里可能有虚拟网卡、临时接口、隧道接口；文件系统里可能有临时挂载、只读镜像、容器挂载；服务列表里可能有短生命周期服务。如果不做过滤，Zabbix 会生成大量无意义对象。发现规则应设置清晰的过滤条件，排除不需要监控的对象，并为不同对象设置合理宏。

LLD 生成的触发器也要控制严重级别。不是每一个接口 down 都是灾难级，不是每一个文件系统满都影响业务。可以使用用户宏按主机组或模板调整阈值，例如 {$VFS.FS.PUSED.MAX.WARN}、{$IF.UTIL.MAX}。宏让模板保持统一，同时允许不同环境微调。

自动发现还有生命周期问题。对象消失后，Zabbix 会按保留策略处理已丢失资源。这个周期要符合业务现实。太短会导致临时波动引发对象删除和重建，太长会留下大量过期对象。对于动态环境，需要结合对象命名、过滤和保留周期一起设计。

验证和排障

配置验证与排障路径

监控项没有数据时，先判断是采集失败、预处理失败、类型不匹配还是权限问题。Agent 类 item 可以在主机本地用 zabbix_agent2 -t key 验证，也可以从 Server 或 Proxy 用 zabbix_get 验证被动检查。HTTP、SNMP、JMX、ODBC 类 item 要分别检查网络连通、认证、协议版本和返回格式。

触发器不触发时，先看 item 是否有最新数据，再看表达式是否引用了正确 host 和 key，然后看时间窗口内是否真的满足条件。很多触发器不生效，是因为 item 本身 unsupported、数据类型不是数值、预处理失败导致值未入库，或者表达式使用了旧语法。触发器反复抖动时，重点检查窗口长度、恢复条件、阈值滞后和采集周期。

验证时不要只用真实故障等待触发。可以为测试主机创建临时 item 或临时宏，降低阈值模拟触发；可以让脚本返回固定异常值；可以短暂停止测试 Agent 验证 nodata；可以用维护窗口验证通知抑制。每次测试都要确认 Problem、Recovery、Event tags、Action 条件和通知渠道是否完整。

常见问题定位图

常见问题可以归成几类。第一，key 写错或参数转义错误，表现为 unsupported item。第二，采集周期和触发器窗口不匹配，例如五分钟窗口却十分钟采一次。第三，预处理把异常值丢弃，导致触发器看不到异常。第四，模板继承层级混乱，主机级修改覆盖了模板预期。第五，严重级别和动作条件不一致，触发器已经 Problem 但没有通知。

团队治理

监控项和触发器要进入模板治理，而不是散落在单台主机上。单台主机上的临时修改很难复用、审查和追踪，也容易在模板更新时丢失。通用能力放模板，差异化阈值用宏，业务例外写说明。只有确实属于单机特殊情况的配置，才放在主机级。

模板变更要有版本记录。新增 item 会增加采集压力，新增触发器会增加告警面，修改阈值会改变响应行为，删除 item 会影响历史图表和 dependent item。重要模板变更应先在测试主机组验证，再推广到生产主机组。推广后观察 Server/Proxy 性能、unsupported item 数量、告警数量和用户反馈。

每个触发器都应该有处置提示。提示不需要写成完整手册，但至少说明可能原因、第一步检查、相关系统和升级路径。告警只告诉你“出问题了”还不够，好的告警应该让值班人员知道下一步看哪里。Zabbix 支持在触发器描述中加入宏和说明，这部分内容应该纳入模板质量检查。

常见 item type 的选择

Zabbix 支持的采集方式很多，但选择时要遵循一个原则：让数据从最可靠、最接近事实、维护成本最低的位置进入系统。能由 Agent 本地采集的系统指标，就不要绕到远程脚本；能由设备 SNMP 稳定提供的接口状态，就不要在服务器上写探测脚本；能由应用 HTTP 健康接口表达的业务状态，就不要只看进程是否存在。

Zabbix agent 和 Zabbix agent (active) 适合主机本地指标。它们的差异在前一篇已经讲过：被动检查由 Server 或 Proxy 拉取，主动检查由 Agent 上报。对于普通主机基线指标，主动模式通常更适合大规模环境；对于少量需要从 Server 侧即时验证的指标，被动模式仍有价值。

SNMP agent 适合网络设备、存储设备、UPS、部分硬件管理模块。SNMP 的难点通常不在 Zabbix，而在设备侧 MIB、OID、版本、团体字或 SNMPv3 认证配置。生产环境优先使用 SNMPv3，至少要避免在跨安全区网络里使用明文团体字。SNMP item 的触发器要注意端口角色，不同接口的 down 含义不同，不能把所有端口都按核心链路处理。

HTTP agent 适合采集 HTTP API、健康检查接口、Prometheus 风格的简单文本端点或第三方系统状态。它的优势是无需在目标机器安装 Agent，适合对外部服务做黑盒检查。缺点是执行位置在 Server 或 Proxy，必须确认从执行位置到目标地址的网络路径代表真实用户或真实依赖路径。对于多区域服务，可能需要多个 Proxy 分别探测。

Calculated item 适合基于已有指标做二次计算，例如错误率、可用率、容量剩余天数的简化表达。使用计算项时要注意源 item 的采集周期和缺失值，否则计算结果可能滞后或为空。不要把过于复杂的业务计算放进 Zabbix，复杂分析应交给数据平台或专门的可观测性系统。

Dependent item 适合“一次采集，多处拆分”。例如一个 HTTP API 返回主机多个服务状态，一个数据库查询返回多个计数器，一个脚本输出 JSON。master item 负责采集原始数据，dependent item 通过 JSONPath、正则或 JavaScript 拆字段。这样可以减少请求次数，降低目标系统压力，也让相关指标在同一时间点采集。

Trapper item 和 zabbix_sender 适合由外部系统主动推送数据，例如批处理任务结束状态、部署流水线结果、备份系统任务状态。它的风险是 Zabbix 不主动采集，数据发送失败时容易沉默。因此 trapper 类指标通常要配合 nodata() 触发器，确认数据按预期到达。

宏和模板阈值

模板要复用，阈值要可调，这两件事靠用户宏连接。直接在触发器里写死 90、80、5m，短期看方便，长期会导致模板难以适配不同环境。更好的做法是把阈值写成宏，例如 {$CPU.UTIL.MAX}、{$VFS.FS.PUSED.MAX.WARN}、{$SERVICE.RESPONSE.MAX}，在模板层给默认值，在主机组或主机层覆盖特殊值。

宏的命名要表达对象、指标和用途。{$WARN} 这种宏无法维护，{$VFS.FS.PUSED.MAX.WARN} 就清楚得多：文件系统、已用百分比、最大警告阈值。对于同一个指标的不同严重级别，可以使用 WARN、HIGH、DISASTER 后缀。对于恢复阈值，可以使用 RECOVERY 或单独说明，避免触发和恢复混在一起。

宏覆盖要有边界。模板层保存通用默认值，主机组层保存环境差异，例如生产、测试、灾备；主机层只处理个别例外。大量主机级宏会让模板失去统一性，也会让后续阈值审计变得困难。每个主机级例外都应该写原因和复审日期，否则很容易成为永久临时配置。

宏还可以用于 LLD 过滤和发现对象阈值。例如不同文件系统可以通过宏排除临时挂载，不同接口可以通过宏定义带宽阈值。对于网络接口、磁盘和服务这种对象多、差异大的场景，宏比复制多个模板更适合治理。

触发器案例

CPU 触发器不要只写“最新值大于 90”。更稳妥的表达是“CPU 用户态和系统态持续较高，同时系统负载或业务延迟也异常”。如果只看 CPU 使用率，批处理、压缩、备份、报表任务都可能触发无意义告警。对于普通服务器，可以使用五分钟平均值作为预警，十分钟持续高位作为高危，再结合 iowait 或负载区分 CPU 忙和 I/O 堵塞。

磁盘触发器要区分容量和增长速度。分区使用率大于阈值是容量风险，但如果磁盘还有数 TB 空间，80% 不一定紧急；如果日志分区半小时增长十几个百分点，即使当前只有 70%，也可能需要马上处理。可以设计两个触发器：一个看使用率，一个看短时间增长趋势。对数据库数据盘、日志盘、临时目录和备份目录应使用不同阈值。

服务存活触发器要区分“进程不存在”和“服务不可用”。进程在不代表业务可用，端口监听也不代表接口正常。关键应用至少应有本地进程检查和外部健康检查两个视角。本地检查适合定位进程级问题，HTTP 或 TCP 检查适合确认服务对外可用。两个触发器可以设置依赖，避免同一个故障产生重复通知。

接口延迟触发器要避免被单次抖动影响。可以用 avg(5m) 表示持续变慢，也可以用分位数指标，如果应用本身能提供 p95 或 p99。不要用均值掩盖尾延迟问题，也不要对低频接口设置过短窗口。对于业务接口，触发器说明里应写明探测来源、目标 URL、预期状态码、超时时间和是否经过负载均衡。

无数据触发器要谨慎。nodata() 可以发现采集中断，但在维护窗口、主机关机、Proxy 故障、网络隔离时也会产生大量事件。无数据触发器应结合主机维护状态、依赖关系和主机生命周期。对主动 Agent，nodata 可能代表 Agent 停止、主机名不匹配、Proxy 堆积或网络中断，不要直接解释为业务故障。

容量影响评估

每新增一个 item，都会带来采集、传输、预处理、历史写入、趋势计算和前端查询成本。单个 item 看起来很轻，但一套模板如果包含两百个 item，挂到一千台主机上就是二十万个采集点。采集周期从五分钟改成一分钟，压力会放大五倍。触发器、图表和 dependent item 也会进一步增加处理成本。

因此模板上线前要做粗略容量估算。估算内容包括主机数量、item 数量、平均采集周期、每秒新值数、预处理比例、dependent item 数量、历史保留周期和趋势保留周期。对于使用 Proxy 的区域，还要估算 Proxy 的缓存、队列、数据库或本地缓存压力。不要等 Zabbix Server 队列堆积后才发现模板过重。

高频指标要有充分理由。比如一秒级或十秒级指标适合短期故障诊断，不一定适合长期常态采集。Zabbix 可以做高频采集，但它不是专门的时序数据库集群。对于需要大规模高频指标和复杂聚合的场景，可能需要结合 Prometheus、VictoriaMetrics、InfluxDB 或其他指标平台，而不是把所有需求压进 Zabbix。

复审清单

监控项和触发器上线后要定期复审。第一，看 item 是否仍然有数据，unsupported item 是否持续存在。第二，看采集周期是否合理，是否存在大量高频但无人使用的指标。第三，看触发器是否产生过事件，是否长期从不触发或频繁抖动。长期不触发不一定没用，但需要确认它是否仍然表达真实风险。

第四，看严重级别是否符合实际响应。一个长期被忽略的 High 告警，要么处置流程有问题，要么严重级别定错了。第五，看标签是否完整，告警动作是否能基于标签正确路由。第六，看依赖关系是否仍符合拓扑，尤其是网络、虚拟化和应用依赖发生变更后。第七，看触发器说明是否仍然可执行，是否包含过期系统名、旧联系人或错误处理步骤。

复审不应该只由平台管理员完成。业务负责人、系统管理员、数据库管理员、网络工程师和值班人员都应该参与，因为他们分别知道业务影响、系统行为、数据含义、拓扑关系和处置体验。监控配置的质量，最终要用故障响应效果来检验。

上线评审可以用一组固定问题收口。这个监控项的业务含义是什么；采集失败时会不会被发现；返回值单位是否明确；预处理失败会留下什么痕迹；触发器阈值来自哪里；触发和恢复是否有滞后；严重级别对应哪类响应；是否需要依赖上游触发器；维护窗口是否会抑制通知；告警发出后第一处理人是谁。只要其中任何一个问题答不上来，就说明配置还没有达到生产交付标准。

评审还要关注删除和修改。删除一个 item 可能会影响 dependent item、触发器、图表、仪表盘和历史对比；修改 key 可能导致历史不连续；修改数据类型可能让旧值无法解释；修改宏默认值可能同时影响大量主机。模板维护者应该把这些影响写进变更说明，而不是只写“优化监控项”。对于核心模板，建议每次变更都保留导出文件，便于回滚和审计。若变更涉及告警动作，还要提前通知值班团队，避免他们在新规则生效后才发现通知内容、严重级别或路由方式已经改变。必要时应安排灰度窗口，只让少量主机先使用新模板，观察一个完整业务周期后再扩大范围，并记录新增告警数量和误报反馈，为下一次复审提供依据和责任追踪。变更结论也要完整归档保存备查。

一个完整设计样例

以“订单 API 可用性”为例，不建议只监控进程。可以设计四个层次：本机进程存活、端口监听、HTTP 健康接口、业务交易探测。本机进程由 Agent 采集，端口可以由 Agent 或 Simple check 采集，HTTP 健康接口由本区域 Proxy 执行，业务交易探测则通过 HTTP agent 或外部脚本返回明确状态。

监控项包括：进程数、端口状态、健康接口状态码、健康接口耗时、业务探测成功率、最近一次错误码。预处理把 HTTP 返回 JSON 中的状态和耗时拆成 dependent item。触发器设计为：进程为零立即告警；端口不可达持续两分钟告警；健康接口五分钟内持续失败告警；业务探测成功率低于阈值告警；如果本机进程已经失败，下游 HTTP 失败触发器依赖进程触发器。

严重级别根据影响设置。单台应用实例进程失败，如果还有负载均衡冗余，可以是 Average；全部实例健康接口失败，应是 Disaster；业务探测成功率下降但未完全中断，可以是 High。标签包含 service=order-api、env=prod、team=mes、symptom=availability。这样告警动作可以准确路由到订单系统值班组。

验收时，分别模拟进程停止、端口阻断、健康接口返回错误、业务探测失败和恢复。每个场景都要确认事件产生、严重级别、依赖抑制、恢复通知和处置说明是否符合预期。这个样例说明，好的监控不是一个阈值，而是一组围绕故障语义组织起来的数据、规则和流程。

小结

监控项和触发器是 Zabbix 从“数据采集工具”变成“运维判断系统”的关键层。监控项要回答数据从哪里来、多久来一次、是什么类型、怎样清洗和保存；触发器要回答什么情况算问题、持续多久算问题、恢复条件是什么、问题有多严重、是否依赖上游。

下一篇会进入告警配置与通知。告警不是从通知渠道开始，而是从本篇的触发器质量开始。触发器语义清晰、严重级别准确、标签和依赖关系完整，通知系统才能把正确的问题发给正确的人。

参考资料