LinkedIn是如何利用异常日志实现服务监控

focus-linkedin.png

来自LinkedIn性能工程团队的的工程师Toon SripatanaskulZhengyu Cai在官方网站上披露了他们是如何通过Inception处理内部系统的日志,从而实现服务监控的。

 早在2012年初,LinkedIn的性能工程团队就尝试构建一种工具,它可以对发生代码变更后的服务进行有效性验证。
 
日志消息,特别是异常日志,可以很准确地反应服务的运行状况。对于新部署的服务,通过检查是否有新的异常日志出现就可以知道服务的健康状况。那个时候,他们使用脚本把日志文件拷贝到其它机器上,然后通过正则表达式生成最终的日志报告。这种方式在刚开始的时候运作良好,但LinkedIn发展迅速,脚本工具不具备伸缩性,无法跟上公司的发展速度。

2012年底,他们构建了一个日志消息处理系统,叫作Inception(Linked In Ex ception的合体)。他们把各个数据中心产生的日志消息聚集到Kafka上,然后Inception通过Kafka客户端处理这些消息,并把它们存放到如下几个数据库表中:
 

唯一性异常(What):异常日志消息的堆栈信息被抽取出来,并通过散列生成MD5串,这个串就是这个消息的签名。这样,他们就可以通过比较这个散列值快速地识别出新的异常,同时可以对异常进行去重。在计算散列值时,消息里的动态数据会被过滤掉,比如时间戳和代码行数。这个表保存的是日志消息和它的散列值。
实例(Where):这个表保存的是发生异常的服务实例,包括主机名、服务名和代码版本号。
时间序列(When):他们以分钟时间为单位,并检查在一分钟内某种异常发生的次数。这个表同时还引用了上述两个表的数据。

 把以上三个表的数据连接起来,他们就有足够的信息来生成日志报表,包括唯一性日志消息以及它们的发生次数和发生地点。

/uploads/fox/09142702_0.png
 
几年来,为了适应LinkedIn迅速的发展,Inception的架构也在不断演进。在经历了几次伸缩性问题之后,他们决定使用在Inception里使用Apache Samza来处理日志。Samza不仅处理速度快,而且高度可伸缩。Inception现在每秒可以处理110万条日志消息。
 
除此以外,Inception还支持多种数据源。
/uploads/fox/09142702_1.png
 

服务端异常: Inception现在支持Java、Python、Scala和C++的服务端异常。
JavaScript异常:他们使用一种数据管道从用户的浏览器端收集JavaScript异常,这些客户端异常通过REST API发送到专门的服务器上,并被转成Kafka事件。
移动设备异常:移动设备异常跟服务端异常一样,也包含了堆栈信息。不过收集这些信息会比较困难一些,目前他们还在不断解决这方面的问题。
测试框架异常: Inception集成了Selenium框架,对于每一个测试用例,他们都会有一个唯一的标识,它们会被传播到下游的后端服务上。Inception因此可以知道下游服务是否运行正常。
JIRA集成:当Inception检测到异常时,他们的另外一个系统就会创建一个JIRA ticket。他们通过这种方式报告缺陷,不过这种方式会创建过多的ticket,从而造成干扰,他们正在完善这个方案。

 说到这里,不得不提一下,在日志分析技术领域,ELK(Elasticsearch、Logstash、Kibana)是另外一个值得一说的日志分析技术栈。ELK可以保存完整的日志信息,包括时间戳、实际发生次数和具体的堆栈信息。
 
不过ELK会占用大量的存储空间。对于LinkedIn来说,为了得到一个粗略的报表,可能因此需要耗费50T的存储空间,而Inception只需要30G的空间,并且处理速度更快。这么说来,Inception似乎在这方面更胜一筹。
 
 

原创文章,作者:ItWorker,如若转载,请注明出处:https://blog.ytso.com/256066.html

(0)
上一篇 2022年5月18日
下一篇 2022年5月18日

相关推荐

发表回复

登录后才能评论