Linux 从“被动救火”到“主动治理”

主动治理需将cgroup v2内存限制、journalctl结构化日志查询、inotifywait配置变更监控嵌入日常操作：用MemoryMax限制服务内存防OOM；用journalctl –since等命令精准查日志；用inotifywait实时校验配置变更。

linux 系统运维没法靠“等出事再查”撑过三个月——日志堆积、资源突增、服务静默挂死，都是被动响应的代价。主动治理不是加监控看板，而是把可观测性、资源约束和变更控制嵌进日常操作习惯里。

用 cgroup v2 限制关键服务内存，避免 OOM 杀进程

Linux 默认不设内存上限，systemd 启动的服务可能吃光内存后触发 OOM Killer，随机干掉进程（比如干掉数据库而非日志收集器）。cgroup v2 是目前最可控的方式：

• 确认内核启用：cat /proc/cgroups | grep memory，且 /sys/fs/cgroup/cgroup.controllers 包含 memory
• 对 systemd 服务加限制：在 /etc/systemd/system/mysqld.service.d/limits.conf 中写：

  [Service] MemoryMax=2G MemorySwapMax=0

• 重载并重启：systemctl daemon-reload && systemctl restart mysqld
• 验证：cat /sys/fs/cgroup/system.slice/mysqld.service/memory.max 应输出 2147483648

注意：v1 和 v2 混用会冲突；centos 7 默认是 v1，需升级到 8+ 或手动启用 v2；MemorySwapMax=0 防止 swap 掩盖真实内存压力。

用 journalctl --since "2 hours ago" 替代翻 /var/log/ 文件

传统日志轮转后，grep -r "Error" /var/log/ 容易漏掉 systemd-journald 缓存中的实时事件，也难对齐多服务时间线。journald 天然支持结构化查询：

• journalctl -u nginx --since "1 hour ago" -p err 查 nginx 近一小时错误
• journalctl _PID=12345 追踪某次请求对应的所有服务日志（含依赖服务）
• 加 --all --no-pager 避免截断二进制字段（如 TLS 握手失败的详细报错）
• 日志量大时，/etc/systemd/journald.conf 调整 SystemMaxUse=512M 防止占满根分区

别依赖 logrotate 后再查——journald 的索引比 find | xargs grep 快一个数量级，且自带时间戳对齐。

用 inotifywait 监控配置目录变更，自动触发校验

配置被手动改坏却没人知道，是多数线上事故的起点。与其等服务 reload 失败，不如在文件系统层捕获变更：

• 安装：apt install inotify-tools（debian）或 yum install inotify-tools（RHEL）
• 监控 /etc/nginx/conf.d/ 并校验语法：

  inotifywait -m -e modify,move,create,delete /etc/nginx/conf.d/ |    while read path action file; do     nginx -t &>/dev/null && echo "$(date): OK" || echo "$(date): NG - $file"   done

• 用 systemd --user 启动该脚本，确保随用户会话持久运行
• 注意：inotifywait 不递归监控子目录（除非加 -r），且单实例最多监听 8k 文件，超量需分目录拆解

这比定时 crontab 扫描高效得多——变更即响应，且不依赖服务自身 reload 机制是否健壮。

真正卡住主动治理落地的，往往不是工具不会用，而是没把 cgroup 限值写进 CI/CD 的部署模板、没把 journalctl 查询逻辑封装成运维脚本、也没让 inotifywait 监控成为新服务上线 checklist 的强制项。机制一旦脱离人工记忆，才开始生效。