logback db

用slf4j+logback记录日志,之前是打到日志文件中。日志多了之后,又开始用logack的不同appender区分日志文件。最初的时候还比较实用,查阅日志很方便。但随每个开发者都随手新建一个自己的日志文件以便于自己查询方便,每次项目启动之后都会新建数十个文件,运行一周后,日志文件夹就会出现上千个文件。在缺乏必要的维护机制时,日志膨胀已经让阅读日志成为了一件很困难的事。

如果用logback的db appender,把日志进行结构化,也许会缓解这个问题。

在logback的配置文件中,创建以下appender:

<appender name=”DB” class=”ch.qos.logback.classic.db.DBAppender”>
<connectionSource
class=”ch.qos.logback.core.db.DriverManagerConnectionSource”>
<driverClass>com.mysql.jdbc.Driver</driverClass>
<url>jdbc:mysql://localhost:3306/logback_demo</url>
<user>root</user>
<password>admin</password>
</connectionSource>
</appender>

相应的配置都很好懂,按照需求进行配置进可以了。

logback不会自动建表,需要根据要求手工建立。建表语句在logback-classic.jar\\ch\qos\logback\classic\db\script下,提供了主要数据库各个版本的create sql。

主要的日志信息保存在logging_event表中,有名为arg 1、2、3的三个字段,对应输出log时替换log字符串中{}的参数。这几个字段会对日志的灵活格式化很有作用。只有三个,预计极端情况下会不够用,特别是写输出日志的代码时,没有考虑到参数组织的情况下。

有时间戳和event_id字段,可以保证日志的输出顺序是可查的。

 

有几个未解决的问题:

  • 还没有找到打印多层调用堆栈的方法。
  • 有些日志在控制台能输出,但到了数据库中就莫名其妙的没有了。
  • 没有找到能做ticket id的字段,因此无法对日志有效分类。比如设计日志时会用到这种策略,关于某个实体的每条处理过程,都必定在日志中包含“[moduleid=xxxx]”这样的字样。在发生错误时,根据出错的实体id,就可以找到这条实体操作的所有过程。但按照logback db的方案,除了全文检索外,没有找到有效的方法。
  • 没有看到自动分表的机制,日志的膨胀的问题不知如何处理,因此也不知道运行起来效率如何。

发表评论

电子邮件地址不会被公开。 必填项已用*标注