现在系统基本都是微服务架构，对于复杂微服务链路调用如下问题如何解决？
一个请求经过了这些服务后其中出现了一个调用失败的问题，如何定位问题发生的地方？
如何计算每个节点访问流量？
流量波动的时候，增加哪些节点集群服务？
为了解决分布式应用、微服务系统面临的这些挑战，APM系统（ApplicationPerformanceManagement，即应用性能管理，简单来说就是应用监控）为之诞生，核心满足微服务系统监控的三要素如下：
Logging：就是记录系统行为的离散事件，例如，服务在处理某个请求时打印的错误日志，我们可以将这些日志信息记录到ElasticSearch或是其他存储中，然后通过Kibana或是其他工具来分析这些日志了解服务的行为和状态。大多数情况下，日志记录的数据很分散，并且相互独立，比如错误日志、请求处理过程中关键步骤的日志等等
Metrics：是系统在一段时间内某一方面的某个度量，例如，电商系统在一分钟内的请求次数。我们常见的监控系统中记录的数据都属于这个范畴，例如Promethus、Open-Falcon等，这些监控系统最终给运维人员展示的是一张张二维的折线图。Metrics是可以聚合的，例如，为电商系统中每个HTTP接口添加一个计数器，计算每个接口的QPS，之后我们就可以通过简单的加和计算得到系统的总负载情况。
Tracing：即我们常说的分布式链路追踪。在微服务架构系统中一个请求会经过很多服务处理，调用链路会非常长，要确定中间哪个服务出现异常是非常麻烦的一件事。通过分布式链路追踪，运维人员就可以构建一个请求的视图，这个视图上展示了一个请求从进入系统开始到返回响应的整个流程。这样，就可以从中了解到所有服务的异常情况、网络调用，以及系统的性能瓶颈等。
OpenTracing早在在年4月谷歌发表了一篇论文《Dapper,aLarge-ScaleDistributedSystemsTracingInfrastructure》阐述分布式追踪的概念，OpenTracing用于分布式跟踪和上下文传播的一致的、表达的、提供了一个标准的与供应商无关的api框架，这意味着如果开发者想要尝试一种不同的分布式追踪系统，开发者只需要简单地修改Tracer配置即可，而不需要替换整个分布式追踪系统；OpenTracingAPI目前也支持众多语言。了解OpenTracingAPI可以有利于更好学习本篇的主角SkyWalking。
OpenTracingGitHub地址