Inception:LinkedIn是如何利用异常日志实现服务监控的-阿里云开发者社区

开发者社区> 开发与运维> 正文

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

简介:

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

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

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

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

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

20170117113131863.jpg

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

20170117113132656.jpg

服务端异常: 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似乎在这方面更胜一筹。


本文转自d1net(转载)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章