方向
全部语言教程功能实现面试题运维工具脚本AI 实践
分类
全部Shell 脚本进程管理定时任务容器运维监控告警

分类： 运维工具脚本

inotify 监控目录并触发告警的轻量脚本

线上服务器经常出这种事：某个目录本该只读，结果被人手动改了个配置文件；或者 /etc/nginx/conf.d 下突然多出一个 .conf，reload 之后整站 502。事后翻 ~/.bash_history 往往已经断档，审计日志又重又慢。真正需要的是一层极轻的「哨兵」：目录内容一变，几秒内就把变更路径、事件类型、操作者推到你面前。 inotify 是

容器日志体积失控：json-file 驱动的 max-size 与 max-file 配置脚本

Docker 默认使用 json-file 日志驱动，而且默认不做任何轮转。一个打印量稍大的服务，跑上两周就能把宿主机的 /var/lib/docker 撑满，然后你会在 docker ps 里看到容器状态变成 Up 但业务全挂，或者在 dmesg 里看到 No space left on device。更麻烦的是，日志文件被删掉之后磁盘空间并不一定释放——

多主机时间同步与漂移巡检：一个 Ansible Playbook 全覆盖

集群里最容易被忽略、又最容易引发"玄学故障"的基础项，就是时间。NTP 漂移几百毫秒，可能让 JWT 校验随机失败、让 Kafka 消费者位点错乱、让分布式锁提前释放、让 ELK 里的日志时间线对不上。而这类问题往往不具备可复现性，排查成本极高。 手工逐台 ssh 上去看 chronyc tracking 的运维方式，在几十台机器规模下就完全不可接受了。本文

服务健康检查脚本：curl 超时与状态码分级判定

用 curl 做服务健康检查几乎是所有运维脚本的标配，但大多数实现只写了一行 curl -s -o /dev/null -w "%{http_code}"，然后判断是否等于 200。这种写法在真实生产环境里会暴露三个问题：没有设置超时导致脚本被挂死、把「服务不可达」和「服务返回业务错误」混为一谈、无法区分 HTTP 状态码中哪些属于自身异常、哪些属于上游依赖