分布式系统调用链监控

关键字：分布式系统调用链监控

推荐相关文章：
1. zipkin分布式追踪系统： https://github.com/openzipkin/zipkin
2. Google Dapper： http://bigbully.github.io/Dapper-translation/
3. 淘宝的鹰眼系统：http://blog.csdn.net/u011277123/article/details/71402810


应用架构由集中式向分布式演进后，整个调用关系变得复杂。
分布式架构由复杂且较大规模集群构成，各个应用之间相当独立，可能由不同团队、不同语言实现。
系统一个完整的调用过程可能横跨多个服务及数据中心。
复杂的调用导致系统出问题后难以定位问题。
无法准确知道整体系统性能及运行情况。

全链路性能监控

一个请求完整的调用链可能如下图，经过多个系统服务，调用关系复杂。
[img]https://img-blog.csdn.net/20161222112952923?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]

这里写图片描述

期间我们会关注各个调用的各项性能指标，比如吞吐量（TPS）、响应时间及错误记录等。

吞吐量，根据拓扑可相应计算组件、平台、物理设备的实时吞吐量。
响应时间，包括整体调用的响应时间和各个服务的响应时间等。
错误记录，根据服务返回统计单位时间异常次数。

全链路性能监控从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。
Google Dapper

系统整个调用链
1. 当用户发起一个请求时，首先到达前端A服务，然后分别对B服务和C服务进行RPC调用；
2. B服务处理完给A做出响应，但是C服务还需要和后端的D服务和E服务交互之后再返还给A服务，最后由A服务来响应用户的请求；
[img]https://img-blog.csdn.net/20161222151058055?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]
这里写图片描述

对整个调用过程的追踪
1. 请求到来生成一个全局TraceID，通过TraceID可以串联起整个调用链，一个TraceID代表一次请求。
2. 除了TraceID外，还需要SpanID用于记录调用父子关系。每个服务会记录下parent id和span id，通过他们可以组织一次完整调用链的父子关系。
3. 一个没有parent id的span成为root span，可以看成调用链入口。
4. 所有这些ID可用全局唯一的64位整数表示；
5. 整个调用过程中每个请求都要透传TraceID和SpanID。
6. 每个服务将该次请求附带的TraceID和附带的SpanID作为parent id记录下，并且将自己生成的SpanID也记录下。
7. 要查看某次完整的调用则只要根据TraceID查出所有调用记录，然后通过parent id和span id组织起整个调用父子关系。
[img]https://img-blog.csdn.net/20161222153943538?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]

这里写图片描述
调用链监控核心工作

调用链数据的生成，对整个调用过程的所有应用进行埋点并输出日志。
调用链数据采集，对各个应用中的日志数据进行采集。
调用链数据存储及查询，对采集到的数据进行存储，由于日志数据量一般都很大，不仅要能对其存储，还需要能提供快速查询。
指标运算、存储及查询，对采集到的日志数据进行各种指标运算，将运算结果保存起来。
告警功能，提供各种阀值警告功能。

整体架构
[img]https://img-blog.csdn.net/20161222231603947?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]

这里写图片描述
* 通过AGENT生成调用链日志。
* 通过logstash采集日志到kafka。
* kafka负责提供数据给下游消费。
* storm计算汇聚指标结果并落到es。
* storm抽取trace数据并落到es，这是为了提供比较复杂的查询。比如通过时间维度查询调用链，可以很快查询出所有符合的traceID，根据这些traceID再去hbase查数据就快了。
* logstash将kafka原始数据拉取到hbase中。hbase的rowkey为traceID，根据traceID查询是很快的。
AGENT无侵入部署

通过AGENT代理的无侵入式部署，将性能测量与业务逻辑完全分离，可以测量任意类的任意方法的执行时间，这种方式大大提高了采集效率，并且减少运维成本。根据服务跨度主要分为两大类AGENT：

服务内AGENT，这种方式是通过Java的agent机制，对服务内部的方法调用层次信息进行数据收集，如方法调用耗时、入参、出参等信息。

跨服务AGENT，这种情况需要对主流RPC框架以插件形式提供无缝支持。并通过提供标准数据规范以适应自定义RPC框架：
Dubbo支持
Rest支持
自定义RPC支持

比如生成的数据格式如下：

{
"hostIp": "192.168.4.1",
"instanceName": "TracingDemo",
"isEntry": true,
"errCode": 0,
"spanId": "3cbfe7f0-141c-4597-8b15-38d2fb145e01",
"parentId": "16a52a9f-e697-45ce-92fb-7395339eae4b",
"traceId": "e5549498-60f3-4870-8483-fe26f6d0367b",
"className": "dao.impl.ProductDaoImpl",
"methodName": "queryProduct",
"inParam": "",
"createTime": 1448442004537,
"returnTime": 1448442004537,
"callTime": 5
}



调用链监控好处

准确掌握生产一线应用部署情况；
从调用链全流程性能角度，识别对关键调用链，并进行优化。
提供可追溯的性能数据，量化 IT 运维部门业务价值。
快速定位代码性能问题，协助开发人员持续性的优化代码；
协助开发人员进行白盒测试，缩短系统上线稳定期。

一些效果图
[img]https://img-blog.csdn.net/20161222170147605?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]
[img]https://img-blog.csdn.net/20161222170232902?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]
[img]https://img-blog.csdn.net/20161222170303152?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd2FuZ3lhbmd6aGl6aG91/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast[/img]