第 03 篇已经讲过 Agent 2、主动与被动模式、TLS/PSK、UserParameter 和批量接入。本篇不重复安装过程，而是回答服务器进入 Zabbix 后更关键的问题：一台服务器到底应该监控什么，Linux 与 Windows 的基线有什么差异，模板和宏怎样组织，哪些服务和进程值得告警，如何把几十台或几百台服务器按同一标准纳管，以及如何证明监控不是“主机图标变绿”而是真能发现故障。

本文以 Zabbix 7.0 LTS 和当前官方模板机制为主要范围，优先使用 Zabbix agent 2、官方开箱模板和低级自动发现。官方文档说明，Zabbix 提供预配置模板来加速监控对象接入，模板位于 Data collection > Templates；升级 Zabbix 后，现有模板不会自动更新，以免覆盖本地修改。因此服务器监控不仅是初次接入，还包括模板升级、宏治理和持续复审。

服务器监控不是只看 CPU 和内存。完整基线至少覆盖主机可达、Agent 可用、CPU、内存、交换空间、文件系统、磁盘 I/O、网络接口、进程、系统服务、时间同步、证书或任务状态，以及少量真正代表业务可用性的探针。

从服务器角色定义监控目标

同样是 Linux 服务器，Web 节点、数据库节点、容器宿主机、备份服务器和批处理节点的正常状态并不一样。Web 节点关注接口可用性、错误率、连接数和负载均衡状态；数据库节点关注 I/O、内存、连接、复制和容量；容器宿主机关注节点资源、容器运行时和关键服务；备份服务器关注任务结果、存储空间和吞吐；批处理节点可能在任务窗口长期高 CPU，这不一定是故障。

因此服务器监控应分成两层。第一层是操作系统基线，所有同类系统都需要；第二层是角色模板，按业务和技术角色追加。不要创建一个“万能服务器模板”挂到所有机器上，也不要把所有角色差异写成单机配置。通用能力放基础模板，角色差异放角色模板，个别阈值通过宏覆盖。

服务器清单至少要包含主机名、系统版本、业务系统、环境、角色、负责人、机房或云区域、重要级别、维护窗口和退役状态。这些字段应进入主机组、标签或资产字段，后续告警路由、Dashboard、维护窗口和容量统计都会依赖它们。

采集架构选择

Zabbix Agent 主动模式与被动模式架构

服务器基线优先使用 Agent 2。官方文档说明，Agent 2 模板与插件配合工作，基本配置通常通过用户宏完成，更深层定制通过插件配置完成。插件支持命名会话时，可以为同类多个实例定义各自 URI、用户名和密码。这比在每台服务器上堆积临时脚本更容易治理。

大规模或跨区域环境优先使用主动检查，让 Agent 向本区域 Proxy 或中心 Server 获取检查列表并上报数据。小规模内网或需要 Server 即时拉取的少量指标可以使用被动检查。无论采用哪种模式，都要保持主机身份、模板类型和 item 类型一致。主动 Agent 绑定了仅被动 item，或者被动 Agent 被防火墙阻断，都会造成数据缺失。

服务器基线之外的外部可用性检查，不应全部从本机执行。应用进程在、端口在，不代表用户能访问。关键服务应至少增加一个由 Server 或 Proxy 发起的 TCP、HTTP 或业务探测。这样可以区分“本机内部看起来正常”和“外部路径实际可用”。

Linux 基线

Linux 基线从资源、内核、文件系统、服务和时间五个方面设计。

CPU 需要看使用率结构，而不是只看总百分比。用户态高通常表示应用计算消耗，系统态高可能与系统调用、内核活动或网络处理有关，iowait 高更可能指向存储等待。Load Average 要结合 CPU 核数和任务类型解释，不能简单规定大于某个固定值就是故障。批处理服务器短时高负载可能正常，低延迟接口服务器持续排队则可能影响业务。

内存要看 available、swap 使用和换页活动。Linux 会把空闲内存用于页缓存，free 很低不等于内存不足。更有意义的是可用内存持续下降、swap 持续增长、页面换入换出增加、应用被 OOM Killer 终止。触发器应结合多个指标，而不是只对“已用百分比”设一个统一阈值。

文件系统要同时看容量、inode、挂载状态和增长速度。官方文档说明，Zabbix 可以通过 vfs.fs.get master item、dependent LLD 和 item prototypes 发现挂载文件系统及其名称、类型、大小、inode 和挂载选项。模板过滤必须排除临时文件系统、容器挂载、只读镜像和不需要告警的挂载点，否则会产生大量无意义对象。

磁盘 I/O 要看设备利用率、吞吐、操作数和延迟，但阈值与存储类型相关。机械盘、SSD、本地 NVMe、SAN LUN、云盘的正常延迟差异很大。Zabbix 负责持续采集和趋势告警，真正定位时仍要结合 iostat、存储平台和应用请求延迟。不要把某个通用 await 数值当作所有存储的固定标准。

网络基线包括接口流量、错误包、丢弃包、接口状态和 TCP 状态。服务器接口 down 是否告警要看 bond、team、虚拟接口和备用口。容器宿主机会产生大量 veth 和 bridge，必须通过 LLD 过滤。TIME_WAIT、CLOSE_WAIT、ESTABLISHED 数量要结合连接模型解释，单独看数量很容易误判。

systemd 服务可以用 Agent 2 的 systemd.unit.discovery 发现。官方文档说明该 key 只支持 Zabbix agent 2，并返回 systemd unit 的 JSON 信息。发现所有服务并全部告警是不合理的，应通过宏和过滤只纳入关键服务，例如应用服务、数据库、消息队列、Agent、本地代理和安全组件。

Windows 基线

Windows 基线与 Linux 的目标相似，但数据来源和故障语义不同。CPU、内存、磁盘、网络可以通过 Agent 和 Performance Counters 获取；服务状态通过 Windows service discovery；事件日志用于少量关键事件；时间同步、补丁状态、计划任务和磁盘队列可能需要角色模板补充。

Windows 内存要关注 Available MBytes、Committed Bytes、Pages/sec 和分页文件，不要只看百分比。Windows 文件缓存、提交限制和应用工作集会影响解释。磁盘监控要区分逻辑磁盘容量和物理磁盘性能，数据库或文件服务器还要看 Avg. Disk sec/Read、Avg. Disk sec/Write、Current Disk Queue Length 等指标，但阈值应按存储能力和工作负载确认。

Windows 服务发现尤其需要过滤。域控、SQL Server、IIS、备份客户端、安全软件和业务服务都有大量相关服务，不是所有 Automatic 服务停止都应该同级告警。建议按角色维护关键服务列表，使用宏决定哪些服务需要发现和触发。服务显示名和服务名要区分，模板和运维记录应使用可稳定匹配的服务名。

Windows 事件日志适合监控明确事件，不适合把所有 Error 和 Warning 都发成告警。补丁、驱动、域策略、安全软件和应用都可能产生大量低价值事件。应先和系统负责人确认关键来源、事件 ID、级别和业务影响，再创建日志 item 和触发器。日志全文检索仍应交给日志平台。

Windows 性能计数器实例可能动态变化。官方文档提供 Windows performance counter instance discovery，用于发现多实例计数器。IIS Application Pool、SQL Server 实例、磁盘、网络接口等场景可以使用发现，但同样要做过滤和生命周期治理。

Linux 与 Windows 接入流程

Linux 与 Windows 服务器接入流程

接入流程可以统一为九步：确认资产身份；确认 Agent 版本和采集模式；配置 TLS；创建或自动注册主机；加入主机组和标签；关联操作系统基础模板；关联角色模板；调整宏和发现过滤；完成数据与告警验收。

官方模板接入时，先检查当前 Zabbix 实例中的模板版本。官方文档明确说明，升级 Zabbix 不会自动更新已有模板。不要因为 Server 已升级到新版本，就假设模板也已经是新版本。模板升级前应导出现有模板，检查本地修改，再按官方模板升级流程合并。

对于主动模板，Agent 配置中的 ServerActive 必须指向正确 Server 或 Proxy，主机名必须匹配。官方 Agent template operation 文档给出的基本步骤是：安装 Agent；主动检查时配置 ServerActive；把模板链接到目标主机；必要时调整模板宏；配置目标实例允许 Zabbix 获取数据。

服务器接入后先观察两个到三个采集周期。检查 Agent ping、系统信息、CPU、内存、文件系统、接口和进程数据是否到达；检查 unsupported item；检查 LLD 是否发现了正确对象；检查没有大量无意义文件系统、接口或服务。确认数据质量后再打开正式告警动作。

模板与宏治理

服务器模板可以按四层组织。第一层是操作系统基础模板，例如 Linux 或 Windows 基线。第二层是角色模板，例如 Web、数据库、容器宿主、备份、跳板机。第三层是应用模板，例如 Nginx、Apache、IIS、Redis、Docker。第四层是组织策略模板，例如时间同步、证书、备份状态和安全基线。

模板不要直接复制修改官方模板后失去来源。更稳妥的做法是保留官方模板，并通过链接自定义模板、用户宏、过滤宏和少量覆盖实现本地策略。确实需要修改官方模板时，要记录差异，以便未来升级。

宏用于表达阈值和过滤。例如文件系统使用率警告和严重阈值、文件系统发现排除规则、网络接口过滤、服务发现过滤、进程最小数量、业务端口。模板层给默认值，主机组层表达环境差异，主机层只处理例外。主机级例外要写原因和复审日期。

固定阈值不能机械套用。CPU 80%、磁盘 85%、内存 90% 只能作为讨论起点，不是生产标准。一个 100 GB 分区剩余 15 GB 和一个 100 TB 分区剩余 15 TB，处置紧急度不同；一台批处理服务器 CPU 95% 可能是正常利用，一台核心 API 节点 CPU 70% 就可能伴随延迟增长。

服务、进程和业务探针

服务监控应分三层。第一层是操作系统服务是否运行，例如 systemd unit 或 Windows service。第二层是进程和端口，例如进程数、监听端口。第三层是业务探针，例如 HTTP 健康接口、数据库查询、消息队列状态或实际业务交易。三层互相补充，不能只看其中一层。

进程存在不代表健康。Java 进程可能仍在但线程池耗尽，Nginx 进程可能在但上游全部失败，数据库进程可能在但只读或锁死。因此关键应用应提供健康接口或可验证请求。Zabbix HTTP agent、Web scenario、simple check 或外部脚本可以承担外部探测。

如果官方模板已有应用集成，优先使用官方模板。Zabbix integrations 页面集中列出官方模板和集成。例如 Apache、MySQL、SMART 等模板可以减少自定义脚本。自定义 UserParameter 只在官方模板无法覆盖且返回值稳定时使用，脚本要有超时、权限、依赖和本地测试。

业务探针必须控制副作用。健康检查只能读，不应修改数据；数据库探针使用只读账号；HTTP 探针避免触发真实订单或扣费；脚本超时要小于 Agent Timeout；返回值必须稳定。探针失败时，要能区分网络失败、认证失败、依赖失败和业务失败。

批量纳管

服务器批量纳管流程

主机超过几十台后，应通过配置管理、自动注册、API 或 CMDB 同步纳管。手工创建主机容易造成命名、标签、模板和 TLS 配置不一致。批量纳管的核心不是批量安装，而是让主机生命周期和监控对象生命周期一致。

自动注册适合云主机和标准化服务器。注册规则可以根据 HostMetadata、主机名或环境字段把主机放入主机组、关联模板和添加标签。自动注册必须使用可信身份和加密连接，不能让任何能连到 Server 的主机自动获得生产模板。

CMDB 同步适合资产治理成熟的环境。CMDB 作为资产来源，向 Zabbix API 创建、更新、禁用和删除主机；Zabbix 返回可用性、最新数据和问题状态。同步要处理幂等、重命名、退役、临时失联和责任人变化。资产不存在时，不要立即删除历史数据，可以先禁用或进入退役状态。

批量发布应分批。先测试环境，再非关键生产，再关键生产。每批观察 Agent 日志、Proxy queue、Server queue、unsupported item、告警数量和数据库写入变化。新增一百台主机可能同时增加上万个 item，必须评估采集周期和平台容量。

告警策略

服务器告警应围绕影响和持续时间设计。主机不可达、Agent 无数据、根分区耗尽、关键服务停止、文件系统只读、OOM、时间严重偏差、备份失败通常需要明确告警。CPU、内存、I/O、连接数等性能指标更适合持续窗口和多指标关联。

CPU 告警可以结合使用率、负载和业务延迟。内存告警可以结合 available、swap 和分页。磁盘告警可以结合使用率、剩余绝对空间和增长速度。网络告警可以结合接口状态、错误包和业务探测。这样比单一阈值更接近真实故障。

服务器告警还要考虑冗余。负载均衡后的单个 Web 节点故障，与整个集群不可用的严重级别不同；数据库从库故障与主库故障不同；容器集群单节点压力与控制平面故障不同。主机级告警应通过标签和服务级告警组合，避免把所有单机问题升级成业务灾难。

维护窗口必须跟随补丁、重启、扩容、迁移和发布。服务器变更期间，主机无数据、服务停止和资源波动可能是预期现象。维护结束后，要确认主机恢复上报、关键服务启动、文件系统挂载、时间同步和业务探针正常。

仪表盘设计

服务器仪表盘可以分三层。全局服务器总览展示未恢复问题、不可达主机、Agent 异常、容量 Top N、CPU/内存压力 Top N。角色仪表盘展示同类服务器的关键指标，例如 Web 集群、数据库集群、容器节点。主机详情页展示单台主机资源、服务、进程、日志和事件。

不要在全局页面放每台主机的折线图。Top hosts、Problems、Host navigator、Host card 更适合规模化观察。需要分析趋势时再下钻到 Graph。容量页面默认使用七天或三十天，值班页面默认使用最近一小时或当前状态。

故障注入与验收

服务器告警验证与排障

服务器监控必须通过故障注入验收。测试环境可以短暂停止 Agent，验证无数据或可用性告警；停止一个非关键测试服务，验证服务发现和触发器；创建临时大文件，验证文件系统阈值；让健康接口返回失败，验证业务探针；恢复后确认 Recovery 事件。

故障注入要有安全边界。不要在生产核心服务器随意消耗 CPU、填满磁盘或杀死服务。生产验证可以使用专门测试主机、临时模板宏、低风险服务或维护窗口。所有测试都要有回滚和清理。

验收清单至少包括：主机身份正确；主机组和标签正确；Agent 和 TLS 正常；基础模板和角色模板正确；关键 item 有数据；LLD 结果合理；unsupported item 已处理；关键触发器能产生和恢复事件；告警路由正确；维护窗口有效；Dashboard 可见；退役流程明确。

常见故障

Agent 可用但部分 item 无数据，常见原因是模板类型不匹配、key 不支持、权限不足、依赖命令缺失或预处理失败。先在本机使用 zabbix_agent2 -t <key> 测试，再看 Agent 日志和 item error。不要直接重装 Agent。

文件系统告警很多，通常是 LLD 过滤不合理，把容器挂载、临时文件系统和只读镜像都纳入。服务告警很多，通常是发现所有 systemd 或 Windows 服务后没有过滤。网络接口告警很多，通常是虚拟接口、备用口或临时接口没有排除。

数据延迟集中发生在一批主机时，先看对应 Proxy 和网络区域；只发生在单机时，看 Agent 服务、主机负载、磁盘、DNS、TLS 和主机名。批量新增主机后 Server queue 增长，则需要检查平台容量、采集周期和模板重量。

安全和权限

Agent 使用低权限账户运行，自定义脚本使用最小 sudo 规则。监控账号不应具备修改业务数据的能力。TLS/PSK 或证书用于跨区域和不可信网络。Agent 被动端口只允许 Server 或 Proxy 访问，主动模式只连接受控入口。

Windows 上要考虑杀毒软件、EDR、域策略和防火墙对 Agent 的影响。Linux 上要考虑 SELinux、AppArmor、systemd sandbox 和文件权限。监控脚本、PSK 文件和插件配置都要限制读取权限。

模板升级与复审

官方模板升级不是自动发生的。Zabbix 升级后，应查看当前版本模板变化，导出本地模板，比较宏、item、trigger、discovery 和 dashboard 差异，再在测试主机上导入验证。直接覆盖可能丢失本地修改，长期不升级则可能错过修复和新能力。

服务器监控每季度复审。检查退役主机、unsupported item、长期无数据、反复告警、主机级宏例外、模板版本、Agent 版本、自定义脚本负责人、TLS 密钥、服务发现过滤和容量趋势。遇到系统大版本升级、角色变化或迁移时提前复审。

CPU、内存与 I/O 的联合判断

服务器性能告警不应把 CPU、内存和磁盘分开孤立判断。应用响应变慢时，CPU 高可能是正常计算，也可能是线程忙等；Load 高可能来自 CPU 队列，也可能来自不可中断的 I/O 等待；内存高可能是应用工作集，也可能只是文件缓存；磁盘忙可能是业务高峰，也可能是日志暴增或备份任务。

一个更可靠的排障顺序是先看业务症状，再看系统资源。业务接口延迟升高时，检查 CPU user、system、iowait、load、上下文切换、内存 available、swap、磁盘 await、队列和网络错误。只有多个指标形成一致证据，才判断资源瓶颈。Zabbix Dashboard 可以把这些相关指标放在同一个主机详情页，但不必全部做成高优先级触发器。

CPU 持续高而业务正常时，可以进入容量观察，不必立即升级；CPU 高并伴随接口延迟和错误率时，才需要快速处置。内存 available 低但 swap 没增长、分页正常、业务正常时，可能只是缓存使用；available 持续下降、swap 增长并出现 OOM 时才是明确风险。磁盘利用率高但延迟低，可能是设备正常满负荷；延迟和队列持续上升更能说明瓶颈。

这种联合判断也应写进告警说明。告警消息可以列出当前 CPU、负载、可用内存、swap 和 I/O 等待，帮助值班人员快速判断，而不是只发一个“CPU 超过 80%”。

文件系统与容量治理

文件系统告警需要同时使用百分比和绝对空间。小分区 90% 可能只剩几百 MB，风险很高；百 TB 数据盘 90% 仍有十 TB，可能有足够处理时间。模板可以用不同宏表达警告和严重阈值，并为关键数据盘设置绝对剩余空间或预测触发器。

inode 是 Linux 容量监控的另一条线。大量小文件可能在空间尚未耗尽时先用完 inode，导致无法创建文件。日志目录、邮件队列、缓存目录、容器层和临时任务目录容易出现这个问题。文件系统 LLD 应同时生成空间和 inode item。

容量告警要有处置路径。日志分区增长可能需要调整日志轮转、清理异常日志或修复应用错误；数据库数据盘增长需要扩容或归档；备份盘增长需要保留策略；容器目录增长可能是镜像、层或日志。告警说明应包含目录用途和负责人，不能只告诉值班人员“磁盘满了”。

容量 Dashboard 建议展示使用率 Top N、绝对剩余空间 Top 风险、七天增长和预测剩余天数。每周或每月复审，提前发起扩容。容量采购和云盘扩容都有时间成本，阈值应为处理留出窗口。

时间同步、证书与计划任务

时间同步是服务器基线中经常被忽略的部分。时间偏差会影响日志关联、TLS、Kerberos、数据库复制、任务调度和故障时间线。Linux 可以监控 chrony 或 systemd-timesyncd 状态、偏差和上游源；Windows 可以监控 Windows Time 服务和域时间同步。时间偏差超过业务容忍度时应告警。

证书监控适合角色模板，而不是所有服务器都加相同脚本。Web、反向代理、API 网关、数据库 TLS 和内部服务可能使用不同证书。Agent 2 有 WebCertificate 等插件和官方集成，具体能力依赖 Zabbix 版本。文章以 7.0 LTS 为范围时，应核对对应模板要求，不把更高版本模板直接当作 7.0 可用。

计划任务和批处理要监控“结果”和“新鲜度”。只看 cron 或 Task Scheduler 服务运行不够。备份、数据同步、报表、清理任务应返回最后成功时间、最后状态、持续时间和处理数量。可以通过 trapper、sender、日志或脚本上报。触发器使用 nodata() 或最后成功时间判断任务是否按期完成。

计划任务监控要避免把命令逻辑写死在 Zabbix。任务系统负责执行，Zabbix 负责观察结果。任务完成后主动发送状态通常比 Zabbix 频繁扫描日志更可靠。上报要带唯一任务名、环境和时间，失败时保留错误摘要和外部日志链接。

备份与恢复监控

备份系统常见误区是只看备份服务进程或存储空间。真正需要监控的是任务是否成功、备份是否按时产生、备份大小是否异常、保留策略是否执行、恢复测试是否完成。一个显示“备份成功”的任务，如果生成文件大小为零或很久没有做恢复测试，仍然不能证明可恢复。

Zabbix 可以采集备份系统 API、任务日志、状态文件或 sender 上报结果。模板至少包含最后成功时间、最后失败时间、任务持续时间、备份大小和目标存储空间。关键系统的恢复演练结果也可以作为低频 item 记录，超过约定周期未演练时提醒负责人。

备份失败严重级别要按 RPO 和业务等级设置。每日全备失败和每小时增量失败影响不同；有多份副本和只有单一副本不同；测试系统和核心生产不同。告警路由应到备份团队和系统负责人，而不是只到平台组。

硬件健康

操作系统 Agent 无法覆盖所有硬件故障。物理服务器还应通过 IPMI、Redfish、厂商管理控制器或官方模板监控电源、风扇、温度、RAID、电池、物理磁盘和传感器。Zabbix 提供 IPMI 模板，具体硬件模板在 integrations 中按厂商选择。

SMART 适合本地磁盘健康。官方 SMART 集成使用 Agent 2 和 smartmontools，通过 LLD 发现 HDD、SSD 和 NVMe，并采集属性。使用前要确认 Agent 权限、smartmontools 版本和虚拟化边界。虚拟机里看到的虚拟磁盘通常不能代表物理盘健康，物理层应从宿主机或存储平台监控。

硬件告警要与厂商管理平台和维修流程联动。温度、风扇或 RAID 降级不是普通资源告警，可能需要现场处理、备件和停机窗口。告警中应包含机房、机柜、资产编号、序列号和保修联系人。

Linux 验收案例

假设纳管一台生产 Linux 应用服务器。主机标签包括 env=prod、service=mes、role=app、team=appops。关联 Linux 基础模板、应用角色模板、Nginx 或应用模板。Agent 2 使用主动模式连接区域 Proxy，并启用 PSK。

接入后检查 Agent ping、主机名、系统版本、CPU 核数、内存、swap、文件系统、inode、网络接口和 systemd 发现。确认容器挂载和临时文件系统已过滤，关键服务被发现，非关键服务不会告警。检查角色模板的健康接口和证书 item。

验收测试包括：维护窗口内重启 Agent，确认通知抑制；维护结束后 Agent 恢复；停止测试服务，确认服务告警；恢复服务，确认 Recovery；让测试健康接口返回失败，确认外部探针；创建临时文件接近测试阈值，确认文件系统事件后清理。

最后检查告警路由是否到应用团队，Dashboard 是否能按 service=mes 展示，主机退役时 CMDB 或自动化流程能禁用对象。完成这些步骤才算纳管结束。

Windows 验收案例

假设纳管一台 Windows Server 2022 IIS 服务器。关联 Windows 基础模板和 IIS 角色模板，Agent 2 通过软件分发系统安装。标签包含环境、系统、角色和团队。主机名来自资产系统，避免克隆或重装后产生重复对象。

检查 Windows 服务、性能计数器、逻辑磁盘、网络接口和事件日志。确认系统盘和数据盘阈值不同，分页和 Available MBytes 有数据，IIS Application Pool 实例发现正确，关键服务列表不包含大量无关服务。事件日志只匹配明确事件 ID 和来源。

验收可以在维护窗口停止一个测试 Application Pool，确认服务或应用池事件；访问健康 URL，确认外部探针；检查 Windows 防火墙和 EDR 没有阻止 Agent；重启服务器后确认 Agent 自动启动、主机身份不变、数据连续。恢复后检查告警和工单闭环。

服务器监控排障手册

当主机完全无数据时，先看 Agent 服务、网络方向、ServerActive 或 Server 参数、主机名、TLS 和 Proxy。只看 ZBX 图标不够，主动模式需要看 latest data 和 Agent 日志。区域内多台同时无数据时优先看 Proxy 和网络，不要逐台重装。

当某类 item 批量 unsupported 时，先看模板升级和 Agent 版本。新模板可能使用旧 Agent 不支持的 key，或者 Agent 2 插件未安装。单机 unsupported 更可能是权限、依赖或系统差异。先本地测试 key，再比较同类正常主机。

当触发器频繁抖动时，检查采集周期、时间窗口、恢复条件和维护状态。资源指标通常不应使用单点值；服务状态需要确认是否真的重启；无数据告警要考虑主机退役和网络维护。不要简单增加重复通知间隔掩盖触发器问题。

当前端图表慢时，检查时间范围、item 数量、历史保留和数据库。主机详情页放太多高频图表也会增加查询压力。短期排障用 history，长期容量用 trends 和聚合视图。

退役治理

服务器退役时，监控对象也要退役。流程至少包括进入维护或退役状态、停止告警、保存必要历史、删除或禁用主机、回收 PSK 或证书、移除自动注册规则例外、清理自定义脚本和配置管理清单。

不要让退役主机长期保持 Problem。这样会污染告警统计和 Dashboard，也让值班人员习惯忽略无数据问题。资产系统应驱动 Zabbix 状态，Zabbix 也可以把长期无数据反馈给资产负责人核对。

重装和迁移要区分“同一资产继续”还是“新资产替换”。如果需要保留历史连续性，主机身份和对象应谨慎迁移；如果是新资产，应创建新对象并关联旧资产记录。不要仅为了保留图表，把两个不同服务器共用同一主机对象。

交付记录

每批服务器纳管完成后，应留下结构化记录：主机清单、系统版本、Agent 版本、采集模式、Proxy、TLS 策略、基础模板、角色模板、主机级宏例外、关键服务、业务探针、维护窗口、验收结果和责任人。记录还要注明哪些命令在测试环境执行过，哪些只是配置路径，避免后续人员把未经现场验证的示例当成事实。

交付记录应能够回答三个问题：这台服务器为什么被监控；出现告警时谁处理；服务器变化或退役时谁更新监控。无法回答这三个问题的主机，即使最新数据正常，也只是技术接入完成，没有完成运维交付。每次季度复审后还应更新记录，标明模板版本、例外配置和遗留问题，并保存验收证据、整改责任人、完成日期和复核结论记录归档备查清单明细表。

一个完整案例

假设要纳管一个生产 Web 集群，包含四台 Linux 节点，由负载均衡提供服务。基础模板负责 CPU、内存、文件系统、网络和 Agent；角色模板负责 Nginx 或应用服务、健康接口、证书和日志错误计数；集群级探针从 Proxy 请求负载均衡地址。

单节点服务停止时，主机触发 Average 或 High，通知应用团队，但集群探针仍正常；两台节点故障或集群探针失败时，服务级告警升级。文件系统增长、证书临期进入提前处理流程，CPU 短时高峰只记录，持续高位并伴随接口延迟才告警。

上线时分两批接入，先两台观察一天，再接入剩余两台。验收包括停止测试节点服务、恢复服务、模拟健康接口失败、验证维护窗口和告警路由。交付记录包含模板、宏、关键服务、探针、责任人和退役流程。

小结

服务器监控的核心不是收集尽可能多的指标，而是建立基线、角色和业务三层监控，把 Linux 与 Windows 的差异、模板与宏、LLD 过滤、服务探针、批量纳管、告警和生命周期统一起来。

下一篇进入数据库监控实战。数据库服务器仍需要本篇的操作系统基线，但数据库实例的连接、查询、锁、复制、容量和备份状态需要独立模板和最小权限账号。

参考资料