现在主流的服务应用都会有相应的日志模块, 产生大量的日志。 但说实话, 一般大家是不太关心这些成百上千的日志文件, 只有当系统运行出了问题, 才会翻出特定时间的日志文件, 查看有没有Error记录。 这种Error记录的确在查找系统bug的时候起到了很大的作用, 但我总觉得这有点大才小用的感觉。 想想系统每天都会产生100+M的日志文件,而可能一个月或更长的时间才会有查看日志的需要, 大部分的日志文件却都被雪藏起来, 永远也没有用武之地了。
日志能不能为我们做的更多?
之前做的一个项目, 日志模块会把每个方法的调用开始时间, 结束时间, Error, 每个Web Request请求的开始,结束时间都记录在日志里。 所以就有一些想法, 用这些日志文件来分析系统的性能以及分析系统存在的潜在问题。
分析方法的调用次数以及平均响应时间
分析一定时间的日志文件, 基于方法签名可以分析出每个方法在这段时间的调用次数, 已经平均调用时间。 这样的一份分析报告可以帮助你找出哪些方法是系统的性能瓶颈, 比如说注意平均时间大于10ms的方法, 很可能其中就有导致系统变慢的原因; 也可以帮助你留意调用次数特别多的方法, 可以帮助你找出那些方法调用过于频繁, 看时候可以针对这些方法进行性能优化。 比如说如果你发现一个数据库查询方法在一个用户操作被调用了很多次, 那么你就可以考虑把这个查询操作的结果放在内存进行缓存, 这样可以极大地优化系统响应时间。
定位Error及分析出Error的上下文
定位Error并不难, 很多的LogViewer等工具就可以做到。我觉得找出这个Error的上下文才比较重要。 想想看, 当你发现一个Error的时候, 可以很直观的看到这个方法的调用上下文, 甚至是每个方法的参数, 这样是不是对于你找出这个Error很有帮助! 当然最好有一个可视化工具, 嘿嘿,这个工具我还在开发中, 等可以用了再给大家瞧瞧:)
列出方法调用堆栈
可视化的列出一定时间内的方法调用堆栈, 并且标记出每个方法的调用时间。 用处嘛, 系统开发过程中都会对Web Services进行Performance Test, 对于那些性能不佳的service, 我们可以分析这段调用时间的日志, 列出调用的堆栈,从service request开始, 逐层查看每个方法的调用时间, 可以很容易找出那些使service变慢的方法。 之后的事情大家都知道了, Fix他吧。
解决多线程死锁
对于咱们这些程序员来说, 多线程死锁可算是最头痛的事情了吧。 首先难以重现,要知道死锁问题本身就是一个随机产生的问题, 不是每次都能重现, 而且每次锁住的地方也可能不一样, 这就最让人抓狂了。 线上发现问题, 死锁导致系统不可用, 但在本地怎么也重现不了问题。 这你能说因为无法重现就说这不是问题吗! 还得修呀。 我的想法就是分析服务器日志文件, 以线程进行分组,然后找出停止记录日志的线程, 基本上这就是锁住的地方了。 然后查看其他线程在这个锁住的时间点左右的操作, 这样基本上就能找到思索的原因了。
对Log基于内容的搜索
其实就是查找出特定的方法或特定的Info, 比如说对方法名称进行正则表达式匹配搜索, 或是对代码中Log的Info进行搜索。
以上只是我对日志文件应用的一些想法, 有些已经运用, 有些还只是想法, 欢迎大家多交流交流:)