Linux 从“救火式运维”到“体系化运维”

体系化运维的核心是建立可验证的闭环机制。需配置systemd-journald持久化日志、rsyslog保留RFC5424结构、prometheus合理设置scrape_timeout、ansible校验系统版本并验证变更生效，缺一环即退化为救火式运维。

救火式运维不是能力问题，是缺乏可复用的机制和可观测性基线。体系化运维不是堆工具，而是让 systemd、journalctl、rsyslog、prometheus 这些组件各司其职，且配置能被版本管理、批量部署、快速验证。

systemd 日志没存满就丢日志？查 SystemMaxUse 和 MaxFileSec

默认 systemd-journald 只保留最近 2 周或 100MB（取决于发行版），重启后内存日志全丢。这不是 bug，是设计选择——但生产环境必须改。

• SystemMaxUse=512M 和 RuntimeMaxUse=256M 写进 /etc/systemd/journald.conf，避免磁盘写满触发自动清理
• MaxFileSec=1month 控制单个日志文件生命周期，防止日志碎片化；搭配 RotateintervalSec=1week 更可控
• 改完必须 sudo systemctl restart systemd-journald，且注意：旧日志不会自动归档，要手动 journalctl --vacuum-time=30d
• 若日志量极大，关掉 Storage=volatile（默认值），启用 Storage=persistent，否则 /var/log/journal/ 根本不落地

rsyslog 转发到远程中心时字段丢失？重点看 $ActionForwardDefaultTemplate 和 RSYSLOG_ForwardFormat

很多团队用 rsyslog 把本地日志推给 elk 或 Loki，结果发现 hostname、pid、app-name 全变成 -，本质是模板没继承原始结构。

• 不要用默认的 RSYSLOG_SyslogProtocol23Format（它会丢 structured-data），改用 RSYSLOG_ForwardFormat，它保留 RFC5424 结构
• 在 /etc/rsyslog.d/50-remote.conf 里显式声明：$ActionForwardDefaultTemplate RSYSLOG_ForwardFormat
• 如果目标是 Loki，还需加 $EscapeControlCharactersOnReceive off，否则换行符被转义，logcli 查不到多行日志
• 转发前先用 logger "test $(date)" + journalctl -n1 确认本地日志字段完整，再验证转发链路

Prometheus 抓不到 node_exporter 指标？先确认 scrape_timeout 和 node_exporter --no-collector. 参数冲突

常见现象：curl http://localhost:9100/metrics 能返回内容，但 Prometheus 的 Targets 页面显示 context deadline exceeded，其实是超时或采集器被误禁用。

• 检查 prometheus.yml 中对应 job 的 scrape_timeout，若设为 5s，而 node_exporter 启动时加了 --no-collector.diskstats（依赖 /proc/diskstats），在高 I/O 机器上可能卡住超过 5 秒
• 改法二选一：要么调大 scrape_timeout: 10s，要么删掉不必要的 --no-collector. 参数——多数场景留着 diskstats、netdev、meminfo 就够用
• 用 node_exporter --collector.textfile.Directory /var/lib/node_exporter/textfile_collector 补充业务指标时，确保目录权限为 node_exporter 用户可读，否则整个 metrics endpoint 返回 500

Ansible 批量改配置却漏掉某台机器？别只信 inventory_hostname，查 ansible_facts['default_ipv4']['address']

运维体系化最脆弱的一环，是“以为改了，其实没生效”。比如统一更新 journald.conf，但某台机器因内核版本老，systemd 版本低于 219，不支持 MaxFileSec，Ansible 却没报错。

• 在 playbook 开头加 gather_facts: yes，然后用 when: ansible_facts['systemd_version'] | int >= 219 控制任务执行条件
• 关键配置变更后，强制加一个 command: journalctl --disk-usage 任务，注册结果，用 failed_when 判断是否真写入了新限制
• 别依赖 inventory_hostname 做唯一标识——dns 故障时它可能解析失败；改用 ansible_facts['default_ipv4']['address'] 或 ansible_facts['product_uuid'] 做校验基准

体系化运维真正的门槛不在工具链多复杂，而在每个环节都得有“可验证的闭环”：改了配置，得有命令立刻证明它生效；加了采集，得有指标证明它稳定；发了告警，得有人确认它不误报。缺任何一环，就还是救火。