修改Zookeeper输出日志 zookeeper.out输出路径【转】

使用过zookeeper的小伙伴都知道，当前终端处于哪个目录，执行完zkServer.sh start命令， zookeeper.out就会写在哪个目录，下次想看zookeeper日志的时候，又忘记上次在哪执行的命令啦，这真的很蛋疼（虽然可以每次固定在某个目录执行），在多次痛苦之后，决定修改日志输出到固定目录，方便问题定位。

 

查看bin目录下的zkEnv.sh找到了这一行，发现如果没有配置ZOO_LOG_DIR，默认就是保存在终端所在当前目录下，所以果断修改（或者可以在上面配置ZOO_LOG_DIR这个变量）

ZOO_LOG_DIR="$ZOOKEEPER_PREFIX/logs"

将日志文件写到zookeeper安装目录下的logs文件夹中（logs不需要创建，它会自己创建）

美中不足的是在你设定的目录中, 仍会有zookeeper.out文件存在, 虽然它的size=0,究其原因是因为zkServer.sh会使用nohup进行zookeeper的启动, 然而nohup必然会输出一个日志文件到你设置的目录中,

相关代码如下, 需要将此处的逻辑修改掉, 就可以将zookeeper.out移除啦,

最后修改 bin/zkServer.sh

_ZOO_DAEMON_OUT="$ZOO_LOG_DIR/zookeeper.log"

ok，完成！

既然改都改了，为什么不改的彻底一点呢？让他按照天进行滚动

继续修改bin目录下的zkEnv.sh，修改为：

将
ZOO_LOG4J_PROP="INFO,CONSOLE"
修改为：
ZOO_LOG4J_PROP="INFO,ROLLINGFILE"

修改conf/log4j.properties文件

 

 

其它可配置参数：

log4j.appender.ROLLINGFILE.File=zookeeper.log
log4j.appender.ROLLINGFILE.DataPattern='.'yyyy-MM-dd-HH-mm
log4j.appender.ROLLINGFILE.Threshold=debug
log4j.appender.ROLLINGFILE.encoding=UTF-8
log4j.appender.ROLLINGFILE.Append=false
log4j.appender.ROLLINGFILE.layout=org.apache.log4j.PatternLayout
log4j.appender.ROLLINGFILE.layout.ConversionPattern= [%d{yyyy-MM-dd HH:mm:ss}]%-5p %c(line:%L) %x-%m%n
DailyRollingFileAppender特点是固定周期时间生成一个日志文件，比如，默认情况是每天生成一个文件。这种日志可以方便根据时间来定位日志位置，使日志清晰易查。但是这种日志有个不好地方是，不能限制日志数量，MaxBackupIndex属性和MaxFileSize在DailyRollingFileAppender中是无效的，这个还是按照自己的需求来定！

所以还需要自己弄个Crontab定期清理日志

脚本定期清理zk快照和日志文件

正常运行过程中，ZK会不断地把快照数据和事务日志输出到dataDir和dataLogDir这两个目录，并且如果没有人为操作的话，ZK自己是不会清理这些文件的。 我这里采用脚本切割。

#!/bin/bash
#清理zookeeper的日志 保留7天内的
#

datadir=/opt/zookeeper/zkdata/version-2
logdir=/opt/zookeeper/log/version-2

cd $datadir
find . -mtime +7 |xargs rm -rf 
cd  $logdir
find . -mtime +7 |xargs rm -rf 

#########################################################################

注意：如果仅仅是清理快照日志数据：在zoo.cfg中配置即可

1. autopurge.snapRetainCount=20   #保留日志快照数量

2. autopurge.purgeInterval=48       #保留48小时内的日志数据

转自
————————————————
版权声明：本文为CSDN博主「笨鸟先飞-天道酬勤」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/dehu_zhou/article/details/81939965