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是取不到的；
网友评论