在工业自动化、智能制造、能源监控等关键领域，Linux工控机正扮演着“大脑”与“神经中枢”的角色。然而，许多工程师和运维人员都曾遭遇一个看似不起眼却足以引发系统停机的“幽灵”问题：系统盘空间在毫无预警的情况下被写满，导致关键应用崩溃、数据丢失，甚至整个生产线中断。

这个问题的元凶，往往不是核心应用本身，而是那些默默记录着系统一举一动的日志文件。它们如同细沙，日积月累，最终堵塞了系统的“血管”。本文将深入剖析这一工业场景下的典型痛点，并提供一套经过验证的、可落地的日志管理与自动清理“黄金配置法则”。

一、 痛点深析：为什么日志会成为“系统杀手”？

在工业环境中，Linux工控机的日志问题尤为突出，原因在于其独特的应用场景：

• 7x24小时不间断运行：工业系统常年无休，日志持续产生，没有“喘息”的窗口进行手动清理。

• 高频率数据采集与事件记录：PLC通讯、传感器数据、设备状态、异常报警等信息被密集记录，日志量增长迅猛。

• 应用多样性：除了系统日志（/var/log），还有数据库日志、特定工业软件（如SCADA、MES客户端）日志、容器日志等，管理分散。

• 磁盘容量限制：工控机通常采用固态硬盘（SSD）且容量有限，以追求稳定性和成本控制，空间本身并不宽裕。

• 后果严重性：系统盘满可能导致：

• 无法写入新日志，丢失关键故障线索。

• 应用崩溃，如数据库服务停止。

• 系统卡顿甚至无法启动。

• 在紧急情况下影响故障恢复速度。

二、 解决方案：日志管理与自动清理的“黄金配置法则”

解决之道并非简单地写个定时删除脚本，而是一套涵盖监控、轮转、清理、归档的完整体系。以下法则以systemd/journald（现代Linux主流）和logrotate为核心，兼顾传统syslog。

法则一：核心配置——启用并优化 journald（系统日志）

journald是systemd套件的一部分，它默认将日志存储在/var/log/journal，但默认配置下可能不做空间限制。

• 启用持久化存储（如果尚未启用）：

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald

• 关键配置：限制日志占用空间
  编辑 /etc/systemd/journald.conf，取消以下行的注释并修改：

[Journal]
# 将日志总大小限制在系统内存的10%（例如4G内存限制为400M），或设定固定值
SystemMaxUse=500M
# 单文件大小限制
SystemMaxFileSize=50M
# 保留时间（旧日志自动删除）
MaxRetentionSec=1month
# 或使用以下更直接的磁盘空间限制
# RuntimeMaxUse=, SystemMaxUse= 设置最大磁盘使用量

修改后重启服务：sudo systemctl restart systemd-journald

法则二：骨干工具——精通 logrotate（应用日志）

logrotate是管理应用日志（如Nginx、Apache、自定义应用）的瑞士军刀。其核心思想是轮转：重命名旧日志，创建新日志，压缩历史文件，删除过旧文件。

• 全局配置 (/etc/logrotate.conf)：

# 每周轮转一次
weekly
# 保留4个周期的日志（即一个月）
rotate 4
# 轮转后创建新的空日志文件
create
# 启用压缩，节省空间
compress
# 包含自定义配置目录
include /etc/logrotate.d

• 为特定应用定制配置 (在/etc/logrotate.d/下创建文件，如 my_industrial_app)：

/var/log/myapp/*.log {
daily # 工业环境可能需更频繁，如daily
missingok
rotate 30 # 保留30天
compress
delaycompress # 延迟一次再压缩，便于排查最新问题
notifempty
create 0640 root adm
sharedscripts
postrotate
# 如果应用支持，发送信号让其重新打开日志文件
/bin/kill -HUP `cat /var/run/myapp.pid 2>/dev/null` 2>/dev/null || true
endscript
}

• 手动测试配置：sudo logrotate -d /etc/logrotate.d/my_industrial_app （-d为调试模式，不实际执行）

• 自动化：logrotate通常由cron每日定时运行，无需额外干预。

法则三：空间守卫——实施磁盘空间监控与告警

预防优于治疗。设置磁盘空间监控，在达到阈值（如80%）时提前告警。

• 简单脚本示例 (/usr/local/bin/check_disk.sh)：

#!/bin/bash
THRESHOLD=80
USAGE=$(df / | grep / | awk '{ print $5 }' | sed 's/%//g')
if [ $USAGE -gt $THRESHOLD ]; then
echo "警告：根分区使用率 ${USAGE}% 超过 ${THRESHOLD}%" | \
mail -s "工控机磁盘空间告警" admin@yourcompany.com
# 或集成到企业微信、钉钉、SNMP等
fi

• 加入Cron定时任务：crontab -e 添加 0 * * * * /usr/local/bin/check_disk.sh （每小时检查一次）。

法则四：深度清理——识别并处理“日志大户”

定期分析哪些目录或文件最占空间。

• 快速定位命令：

# 查看/var/log目录下大小排序
sudo du -sh /var/log/* | sort -rh | head -10
# 查找大于100M的文件
sudo find /var/log -type f -size +100M -exec ls -lh {} \;

• 常见“大户”及处理：

• journal日志：已通过法则一控制。

• 容器日志（如果使用Docker）： Docker容器日志默认会无限增长。在/etc/docker/daemon.json中配置：

{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}

重启Docker：sudo systemctl restart docker

• 特定应用缓存或临时文件：检查应用自身配置，设定清理策略。

法则五：归档与审计——满足合规性要求

对于需要长期保留用于审计或故障分析的日志，不能一删了之。

• 使用logrotate的olddir指令：将轮转后的压缩日志移动到专门的、容量更大的归档存储分区或网络存储（NFS）。

• 集成日志管理平台：对于大型工业系统，考虑将关键日志实时发送至外部的ELK Stack（Elasticsearch, Logstash, Kibana）、Graylog或Splunk等中央日志管理平台。这既释放了本地磁盘空间，又提供了强大的搜索、分析和可视化能力。

三、 实施路线图与风险规避

• 评估与规划：首先使用df和du命令全面了解当前磁盘使用情况和日志分布。

• 分步实施：先在测试环境验证配置，然后按“监控告警 -> 配置journald -> 配置logrotate -> 处理特殊应用”的顺序在生产环境实施。

• 风险规避：

• 切勿直接rm -rf /var/log/*：这可能导致运行中的服务报错。

• 保留足够的日志周期：根据故障排查和合规要求设定保留时间，工业环境建议关键日志至少保留30天。

• 配置后务必测试：测试日志是否能正常轮转、应用是否能在轮转后继续写入日志。

• 文档化：记录所有变更的配置和清理策略。

Linux工控机系统盘写满的问题，本质上是一个运维管理问题。通过实施上述以预防性监控、自动化轮转清理、集中化归档为核心的“黄金配置法则”，可以将这一被动救火的问题转化为主动、优雅的系统管理流程。这不仅保障了系统的稳定运行，也为工业现场的故障追溯与性能分析保留了清晰、有序的数据线索，是构建高可靠工业软件基础设施不可或缺的一环。记住，对待日志，要像对待生产线上的物料流一样，设计好它的“流入、存放、流转和流出”的全生命周期管理。