分类： 运维工具脚本

线上排障时最常被问的一句话是「这个服务的内存是什么时候涨上去的」。监控平台往往只保留 7～15 天的高精度曲线，而内存泄漏的斜率可能一个月才看得出来；容器重启后历史数据又断了一截。psutil 是 Python 里直接读 /proc 的轻量库，几十行代码就能在自己的机器上落一份「按分钟采样、按天归档」的 RSS 趋势文件，不受监控系统保留策略限制。下面这份脚

线上经常遇到这样的场景：监控面板显示 Pod 内存 2.3GiB，而 requests 只给了 512Mi，limits 是 1Gi，于是怀疑监控出错或容器逃逸；另一种情况是扩容时 kubectl top 的值远低于 requests，HPA 一直不缩容，节点资源被白白占着。这两个数据来自完全不同的链路——kubectl top 读的是 metrics-se

在 Nginx 里做反向代理，最容易踩的坑之一，就是 location 前缀和 proxy_pass 尾部斜杠的搭配。表现往往是：本地用 curl 直连后端 200，经过 Nginx 就变成 404；或者用 /api/health 探活一直 404，但日志里看不出任何"配置错误"——因为 Nginx 认为一切正常，它只是把你请求的 URI 按规则改写后转发出

很多团队改 /etc/ssh/sshd_config 的方式还是「登上去 vim 一下，然后 systemctl reload sshd」。这种做法的风险不在于改错一两行，而在于改完之后没人知道这台机器上到底改过什么：三年前有人把 PermitRootLogin 改成 yes，两年半前另一个人把 PasswordAuthentication 复制了两行、一行

日常运维里最容易出事的不是磁盘满，而是同一个备份脚本被 crontab 和手动执行同时拉起来两份。两份 rsync 抢同一个目标目录，两份 mysqldump 同时往同一个 .sql 里写，两份日志清理脚本同时 find -delete，结果往往是文件损坏、任务卡死、负载飙高，而排查时又抓不到现场。本文给出一个不依赖 flock 之外的额外软件、只用 She