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这一中心化瓶颈,大幅降低了网格内的延迟与资源开销。
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端点,执行拉取。
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 |