最新在七零那些事儿_写日志的那些事儿.doc

《最新在七零那些事儿_写日志的那些事儿.doc》由会员分享，可在线阅读，更多相关《最新在七零那些事儿_写日志的那些事儿.doc（4页珍藏版）》请在得力文库 - 分享文档赚钱的网站上搜索。

1、最新在七零那些事儿_写日志的那些事儿一般提到写日志，主要有下面几种不同的场景：诊断日志：应用打印异常信息，排查问题用，一般是给人看的，输出格式会比较随意，里面可能会有异常堆栈，或者排查问题用的一些文本信息；数据日志：一般是用来做监控和数据分析的，可以人肉临时分析，也可以给机器分析，要求格式比较固定；交易日志：一般在日志式文件系统、NoSQL、DB 中使用，一般有journaling，WAL（write-ahead logging），binlog。这种日志通常都不是给人看的。EagleEye 写的日志，是数据日志，记录的是中间件的网络调用埋点，或者是应用的业务埋点，它

2、们都通过调用 eagleeye-core 的 EagleEye API 输出。EagleEye 在写日志方面，有下面几个目标：写日志性能要足够好，应避免影响应用主流程；写日志对系统影响尽量小，在系统压力很大的时候，甚至可以选择放弃输出日志。在最老的实现里，EagleEye 使用了常见的 log4j 去写日志，在 1.1.3 版的大幅重构之后，就自己直接实现了写日志。当时想法就是要简化写日志的逻辑，因为 EagleEye 并不是通用的写日志组件，而是写自己的埋点日志。不使用通用的日志框架，主要考虑有几点：自己写，可控性强，可以做专门定制化，有利于提升性能避免日志组件的依赖冲突问题，不用再担心 C

3、lassloader 隔离、类加载等可以把很多 EagleEye 不需要的通用逻辑砍掉，例如配置化、日志级别（LogLevel）、日志格式（Layout）、层次结构（Category）、多种输出实现（Appender）从写日志这个功能上面讲，可以细分成三步：写日志到 logger：指调用 log(.) 方法，把字符串和相关参数传到日志框架。对于框架来说，这是一个追加日志的事件（LogEvent）。把日志编码成字符串或字节：指把日志事件格式化，编码成字符串或字节数组的过程，例如每行日志按照指定格式追加时间戳、日志级别、代码位置等信息，就是在这一步完成。日

4、志输出到目的地：通用日志框架可以指定多个输出目的地（Appender），目的地不仅可以是写本地文件，甚至可以是走网络、存数据库、发消息等。下面就这三步，结合 EagleEye 关注的目标，说说在这些方面遇到了什么问题，以及如何实现的。写日志到 logger同步写的问题多线程环境并发写日志，首先需要保证线程安全，就是说，多个线程一起写日志时，内容不能出现交织。要做到这一点，最最简单的办法，就是每条线程单独写一个文件，这个方案在淘宝是不现实的，因为应用的线程非常多（仅 HSF 线程池就已经有 600 个线程），如果采用这个方案，会产生很多日志文件。再简单一点的办法是把写日志作为临界区，进入临界区时

5、用锁来保证每一时刻只有一个线程在写日志，例如 BufferedOutputStream 就是一个写时同步的实现。应用用 log4j、logback 打日志，如果没特殊配置过，一般就是同步写的。EagleEye 的 1.1.x 版自己实现写日志，用的就是同步写的方案。使用同步写一般是很快的，但是极偶尔会出现写日志写 hang 住的情况，这时候会把当前正在写日志的线程卡住，其它要写日志的线程就会堵塞在临界区外面等待。EagleEye 1.1.x 版上线后，遇到过好几次应用的 HSF 线程池里几乎全部线程都卡在写 EagleEye 日志上的情况，导致这台服务器的服务有一段时间基本不可用。出现写硬盘

6、hang 住的情况虽然不多见，但是起因很难排查，对于 EagleEye 这种网络调用埋点，一旦卡住，就会导致这次调用超时。如果是业务线程写日志 hang 住，就会导致业务请求处理超时。（所以应用使用同步去写日志，都会有因为写日志导致响应超时的风险。）异步写，基于 BlockingQueue在 1.2.x 之后，改用了异步写的方案：任何线程要写日志，只需要把日志事件对象加入日志队列就行了，后台会专门起一个线程从队列取日志、写文件。这是一个典型的多生产者对单消费者的问题，关键就在于这个队列的实现，因为这里面涉及消费者等待队列不空，生产者等待队列空的逻辑，当时就选择了比较直观的 BlockingQueue。第 4 页 共 4 页