磁盘空间与Inode耗尽
日志文件、临时文件和数据库Binlog是磁盘空间的三大杀手，Inode耗尽则是文件数量过多导致，典型场景是业务产生海量小文件（如验证码图片、临时缓存），但清理机制失效。高可用架构下的服务器磁盘使用率达到85%即视为告警阈值,而不是等到完全写满。
排查命令是 df -h 查看空间，df -i 查看Inode，定位大文件目录可使用 du -sh ./ | sort -hr | head -20 由大到小排序，针对日志增长，建议在 /etc/logrotate.d/ 下为不同应用配置独立的切割策略：
- 按大小切割：
size 100M，超过100MB轮转 - 按时间切割：
daily每日轮转，保留7天 - 压缩旧日志：
compress选项减少空间占用
内存溢出与GC异常
Java应用和Node.js应用是内存问题的高发区，常见模式是堆内存持续增长，触发频繁的Full GC，STW时间过长导致请求大面积超时，可观察配置JVM参数中的 -Xlog:gc 日志输出，或者使用 jstat -gcutil PID 1000 每1秒采样一次查看GC频率。
业务层排查时，优先检查是否存在未关闭的数据库结果集、未释放的IO流、以及无界队列缓存，分布式缓存的key如果没有设置过期时间，也会被误认为内存泄漏,实际上是无界增长。
安全攻击型问题的识别与应对
安全类故障的特征是突发性、持续性和有规律性,与业务波峰有本质区别。
DDoS与CC攻击的流量特征
DDoS攻击的表现是流量瞬间飙升，正常业务请求被淹没，CC攻击则更阴险，模拟真实用户请求，反复请求高消耗接口（如报表查询、文件下载），导致应用资源被耗尽，区别在于：DDoS的流量曲线是陡峭的尖峰,CC攻击的曲线是平缓的持续爬坡。
基本防护手段是启用云服务商的DDoS高防或WAF，同时在上游Nginx层做 请求频率限制（limit_req 模块）和 并发连接限制（limit_conn 模块），规则优先设置针对单个IP的每秒请求数上限,并配合人机验证策略拦截异常客户端。
端口扫描与暴力破解
从安全设备告警中看到大量来自同一IP的不同端口探测记录，通常属于自动化扫描行为，暴力破解集中在SSH（22端口）、Redis（6379端口）和数据库端口，缓解手段：禁止root直接SSH登录，使用密钥认证替代密码认证，将Redis绑定内网IP并开启 requirepass，对于暴露在公网的端口，可用开源工具 fail2ban 动态封禁连续失败N次的来源IP。
下游服务器故障排查的黄金路径
面对故障时，需要一套高效的前后过滤机制，而不是盲目抓瞎,按下述顺序操作能覆盖绝大多数场景：
- 查图表：查看监控面板（Zabbix/Prometheus/Grafana），关注CPU、内存、磁盘、网络这四项指标的曲线变化，找出异常拐点的时间段，如果四项指标全部正常,则优先怀疑应用层或路由层问题。
- 查日志：检查下游服务器的应用日志和系统日志（
/var/log/messages），应用日志中的Exception堆栈是定位根因的富矿，若日志大量输出OutOfMemoryError，重点检查堆内存配置；若出现Connection Refused,则检查并发连接数是否超出内核参数上限。 - 复现操作：在业务低峰期或维护窗口，手动触发一个测试请求模拟线上行为，观察失败发生在哪一步，使用 strace -p 进程ID 跟踪系统调用阻塞点，能直接定位是在网络读写、文件IO还是锁等待上耗时。
- 修复验证：应用临时配置或补丁后，采用灰度方式验证先让5%的流量经过修复后的节点，观察10分钟无异常，再逐步扩大流量比例，切不可直接全量上线,避免引入回退故障。
常见故障排查命令速查
| 故障类型 | 首选命令 | 关键指标 |
|---|---|---|
| 连通性 | ping、traceroute |
丢包率、RTT延迟 |
| 端口服务 | telnet、nc |
是否响应、握手时长 |
| 连接数 | ss -lnt |
队列溢出计数、已建立连接数 |
| 文件描述符 | lsof -p PID |
打开的fd数量及类型 |
| 内存GC | jstat -gcutil PID |
Full GC频率与耗时 |
| 磁盘Inode | df -i |
Inode使用率 |
| 系统调用阻塞 | strace -p PID |
阻塞等待的资源类型 |
下游服务器问题会带来哪些业务后果
下游服务器的稳定性直接影响整个系统的可用性，统计表明，下游故障引发的事故平均恢复时间通常在30分钟至2小时之间，期间造成的直接经济损失因业务类型而异，对于电商交易链路，每1分钟的不可用都可能影响成百上千笔订单；对于金融支付链路,故障会触发监管级的事故上报。
从运维成本角度审视，处理一次下游故障的综合成本是预防性投入的5至10倍，包括研发人员排障时间、硬件紧急更换费用、必要时求助第三方专家的专家费，以及事后复盘填写报告的人力，这笔账算下来,提前做好监控告警和冗余设计远比事后救火划算。
以下游服务器常见的故障排查思路有哪些为例推荐一个低成本起步方案：免费使用Prometheus采集下游节点的四类指标，配合Alertmanager将告警推送到钉钉或企业微信，这能在<10分钟内部署完成，覆盖CPU、内存、磁盘、网络四项基础监控。
需要留意的是，排查所有下游服务器问题的共同前提是有清晰的监控数据，没有监控就无从对比“故障前后差异”，相当于蒙着眼睛修车，备齐监控工具和日志采集流程后,绝大多数故障都能在15分钟内定位到根因层面。
Q&A：关于下游服务器问题的补充解答
如何判断是上游还是下游服务器故障？
从时间维度看，下游故障通常表现为接口整体超时或报错率突然上升；从链路维度看，在上游服务器上telnet下游端口失败，基本可以确定是下游服务异常，更精确的做法是在上游记录每个调用的耗时明细，若耗时分布集中在下游处理阶段而非网络传输,则问题在下游应用本身。
下游服务器响应慢是什么原因？
主要原因集中在资源竞争、应用代码效率、外部依赖拖慢三个方面，先用 top 和 free -m 排除资源瓶颈，再通过链路追踪工具定位耗时最长的调用段，从业界经验来看，大部分慢响应问题源于下游应用调用更底层的外部服务（如数据库查询未命中索引、Redis集群出现热key）,单纯增加下游服务器配置并不能根治。
下游服务器的监控指标应该设置什么阈值？
CPU使用率建议 85%告警，95%严重告警；内存使用率超过 85% 即触发排查，重点排查是否存在物理内存与Swap之间的频繁交换；磁盘利用率保持在70%以下为健康水位，超过80%属于预警区间；网络带宽使用率以端口规格的 70% 作为扩容基线即可，各指标阈值需要结合业务请求量基线调整,例如秒杀类业务可短期容忍高CPU占用但不可长时间处于高内存状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/785576.html
