边缘可观测性：Envoy 和 Istio 中的新 OTel 功能

在云原生和分布式应用程序的动态世界中，有效管理微服务至关重要。Kubernetes已成为容器编排的事实标准，可实现容器化应用程序的无缝部署、扩展和管理。

然而，这些系统的分布式特性增加了网络通信的复杂性，以实现集群内的通信。Envoy 和 Istio 这两个知名项目已成为顺利管理和运营此类复杂环境的基础。

总之，这些技术使组织能够构建可扩展、有弹性且安全的分布式系统。

Istio 是一个服务网格，负责协调微服务之间的通信，提供流量管理、安全和可观测性等功能。Istio 使用 Envoy 代理作为其数据平面。Envoy 是一个高性能代理，专为单个应用程序/服务以及服务网格的通信总线和“通用数据平面”而设计。

Envoy 和 Istio 项目是开源的，并且是 Cloud Native Computing Foundation 的一部分。

Envoy 和 Istio 中的可观测性

Istio 服务网格部署的 Envoy 代理是确保进出请求得到正确跟踪的理想选择。这种方法提供了整个服务网格的分布式跟踪，可以概览服务之间的通信——即使应用程序本身未被检测。

注意：最低限度，应用程序必须配置为传播 traceparent 标头。

Envoy 提供了多种 HTTP 跟踪器 来跟踪请求，包括 OpenTelemetry 跟踪器。跟踪器可以直接在 Envoy 中进行配置（当将其用作独立组件时），或通过 Istio 为所有 Envoy 实例进行配置。

以下是 Istio 和 Envoy 如何协同跟踪请求的示例

Envoy 和 Istio 中新的 OTel 跟踪功能

尽管 Envoy 已经支持使用 gRPC 导出 OpenTelemetry 跟踪，但它缺乏使用 HTTP 导出的支持。OpenTelemetry 将这两种协议作为一等公民支持。此外，诸如提供资源属性和可配置采样决策等其他领域仍然落后于 OpenTelemetry 规范的稳定部分。

从 Envoy 1.29 和 Istio 1.22 开始，用户可以访问下面描述的新功能。

OTLP HTTP 导出器

Envoy 中的 OpenTelemetry 跟踪器现在可以配置为使用 HTTP 导出 OTLP 跟踪。这允许它直接从 Envoy 代理将遥测数据发送到使用 OTLP/HTTP 的可观测性接收器。

资源探测器

Envoy 现在附带 Environment Resource Detector。此资源探测器遵循 OTel 规范，并允许用户进一步丰富 Envoy 代理生成的跨度。

资源探测器功能不仅添加了环境探测器，而且通过 Envoy 的内置扩展功能，还使任何其他资源探测器都可以轻松添加。

自定义采样器

Envoy 增加的另一个令人兴奋的功能是实现和配置自定义采样器的可能性。Envoy 遵循 OTel Sampler 接口，这使得任何人都可以轻松贡献自己的采样器。

Envoy 附带 Always On Sampler，它只是转发所有跨度。此基本实现可用作更智能采样器的参考实现。

演示

是时候看看新功能如何发挥作用了！为此，我们使用了 Istio Bookinfo 应用程序，并演示了如何

• 在 Kubernetes 中部署，以 Istio 作为服务网格
• 通过 HTTP 将跟踪导出到 Jaeger

安装 Jaeger

首先，安装 Jaeger operator

kubectl create namespace observability
kubectl create -f https://github.com/jaegertracing/jaeger-operator/releases/download/v1.57.0/jaeger-operator.yaml -n observability

然后部署 Jaeger all-in-one

kubectl apply -f - <<EOF
apiVersion: jaegertracing.io/v1
kind: Jaeger
metadata:
  name: simplest
EOF

安装和配置 Istio

接下来，使用 istioctl 安装 Istio

cat <<EOF | istioctl install -y -f -
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  meshConfig:
    enableTracing: true
    extensionProviders:
    - name: otel-tracing
      opentelemetry:
        port: 4318
        service: simplest-collector.default.svc.cluster.local
        http:
          path: "/v1/traces"
          timeout: 5s
        resource_detectors:
          environment: {}
EOF

这会安装 Istio 并将 OpenTelemetry 跟踪提供程序配置为通过 OTLP/HTTP 使用 http 导出器，并将 Jaeger collector 作为端点。此配置还启用了 resource_detectors 中的环境资源探测器。

接下来，我们需要使用 Istio 的 Telemetry API 启用跟踪器。

kubectl apply -f - <<EOF
apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: otel-demo
spec:
  tracing:
  - providers:
    - name: otel-tracing
    randomSamplingPercentage: 100
EOF

最后，我们为 Envoy 代理配置 OTEL_RESOURCE_ATTRIBUTES 环境变量。

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ProxyConfig
metadata:
  name: my-proxyconfig
  namespace: istio-system
spec:
  concurrency: 0
  environmentVariables:
    OTEL_RESOURCE_ATTRIBUTES: "host.name=abc-123"
EOF

部署应用程序

最后一步是部署 bookinfo 应用程序（bookinfo.yaml）

kubectl label namespace default istio-injection=enabled
kubectl apply -f bookinfo.yaml

实际测试

要测试您的设置，请向其中一个服务发出一些请求，例如

kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"

然后您可以在 Jaeger UI 中查看——您应该会看到一些跟踪！

从 Envoy 生成的跨度中，您可以看到（按顺序）

1. 从 ratings 服务到 productpage 服务的传出（出口）调用。
2. productpage 服务中的传入（入口）调用。
3. 使用 OTEL_RESOURCE_ATTRIBUTES 应用的 host-name 资源属性。此属性被环境资源探测器拾取并添加到 Envoy 创建的所有跨度中。

您还可以看到所有其他下游调用，因为所有服务都已由 Istio 注入了 Envoy sidecar。只需在 Envoy 中启用 OTel 跟踪器，您就可以完全观测服务之间的调用！

后续步骤和总结

通过本文介绍的新功能，用户在导出跟踪数据方面获得了更大的灵活性。他们可以用资源属性丰富其数据，并为未来添加更智能的采样技术奠定基础。

新功能还为可观测性领域的其他参与者（包括云提供商和可观测性供应商）解锁了有趣的用例。随着资源探测器和采样器 API 在 Envoy 中可用，任何人都可以构建对自定义采样器和探测器的支持，从而增强 Envoy 生成的遥测数据的实用性。

Envoy 和 OpenTelemetry 的另一个令人兴奋的下一步是采用现已稳定的 Envoy 中的 HTTP 语义约定。这将使 Envoy 与所有 OTel SDK 一致，后者也遵循稳定的 HTTP 语义约定生成跨度。

与 Envoy 和 Istio 社区合作，将更多 OTel 功能引入这些项目是一次很棒的体验。采用的积极性以及 OpenTelemetry 与 Istio 和 Envoy 等相关 CNCF 项目之间的牢固合作关系，有助于巩固 OpenTelemetry 作为可观测性事实标准的地位。

• ←上一篇
• 下一篇→