前言

云原生架构下，可观测领域的 OpenTelemetry 无疑是新时代的可观测标准。它提供的一些组件与工具极大地帮助了企业构建供应商无关的观测架构。

而在另一个领域，服务网格 ，Istio 也逐渐成为事实上的标准实现，它帮助企业从异构多语言微服务体系的复杂泥潭中解脱出来，无感知的为微服务增加动态管理、安全与可观测能力。

OpenTelemetry 与 Istio 的结合几乎可以说是天作之合，展现出 1 + 1 远大于 2 的能量！

OpenTelemetry 的基本架构

我们先了解一下 OpenTelemetry 的基本架构：

OpenTelemetry 基本上由三大件构成：

OTel Library：在几乎所有语言中为可观测提供统一的 API；

OTel Collector：数据收集程序，提供模型抽象，将统一的数据格式转换到不同后端供应商的数据格式；

其他的一些工具，比如各种 Auto Instruments。 OTel Collector 部署的结构可以拆分成两部分，一部分是 OTel Agent ，另一部分是 OTel Collector。 OTel Agent + OTel Collector 是我们向大家非常建议的架构。 至少对于容器集群来说，OTel Agent 几乎应该是必选项，在虚拟或者裸金属宿主机上可以通过 Agent 提供非常多的有用特性，比方说：批量的数据压缩、网络错误时的重试等等；

Istio 的可观测

Istio 通过自动代理进程流量，帮助进程自动记录流量的观测数据，这包括但不限于：

各类指标。比如 istio_requests_total 指标可以用来统计程序的进出流量的 RPS。

自动的分布式追踪。通过 Istio 数据面，为链路记录了真实可信的现场数据，包括流量本身的表现、延迟、错误原因等等。

进出流量的访问日志。Istio 数据面会自动打印出所有进出流量的日志，其中囊括非常多的信息，比如请求时间、请求的上下游耗时、包体积等等。 Istio 的可观测是完全插件化，可选择的。 但，不幸的是 OpenTelemetry 并不是 Istio 的开箱默认选择，我们需要做一些工作让他们一起 Work。

部署 Otel Agent

在 Kubernetes 集群中，为每台宿主机安装 Otel Agent 有三种选项：

使用官方提供的 Kubernetes Yaml 文件进行定制化安装。

使用 OpenTelemetry 提供的 helm 仓库。 两者都是非常好的选项，根据咱们自身的生产流程和情况进行选择即可。 我们在这里强调一下我们的生产使用的一些重点经验：

部署 Otel Agent 必须配置合适的 CPU 与内存使用，否则可能会影响服务容器的表现。

务必为 Otel Agent 注入与 CPU 限制匹配的 GOMAXPROCS 环境变量，才能正确发挥 Otel Agent 的性能。尤其在裸金属几十个上百个 CPU 核心的情况下，GOMAXPROCS 设置与否将会是影响 Agent 表现最为明显的因素。

HostNetwork 虽然是默认选项，我们强烈建议使用 HostPort 替代，以避免未知危险。

Otel 的 Receivers 配置一定要选择适当的端口，避免和主机上进程端口冲突，并且部署后检查是否有无法启动的 Agent 容器，如果有请手动解决此类问题。 由于是与 Istio 一起工作，我们在这里开启 OpenCensus Receiver 配置，方便 Istio 的追踪数据投递到 Otel Agent 中。

默认情况下 opencensus 监听的端口是 55678。

如果您的服务容器内还使用了其他的分布式追踪的协议，您可以在 receivers 开启，比如您可以同时还开启 Jaeger 协议的 receiver。这样您可以避免在集群内部署多个不同 Tracing 系统的 Agent，从而避免掉不必要的性能开销。

实际上我们的生产实践中也正是这么去做的，Istio 使用 opencensus 协议投递，而我们的服务内，由于历史原因代码中实际使用 Jaeger 协议，你看这就是 OpenTelemetry 的好处，几乎完全的供应商无关的使用体验。

接下来，我们配置完 exporters 信息，基本上 Otel Agent 就可以工作了。

我们可以在配置、部署完 OTel Agent 之后，进行一些实际的数据投递，来验证整个环节是否生效。

比如启动一些 Demo 应用，并产生流量，然后在 Query 侧查询是否存在相关数据。

配置 Istio 分布式追踪

在我们的实践中，我们遵循社区的最佳实践，使用 IstioOperator 安装、管理 Istio 配置。

通过修改我们的 IstioOperator 对象，即可完成分布式追踪的观测开启与配置。

这里可以注意到我们保留了 B3 上下文头部的感知，以保证与原有体系的兼容性。

这里可选的上下文非常多，比如 W3C_TRACE_CONTEXT、B3、CLOUD_TRACE_CONTEXT 等。

当我们修改完 IstioOperator 后，我们几乎立即得到了一个可用的 Tracing 接入。

但是如果你发现此时，Otel Agent 没有收到流量，请不要慌张，只是因为 Tracing 的配置实际是配置在了 Istio 数据面 Envoy 的启动配置文件中。

我们的修改如果想要生效，可以等待下一次服务重新部署即可，或者你也可以立即滚动重启一轮。

全览

最后我们看一下整体的全览。

服务进程和服务网格数据面 Istio-Proxy 均把自身的 tracing 数据投递到 OTel Agent，然后由 OtelAgent 处理后再投递到 Kafka 或 Jaeger Collector 或是其他供应商后端系统。

OpenTelemetry 不仅帮助我们服务网格 Istio 接入了分布式追踪，还统一了 Tracing Agent。

OpenTelemetry 能帮助 Istio 做到的事情也不止于此。

比方说作为 Istio 服务网格的数据面 Envoy，本身是支持将访问日志投递到 OpenTelemetry Agent 的，那么通过 Istio 的 EnvoyFilter 扩展，我们还能非常容易的接入 OpenTelemetry 的日志体系。

我们坚信 OpenTelemetry 与 Istio 服务网格未来会结合的更加紧密，OpenTelemetry 最终将全面地、彻底地接管 Istio 服务网格可观测体系！

作者介绍

唐阳，知乎核心架构平台工程师，负责服务网格等基础设施。