Istio可观察性--Tracing篇

Istio为网格内的全部服务通讯生成详细的遥测。这种遥测功能提供了服务行为的可观察性，使运维同窗能够对应用程序进行故障排除，维护和优化，而不会给服务开发人员带来任何额外负担。经过Istio，能够全面了解受监控的服务如何与其余服务以及与Istio组件自己进行交互。

Istio生成如下遥测类型，以提供总体服务网格可观察性：

• Metrics. Istio根据监控的四个“黄金信号”(延迟，流量，错误和饱和度)生成一组服务指标。 Istio还提供了网格控制平面的详细指标。还提供了基于这些指标构建的一组默认的网格监控仪表板。
• Distributed Traces. Istio为每种服务生成分布式跟踪范围，从而使咱们能够详细了解网格中的调用流程和服务依赖性。
• Access Logs. 当流量流入网格内的服务时，Istio能够生成每一个请求的完整记录，包括源和目标元数据。该信息使咱们可以审核服务行为，能够到单个工做负载实例级别。

本文咱们主要讲述Tracing。

Tracing 简介

为何须要tracing？

在微服务架构中，当多个服务相互调用时，故障排查变得再也不容易。故障的根因是什么，为何请求的性能不佳，哪一个服务是调用堆栈中的瓶颈，请求之间的网络延迟是多少？

有了分布式跟踪，就能够可视化完整的调用堆栈，查看哪一个服务调用了哪一个服务，每一个调用花费了多长时间以及它们之间的网络等待时间是多少。能够知道请求失败的位置或哪一个服务花费太多时间来响应。

Istio对tracing的支持和配置

Istio利用Envoy的分布式跟踪功能提供开箱即用的跟踪集成。具体来讲，Istio提供了安装各类跟踪后端并配置代理以自动向其发送跟踪范围的选项。

默认状况下，禁用Istio跟踪。您能够经过传递tracing.enabled安装选项来启用它。 Istio还支持多种跟踪平台，例如Jaeger，Zipkin和LightStep [x] PM。要配置适当的平台，能够使用tracing.provider安装选项。
须要注意的重要一点是Jaeger仅使用1％的流量进行采样。若是要增长该数量，则还应该配置pilot.traceSampling。

Trace 上下文传播

查找多个HTTP请求之间的相关性的一种方法是使用相关性ID。该ID应该传递给全部请求，以便跟踪平台知道哪些请求属于同一请求。

尽管Istio利用Envoy的分布式跟踪功能提供开箱即用的跟踪集成，可是其实这是一个误解，咱们的应用程序须要作一些工做。应用程序须要传播如下header：

• x-request-id
• x-b3-traceid
• x-b3-spanid
• x-b3-parentspanid
• x-b3-sampled
• x-b3-flags
• x-ot-span-context

Istio Sidecar内的Envoy代理接收这些标头，并将它们传递给配置的tracing系统。

实战

为何选择Jaeger？

实际生产环境中，咱们选择Jaeger。受到Dapper和OpenZipkin启发的Jaeger是由Uber Technologies做为开源发布的分布式跟踪系统。它用于监视和诊断基于微服务的分布式系统，包括：

• 分布式上下文传播
• 分布式事务监控
• 根本缘由分析
• 服务依赖分析
• 性能/延迟优化

此外Jaeger 是一个CNCF基金会项目，而且已经毕业。相对其余追踪系统，社区活跃，没有锁定风险。

Jaeger部署架构

Jaeger能够做为多合一二进制（其中全部Jaeger后端组件都在单个进程中运行）进行部署，该部署主要用于测试环境。

生产环境使用可扩展的分布式系统进行部署，以下所述。有两个主要的部署选项：

1. Collectors 直接写数据到存储
2. Collectors 写数据到kafka，而后由ingester组件转储数据

咱们生产环境使用的是第一种部署架构。而且选用的存储后端是Cassandra。

展现效果

Jaeger提供了UI去展现trace结果。具体效果以下：

咱们在使用istio过程当中，当咱们的服务调用没有那么复杂的时候，能够选择不启用tracing。整个tracing系统的成本不低，固然咱们能够经过下降抽样率来下降成本。 此外，正如前面提到的，并非真正意义上的无侵入。咱们须要业务代码作一些工做。