服务器磁盘与带宽告警的排查顺序：一套可复用的处理流程（TinyFish 检索）

[admin]

朗读 点击，生成分享二维码

用 TinyFish 检索了运维社区关于服务器告警处理的实践文章，一个共识是：告警本身不可怕，可怕的是没有固定的处理顺序，每次都在现场现想。整理一套可复用的排查流程。

第一步：先分清是趋势还是尖刺

看监控的时间维度。如果是一条缓慢上扬的曲线，通常是有东西在持续写或者持续跑；如果是瞬间尖刺，多半是某个定时任务或者突发流量。这两种情况处理方向完全不同，先分清能省一半时间。

第二步：磁盘满了先找谁在写

常见的几个方向：

代码： 全选

# 看目录占用，从大到小排
du -xh --max-depth=1 / | sort -h

# 看被删除但进程还占用的文件（df 和 du 对不上时）
lsof +L1

# 看大文件
find / -type f -size +200M -exec ls -lh {} \;

日志文件、容器层、数据库数据和备份文件是最常见的三类元凶，按这个顺序排查通常很快命中。

第三步：带宽告警先看方向和进程

代码： 全选

# 实时看流量落在哪个进程
iftop -P

# 按连接数和流量排序
ss -tunp | head -50

要区分是入站流量还是出站流量。出站异常通常是数据同步或者被当作跳板，入站异常多半是业务量涨了或者被扫。

第四步：清理要有边界

- 日志压缩后归档，别直接删，出问题还要回溯
- 容器镜像定期清，用 docker system prune 之前先确认没有需要保留的构建缓存
- 备份保留策略写清楚，别手动删

最后：把临时办法固化成定时任务

每次手工救火之后，想一想能不能变成自动清理或者自动告警。救火一次是运气，不重复救火才是能力。

参考来源：运维社区服务器告警处理实践、腾讯云开发者社区运维专题。信息时效性有限，以实际系统情况为准。

[admin]

好内容，收藏了。之前也踩过类似的坑，配好之后确实省心很多。