JAVA的日志大家基本都在用slf4j。SLF4j(Simple Logging Facade for Java)是一个通用的日志框架。里面只定义了接口,是门面模式的典型代表。提起门面模式又想起来一个典型代表:spring mvc里的上下文,不管用的具体实现是哪一个,都走统一的接口:ApplicationContext。实现门面模式的技术叫动态绑定,是Java多态的一个体现。
slf4j刚开始使用的时候遇到了很多问题,因为大家都在使用自己的日志系统和通用接口。比如:common-logging(jakarta common logging 简称jcl)是apache提供的一个通用的日志接口。用户可以自由选择第三方日志组件作为具体实现。具体实现比较常用的有java.util.logging,log4j,logback。由于logback在性能上的改进。所以实现上大家普遍选用logback。但是像java基本类库和apache一些类库里本来已经使用了其他的,这时候就需要用到桥接模式。slf4j用于桥接的jar包邮log4j-over-slf4j.jar(桥接log4j),jcl-over-slf4j.jar(桥接common-logging),jul-to-slf4j.jar(桥接java.util.logging)。工作原理就是包含了大部分使用的类的代替类,重新把所有的工作指向相关的slf4j类。其实每一种桥接都对应了一种驱动,将slf4j强制交给某个实现来执行的,对应一种实现的桥接和驱动不能同时存在,否则,想想都知道,根本启动不了。logback的驱动类是logback-classic.jar。下面借用之前给组内人员做技术分享时的一页PPT:
一般做业务,开发的时候sql错误是大家很关心的。使用经典的springmvc+servlet容器+ibatis架构,SQL的输出需要额外的包装。比如号称是最好用的数据库连接池的druid或者直接将数据库驱动改用log4jdbc。用法自行百度,本姑娘只讲原理。
SLF4j的优势在于上面介绍的与客户端解耦和采用占位符减少字符串拼接节省内存。原理就是slf4j中提供了ILogger和ILoggerFactory接口。其实现Logger类用来打印日志,LoggerFactory类用来获取Logger。而类实例是通过StaticLoggerBinder类来定义。这个类是实现slf4j的驱动自行定义的统一入口。SLF4j没有实现StaticLoggerBinder,只是负责使用类加载机制加载它。
虽然主流的日志实现都是采用这种方式实现的。但是slf4j还提供了SPI的接口支持。因为没有主流对应的实现,介绍SPI还是用我所擅长的搜索引擎来讲。先介绍概念:
SPI(Service Provider Interface):这是jdk1.5的一个内置标准,允许不同的开发者去实现某个特定的服务,是一种服务提供发现机制。实现时需要声明一个service provider,它在jar包的META-INF目录下创建一个service子目录,并且为每一个service provider提供一个以service全名命名的文件。下面是lucene源码中的截图。大家要是对SPI感兴趣,可以研究一下java.util.ServiceLoader的源码。类加载机制的原因,service provider的声明和实现类必须要在一个jar包里,来保证安全。lucene的自己的测试框架中必须要声明其编解码器,就是用的SPI。
我们现在用的Dubbo框架也是基于SPI机制提供扩展功能。可以支持不同的传输协议。
下面来谈谈我们业务中对日志处理的运用。每个项目都有自己的业务日志。那么我们部门总架构师,我家微微一笑很倾城的男神老大想要查看自己下面的子业务的健康状况怎么办呢?
一般来说每个公司都会基本的监控,最常用的三大开源运维监控工具zabbix,nagios和open-falcon。在之前的公司,运维用的是nagios。来乐视之后,刚开始用的是zabbix,后来换成了falcon。但是这些都是基于脚本的,只能进行一些基础监控。这类监控属于故障快速发现类。美团点评研发了一款分布式实时监控系统叫CAT(Central Application Tracking), 是基于纯Java开发的分布式实时监控系统。可以基于日志埋点做更细粒度的监控。它属于系统问题分析类。
大公司的架构除了平时的业务架构,技术架构,软件架构之外,还有一块是团队能力建设。打造团队核心竞争力。考虑这方面,设计构建自己的中间件就极为重要。这一块,在我们部门,除了我在做的搜索引擎中间件,还有阿里来的阳哥设计了一款异常统一处理平台。这个就是用spring mvc创建一个java bean。这个bean拦截了所有error级别的日志,将它异步发送的统一的redis集群。有统一的日志服务端再进行更详细的处理:包含给相关人员发报警邮件,有统一的日志分析平台,便于对各个模块的性能,代码质量做量化。logback本身也是可以发送报警邮件的。但是这个有性能问题,报警邮件过于频繁会影响正常服务的。
下面说一下CAT。我们目前线上也在用这个东西。CAT的一个重点是埋点,它决定了实际上能做的事情。
CAT监控系统将每次URL,Service的请求内部执行情况都封装为一个完整的消息树,消息树可能包括Transaction,Event,Heartbeat,Metric和Trace信息。
昨晚跟一个美团点评的哥哥聊天,了解到美团喜欢用数据说话,这个CAT的数据是这样的:号称单台机器QPS 15w。然后:我们没有那么大并发,所以没试过是不是真的[擦汗]
差点忘了大事:问问大家最近有想动一动的么?在北京的童鞋有想去阿里,蚂蚁金服,美团点评,美团金融,猫眼电影,京东,乐视网我们部门也在招人,还有东直门的创业公司,燕郊的创业公司。总之,都可以找我,简历发我邮箱 xiexiaojing@le.com。
欢迎大家多留言,说出自己的建议或者关心的内容。我尽量每条都回。这些都是督促我思考的宝贵资源~~谢谢大家的阅读,当然更感谢默默推荐的朋友
=============================== 华丽的终止符 ================================