从零开始开发xhh分布式链路追踪系统,based on zipkin

1. 需求说明:

在微服务越来越流行的趋势下,系统之间的调用日趋复杂。一次请求可能会调用多个服务。如果一次请求挂了,或者响应很慢,往往难以发现问题出在哪个服务上,也难以查看请求的耗时。链路监控的目的就是将一次请求的服务调用情况记录下来,这次请求调用了哪些服务(服务依赖),耗时多少。在此基础上,如果发现请求失败,会邮件通知管理员(预警功能)。所以,链路监控包含监控功能,预警功能。

2. 项目框架

基于推特开源的open zipkin(https://github.com/openzipkin:发现要迁移到apache了)。因为要集成到两个系统,本想在各个系统创建单独的maven module,单独创建一个工程,开发一个公共组件更符合代码复用,开闭原则。其他系统只需要引入这个公共组件,添加一些额外配置,比如采样率,kafka的server地址等,也要稍微改一下代码,就有了链路监控的功能了。

该项目采用zipkin提供的brave工具库采集监控数据,并发送到kafka。有两个消费者消费kafka。一个是Zipkin UI(用于展示链路信息的Web管理界面),它从kafka拿到数据后,存储到Elastic Search;另一个是Storm实时流处理平台,它解析监控数据,如果发现调用异常会发送邮件给用户(重复预警邮件会通过mongodb和guava本地缓存过滤掉)。

3. 项目遇到的难点

3.1 链路监控

监控信息增加响应头的信息:response.size;

公共组件用低版本的jdk打包;

监控信息增加post请求的body(修改源码的方式);

支持收集httpclient,restTemplate,MySQL的监控信息;

通过重写TracingStatementInterceptor的方式过滤掉一些没有必要的SQL,比如'SET autocommit=0'。zipkin提供的brave-instrumentation-mysql收集了太多冗余的sql。

3.2 storm实时流处理

一条链路上如果有一个调用出现问题,可能会发送多封邮件。解决方法:将同一条链路上的监控信息都发送到同一个bolt,用本地缓存保存已发送邮件的trace id;

增加MySQL慢查询的监控;

配置文件的初始化未生效的问题。因为分布式的原因,配置文件的初始化在topology里,其他bolt是取不到的;

你可能感兴趣的:(从零开始开发xhh分布式链路追踪系统,based on zipkin)