[单master节点k8s部署]42.全链路监控(一)

微服务架构将应用拆分成多个独立的服务，系统整体变得更加复杂。全链路监控可以帮助开发和运维团队理解和管理这种复杂性，追踪请求在不同服务之间的流转过程。通过全链路监控，可以识别整个调用链中的性能瓶颈。它能够显示每个服务的响应时间，帮助定位那些服务或操作导致了延迟，从而有针对性的进行优化。

同时，全链路监控可以帮助快速定位故障源，并且帮助分析微服务之间的复杂依赖关系。通过监控各个服务的资源使用情况,可以更好地进行容量规划和资源分配,确保系统的高效运行。

全链路监控可以得到用户路径，从而进行分析汇总，优化业务的应用场景。通过zipkin，skywalking 和pinpoint等工具，可以实现微服务调用和服务情况的可视化分析。

Dapper

Dapper是goggle的一个大规模分布式追踪系统的基础设置，google在2010年发布的论文详细解释了这一工具以及其工作原理。现代互联网服务通常是通过复杂的大规模分布式系统实现的，这些系统由不同的团队和不同的编程语言开发的模块组成，可能跨越成千上万台机器。为了更好地理解这些系统的行为，尤其是诊断性能问题，谷歌开发了Dapper。Dapper的目的是为开发人员提供一种低开销、透明、可扩展的方式来追踪和分析系统中各个部分的行为。

以图中的请求为例，最开始用户发起的请求为X，但是X到达微服务A后，又被向后传递，这张图把请求的微服务分为三层，分别是frontend，middle tier和backend。但是在大规模集群中，各个微服务的关系没有这么清晰可见，如何弄懂微服务之间的关系呢，有两种方法。一种叫做black box，就是根据微服务调用次数的统计数据来找到微服务之间的关联关系，但是这种方法需要大量的数据。基于标注的方法（annotation based）是通过应用程序或者中间件的形式 为每一个请求添加一个全局标识符，将这些消息记录链接回原始请求。

虽然黑盒方案比基于标注的方法更具可移植性，但由于依赖统计推断，它们需要更多的数据才能获得足够的准确性。基于注释方法的主要缺点显然是需要对程序进行instrumentation(插桩)。在我k8s的环境中，由于所有应用程序使用相同的线程模型、控制流和RPC系统，我们发现可以将instrumentation限制在一小组通用库中，从而实现对应用程序开发人员实际上透明的监控系统。

 Dapper使用span来描述每一个操作，图中可以看到请求X到达fontend后，首先生成了一个span id为1，他的parent id为0，表示这是根节点。然后backend call的parent id为1，span id为2，请求span的标记依次增加。同时这个请求也有一个trace id，没有在图上标注。

下图可以更好的看清楚span的划分，从上面的图1看到，一个rpc的请求和回复可以看作是一个span，下图也有体现出来。下图有标记trace id。

Span的开始和结束时间，以及任何RPC计时信息都由Dapper的RPC库插桩记录。如果应用程序所有者选择使用自己的注释来增强跟踪，这些注释也会与其他span数据一起记录。以上就是链路追踪的基本原理和做法，后续的链路追踪工具也是遵循这一原理进行开发的。

Span 数据结构：

链路追踪工具

zipkin

github：

zipkin 是一个分布式的追踪系统，它能够帮助你收集服务架构中解决问题需要的时间数据，功能包括收集和查找这些数据。如果日志文件中有跟踪 ID，可以直接跳转到它。否则，可以根据服务、操作名称、标记和持续时间等属性进行查询。例如在服务中花费的时间百分比，以及哪些环节操作失败。特点是轻量，使用部署简单。

pinpoint

skywalking

github: 
https://github.com/apache/incubator-skywalking
skywalking 是本土开源的调用链追踪系统，包括监控、跟踪、诊断功能，目前已加入 Apache 孵化器， 专门为微服务、云本地和基于容器（Docker、Kubernetes、Mesos）架构设计。