分布式服务化的阶段，传统的日志监控等方式无法很好达到跟踪调用，排查问题等需求。
各种服务之间调用：
1.如何快速发现问题？
2.如何判断故障影响范围？
3.如何梳理服务依赖以及依赖的合理性？
4.如何分析链路性能问题以及实时容量规划？
技术调研指标
面对各种链式追踪系统开源，我们要如何选择：
我们主要关注在请求处理期间各个调用的各项性能指标，比如：吞吐量（TPS）、响应时间及错误记录等。
吞吐量，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。
响应时间，包括整体调用的响应时间和各个服务的响应时间等。
错误记录，根据服务返回统计单位时间异常次数。
全链路性能监控 从整体维度到局部维度展示各项指标，将跨应用的所有调用链性能信息集中展现，可方便度量整体和局部性能，并且方便找到故障产生的源头，生产上可极大缩短故障排除时间。
我们除了性能指标之外，我们也需要链式追踪系统拥有以下功能：
请求链路追踪，故障快速定位：可以通过调用链结合业务日志快速定位错误信息。
可视化： 各个阶段耗时，进行性能分析。
依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
数据分析，优化链路：可以得到用户的行为路径，汇总分析应用在很多业务场景。
链式追踪系统
cat， zipkin， pinpoint , skywalking
cat
大众点评开源，基于Java开发的实时应用监控平台，包括实时应用监控，业务监控 。 集成方案是通过代码埋点的方式来实现监控，比如： 拦截器，注解，过滤器等。 对代码的侵入性很大，集成成本较高。风险较大。
zipkin
由Twitter团队开源， Zipkin是一个分布式的跟踪系统。它有助于收集数据需要解决潜在的问题在市微服架构的时机。它管理数据的收集和查找 。
该产品结合spring-cloud-sleuth使用较为简单， 集成很方便。 但是功能较简单
pinpoint
skywalking
技术选型考虑
探针的性能消耗
APM组件服务的影响应该做到足够小。服务调用埋点本身会带来性能损耗，这就需要调用跟踪的低损耗，实际中还会通过配置采样率的方式，选择一部分请求去分
析请求路径。在一些高度优化过的服务，即使一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪系统关停。
代码的侵入性
即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担。
对于应用的程序员来说，是不需要知道有跟踪系统这回事的。如果一个跟踪系统想生效，就必须需要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，往
往由于跟踪系统在应用中植入代码的bug或疏忽导致应用出问题，这样才是无法满足对跟踪系统“无所不在的部署”这个需求。
可扩展性
一个优秀的调用跟踪系统必须支持分布式部署，具备良好的可扩展性。能够支持的组件越多当然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也可以自行扩展。
数据的分析
数据的分析要快 ，分析的维度尽可能多。跟踪系统能提供足够快的信息反馈，就可以对生产环境下的异常状况做出快速反应。分析的全面，能够避免二次开发。
功能模块
一般的全链路监控系统，大致可分为四大功能模块：
一.埋点与生成日志
埋点即系统在当前节点的上下文信息，可以分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间，协议类型、调用方 ip和端口，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下一步扩展做准备；
不能造成性能负担：一个价值未被验证，却会影响性能的东西，是很难在公司推广的！
因为要写log，业务QPS越高，性能影响越重。通过采样和异步log解决。
二.收集和存储日志
主要支持分布式日志采集的方案，同时增加MQ作为缓冲；
每个机器上有一个 deamon 做日志收集，业务进程把自己的Trace发到daemon，daemon把收集Trace往上一级发送；
多级的collector，类似pub/sub架构，可以负载均衡；
对聚合的数据进行 实时分析和离线存储；
离线分析 需要将同一条调用链的日志汇总在一起；
三.分析和统计调用链路数据，以及时效性
调用链跟踪分析：把同一TraceID的Span收集起来，按时间排序就是timeline。把ParentID串起来就是调用栈。
抛异常或者超时，在日志里打印TraceID。利用TraceID查询调用链情况，定位问题。
依赖度量：
强依赖：调用失败会直接中断主流程
高度依赖：一次链路中调用某个依赖的几率高
频繁依赖：一次链路调用同一个依赖的次数多
离线分析：按TraceID汇总，通过Span的ID和ParentID还原调用关系，分析链路形态。
实时分析：对单条日志直接分析，不做汇总，重组。得到当前QPS，延迟。