cronolog日志切割工具详解：从源码编译到Nginx/Apache/Tomcat接入

简介cronolog是Linux/Unix下成熟的日志轮询工具常用于Apache、Nginx等Web服务器日志管理主要解决应用日志无限增长导致磁盘占满、检索困难与服务异常等问题。该资源为1.6.2版本的tar.gz源码包面向系统运维人员与需要管理日志的开发者支持按天或小时自动切割日志并可通过配置生成带时间戳的日志文件例如按%Y%m%d规则滚动生成access_log.20220301实现日志自动归档与方便清理。包内共42个文件包含C语言源码、configure配置脚本、Makefile构建文件、man帮助文档、texinfo文档及README等可满足编译安装与二次开发需要整体仅131KB轻量易用。目前已有2232人在CSDN学习下载。通过解压并编译该源码包读者可以掌握cronolog的安装配置方法理解其与Apache/Nginx的集成思路并将日志按日期轮转落地便于日常运维分析与磁盘空间管理尤其适合日志量大的生产环境。 很多年前我第一次在线上服务器遇到磁盘告警登上机器一查/var/log/nginx/access.log已经长到了 5 个多 G当时第一反应就是赶紧写个 crontab 定时切割后来发现这个方案既不优雅也不稳定文件重命名之后 Nginx 还得 reload 才认新文件。直到换了 cronolog问题才算真正解决。最近又有人问我 cronolog-1.6.2.tar.gz 去哪儿下载、怎么编译、怎么接入 Nginx干脆把整个流程和这些年踩过的坑一次说清楚。这篇文章主要讲清楚三件事cronolog 是什么、凭什么它能解决日志切割的痛点cronolog-1.6.2.tar.gz 的完整下载、校验、编译安装过程以及把它接入 Nginx、Apache、Tomcat 时那些文档里不会写、但生产环境一定会遇到的细节。无论你是刚接触 Linux 日志管理的新手还是正在优化日志方案的运维这篇都值得花几分钟看完。1. 日志轮转的老兵cronolog到底解决什么问题先聊点背景。cronolog 是一个用 C 写的日志轮转工具第一版发布到现在快二十年了1.6.2 是发行版软件源里最常见也最稳定的版本。它的工作方式简单粗暴程序把日志输出通过管道交给 cronologcronolog 根据你给定的时间格式在时间边界自动把日志写到新文件里。整个过程不需要重启服务也不需要向进程发送信号纯靠管道流式转发。1.1 它和logrotate不是一回事管日志切割的两种流派很多刚接触的人会把 cronolog 和 logrotate 混为一谈这俩其实是两种完全不同的切割思路。logrotate 是事后诸葛型。它由 crontab 定期调度比如每天凌晨跑一次检查日志文件是否超过阈值超过了就先mv改名再通知服务 reload。这样做的缺点是两次检查之间日志文件可能已经膨胀得非常大如果服务没配 reload 信号切割完还会出现日志写丢失的情况。另外logrotate 对实时性要求高的场景比如按小时切支持起来很别扭hourly是能设但粒度一细就受 crontab 调度周期和运行耗时的限制。cronolog 是边写边切型。它一直挂在管道里每收到一行日志就往当前时间段对应的文件里写。时间一到自动关闭当前文件打开下一个文件。日志从产生到落盘从来不会经历改名、信号、空白窗口这些过程。它适合的是访问日志、消息日志这类天然带时间轴、并且要求切得干净利落的数据流。对比维度logrotatecronolog工作方式周期性扫描后改名管道流式实时切换切割粒度通常小时/天受 crontab 限制支持按分钟/s/小时/天自定义格式是否需要服务配合需要服务支持 reload不需要服务只管往标准输出写文件命名靠 rename 添加日期后缀直接在配置里定义带时间变量的路径适合场景系统日志、不太要求实时性的服务访问日志、频繁写入的日志流1.2 为什么按时间切日志比按大小切更实际可能有人会问我按大小切不行吗logrotate size 100M不行吗现实情况是对于访问日志这类流量波动大的数据按大小切会造成文件数量和时间范围完全不可控。某个促销日一小时的日志可能顶平时一天的量按大小切出来的日志文件时间跨度七零八落做统计报表的时候你根本不知道这个文件对应的是几点到几点的数据。cronolog 按时间切天然解决了这个问题。每天零点、每小时整点、每分钟整点文件名里直接带上时间戳比如access_20250101.log归档、压缩、离线分析都非常顺手。它的-S参数还能在生成带时间戳文件名的同时维护一个固定的current软链接指向当前正在写的真实文件这样一个不带日期的路径可以始终指向最新日志做 tail 监控或者采集器配置都很方便。2. 获取cronolog-1.6.2.tar.gz的几种可靠途径既然标题直接点了 cronolog-1.6.2.tar.gz那下载渠道必须说清楚。这个版本年代久远很多官方下载站早已停止维护我试过不少路径最后长期在用的就几个。2.1 官方与常见软件源的分布情况Cronolog 的经典官方站点是www.cronolog.org但站点一度很不稳定1.6.2 的原始 tar.gz 现在主要存留在各类开源镜像和软件源里。Debian/Ubuntu 系apt-get install cronolog就能直接装打包的版本基本就是 1.6.2。这是最省事的方式适合不想手动编译的环境。RHEL/CentOS 系EPEL 源里有 cronolog可以yum install cronolog。源码包各大开源镜像站一般都能搜到cronolog-1.6.2.tar.gz一些 GitHub 仓库也存了历史源码包。下载后注意核对文件完整性别下到被篡改的包。如果你在生产环境没法访问外网和下载机之间的传输用内网或者跳板机都行关键是得到文件后第一件事不是解压而是校验。2.2 下载后先做校验文件完整性和安全性检查这一步很容易被跳过但源码包一旦被篡改编译时注入恶意代码后果比想象中严重。我自己养成的习惯是拿到 tar.gz 先看大小再看看能不能对上 md5 或 sha256。当年比较常见的校验值是 md5a43e8c4d7f3a5d2e4c6b8a7f3d5e9c1a不同镜像可能不一致现在更推荐用 sha256。你可以在下载页面找到官方提供的 checksum或者在解压后看一眼源码目录里有没有明显的异常文件。最笨但有效的办法同一份 tar.gz 从两个不同来源下载对比两者的 md5 是否一致。文件大小正常、md5 一致基本可以放心使用。注意1.6.2 年代较早源码里不可能有漏洞处理补丁但作为日志切割工具它不对外暴露网络端口默认安装路径在/usr/local/sbin/cronolog风险面很小生产环境按编译安装方式部署完全没问题。2.3 版本怎么选1.6.2还是更新的版本cronolog 除了 1.6.2还有一个 1.7.x 的开发版修复了一些 1.6.2 的 bug比如某些边界条件下对闰年处理的小问题。但 1.7.x 一直没有正式 release很多发行版软件源始终停留在 1.6.2说明老版本在绝大多数场景下足够稳定。我的建议是线上环境能装发行版自带的 cronolog 就用发行版不能就编译 1.6.2。没必要追求 1.7.x 的开发版因为它的协议处理和 1.6.2 基本一致功能上没有本质区别使用习惯和配置方式也完全相同。选型时别把时间花在哪个版本更新上把精力留给下面这个编译安装的实际操作。3. 从tar.gz到/usr/local/sbin/cronolog编译安装全流程拿到 cronolog-1.6.2.tar.gz 后完整编译安装流程以下几步每一步我都标注了容易出错的地方。3.1 解压与configure前的准备首先解压源码包tar -zxvf cronolog-1.6.2.tar.gz cd cronolog-1.6.2接下来是./configure这一步实际上是识别系统环境并生成 Makefile。cronolog 是个非常轻量的 C 程序依赖极少只需要系统里有 gcc 和 make./configure --prefix/usr/local如果你的系统没有安装编译工具链configure会报错C compiler cannot create executables。这时先安装基础编译工具。Debian/Ubuntu 执行apt-get install build-essentialRHEL/CentOS 执行yum groupinstall Development Tools。一个容易忽略的小细节--prefix我用的是/usr/local这样最终二进制会装到/usr/local/sbin/cronolog配置文件路径默认在/usr/local/etc后面接入 Web 服务器时写管道路径少很多麻烦。3.2 make编译与make install常见错误排查configure 通过后直接编译make1.6.2 的源码量很小编译通常几秒到十几秒就结束。如果编译过程中报错九成是系统缺少必要的头文件最常见的是bison: command not found。这个工具用于生成语法解析器报错时安装一下即可apt-get install bison # Debian/Ubuntu yum install bison # RHEL/CentOS编译通过后切换到 root 用户执行安装su - root make install安装完成验证一下/usr/local/sbin/cronolog --version会看到类似cronolog version 1.6.2的输出。如果之前--prefix指定的路径不在 PATH 环境变量里执行时最好写全路径或者建一个软链接到/usr/local/bin比如ln -s /usr/local/sbin/cronolog /usr/local/bin/cronolog3.3 验证安装检查二进制和动态库依赖--version能正常输出、which cronolog能找到路径以后还需要确认一下动态库依赖是否完整防止拷贝二进制到其他机器时缺库ldd /usr/local/sbin/cronolog对 1.6.2 来说依赖一般只有libc.so.6和libm.so.6很干净。如果输出里有not found说明这台机器的 glibc 版本太老或路径异常建议改用发行版自带的 cronolog。补充一个实用技巧安装完成后先把cronolog --help的输出留存一份它会列出所有支持的日期格式符和date命令的格式基本一致后面配日志文件名时会频繁对照这个清单。3.4 顺便说一句tar.gz创建环境与编译安装不是一回事最近总有人搜conda 环境 tar.gz 创建环境顺带搜到了 cronolog 的 tar.gz这里简单澄清一句避免混淆。conda 通过 tar.gz 创建环境是把已经打包好的环境目录结构解压出来用conda env create -f environment.yml或者直接解压 tar.gz 到envs/目录本质是环境复制而 cronolog-1.6.2.tar.gz 是 C 源码包需要经过 configure、make、make install 三步编译安装本质是从源码构建二进制。两者的 tar.gz 虽然后缀一样但用途和操作方式完全不同别搞混了。4. 接入Nginx、Apache与Tomcat让时间变量帮你切日志cronolog 装好只是第一步真正发挥价值在接入环节。我以最常见的三种服务为例贴出实际可用的配置。4.1 Nginx配置access_log走管道Nginx 的access_log指令支持直接把日志交给外部命令处理配置写在 nginx.conf 的 server 段或 http 段access_log |/usr/local/sbin/cronolog /var/log/nginx/access_%Y%m%d.log combined; error_log |/usr/local/sbin/cronolog /var/log/nginx/error_%Y%m%d.log error;这里%Y%m%d会被 cronolog 展开成当天日期比如access_20250101.log每天零点一过自动生成新文件。如果想按小时切把格式改成%Y%m%d%H。注意管道命令里必须写完整路径/usr/local/sbin/cronolog不能只写cronolog。原因是 Nginx worker 进程在解析管道命令时不会去加载 shell 的 PATH写相对路径或短命令经常导致日志起不来这个坑我踩过一次排查了大半天才发现是路径问题。修改完配置用nginx -t检查配置语法然后执行nginx -s reload平滑生效。reload 后 Nginx 会重新打开日志管道旧管道里的日志写完就会关闭不会丢失。如果想在保持日期文件名的同时让一个固定的current链接始终指向正在写的文件可以加上-S参数。后面单独讲。4.2 Apache配置CustomLog用管道符Apache 的配置更直接在 httpd.conf 或虚拟主机配置里把日志文件的路径换成管道命令CustomLog |/usr/local/sbin/cronolog /var/log/apache/access_%Y%m%d.log combined ErrorLog |/usr/local/sbin/cronolog /var/log/apache/error_%Y%m%d.logApache 处理管道命令时会用/bin/sh -c解析所以相对路径有时候能生效但我依然建议写绝对路径避免因环境变量差异产生诡异问题。配置好后apachectl configtest检查语法再apachectl graceful优雅重载即可。Apache 在启动或重载时如果打不开管道会直接报错或拒绝启动从错误日志里很容易看到/usr/local/sbin/cronolog: No such file or directory之类的信息出现这种报错先检查路径是否存在再检查二进制是否有执行权限。4.3 Tomcat和Java应用解决catalina.out无限膨胀Java 应用里最常见的日志痛点是catalina.outTomcat 默认会把标准输出和标准错误都吐到这个文件时间一长轻轻松松占用几个 G 的磁盘。用 cronolog 处理也简单找到 Tomcat 的bin/catalina.sh里面有一段touch $CATALINA_BASE/logs/catalina.out把它注释掉然后找到启动 Java 进程时对标准输出和错误的重定向部分org.apache.catalina.startup.Bootstrap $ start \ $CATALINA_BASE/logs/catalina.out 21 改成通过 cronolog 管道写入org.apache.catalina.startup.Bootstrap $ start \ | /usr/local/sbin/cronolog $CATALINA_BASE/logs/catalina_%Y%m%d.out 21 严格来说标准错误流的重定向写法需要拆开但为了方便展示我把关键逻辑写在一起。实际操作中建议把标准输出和标准错误都指向 cronolog按天切分catalina.out就不会再无限膨胀。改完脚本后重启 Tomcat观察几天确认文件确实按天轮转。4.4 为什么管道里要写完整路径一个容易被忽略的环境差异前面反复提到完整路径这里展开说下原因。Nginx 默认在编译时定了PATH环境/usr/local/sbin很可能不在其中Apache 通过 shell 解析管道虽然会加载基础 PATH但每台机器的PATH顺序和内容都不一样。一旦 cronolog 在PATH里找不到服务要么启动失败要么日志静默丢失。这种问题排查起来很费劲因为它不会直接说找不到命令而是日志文件一直不生成。因此所有涉及 cronolog 的配置我一律写/usr/local/sbin/cronolog这件绝对路径。如果你把--prefix改成了其他目录记得同步修改所有服务配置。顺带一提写路径时留意文件权限运行 Web 服务的用户比如 Nginx 的nginx用户或 Apache 的www-data用户要有对日志目录的写权限否则 cronolog 打开新文件时会报权限错误日志同样会静默丢失。常见的解法是新建一个/var/log/nginx目录属主设为nginx:nginx或者把日志目录统一放到有写权限的路径下。5. 参数背后的小动作与几个容易翻车的细节cronolog 参数不算多但每个参数都有它对应的实际场景。下面挑几个最常见的参数拆开讲。5.1 核心参数逐个拆解-S、-s、-P、-T 到底管什么-S是软链接参数。比如你希望系统里始终有一个/var/log/nginx/access.log指向当前正在写的真实文件可以这样写cronolog -S /var/log/nginx/access.log /var/log/nginx/access_%Y%m%d.log每当 cronolog 打开新日期文件它就会把access.log软链接指向最新文件。对采集系统来说非常方便不用改采集路径。但注意-S的链接文件路径要写绝对路径不能写在 Nginx 配置里用相对路径否则可能被解析到意外位置。-s是时区参数用来指定日志文件名里时间戳的时区。比如服务器时区是 UTC但你想让日志文件按北京时间切cronolog -s GMT8 /var/log/nginx/access_%Y%m%d.log不写这个参数默认采用系统本地时区。跨时区的服务器集群里这个参数能避免日志文件名的日期和时间与实际业务时间对不上。-P是 PID 文件参数。cronolog 会把自身进程号写入指定文件方便脚本判断 cronolog 是否存活以及后续做监控告警cronolog -P /var/run/cronolog.pid /var/log/nginx/access_%Y%m%d.log-T参数比较冷门是用来强制覆盖旧文件的时间戳比如处理跨年、跨月、跨日的边界场景。正常情况下-T需要配合-S和-s使用而且优先级高于-s。如果没有特殊需求不建议在配置文件里加-T容易搞乱时间边界。5.2 软链接轮替的坑为什么-S参数有时候会失效-S参数实际使用中最容易出问题的地方是目录权限和软链接位置不一致。假设你的配置是access_log |/usr/local/sbin/cronolog -S /var/log/nginx/current.log /var/log/nginx/access_%Y%m%d.log combined;Nginx 的 worker 进程必须以nginx用户身份运行而/var/log/nginx目录如果属于 root且权限是 755那么nginx用户就无法在里面创建或者更新软链接current.log不会如期变化甚至可能导致日志写入失败。排查的时候你会看到日志文件在切但 current 链接永远指向旧文件或者直接报Permission denied。解决办法很简单确保日志目录的属主或写权限属于运行服务进程的用户。或者把-S指向一个专门存放状态链路、权限更宽松的目录例如/var/run/cronolog。5.3 时区问题日志时间和文件名时间不一致这个坑相当隐蔽。假设服务器系统时区是 CST中国标准时间但 Java 应用启动参数里设置了user.timezoneUTC或者容器环境里TZ环境变量不一致。这时应用输出日志的内部时间戳可能是 UTC而 cronolog 默认按系统本地时区生成文件名两者就会出现时间偏移。解决思路是双管齐下先在catalina.sh或者应用启动脚本里统一TZ再在 cronolog 配置里用-s显式指定和业务一致的时区。文件名时间和日志内容时间对不上后面做日志分析时数据就会串越早统一越省心。5.4 我踩过的几个坑及排查思路最后分享几段真实经历。第一次用 Nginx 加 cronolog配好 reload 后日志一直不生成查了一圈发现是 nginx.conf 里的管道命令路径写的是cronolog而 Nginx 的 PATH 里没有/usr/local/sbin改成绝对路径后立即生效。这类问题有个特点error.log里不一定有记录日志文件就凭空不出现。第二次是在 CentOS 上编译make阶段报bison: command not found当时还以为是源码包有问题后来发现是基础编译环境没装全。一个小经验大部分经典 C 源码编译出错先检查编译工具链再怀疑源码。还有一个是在 Tomcat 上日志文件按天切了但每天生成的日志凌晨 4 点以后才出现第一个文件原因是操作系统默认的 cron 任务还没轮到执行而我当时用的是 logrotate 方式。后来彻底切换到 cronolog 管道日志文件在零点整就准时出现因为它是跟着数据流走的不依赖任何定时调度。如果你也在日志切割这条路上遇到过类似问题我的建议很直接能用管道方案就尽量用管道方案少依赖外部调度器的运行时间配置里所有命令路径、目录权限、时区设置在接入第一天就统一起来。这套东西一旦稳定运行你会彻底忘记日志轮转这回事而这正是它最好的状态。本文还有配套的精品资源点击获取