服务器状态监控，很多人第一反应就是安装软件查看CPU运行曲线。查看曲线固然有用，但实际运维里棘手的故障往往是凌晨三点数据库连接数突然打满，或是磁盘写满让服务静默退出，等到第二天上班才发现。监控的核心目标是及时收到告警，而不是事后回看图表。
存活检查是最低限度要求。ping连通性、端口监听状态、HTTP返回码是否为200。Uptime Kuma、Better Stack这类工具部署简单，几分钟就能搭建完成，配置钉钉或者飞书webhook，服务器下线就能收到消息。这属于黑盒监控，从外部模拟用户访问探测，简单可靠。缺点只能提示服务异常，无法定位故障根源。
想要查看服务器内部指标，需要部署agent或者开启SNMP。node_exporter搭配Prometheus是很常见组合，可以采集CPU、内存、磁盘、网络、文件句柄、TCP连接数。Zabbix、Netdata上手更简单，安装自带可视化面板。Netdata刷新速度快，适合实时观察；Zabbix适合长期存储数据，配置阈值告警。云服务器自带基础监控也可以使用，不过采集粒度偏粗，告警能力有限，只能作为补充。
服务层面监控比系统指标更贴近业务本身。Nginx活跃连接、MySQL慢查询与连接数量、Redis内存占用和命中率、消息队列堆积量，这类指标异常，往往比CPU飙升更早暴露业务故障。写脚本定时检测进程存活、端口监听状态，属于简易有效的监控手段。进程存在不代表服务正常，还需要发起真实请求校验返回内容。
系统状态变更也需要及时感知。不光监控服务宕机，还要留意配置修改、新增监听端口、新增计划任务、文件权限改动。这些变更有可能是正常运维操作，也可能是入侵或者误操作。auditd、osquery、AIDE可以记录文件和系统调用变化。Ansible、SaltStack这类配置管理工具会保存变更记录，结合Git，能够记录修改人、修改时间。
日志也是告警来源。把日志统一汇总到Loki、Elasticsearch或者Graylog，设置关键字告警，比如OutOfMemory、Connection refused、Disk full。日志告警容易产生误报，需要持续调整规则，但很多故障第一现场信息保存在日志内。
告警推送只是其中一步。全部告警发送邮件等于没有告警，要按故障严重程度分流。P1级故障电话通知，P2短信加即时消息，P3提交工单。钉钉、飞书、Slack、Teams机器人很方便，但不要把所有告警推送至同一个群。告警聚合和抑制很关键，一台交换机故障，下游几十台服务器全部掉线，如果每台机器单独推送告警，值班人员会被大量消息干扰。Prometheus的Alertmanager支持分组、抑制、静默，Zabbix也可以配置依赖关系。
轮询间隔决定故障发现速度。一分钟一次探测，最坏情况需要等待一分钟才能发现故障。核心业务探测间隔可以缩短到10秒或者15秒，但不要全部检测项都使用短间隔，不然采集服务自身压力过大。心跳机制适合边缘设备或者定时任务：客户端定时上报状态，超过阈值未收到上报就触发告警。推送模式实时性更强，但架构复杂度更高。
监控系统本身也会出现故障。告警渠道不要只依赖单台机器。可以使用外部服务二次验证，例如Uptime Robot从公网探测业务，或者不同云厂商探针交叉校验。告警通道准备备用方案，短信收不到还有电话，电话无人接听就通知第二联系人。
监控系统部署完成不代表工作结束。每季度复盘告警记录，清理长期不触发的无效规则，调整不合理阈值。系统变更窗口期提前静默告警，避免升级期间大量告警刷屏。有效的告警，是在合适时间通知对应负责人，而不是持续推送无关消息，造成告警疲劳。