运维手册

监控告警：Zabbix、Prometheus 与 Grafana 分工

划清采集、规则、通知和看板职责，建立唯一告警责任、测试通知与数据缺口处置。

监控告警：分工与通知闭环

图中 Zabbix、Prometheus、Grafana 是同一能力域内的组合，不应让三个系统对同一故障各自通知同一值班组。建议 Zabbix 承接已存在的主机及网络设备监测，Prometheus 承接服务和云原生指标，Grafana 聚合看板；这是待评审的分工，不是产品限制或已完成集成。

Prometheus 的告警规则产生告警，Alertmanager 负责分组、静默、抑制和通知，因此本方案额外列出通知组件；图中没有画出它，不代表已有部署。官方告警流程

为每类信号登记来源、采集间隔、标签、保留期、负责人及主要通知渠道。以服务、环境、区域和严重级别定义路由；不要将请求标识、用户编号等无限增长的值放入指标标签。区分“目标无法采集”“数据超过新鲜度预算”和“业务指标超标”，为每项写清独立判据。

确认出口防火墙、代理、证书及通知账号权限。通知接收人、确认期限和升级路径应由值班制度确定，不写死通用响应承诺。所有配置、测试告警和故障演练均待目标环境授权后实施。

先选一个试点服务，登记目标并验证采样连续性，再建立总览、实例和故障调查三层看板。给每条规则填写影响、排查入口和恢复条件。评审哪些告警由 Zabbix 主发，哪些由 Prometheus 主发，其余系统只展示关联证据。

Zabbix 的通知还依赖动作、媒介和接收者设置，触发器产生问题不等于通知已送达。Zabbix 通知文档试点需要人为批准的测试事件，核对触发、路由、送达、确认和恢复通知全流程；测试消息明确标注演练且只发至约定范围。

检查目标可用率、采集失败、规则求值耗时、时间序列增长、远端写入积压、通知失败及静默过期时间。Grafana 面板需显示所选环境和时间范围，并验证单位与聚合维度。曲线为空时不默认画成零；聚合平均值正常时仍抽查尾部延迟和单实例异常。

维护窗口结束后确认告警重新生效，人员轮值后核对接收人。每周复查长期无主告警、重复通知、无行动项告警和持续静默，形成可审阅的规则调整记录，不通过无限提高阈值“消除噪声”。

单目标缺数先查 exporter 或 agent、认证和网络；整组缺数查服务发现、代理和公共证书。数据正常但规则不触发，比较表达式的标签匹配、持续时间和求值状态。告警触发而无人收到，则查通知路由、静默、媒介和外部服务返回，保留脱敏失败信息。

Grafana 空面板而数据源查询正常，重点检查变量、面板权限和时间范围；不要为了看板恢复而改写采集标签。监控系统自身故障应通过独立探测发现，避免只靠同一个 Prometheus 监控自己的存活。

本方案要求规则、目标清单、路由、看板与数据源配置纳入受控版本管理，凭据单独保管。Grafana 恢复范围不仅是面板导出，还包括配置、插件以及所用数据库，具体方法依部署方式确定。Grafana 备份文档

历史指标是否备份、可丢失窗口及远端存储责任需单独批准，配置恢复不能补回未采集的数据。在隔离环境验证恢复后先禁用真实通知出口，避免历史告警批量打扰值班；对当前规则和时间范围确认后才申请恢复通知。

验收包含采集连续性、错误标签拒绝、规则触发、单一责任路由、恢复通知、静默到期以及看板权限拒绝。保留事件时间线和真实测试结果。出现无主高危告警、通知链未验证、标签失控或无法区分缺数与健康时，停止新增目标。继续阅读主机监控场景和Kubernetes 监控场景。

规则、通知和看板分别以上述官方资料为依据。本文描述的是运行验收设计，不宣称当前站点已连接真实监控数据，也不承诺三种工具已完成身份联邦或自动告警去重。