UIS对/var/log目录下的日志没有固定的“多长时间清理一次”的说法，其核心管理逻辑是基于磁盘使用率阈值触发的自动清理。具体的清理机制和你需要关注的文件类型如下：

 UIS日志清理的核心机制：基于磁盘使用率自动触发

UIS的日志清理是空间驱动的，即：

• 触发条件：当/var/log分区的磁盘使用率超过80%时，系统会自动触发清理流程。

• 清理目标：系统会自动清理/var/log分区下的日志文件以释放空间。这通常意味着清理的是那些已被压缩、轮转或不再被当前服务锁定的旧日志文件。

版本差异提示：根据社区信息，/var/log分区的使用率告警阈值（80%）和自动清理机制在UIS 6.5等较新版本中已较为完善。但更早的版本（如UIS 6.5的E0712H01版本）可能存在特定日志压缩不完善的已知问题，导致/var/log/secure文件异常增长，需要升级到0716P03或更高版本才能彻底解决。

 主要清理的文件类型

在/var/log下，UIS可能会自动清理或你需要关注的文件主要有这几类：

• 历史压缩日志包：最常见的例子是Ceph存储相关的日志。当/var/log/storage/backup/ceph目录下积压了大量.gz压缩包文件时，系统会在空间不足时清理它们。

• 轮转后的日志文件：系统会通过logrotate等工具对日志进行“轮转”（如将messages重命名为messages.1，并创建新的messages）。轮转后，旧的.1、.2或.gz文件是系统自动清理的对象。

• 特定的大日志文件：官方案例中多次提到/var/log/secure文件（记录用户认证信息）会异常增长，是造成分区占满的常见原因之一，需要特别关注。

 手动清理的推荐方案

如果分区使用率持续高企但自动清理未触发，你可以通过以下方式手动介入：

1. 安全清空正在使用的大日志文件
   这是处理单个日志文件过大的推荐方式。首先通过cd /var/log进入目录，然后使用du -sh *命令找出占用空间较大的文件。接着，通过echo "" > /path/to/large/logfile.log命令安全清空它。此方法无需重启服务，日志文件会立即被清空，正在写入的进程会继续正常工作。

2. 使用journalctl管理systemd日志
   如果systemd-journald日志（通常位于/var/log/journal/）占用过高，可以使用journalctl命令管理。通过journalctl --vacuum-time=7d可清理7天前的日志，journalctl --vacuum-size=500M可限制日志总大小不超过500MB，journalctl --rotate则可强制立即轮转。

3. 配置logrotate（高级）
   如需自定义轮转策略，可编辑/etc/logrotate.conf或在/etc/logrotate.d/目录下创建配置文件，来指定日志文件的轮转频率、保留份数和是否压缩等。

H3C UIS 0886P06 /var/log 清理策略

⏱️ 清理周期

• 默认频率：每日凌晨 1 点自动检查并执行清理
• 触发条件：满足任一阈值即触发（先到先得）
  1. 日志存储天数超期（优先按时间清理）
  2. 日志存储空间占比达 90%（按空间阈值清理）H3C

📋 清理范围与保留规则

🔧 核心机制与安全操作

1. 底层依赖：系统通过 /etc/logrotate.conf 及 /etc/logrotate.d/ 下的配置文件统一管理，每日由 crontab 自动调用
2. 安全清理原则
   • 压缩日志（.gz）可直接删除，未压缩日志建议用 > 日志名 置空，避免句柄异常
   • 禁止手动删除 /var/log 下正在写入的活跃日志文件
3. 自定义调整路径
   • 管理平台：进入 “系统配置→全局配置→数据清理”，可修改各类型日志存储天数与空间阈值（50%~90%）H3C
   • 底层配置：编辑 /etc/logrotate.d/ 下对应服务配置（如 uis、syslog），调整轮转频率、保留数等，修改后无需重启服务

🛠️ 快速验证与手动执行