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系统的成本不低，当然我们可以通过降低抽样率来降低成本。
此外，正如前面提到的，并不是真正意义上的无侵入。我们需要业务代码做一些工作。