日志的应用,由浅入深,经验分享(一)

日志作为业务应用程序的必不可少的一部分,我们有没有充分利用起来呢?比如,协调一致的格式,脱敏,埋信息点,利用日志跟踪。同时,也要留意到,大量的日志如果写到磁盘时,它对于毫秒级的应用是不可承受的慢。

前言:

对于日志,一句话就是您想要解决什么问题,就要设计怎么样的日志,以便于您解决问题。如果你是架构师,你就是设计师。

问题陈述:

对于目前的很多架构师来说,先是遇到很多问题:

  1. 开发队伍不是一个,很难协调日志格式。

  1. 旧的程序包已经有旧的日志格式,全部更新代价太大。

  1. 日志到底能解决什么问题,架构师自己也不明确。怎么设计日志格式呢?

  1. 技术选型,我到底是用现成的日志工具ELK,还是日志易或splunk,还是定制化一套自己的日志应用程序呢?

。。。

问题阐述:

对于第一个问题:格式无法统一

开发队伍不是一个,这是项目执行问题,架构师是否可以规定如果打下日志,必须用规定的日志API,可以在log4j,logback再包一层,而不是每个开发队伍,或每个开发人员各用各的方法。如果谁违反,可能有什么小惩罚,如果今天做得好,可以有什么积分。笔者也遇到,国内的开发队伍往往面对开发时间短,项目管理无法监管的问题,那日志格式就无法统一,日志所产生的作用就没有了。

对于第二个问题,历史遗留

是预算的问题。先前的日志可能格式怪异,信息缺少。。。 对于格式怪异,会造成日志解析的困难,直接造成技术上的难度。 信息缺少,那就只有后加上,就是纯预算问题。一个历史沉淀多年的组件,非常多代码的软件包,要加信息,预算怎么解决?!

第一,第二个问题大部分工作是项目经理的工作和头痛的事。我们来分析第三个,和第四个问题。因为这是原汁原味的架构师问题。

对于第三个问题,日志功能

日志能解决的问题很多,以下为几个类别:

功能:

性能和稳定性测试:

笔者在芬兰诺基亚工作的时候,用日志解决稳定性测试,性能测试的问题。技术人员都知道,逻辑上的错误,一般都能重复再现。但性能上的问题,稳定性方面的问题,要捕捉重现问题难度就很大,因为性能,稳定性问题一般不重现,只有当特定时候,才可以复制。其实,读到这里,读者可以知道,日志对多线程应用特别有帮助。单线程,有的都可以用单步调试看问题。多线程,特别是性能,稳定性测试,多线程交织在一起,有的无法解藕的,没有办法用一般工具的。只能用日志来排查问题。 

KPI报告:

有的程序,都会向数据库输出指标,比如时序数据库,有的应用,开发人员就把KPI打入日志,然后让日志应用工具,比如 Elastic Search,Solr,Splunk 直接用现成工具库,描绘成不同的图线,报表。

目标跟踪,

比如用户跟踪,事务(transaction)跟踪,订单跟踪,回放。在通讯领域中,用户的手机信号怎么会断掉的?是用户自身问题,还是网络问题?事务失败,是那个模块出现问题?其实这些信息,可以作为数据挖掘的非常有价值的数据。

告警
模块的消息进出不一致,

各个模块的消息进出应该是匹配的,日志统计完以后,如果不匹配,可以通过日志应用程序告警。

内部堆栈

在Java应用程序中,JVM的一些参数,可以每隔一段时间打印在日志里,然后让日志应用程序决定目前业务应用程序是否健康。如果不健康,输出告警。

这一类要注意的问题:

脱敏数据,

敏感数据要上mask。

日志动态改变模式,

在生产线上,我们都是用log.error 这个层次,以免影响产品的性能,但在特定时候,特殊时段,我们在线调试的时候,我们要看debug层次的信息,甚至要看trace层次的信息,所以,日志的层次改变是动态在线改变。打出一段日志后,再恢复成平时的error 层次。

对于第四个问题,技术选型

一般项目,20个人左右,甚至100个人左右的项目,尽量用现成工具,那怕是商业工具,比如ELK,日志易,splunk。对于多线程,业务复杂度高,需要跟踪,又没有单一键值的 (key),或者说项目投资是1个亿以上的,还是要自己定制一套日志系统。 哪怕是这样,也是业务代码和工具结合着用,重新打造一个底层的优化的索引引擎是不现实的。有的功能是现有工具无法实现的。ELK多重join无法实现,日志易,Splunk在动态回溯,单一目标多键值跟踪上也有做不到的地方。未来都会一,一展开。

版本:

  1. 第一部分第一版写于2013年1月19日上海。发布于CSDN。

你可能感兴趣的:(综合,log4j,splunk,日志易,ELK,日志)