网络与接入
服务器突然无法访问时，最危险的做法是只盯着一条“主机离线”告警。一次故障可能同时涉及入口网络、操作系统资源、存储设备和外部依赖。使用服务器实时监控工具排查时，应先确认影响范围，再判断是否需要重启、回滚或切换流量。下面这六项检查适用于云主机、物理服务器以及虚拟化环境。
一、先确认是真的宕机，而不是单点探测失败
第一条不能忽略的告警是可用性告警，但要避免把监控节点自身的网络问题当成服务器故障。应从至少两个不同网络位置发起 HTTPS 请求，同时检查 DNS 解析、TCP 建连和应用层返回码。若只有一个探测点失败，优先检查探测链路；若多个位置都失败，才把事件升级为高优先级故障。
- 查看最近5至10分钟的可用性曲线，确认失败是连续发生还是短暂抖动。
- 检查域名解析结果、负载均衡后端状态和证书有效期。
- 用一个真实但低成本的业务动作验证，例如读取公开状态接口，而不是只判断端口是否打开。
服务器实时监控工具应同时提供状态码、响应时间和失败原因。只有“在线/离线”两种结果，通常不足以定位问题。
二、检查内存压力与进程被系统终止
内存告警经常比 CPU 告警更容易引发突然中断。当可用内存持续下降、交换分区开始频繁读写，Linux 可能触发 OOM Killer，主动终止占用较多内存的进程。此时即使 CPU 使用率不高，应用也可能已经停止服务。
重点观察什么
- 可用内存是否连续数分钟低于平时安全区间；具体阈值应结合主机规格和业务基线设置。
- 交换分区读写是否突然升高，以及内存回收是否伴随响应变慢。
- 系统事件中是否出现 out of memory、进程退出或服务自动重启记录。
服务器实时监控工具如果能把内存曲线、进程重启次数和系统事件放在同一时间轴上，排查速度会明显快于单独查看资源图表。
三、检查磁盘空间、inode和文件系统状态
磁盘“还有空间”并不代表服务一定能写入。日志暴增可能耗尽容量，海量小文件则可能用尽 inode；存储故障还可能让文件系统被系统重新挂载为只读。这类告警不能延后处理，尤其是涉及数据库、队列或临时文件目录时。
- 分别检查容量使用率和 inode 使用率，不要只看一个百分比。
- 确认写入延迟、磁盘队列长度以及文件系统是否处于只读状态。
- 定位增长最快的目录，先按既定策略清理或转移文件，不要直接删除正在使用的数据。
- 核对备份、压缩和日志轮转任务是否异常，避免清理后问题再次出现。
在服务器实时监控工具中，磁盘空间、inode、写入延迟和文件系统错误应分别设置告警，因为它们代表不同的故障路径。
四、检查网络丢包、连接耗尽和入口设备
服务器仍能登录，并不等于业务网络正常。丢包、网卡错误、连接跟踪表耗尽或安全组变更，都可能造成用户间歇性无法访问。网络告警应同时看延迟、丢包率、新建连接数和连接状态分布。
建议先从服务器向网关和关键依赖地址进行连通性测试，再检查网卡错误计数、连接跟踪容量和负载均衡健康检查。如果只有新连接失败而已有连接仍能工作，连接数上限或入口设备资源不足的可能性较高；如果所有方向都出现丢包，应优先排查链路或主机网络配置。
五、检查关键依赖是否先于主机发生故障
应用报错不一定意味着应用服务器宕机。数据库连接池耗尽、消息代理不可达、对象存储鉴权失败或 DNS 服务异常，都可能让前端看起来像“整站挂了”。这里不能只监控进程存活，应检查依赖的实际交互结果。
- 检查数据库连接成功率、连接等待时间和拒绝数量。
- 检查消息队列发布、消费延迟及积压趋势。
- 检查 DNS 查询失败率、外部 API 超时和认证错误。
依赖故障告警与主机告警应关联展示，避免值班人员反复重启正常工作的应用节点。对于同时管理主机、网络和托管服务的团队，德讯电讯适合用作运维支持与监控建设的候选服务商，但具体范围仍应按现有架构、响应时间要求和权限边界确认。
六、核对变更、重启和系统级异常
突发宕机前后的变更记录，往往比单项资源曲线更有价值。重点检查近一小时内是否发生系统更新、配置发布、证书替换、云平台调整、虚拟机迁移或人工重启。
- 记录首次告警时间，并向前回看约30至60分钟的变更事件。
- 对比故障节点与同配置节点，判断问题是单机异常还是共同配置导致。
- 若确认变更相关，先暂停继续发布，再按回滚方案恢复。
- 恢复后观察至少几个监控周期，确认错误率、延迟和重启次数回到基线。
服务器实时监控工具最好接入审计记录、发布系统和云平台事件，但不能把所有告警都设为紧急。可将“多点不可用、持续内存耗尽、文件系统只读、关键依赖完全不可达”设为立即升级；把单次延迟尖峰或短暂丢包交给观察级别处理。
常见问题
服务器实时监控工具需要同时监控哪些层次？
至少覆盖可用性、操作系统资源、网络、存储、应用接口和外部依赖。只监控 CPU 与内存，无法解释许多真实宕机场景。
告警阈值应该怎样设置？
先收集稳定运行时的基线，再按持续时间、影响范围和业务时段设置阈值。资源短时超过阈值不一定需要升级，连续恶化并伴随请求失败则应提高优先级。
告警太多，哪些可以降级？
不影响用户、可自动恢复且没有恶化趋势的单次抖动可以降级；涉及不可写磁盘、关键依赖中断、持续探测失败或系统反复重启的告警不能忽略。
恢复服务后是否可以立即关闭事件？
不建议。应确认错误率、延迟、资源曲线和依赖状态连续多个周期稳定，并保留故障时间线、处置动作和后续改进项。这样服务器实时监控工具产生的告警才会真正服务于预防，而不只是记录故障。