WEBKT

Istio Telemetry V2 深度解析：指标采集机制与 Envoy Filter 定制方法

53 0 0 0

为什么需要 Telemetry？

Istio Telemetry V2 概览

指标采集机制详解

1. Envoy Metrics 基础

2. Istio 默认指标

3. 指标采集流程

4. 自定义指标

Envoy Filter 定制指标

1. 示例：统计特定 URL 的请求量

2. 部署 Envoy Filter

3. 验证自定义指标

4. 扩展和优化

Envoy Filter 定制指标的注意事项

Telemetry V2 与其他可观测性工具的集成

Telemetry V2 的未来发展

总结

你好，我是老码农。今天我们来聊聊 Istio Telemetry V2，特别是它的指标采集机制以及如何通过 Envoy Filter 进行定制。我相信对于很多正在使用或者准备使用 Istio 的同学来说，了解 Istio 的遥测体系至关重要。通过深入理解 Telemetry V2，我们可以更好地监控和优化微服务架构，提高系统的可观测性。废话不多说，让我们开始吧！

为什么需要 Telemetry？

在微服务架构中，服务数量众多、部署环境复杂，故障排查和性能优化变得更加困难。Telemetry（遥测）作为可观测性的重要组成部分，能够帮助我们收集、分析和可视化系统运行时的各种数据，主要包括：

  • Metrics (指标)：量化的数据，例如请求量、错误率、延迟等，用于监控系统的健康状况和性能表现。
  • Logs (日志)：文本形式的事件记录，用于追踪系统行为、排查故障和进行审计。
  • Tracing (追踪)：分布式追踪，用于跟踪请求在多个服务之间的调用链，帮助我们定位性能瓶颈和错误根源。

Istio 作为 Service Mesh 的代表，提供了强大的 Telemetry 功能，能够自动收集和导出大量的指标、日志和追踪数据，而无需修改服务代码。这极大地简化了微服务架构的可观测性工作。

Istio Telemetry V2 概览

Istio Telemetry 经历了多次迭代，目前主要采用 Telemetry V2 架构。与之前的版本相比，Telemetry V2 更加灵活、可扩展，并且支持多种后端存储和分析平台。其核心组件包括：

  1. Envoy Proxy: 作为 Sidecar 代理，Envoy 负责拦截服务之间的流量，并收集各种遥测数据。这是 Istio Telemetry 的关键组成部分。
  2. Telemetry API: Istio 定义了一套 Telemetry API，用于配置遥测策略、定义数据格式和导出数据。该 API 允许用户自定义遥测行为，例如选择要收集的指标、配置数据采样率等。
  3. Telemetry 插件: Telemetry V2 支持多种插件，用于将遥测数据导出到不同的后端存储和分析平台。常见的插件包括：
    • Prometheus: 用于存储和查询指标数据。
    • Jaeger: 用于存储和查询分布式追踪数据。
    • Fluentd/Fluent Bit: 用于收集和转发日志数据。
    • Zipkin: 另一种分布式追踪系统。
    • Cloud Monitoring/Cloud Logging: 各云厂商提供的监控和日志服务。

下图展示了 Istio Telemetry V2 的架构图：

graph LR
    subgraph Kubernetes Cluster
        A[Service A] --> B{Envoy Proxy}
        C[Service B] --> D{Envoy Proxy}
        E[Service C] --> F{Envoy Proxy}
    end
    B -- Metrics, Tracing, Logs --> G[Telemetry API]
    D -- Metrics, Tracing, Logs --> G
    F -- Metrics, Tracing, Logs --> G
    G --> H{Telemetry Plugins}
    H -- Metrics --> I[Prometheus]
    H -- Tracing --> J[Jaeger/Zipkin]
    H -- Logs --> K[Fluentd/Cloud Logging]

从上图可以看出，Envoy Proxy 是 Istio Telemetry 的核心。它不仅负责流量转发，还负责收集各种遥测数据。这些数据通过 Telemetry API 传递给 Telemetry 插件，然后插件将数据导出到相应的后端存储和分析平台。

指标采集机制详解

指标是 Istio Telemetry 中最重要的数据类型之一，它能够量化系统的性能和健康状况。 Istio 使用 Envoy Proxy 收集各种指标，并支持自定义指标。下面我们来详细了解指标采集机制。

1. Envoy Metrics 基础

Envoy 本身就内置了丰富的指标，涵盖了 HTTP 请求、TCP 连接、健康检查、负载均衡等多个方面。这些指标都是通过 Envoy 的统计 API (Stats API) 暴露出来的。 Istio 利用 Envoy 的 Stats API 获取这些指标数据。

Envoy 的指标命名遵循一定的规范，通常包含以下几个部分：

  • Namespace: 指标的命名空间，例如 envoy.http.downstream_rq_。
  • Metric Type: 指标类型，例如 total (总数), active (活跃连接数), time (延迟)。
  • Tags: 指标的标签，用于区分不同的维度，例如 cluster (集群名称), route (路由名称), response_code (HTTP 状态码)。

例如，envoy.http.downstream_rq_200 表示 HTTP 请求的响应状态码为 200 的总数。envoy.cluster.my_cluster.upstream_rq_time 表示集群 my_cluster 中上游请求的延迟。

2. Istio 默认指标

Istio 在 Envoy 的基础上，定义了一组默认指标，用于监控服务之间的通信。这些指标通常以 istio_ 开头，例如：

  • istio_requests_total: 总的请求数量，包括 HTTP 和 gRPC 请求。
  • istio_request_duration_seconds: 请求的延迟，以秒为单位。
  • istio_request_bytes: 请求的字节数。
  • istio_response_bytes: 响应的字节数。
  • istio_tcp_sent_bytes: TCP 发送的字节数。
  • istio_tcp_received_bytes: TCP 接收的字节数。
  • istio_connection_open: 打开的连接数。
  • istio_connection_close: 关闭的连接数。

这些指标通常会带有以下标签：

  • source_app: 请求来源服务的名称。
  • source_version: 请求来源服务的版本。
  • destination_app: 请求目标服务的名称。
  • destination_version: 请求目标服务的版本。
  • destination_service: 请求目标服务的 FQDN（完全限定域名）。
  • destination_workload: 请求目标服务的 workload name。
  • response_code: HTTP 响应状态码。
  • grpc_response_status: gRPC 响应状态。
  • request_protocol: 请求协议 (http, grpc, tcp)。

这些标签使得我们可以根据不同的维度来分析指标数据，例如按服务、版本、状态码等进行分组和聚合。

3. 指标采集流程

Istio 指标采集的流程大致如下：

  1. 流量拦截: Envoy Proxy 拦截服务之间的流量。
  2. 指标收集: Envoy 使用内置的统计过滤器 (Stats Filter) 收集指标数据。对于 HTTP 请求，Envoy 会收集请求的各种信息，例如请求方法、URL、状态码、延迟等。对于 TCP 连接，Envoy 会收集连接的建立、关闭、发送字节数、接收字节数等。
  3. 指标上报: Envoy 将收集到的指标数据上报给 Istio 的 Mixer 组件（在 Telemetry V2 中，Mixer 的功能已经被简化，主要是处理指标数据的配置和导出）。
  4. 指标导出: Mixer 将指标数据导出到配置的后端存储和分析平台，例如 Prometheus。

4. 自定义指标

除了默认指标，Istio 还支持自定义指标。这对于监控特定业务场景非常有用。 Istio 提供了多种方式来自定义指标：

  • Envoy Filter: 通过 Envoy Filter 可以拦截请求，并根据请求的各种信息来生成自定义指标。这是最灵活的方式，可以实现各种复杂的指标逻辑。
  • Wasm 插件: 使用 WebAssembly (Wasm) 编写自定义插件，可以拦截请求、修改请求头、生成自定义指标等。 Wasm 插件具有更高的性能和安全性。
  • 服务代码: 在服务代码中，可以使用 Istio 提供的库来上报自定义指标。这种方式需要在服务代码中添加额外的逻辑，但是可以实现更细粒度的指标控制。

接下来，我们将重点介绍如何使用 Envoy Filter 来定制指标。

Envoy Filter 定制指标

Envoy Filter 是 Istio 中一个非常强大的功能，它允许我们自定义 Envoy Proxy 的行为，包括修改请求头、响应头、路由、负载均衡、指标收集等。通过 Envoy Filter，我们可以轻松地实现各种自定义指标。 Envoy Filter 有多种类型，例如：

  • HTTP Filter: 用于处理 HTTP 请求和响应。
  • TCP Filter: 用于处理 TCP 连接。
  • Network Filter: 用于处理网络流量。
  • Metadata Exchange Filter: 用于交换元数据。

对于指标定制，我们通常使用 HTTP Filter。下面我们通过一个例子来演示如何使用 Envoy Filter 来创建一个自定义指标。

1. 示例：统计特定 URL 的请求量

假设我们需要统计特定 URL (/api/v1/users) 的请求量。我们可以创建一个 Envoy Filter，拦截 HTTP 请求，判断请求的 URL 是否为 /api/v1/users，如果是，就增加一个计数器的值。

首先，我们需要定义一个 Envoy Filter 的 YAML 文件，例如 custom-metrics-filter.yaml：

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: custom-metrics-filter
  namespace: default  #  根据你的实际情况修改 namespace
spec:
  workloadSelector:
    labels:
      app: my-app  #  你的目标服务的标签，确保只影响目标服务
  configPatches:
  - applyTo: HTTP_FILTER
    match:
      context: SIDECAR_INBOUND
      listener: 
        filterChain: 
          filter: 
            name: envoy.http_connection_manager
            subFilter:
              name: envoy.router
    patch:
      operation: INSERT_BEFORE
      value:
        name: envoy.filters.http.lua
        typed_config:
          '@type': type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua
          inline_code: |
            function envoy_on_request(request_handle)
              local path = request_handle:headers():get(':path')
              if path == '/api/v1/users' then
                request_handle:stats():counter('custom.api_users_requests'):inc(1)
              end
            end

让我们来详细解释一下这个 YAML 文件的内容：

  • apiVersion 和 kind: 定义了 Kubernetes API 的版本和类型，这里是 EnvoyFilter。
  • metadata: 定义了 EnvoyFilter 的元数据，包括名称和命名空间。
  • spec: 定义了 EnvoyFilter 的配置。
    • workloadSelector: 用于选择要应用 EnvoyFilter 的服务。这里我们选择标签为 app: my-app 的服务。你需要根据你的实际情况修改这个标签，确保只影响目标服务。
    • configPatches: 定义了要对 Envoy 配置进行哪些修改。
      • applyTo: 指定要修改的 Envoy 配置的类型，这里是 HTTP_FILTER，表示要修改 HTTP 过滤器。
      • match: 用于匹配 Envoy 配置的特定部分。
        • context: 指定过滤器应用的上下文，这里是 SIDECAR_INBOUND，表示应用于 Sidecar 代理的入站流量。
        • listener: 用于匹配监听器配置。
          • filterChain: 匹配过滤器链。
            • filter: 匹配特定的 HTTP 过滤器，这里是 envoy.http_connection_manager。
              • subFilter: 匹配子过滤器，这里是 envoy.router，表示在路由过滤器之前插入我们的 Lua 过滤器。
      • patch: 定义了要进行的修改。
        • operation: 指定修改的操作，这里是 INSERT_BEFORE，表示在路由过滤器之前插入一个新的过滤器。
        • value: 定义了要插入的过滤器的配置。
          • name: 指定过滤器的名称，这里是 envoy.filters.http.lua，表示使用 Lua 过滤器。
          • typed_config: 定义了过滤器的配置，这里是 Lua 过滤器的配置。
            • '@type': 指定配置的类型，这里是 type.googleapis.com/envoy.extensions.filters.http.lua.v3.Lua。
            • inline_code: 嵌入的 Lua 代码，用于实现自定义逻辑。
              • envoy_on_request: 定义了 HTTP 请求的回调函数。当 Envoy 收到 HTTP 请求时，会调用这个函数。
                • request_handle: 表示 HTTP 请求的句柄，可以通过它获取请求的各种信息，例如请求头、URL 等。
                • request_handle:headers():get(':path'): 获取请求的 URL。
                • if path == '/api/v1/users' then: 判断 URL 是否为 /api/v1/users。
                • request_handle:stats():counter('custom.api_users_requests'):inc(1): 增加一个计数器的值。custom.api_users_requests 是计数器的名称，你可以自定义。inc(1) 表示增加 1。

2. 部署 Envoy Filter

将 custom-metrics-filter.yaml 文件应用到 Kubernetes 集群中：

kubectl apply -f custom-metrics-filter.yaml

3. 验证自定义指标

部署完成后，我们可以通过 Prometheus 来验证自定义指标是否生效。首先，确保 Prometheus 已经配置为抓取 Istio 的指标。然后，在 Prometheus 的查询界面中，输入以下查询语句：

custom_api_users_requests

如果你的应用程序访问了 /api/v1/users 路径，你应该能看到 custom_api_users_requests 指标的值在不断增加。这表明我们的 Envoy Filter 已经成功地收集了自定义指标。

4. 扩展和优化

这个例子只是一个简单的示例，你可以根据自己的需求，扩展和优化 Envoy Filter 的功能。例如：

  • 添加标签: 可以在计数器中添加标签，例如 method (GET, POST, PUT, DELETE) 和 status_code，以便更细粒度地分析指标数据。
  • 使用更复杂的逻辑: 可以使用 Lua 脚本实现更复杂的逻辑，例如计算请求的延迟、错误率等。
  • 使用 Wasm 插件: 对于更复杂的逻辑，可以使用 Wasm 插件，可以获得更好的性能和安全性。

Envoy Filter 定制指标的注意事项

在使用 Envoy Filter 定制指标时，需要注意以下几点：

  • 性能影响: Envoy Filter 会增加 Envoy Proxy 的 CPU 和内存消耗。因此，在编写 Envoy Filter 时，需要注意性能优化，避免编写过于复杂的逻辑。
  • 配置管理: Envoy Filter 的配置应该进行版本控制和管理，以便于维护和更新。
  • 测试: 在部署 Envoy Filter 之前，应该进行充分的测试，确保其功能正确，并且不会对系统造成负面影响。
  • 兼容性: Envoy Filter 的配置可能与 Istio 的版本兼容性有关。在升级 Istio 版本时，需要检查 Envoy Filter 的配置是否需要更新。

Telemetry V2 与其他可观测性工具的集成

Istio Telemetry V2 不仅提供了强大的指标采集功能，还支持与其他可观测性工具的集成，例如：

  • Prometheus: 用于存储和查询指标数据。 Istio Telemetry V2 可以将指标数据导出到 Prometheus，并使用 Prometheus 的查询语言 (PromQL) 进行分析。
  • Grafana: 用于可视化指标数据。 Grafana 可以连接到 Prometheus，并创建各种仪表盘，用于监控系统的健康状况和性能表现。
  • Jaeger/Zipkin: 用于存储和查询分布式追踪数据。 Istio Telemetry V2 可以将追踪数据导出到 Jaeger 或 Zipkin，并使用它们的 UI 进行追踪分析。
  • Kiali: 用于可视化 Service Mesh 的拓扑结构、指标和追踪数据。 Kiali 可以帮助我们更好地理解服务的依赖关系和通信模式。
  • Fluentd/Fluent Bit: 用于收集和转发日志数据。 Istio Telemetry V2 可以将日志数据导出到 Fluentd 或 Fluent Bit，并将它们发送到各种日志存储和分析平台，例如 Elasticsearch、Splunk 等。

通过与这些工具的集成，我们可以构建一个完整的可观测性体系，从而更好地监控和优化微服务架构。

Telemetry V2 的未来发展

Istio Telemetry V2 仍在不断发展和完善中。未来，我们可以期待以下几个方面的改进：

  • 更丰富的指标: Istio 可能会提供更多默认指标，覆盖更广泛的业务场景。
  • 更灵活的配置: Istio 可能会提供更灵活的配置选项，允许用户更方便地自定义遥测行为。
  • 更好的性能: Istio 可能会优化 Envoy Proxy 的性能，减少遥测对系统性能的影响。
  • 更强大的集成: Istio 可能会与其他可观测性工具进行更深入的集成，提供更丰富的功能。
  • 支持 Wasm: Wasm 插件的使用会更加便捷，功能会更加强大。

总结

今天，我们深入探讨了 Istio Telemetry V2 的指标采集机制，以及如何使用 Envoy Filter 来定制指标。希望这篇文章能够帮助你更好地理解 Istio Telemetry，并在你的微服务架构中应用它。记住，可观测性是微服务架构成功的关键之一。通过使用 Istio Telemetry，你可以更好地监控和优化你的服务，提高系统的可靠性和性能。

如果你有任何问题或者想法，欢迎在评论区留言，我们一起探讨！

祝你编程愉快！

老码农的后花园 IstioTelemetryEnvoy FilterService Mesh可观测性

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/7591