运维工作里有一类问题，说大不大，说小不小，但碰上了就让人头疼——磁盘满了。而磁盘满的原因里，日志文件占据了相当大的比例。无论是应用程序输出的运行日志，还是各类中间件记录的事件，抑或是操作系统自身的系统日志，它们都遵循一个规律：只增不减，永不停歇。
早期的处理方式很简单，发现磁盘告警了，登录上去手动清理。找到那个最大的日志文件，执行清空或者删除操作，然后重启一下相关的服务。这一套流程下来，少则几分钟，多则半小时。如果运气不好，清理完才发现服务写日志的进程还握着已删除文件的句柄，磁盘空间压根没释放，还得额外花时间处理。
后来觉得手工操作太原始，开始用定时任务配合简单的查找删除命令。设定一个时间点，每天执行一次，把超过若干天的日志文件找出来删掉。这个方案看起来解决了问题，但用久了会发现有不少缺陷。最典型的是缺乏灵活性，有些日志文件虽然时间戳在几周前，但文件大小可能只有几百字节，保留着其实也无妨；另一些日志文件即便只存在了两天，体积可能已经膨胀到了好几个吉字节，光看天数来清理显然不够精确。
另一个隐藏的问题是，直接删除文件有时候会带来麻烦。某些应用程序在日志文件被删除后，不会自动创建新的日志文件，而是持续向已经不存在的文件描述符写入数据，导致日志丢失的同时还可能产生异常。更稳妥的做法应该是清空文件内容，而不是删除文件本身。这个区别，在手动操作或者简单命令里往往容易被忽略。
基于这些痛点，最终决定自己写一个更合适的工具。核心目标很明确：在不影响业务正常运行的前提下，安全、可配置地清理过期的日志文件，保持磁盘使用率始终处于健康水平。
工具的设计思路主要围绕几个维度展开。第一个维度是时间，日志文件存在多久算过期，这个阈值应该可以由使用者自由设定，比如保留最近七天的日志，或者保留最近三十天的。第二个维度是空间，当磁盘的使用率达到某个警戒线时，即便日志文件没到设定的保留天数，也应该触发清理动作。第三个维度是文件内容本身，清理时优先删除体积最大的文件，因为这类文件占用的空间最多，释放效果也最明显。
实现上，这个工具被设计成一个独立的执行程序，不依赖任何外部服务，只靠系统本身提供的文件操作能力来完成工作。它的工作流程大致如下：
首先，扫描指定目录下的所有日志文件。为了准确识别哪些是日志文件，工具支持多种判断方式。最常见的是通过文件扩展名来筛选，比如以点log结尾的文件；也支持通过文件头部特征来识别纯文本格式的日志；还可以让使用者提供一个正则表达式，自定义匹配规则。
扫描完成后，工具会收集每个文件的关键信息，包括文件路径、文件大小、最后修改时间、文件所有者和权限等。这些信息将被用于后续的清理决策。
接下来是决策阶段。工具会读取预先配置好的策略文件，策略文件中定义了清理规则。最简单的规则是按时间清理，比如保留最近十四天的日志，超出这个时间范围的就会被标记为待清理。稍微复杂一点的规则是按磁盘使用率清理，设定一个目标使用率，比如百分之八十，如果当前磁盘使用率超过了这个值，工具就开始计算需要释放多少空间才能回到目标值，然后从最老的或者最大的日志文件开始，逐一标记，直到预计释放的空间满足要求为止。
还有一种常用的策略是混合模式，同时考虑时间和空间两个因素。举个例子，设定保留至少三十天的日志，但无论是否满三十天，只要磁盘使用率超过百分之八十五，就强制清理，清理时优先删除那些既大又老的文件。这种模式在实际使用中最灵活，能够应对各种突发情况。
决策完成后，工具进入执行阶段。执行清理动作时，工具并不是简单地调用删除命令。它会先检查目标日志文件当前是否正在被写入。这个检查通过查看文件打开状态来实现，如果一个文件正被某个进程以写模式打开，直接清理可能会引发问题。对于这类文件，工具会跳过清理，并将其记录到例外日志中，供运维人员后续排查。
对于可以清理的文件，工具默认采用清空内容的方式，而不是删除文件本身。清空操作通过截断文件至零字节实现，这样文件依然存在，只是内容被清除了，持有该文件句柄的进程可以继续向其中写入新的日志，不会出现日志丢失或者服务异常的情况。当然，如果使用者明确要求删除文件，工具也支持删除模式。
整个清理过程会生成详细的执行报告。报告内容包括扫描到的文件总数、总大小、被标记为待清理的文件列表、每个待清理文件的清理原因、实际清理后释放的空间大小、清理过程中遇到的异常以及跳过清理的文件及其原因。这份报告可以输出到标准输出，也可以写入指定的日志文件，还可以通过外部命令发送到更远的地方。
为了让这个工具真正融入运维体系，还需要考虑它的部署和运行方式。最轻量的做法是将编译好的二进制文件分发到各个服务器上，配合定时任务按固定的时间间隔执行，比如每小时运行一次。也可以将其封装成一个系统服务，由进程管理工具来守护，这样即使清理工具本身意外退出，也能被自动重启。
在实际运行过程中，有几个细节值得特别注意。第一个是对符号链接的处理。某些环境里，日志文件可能通过软链接指向另一个位置，如果清理工具直接处理符号链接本身，效果可能不符合预期。工具对此做了区分，当遇到符号链接时，默认跟随链接，处理其指向的真实文件，同时对链接本身不做任何修改。
第二个是对压缩日志的处理。很多日志轮转机制会在日志文件达到一定大小后将其压缩归档，形成以点gz结尾的压缩文件。这类文件虽然也是过期日志，但体积已经被大幅压缩，清理的优先级应该低于未压缩的原始日志文件。工具在扫描时能够识别常见的压缩格式，并根据压缩后的实际大小来评估清理的收益。
第三个是清理操作的原子性和安全性。工具在执行删除或清空前，会先尝试对文件进行一个短暂的锁定操作，如果锁定成功说明没有其他进程在频繁读写该文件，可以安全清理；如果锁定失败或者超时，则说明文件正处于高频率访问状态，这种情况下跳过清理是更安全的选择。
经过一段时间的实际使用，这个工具带来的改变是明显的。磁盘使用率从过去经常突破百分之九十甚至百分之九十五的状态，稳定在百分之六十到百分之七十之间。更重要的是，运维人员不再需要在深夜被磁盘告警叫醒，也不用担心某个日志文件因为忘记清理而导致服务不可用。磁盘空间问题，从一个反复发作的慢性病，变成了一个不需要操心的事情。
当然，任何工具都不可能一劳永逸地解决所有问题。日志清理工具解决了磁盘被写满的问题，但日志本身的价值问题依然存在。哪些日志需要保留，保留多久，哪些日志根本不需要记录，这些是更上层的问题，需要应用程序的设计者和运维人员共同定义。清理工具能做的，是在既定的规则下，安全、高效地执行清理动作，让磁盘永远有空间容纳真正有价值的数据。
回顾这个过程，最初只是为了解决一个频繁出现的磁盘告警问题，后来逐渐演变成了一个相对完整的日志生命周期管理工具。它不需要复杂的外部依赖，配置起来足够灵活，运行起来足够安全，这就达到了当初设计的目标。如果正在阅读这篇文章的你也遇到过磁盘被日志撑满的烦恼，不妨考虑构建一个类似的工具，它可能不会是最耀眼的那个系统组件，但一定是最能让你安心睡觉的那个。
