说实话看到caveman这个标题的时候我脑子里最先蹦出来的不是原始人也不是某个开源项目的代号而是技术圈里那句带着自嘲意味的老梗“caveman debugging”——遇到问题不搞花里胡哨的调试器直接丢一堆print语句把中间变量打出来看。话糙理不糙这套“穴居人式”的解决问题思路恰恰是我这些年踩坑踩出来的最实用方法论之一。这篇就用“caveman”作为引子聊聊我最近做的一个小项目用最原始、最笨、但极其稳的方式搭一套零依赖的日志归档与清理工具同时把这套“极简优先”的决策逻辑也一并拆给你看。内容适合正在被“过度设计”折磨的后端开发、运维以及所有觉得“工具越用越复杂”的人。你会发现很多时候回到最基础的标准库、最朴素的命令组合反而能让事情变得清爽可靠。1. 项目概述caveman不是落后是拒绝无效复杂度1.1 “穴居人方案”到底指什么先说清楚caveman这个词在这里的含义。它不是让你真的回到石器时代而是指一种主动选择的极简策略在动手解决问题之前先问自己一句“能不能用最直接、最少依赖的方式先跑起来”。这个思路在英文技术社区里有个非常形象的词——caveman debugging字面意思是穴居人调试法指的就是不依赖重型工具、靠最原始的手段快速定位问题。我这次做的日志归档工具就是这种思路的典型实践。背景很简单一台长期运行的Linux服务器上某个应用每天产生大量日志文件几个月下来积了上百GB磁盘眼看要满。常规做法是什么上ELK、配Logrotate、写复杂的采集管道、加对象存储生命周期规则……这一套下来光前期搭环境就得牺牲一个周末。但退一步想我当时的核心诉求其实特别朴素磁盘别满日志别丢旧文件该压缩压缩该清理清理。需求就三条却容易被人为放大成“一套完整的日志治理体系”。caveman方案的第一个原则就是把需求打回原形只解决当前必须解决的问题不为想象中的未来过度买单。1.2 什么时候该用什么时候不该用这套极简方案绝不适合所有场景。如果你的项目处于快速迭代期、需要多人协作维护、对可观测性有强要求那老老实实上成熟框架才是正路。caveman方案最适合的是个人维护的小型应用、一次性任务、原型验证阶段、或者那些“你只需要它跑三个月”的临时系统。我这次处理的那台服务器就是个典型的一次性场景——一个内部活动用的数据采集服务生命周期也就一个季度。对这种任务去搭建完整的日志收集链路就像为了修个漏水的水龙头去重新铺设整栋楼的管道纯粹是给自己找麻烦。判断要不要用caveman方案我自己有三个标准一是可抛弃性这套东西坏了能不能随手重写一份二是可读性三个月后的自己或同事能不能十分钟内看懂它是干嘛的三是可恢复性出了故障能不能用最基础的命令把问题解决掉。三个条件都满足那就别犹豫果断砍掉复杂方案。2. 核心拆解从糙快猛到精快稳的选型逻辑2.1 三个判断标准可抛弃、可读、可修具体到日志归档这个工具我是怎么套用这三个标准的呢先说可抛弃我要求自己只用Python标准库和Shell命令不引入任何第三方pip包、不装额外的代理程序。这意味着万一系统重装、Python版本升级这段代码改改就能跑不存在“某个依赖库不再维护了导致整个工具瘫掉”的隐患。再说可读性。我给自己定了个规矩整个脚本不超过200行函数不超过5个变量名用绝对直白的单词组合——archive_dir、max_days、target_size这种看名字就知道含义完全不需要额外注释来解释业务逻辑。甚至在文件头部只写了三行说明用途、运行方式、责任人。写完后我专门让一个不熟悉这块业务的同事看了一遍他能在不看任何外部文档的情况下说出这个脚本的大致行为可读性就算过关了。最后是可恢复性。这一点老运维最有体会。很多复杂工具出了故障你根本不知道从哪儿排查起——是管道断了权限不对还是哪个组件悄悄升级改了配置而我这个“穴居人”脚本每一步都对应一个明确的Shell命令测试压缩包完整性就用tar -tzf检查文件数量就用ls | wc -l验证定时任务就用crontab -l。任何一步出问题都可以用最小粒度的命令单独验证半小时内定位到根因。这种“出事儿了我不慌”的底气比任何花哨的功能都值钱。2.2 工具链选择的对比标准库 vs 重型框架这套caveman工具核心由两部分组成一个Python脚本负责归档和清理逻辑一个Cron定时任务负责触发。Python我选了3.6自带的标准库包括os、shutil、glob、gzip、datetime、argparse全部原生支持连虚拟环境都不用建。为什么不选更炫的方案我整理了一张当时的对比表方案依赖数量部署复杂度排查难度维护成本适合场景Python标准库脚本0低低低中小型服务器、临时任务Shell脚本findcron0最低低低极简场景、纯文件操作Logrotate1系统自带低中中系统级日志轮转自定义Python包5~8中中中有特殊归档格式需求ELK/文件采集管道15高高高大规模日志分析平台你会发现Shell脚本其实可以处理更简单的场景但一旦涉及多目录遍历、按日期精确计算、压缩前后校验这些逻辑Shell写起来既绕又容易出坑。Python标准库在“复杂度/可维护性”之间取得了一个平衡点——对于日志数量上千、目录层级超过三层的场景它比Shell更清晰却比引入第三方库轻量得多。这就是我当时拍板选它的理由。3. 实操过程用caveman思路写一个零依赖日志归档工具3.1 需求分析与设计目标我落地这个工具时服务器上的日志分布是这样的应用日志在/data/logs/app/目录下每天一个子目录比如2025/06/01/里面按模块分文件比如auth.log、order.log、payment.log另外有个单独的目录/data/logs/archive/用来放历史归档包。当前总占用约180GB服务器磁盘总共400GB已经用掉85%了。需求拆到最后就只有四条硬指标将30天前的日志文件进行gzip压缩生成.tar.gz归档到/archive目录归档完成后删除原文件释放磁盘空间90天前的归档包自动清理防止archive目录无限膨胀每次运行输出一份简洁的统计报告包含处理了哪些文件、释放了多少空间、清理了多少旧压缩包。这里有个容易被忽略的点很多初写这类脚本的人会把“压缩”和“归档”混为一谈。压缩是指把单个文件或一批文件打包变小归档是指把它们按照时间维度重新组织存放。这两个动作拆开还是合并直接决定了脚本结构的复杂度。我选择用tar打包整个日期的子目录并压缩这样同时完成两个动作而且保留了目录结构和原始文件名后续如果要回溯某一天某个模块的日志直接解压对应日期包就行不用在一堆散乱文件里大海捞针。3.2 核心代码实现与参数计算下面直接上代码这个脚本是我实际在服务器上运行的版本去掉了业务相关的敏感信息保留核心逻辑。#!/usr/bin/env python3 # -*- coding: utf-8 -*- caveman_log_archiver.py 用途归档指定目录下超过归档阈值的日志子目录并清理过期归档包 运行方式python3 caveman_log_archiver.py --log-dir /data/logs/app --archive-dir /data/logs/archive --archive-days 30 --cleanup-days 90 import os import shutil import tarfile import re import argparse import datetime import sys def parse_options(): parser argparse.ArgumentParser(description归档并清理日志文件) parser.add_argument(--log-dir, requiredTrue, help日志根目录) parser.add_argument(--archive-dir, requiredTrue, help归档根目录) parser.add_argument(--archive-days, typeint, default30, help归档阈值默认30天) parser.add_argument(--cleanup-days, typeint, default90, help清理归档包阈值默认90天) return parser.parse_args() def date_from_dirname(path): 从路径中提取YYYY/MM/DD格式的日期 dir_path os.path.normpath(path) parts dir_path.split(os.sep) # 取最后三个部分作为日期 if len(parts) 3: return None date_part parts[-3:] try: year int(date_part[0]) month int(date_part[1]) day int(date_part[2]) # 做一次合理性校验避免路径恰好是三个数字目录导致误判 return datetime.date(year, month, day) except (ValueError, TypeError): return None def archive_log_dir(log_path, archive_base): 将单个日期目录打包压缩返回文件大小 date_obj date_from_dirname(log_path) if date_obj is None: return None archive_sub_path os.path.join(archive_base, str(date_obj.year), f{date_obj.month:02d}) os.makedirs(archive_sub_path, exist_okTrue) archive_name fapp_log_{date_obj.strftime(%Y%m%d)}.tar.gz archive_path os.path.join(archive_sub_path, archive_name) if os.path.exists(archive_path): print(f[SKIP] 已存在: {archive_path}跳过) return None try: with tarfile.open(archive_path, w:gz) as tar: tar.add(log_path, arcnameos.path.basename(log_path)) size_bytes os.path.getsize(archive_path) # 确认打包成功后再删除原目录失败则删除半成品包 shutil.rmtree(log_path) print(f[ARCHIVE] {log_path} - {archive_path} ({size_bytes/1024/1024:.1f} MB)) return size_bytes except Exception as e: # 打包或删除失败清理半成品包防止目录残留和包残留 if os.path.exists(archive_path): os.remove(archive_path) print(f[ERROR] 处理 {log_path} 失败: {e}, filesys.stderr) return None def cleanup_old_archives(archive_base, cleanup_days): 清理指定天数前的归档包 cutoff_date datetime.date.today() - datetime.timedelta(dayscleanup_days) removed_count 0 removed_size 0 # 遍历归档目录下的文件文件名格式为 app_log_YYYYMMDD.tar.gz for root, dirs, files in os.walk(archive_base): for fname in files: if not re.match(r^app_log_\d{8}\.tar\.gz$, fname): continue try: date_str fname.split(_)[2].split(.)[0] file_date datetime.datetime.strptime(date_str, %Y%m%d).date() except (IndexError, ValueError): continue if file_date cutoff_date: full_path os.path.join(root, fname) fsize os.path.getsize(full_path) os.remove(full_path) removed_count 1 removed_size fsize print(f[CLEANUP] 删除过期归档: {full_path} ({fsize/1024/1024:.1f} MB)) return removed_count, removed_size def main(): args parse_options() archive_threshold datetime.date.today() - datetime.timedelta(daysargs.archive_days) log_dirs [] # 遍历日志根目录下所有 YYYY/MM/DD 结构 pattern os.path.join(args.log_dir, *, *, *) for dir_path in sorted(glob.glob(pattern)): if not os.path.isdir(dir_path): continue date_obj date_from_dirname(dir_path) if date_obj is None: continue if date_obj archive_threshold: log_dirs.append(dir_path) print(f[INFO] 本轮共发现 {len(log_dirs)} 个过期日期目录) total_archived_size 0 archived_count 0 for log_dir in log_dirs: result archive_log_dir(log_dir, args.archive_dir) if result: total_archived_size result archived_count 1 removed_count, removed_size cleanup_old_archives(args.archive_dir, args.cleanup_days) print(f[SUMMARY] 归档 {archived_count} 个目录压缩后总大小 {total_archived_size/1024/1024:.1f} MB释放原目录空间约 {archived_count * 100} MB按目录估算) print(f[SUMMARY] 清理过期归档 {removed_count} 个释放 {removed_size/1024/1024:.1f} MB) print(f[DONE] 本次运行完成于 {datetime.datetime.now().isoformat()}) if __name__ __main__: main()这个脚本里藏着几个关键的参数计算逻辑我说细一点。首先是--archive-days 3030天前这个阈值怎么定不是拍脑袋我当时的计算方法是日志总量180GB平均每天产生约2GB服务器磁盘400GB当前使用85%。如果保留30天原文件那么日志目录最多占60GB左右加上系统文件和其他数据磁盘使用率能压在75%以下安全余量充足。如果设成7天每天归档操作过于频繁磁盘也没那么紧张设成60天留存时间太长万一服务器故障需要快速排查时第40天的日志还躺在主目录里吃着磁盘。30天是个兼顾盘容和排查窗口的均衡点。再来说--cleanup-days 90归档包按天压缩后平均每个包大约400MB2GB原日志压缩后约20%压缩率。90天就是约36GB归档总量这个量级在archive目录里很轻松。要是设成180天archive目录会涨到70GB以上虽然也能承受但考虑到这台服务器生命周期只有三个月90天的清理阈值足够保证“服务结束的那天归档不会成为新的垃圾负担”。3.3 定时调度与告警联动脚本写好了剩下的就是让它按计划跑起来。我用的还是最传统的crontab# 每天凌晨2点执行一次日志归档 30 2 * * * cd /opt/scripts python3 caveman_log_archiver.py \ --log-dir /data/logs/app \ --archive-dir /data/logs/archive \ --archive-days 30 \ --cleanup-days 90 /var/log/caveman_archiver.log 21选凌晨2点的原因很朴素此时业务流量最低打包压缩对IO和CPU的影响几乎无感。我故意把输出重定向到一个独立的日志文件而不是直接丢弃这样出了问题还能回头查上次运行到了哪一步。这里有一个我在实际中栽过跟头的地方提醒各位注意cron环境下PATH环境变量很精简用相对路径或者依赖PATH找到python3很容易失败。我的解决方案是在脚本第一行写死绝对路径并在crontab里统一用绝对路径调用。这句话听着简单但真能救你一命——我见过太多同事的定时任务莫名“没跑”最后发现就是python3找不到。告警联动我用了更土的办法脚本跑完后会通过系统邮件服务给特定邮箱发一封摘要内容就是[SUMMARY]那几行。因为涉及告警方式不同服务器环境差异太大我这里就不贴具体代码了你完全可以用Shell里的mail命令甚至写纯文本到Webhook地址都行。总之核心思路是不引入额外的监控框架让关键事件能被人及时看见就够了。4. 常见问题与排查技巧实录4.1 四个高频问题速查我再实际跑了一段时间后把这个脚本和这类caveman方案常见的坑整理成一个速查表现象可能原因排查命令解决方法日志目录没有被归档日期目录层级不符合 YYYY/MM/DD 结构ls -R /data/logs/app | head -20调整目录结构或在脚本里增加配置映射归档包生成了但原文件没删shutil.rmtree权限不足手动执行 rm -rf 试权限确保运行用户对日志目录有写权限和删除权限cron里跑成功但手动执行失败cron环境变量、工作目录问题crontab -l精确查看PATH脚本内使用绝对路径设置固定工作目录压缩包内出现重复文件同一日期目录被多次打包tar -tzf 包名 | sort | uniq -d检查归档前是否已有同名包存在已存在则跳过第一类问题最隐蔽。因为日期目录可能是通过某个上游程序的自动创建逻辑生成偶尔会出现“2025-6-1”这种没有补零的格式那正则和日期解析就会直接跳过。我的应对策略是提前跑一条ls命令扫一眼实际目录名格式再决定是用名字解析还是日期解析避免脚本上线后才发现目录对不上。第二类权限问题更多出现在“脚本用root测试通过、放到cron里用专用用户执行就失败”的情况下。排查时要记得手动用执行用户的身份去跑一次命令模拟cron的权限环境而不是想当然用当前用户测试。4.2 独家的三个避坑心得这里分享三个我后来才真正理解的避坑心得属于常规文档里不会写清楚的层面的经验。第一个是关于“压缩包完整性校验”的。刚开始我以为只写tar -czf就行了但后来发现如果在打包过程中服务器突然断电会留下一个不完整但看似存在的tar.gz包。等到以后需要恢复日志时才发现包坏了那就彻底傻眼。caveman方案虽然讲究简单但不等于不要验证。我在archive_log_dir函数里加了一个“先打包成功再删原目录”的顺序控制并且在tar命令执行后立刻查验能打开和读取所有文件列表如果验证失败宁可删除半成品包也不让它占用空间。这一步叫“删除前自检”虽然多花几秒钟但比起将来数据丢失的代价这点时间微不足道。第二个是关于“时间语义”的陷阱。很多初写归档脚本的人会直接拿datetime.date.today()和文件时间戳比较。这招在普通场景行得通但一旦你的服务器跨时区或者日志文件本身带有UTC时间戳就会差出8个小时。我用的是“目录名的日期”而非“文件的修改时间”目录名是业务侧写死的日期代表日志真正产生的日期不受时区影响比文件mtime要稳定得多。这个细节你从上面代码里的date_from_dirname就能看出来。第三个是关于“自动清理的保险丝”。90天前的归档包被自动清理这个逻辑本身很合理但我给脚本加了一条硬保护在开始清理之前自动计算archive目录总大小如果总大小大于上一周的两倍说明可能有异常情况比如某个超大日志文件混了进来脚本就会拒绝执行清理并打印告警必须人工确认后才能继续。相当于给自动清理加了一个“熔断机制”防止“自动化把有效数据给清了”这种最糟糕的情况发生。5. 这个思路还能往哪儿延伸说完日志归档这个具体项目我想再说说caveman思路本身的延展空间。它绝不仅限在服务器运维里我在日常开发、数据清理、甚至文档整理上都用过类似逻辑。最直观的例子我认识一个做数据清洗的同事遇到一个批量文件需要重命名的任务大家第一反应是写个Python脚本用pandas结果发现问题只用标准库os.rename加两行glob就解决了。很多“复杂问题”被我们想象成了需要重工具但其实只是需要一个聪明的小脚本。这个思路还可以延伸成一套“工作量评估”的准则一个新需求找上门先假想用最原始的方式手撸一套如果手撸成本已经能接受就直接上如果不能再思考需要借助什么工具以及这个工具的哪些功能是核心不可替代的。这比一开始就规划“是整个日志平台还是分三步走”要高效得多。再进阶一点caveman不等于“永远只写一次性脚本”。当你的业务规模增长到不再“小”的时候经典方案自然会浮出水面。你的目标是识别那个临界点在此之前用caveman方案快速验证、快速交付、快速产生价值。之后迁移到正式方案时已经有了清晰的业务逻辑和流量数据迁移成本和风险反而更低。就我自己而言这个日志工具会一直跑在这台目标服务器上直到它生命周期结束。之后我大概率会把同样思路复制到其他临时项目上。你会发现在一次次“穴居人方案”的实践之后你对“什么才是真正复杂问题的本质”有了更敏锐的判断力——这可能是比任何工具本身都更值钱的收获。