4. Prometheus在Istio中的角色:指标采集架构、Mixer与Telemetry v2、指标暴露端点

Prometheus是Istio可观测性三大支柱(指标、日志、链路追踪)中指标领域的核心后端。Istio通过数据面Sidecar代理(Envoy)生成原始指标数据,再经由不同的采集路径将数据送入Prometheus。理解这一链路中的架构演进、组件职责与暴露端点,是排查指标缺失、数据聚合错误的基础。

4.1 指标采集架构总览

Istio的指标采集架构经历了从Mixer(Telemetry v1)到无Mixer(Telemetry v2)的重大演进。当前主流版本(1.5+)默认使用Telemetry v2,由Envoy直接生成并暴露Prometheus指标,不再经过Mixer组件。

架构演进要点: Telemetry v2将指标生成逻辑下沉到Envoy中,消除了Mixer这一中心化瓶颈,大幅降低了网格内的延迟与资源开销。
Istio指标采集架构演进:Mixer vs Telemetry v2 Telemetry v1 (Mixer 模式) 服务A Pod (Envoy Sidecar) 服务B Pod (Envoy Sidecar) Mixer (istio-telemetry) 指标预处理 & 适配 Prometheus 拉取 /metrics Telemetry v2 (无Mixer) 服务A Pod (Envoy + Wasm) 服务B Pod (Envoy + Wasm) Envoy 直接暴露 /stats/prometheus Wasm插件生成Istio标准指标 Prometheus 拉取 /stats/prometheus 核心变化:Telemetry v2 移除 Mixer,Envoy 通过 Wasm 插件直接生成并暴露 Istio 标准指标

4.2 Mixer模式(Telemetry v1)

在Istio 1.5之前的版本中,Mixer是网格内统一的策略与遥测组件。Envoy Sidecar在每次请求处理前后,通过Report和Check接口向Mixer发送属性数据。Mixer负责将属性聚合为指标,并通过适配器(Adapter)将数据转发给Prometheus等后端。

组件 职责 瓶颈与问题
Envoy Sidecar 拦截流量,生成请求属性(来源、目标、响应码、延迟等) 每次请求都需调用Mixer,增加1-5ms延迟
Mixer (istio-telemetry) 接收属性,执行指标聚合、标签处理、适配器输出 中心化瓶颈,高并发下CPU/内存压力大;单点故障风险
Prometheus Adapter 将Mixer处理后的指标转换为Prometheus格式并暴露 指标经过两次转换(属性→Mixer内部格式→Prometheus格式),易丢失精度
Mixer模式典型故障: 当网格内服务数量超过100个时,Mixer的CPU使用率常飙升至80%以上,导致请求超时和指标采集延迟。这也是社区推动Telemetry v2的主要原因。

4.3 Telemetry v2:无Mixer架构

Telemetry v2将指标生成逻辑从Mixer迁移到Envoy中,通过Wasm(WebAssembly)插件或原生Envoy扩展实现。Envoy在请求处理过程中直接计算指标,并通过/stats/prometheus端点暴露,Prometheus直接拉取每个Sidecar的指标。

4.3.1 核心组件与流程

  • Envoy (Sidecar):内置了envoy.wasm.metadata_exchange和envoy.wasm.stats插件,负责生成TCP/HTTP级别的标准指标。
  • Pilot (istiod):通过XDS协议将指标配置(如统计标签、指标维度)下发给Envoy。
  • Prometheus:通过Kubernetes服务发现自动发现所有Sidecar的/stats/prometheus端点,执行拉取。
Telemetry v2 指标生成与采集数据流 服务A Pod Envoy Sidecar (Wasm插件: stats) 服务B Pod Envoy Sidecar (Wasm插件: stats) HTTP/gRPC 请求 请求经过 istiod (Pilot) XDS 指标配置下发 /stats/prometheus 15090端口 Prometheus 拉取 /stats/prometheus 关键路径:Envoy 通过 Wasm 插件在请求处理过程中直接生成指标,无需经过外部组件 istiod 仅负责下发指标配置(如统计标签白名单),不参与数据面指标计算

4.3.2 Telemetry v2 优势

维度 Telemetry v1 (Mixer) Telemetry v2 (无Mixer)
延迟 每次请求增加1-5ms(Mixer调用) 零额外延迟(指标在Envoy内计算)
资源开销 Mixer需要独立部署,高CPU/内存 仅Envoy Sidecar增加少量CPU(约5-10%)
可靠性 Mixer故障导致指标丢失或请求失败 指标随Sidecar生命周期,无单点故障
扩展性 网格规模受Mixer性能限制 水平扩展与Sidecar数量一致

4.4 指标暴露端点详解

在Telemetry v2架构中,Envoy Sidecar通过两个主要端点暴露指标:

  • /stats/prometheus(端口15090):Istio标准指标端点,包含HTTP、TCP、gRPC等协议级别的请求数、延迟、大小、响应码等。这是Prometheus默认采集的端点。
  • /stats(端口15000):Envoy原生管理端点,包含Envoy内部统计信息(连接池、集群状态、TLS握手等)。通常用于调试,不推荐作为Prometheus主要采集源。

4.4.1 标准指标清单(部分)

指标名称 类型 说明 标签示例
istio_requests_total Counter HTTP/gRPC请求总数 source_workload, destination_service, response_code
istio_request_duration_milliseconds Histogram 请求延迟分布(毫秒) source_workload, destination_service, response_code
istio_request_bytes Histogram 请求体大小分布 source_workload, destination_service
istio_response_bytes Histogram 响应体大小分布 source_workload, destination_service
istio_tcp_connections_opened_total Counter TCP连接打开总数 source_workload, destination_service
istio_tcp_sent_bytes_total Counter TCP发送字节总数 source_workload, destination_service

4.4.2 验证指标端点

可以通过以下命令验证Sidecar是否正确暴露指标:

# 进入任意包含Sidecar的Pod
kubectl exec -it <pod-name> -c istio-proxy -- curl -s http://localhost:15090/stats/prometheus | head -50

# 预期输出示例(包含istio_requests_total等指标)
# HELP istio_requests_total HTTP and gRPC requests
# TYPE istio_requests_total counter
istio_requests_total{response_code="200",source_workload="productpage-v1",destination_service="reviews.default.svc.cluster.local",...} 42
排查提示: 如果/stats/prometheus返回空或缺少istio_前缀的指标,请检查:1) Envoy Wasm插件是否加载成功(查看Sidecar日志);2) istiod是否下发了正确的指标配置;3) 是否启用了Telemetry v2(默认启用,可通过--set meshConfig.enableTelemetry=false关闭)。

4.5 Prometheus采集配置

Prometheus通过Kubernetes服务发现自动发现所有Sidecar的/stats/prometheus端点。Istio默认在istio-system命名空间中部署了一个预配置的Prometheus实例,其采集配置如下:

# Prometheus scrape config (简化版)
scrape_configs:
  - job_name: 'istio-mesh'
    kubernetes_sd_configs:
      - role: pod
    relabel_configs:
      # 只采集包含 istio-proxy 容器的Pod
      - source_labels: [__meta_kubernetes_pod_container_name]
        action: keep
        regex: 'istio-proxy'
      # 重写指标端点地址
      - source_labels: [__address__]
        action: replace
        regex: '([^:]+)(?::\d+)?'
        replacement: '$1:15090'
        target_label: __address__
      # 添加命名空间、工作负载等标签
      - source_labels: [__meta_kubernetes_namespace]
        action: replace
        target_label: namespace
      - source_labels: [__meta_kubernetes_pod_label_app]
        action: replace
        target_label: app
关键配置点:
  • 端口映射:将Pod的任意端口重写为15090(Envoy指标端口)。
  • 容器过滤:只采集包含istio-proxy容器的Pod,避免采集业务容器。
  • 标签注入:将Kubernetes标签(如namespace、app)注入到指标中,便于后续聚合。

4.6 常见故障模式

故障现象 可能原因 排查步骤
Prometheus中缺少istio_requests_total等指标 Telemetry v2未启用;Wasm插件加载失败;Prometheus采集配置错误 1) 检查Sidecar日志中是否有Wasm错误;2) 验证/stats/prometheus端点是否可达;3) 检查Prometheus target状态
指标标签缺失(如source_workload为空) istiod未下发标签配置;Envoy元数据交换失败 1) 检查istiod日志中XDS推送是否正常;2) 验证服务间是否启用了mTLS(元数据交换依赖mTLS)
指标延迟过高或采集超时 Sidecar指标端点响应慢;Prometheus采集间隔过短 1) 检查Sidecar资源限制(CPU/内存);2) 调整Prometheus scrape_timeout和scrape_interval