📚 课程目录第3章 Prometheus核心概念回顾

3. Prometheus 核心概念回顾

在深入 Istio 网格拓扑集成之前，必须牢固掌握 Prometheus 的三大核心支柱：拉取模型、指标类型以及资源发现机制（ServiceMonitor / PodMonitor）。本章将系统梳理这些概念，为后续的集成工程打下坚实基础。

3.1 拉取模型：Pull vs Push

Prometheus 采用 Pull（拉取） 模式，即 Prometheus Server 主动向配置的目标端点（Target）发起 HTTP 请求，获取指标数据。这与传统的 Push（推送）模式有本质区别。

特性	Pull 模式（Prometheus）	Push 模式（如 Graphite）
数据采集	Server 主动拉取	Agent 主动推送
健康检查	拉取失败即视为实例 Down	需额外心跳机制
网络拓扑	Server 需可达 Target	Server 需开放接收端口
配置变更	修改 Prometheus 配置或 ServiceMonitor	修改 Agent 配置
适用场景	Kubernetes、传统数据中心	边缘设备、短生命周期任务

工程要点：在 Istio 网格中，Envoy Sidecar 暴露了标准的 /stats/prometheus 端点，Prometheus 通过 Pull 模式直接采集这些端点，无需在 Sidecar 中安装额外的 Push Agent。

3.2 指标类型详解

Prometheus 客户端库提供四种核心指标类型，每种类型对应不同的监控场景和聚合方式。

类型	语义	典型场景	聚合方式
Counter	只增不减的累计值	请求总数、错误总数、CPU 时间	`rate()` / `increase()`
Gauge	可增可减的瞬时值	内存使用量、并发连接数、温度	直接使用 / `avg()`
Histogram	分桶统计 + 总和 + 计数	请求延迟、响应大小	`histogram_quantile()`
Summary	流式分位数 + 总和 + 计数	延迟分位数（客户端计算）	直接查询分位数

  关键区别：Histogram 的分位数在 PromQL 查询时通过 histogram_quantile() 计算，可以灵活调整分位点；Summary 的分位数在客户端预计算，无法事后调整分位点，但计算开销更低。

3.2.1 Counter：只增不减的计数器

Counter 是最基础的指标类型，代表一个单调递增的累计值。典型指标名后缀为 _total。

# HELP http_requests_total Total number of HTTP requests
# TYPE http_requests_total counter
http_requests_total{method="GET",code="200"} 1027
http_requests_total{method="POST",code="500"} 15

常用 PromQL：

# 每秒请求速率
rate(http_requests_total[5m])

# 过去1小时的总请求增量
increase(http_requests_total[1h])

3.2.2 Gauge：可增可减的仪表盘

Gauge 用于测量可以上下波动的值，如内存使用量、队列深度。

# HELP node_memory_MemAvailable_bytes Memory information
# TYPE node_memory_MemAvailable_bytes gauge
node_memory_MemAvailable_bytes 8.123e+09

常用 PromQL：

# 当前可用内存
node_memory_MemAvailable_bytes

# 过去1小时的平均可用内存
avg_over_time(node_memory_MemAvailable_bytes[1h])

3.2.3 Histogram：分桶直方图

Histogram 将观测值放入可配置的桶（Bucket）中，同时记录所有值的总和与计数。适用于需要计算分位数的场景。

# HELP http_request_duration_seconds request duration histogram
# TYPE http_request_duration_seconds histogram
http_request_duration_seconds_bucket{le="0.1"} 240
http_request_duration_seconds_bucket{le="0.5"} 455
http_request_duration_seconds_bucket{le="1.0"} 502
http_request_duration_seconds_bucket{le="+Inf"} 510
http_request_duration_seconds_sum 156.3
http_request_duration_seconds_count 510

常用 PromQL：

# P99 延迟
histogram_quantile(0.99, rate(http_request_duration_seconds_bucket[5m]))

3.2.4 Summary：预计算分位数

Summary 在客户端直接计算分位数，暴露 _quantile 系列指标。适合对延迟敏感且分位点固定的场景。

# HELP rpc_duration_seconds A summary of RPC durations
# TYPE rpc_duration_seconds summary
rpc_duration_seconds{quantile="0.5"} 0.052
rpc_duration_seconds{quantile="0.9"} 0.124
rpc_duration_seconds{quantile="0.99"} 0.312
rpc_duration_seconds_sum 2.34
rpc_duration_seconds_count 45

3.3 ServiceMonitor 与 PodMonitor

在 Kubernetes 环境中，Prometheus Operator 引入了 ServiceMonitor 和 PodMonitor 两个 CRD（Custom Resource Definition），用于声明式地定义监控目标，替代手动维护 prometheus.yml 中的 scrape_configs。

3.3.1 ServiceMonitor：基于 Service 的发现

ServiceMonitor 通过标签选择器匹配 Kubernetes Service，Prometheus 自动发现该 Service 关联的 Endpoints 并采集指标。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: istio-proxy-monitor
  namespace: istio-system
spec:
  selector:
    matchLabels:
      app: istio-ingressgateway
  endpoints:
  - port: http-envoy-prom
    interval: 15s
    path: /stats/prometheus
  namespaceSelector:
    any: true

字段	说明	典型值
`selector.matchLabels`	匹配 Service 的标签	`app: istio-ingressgateway`
`endpoints.port`	Service 端口名称	`http-envoy-prom`
`endpoints.interval`	采集间隔	`15s`
`endpoints.path`	指标路径	`/stats/prometheus`
`namespaceSelector`	命名空间选择策略	`any: true` 或 `matchNames`

3.3.2 PodMonitor：直接发现 Pod

PodMonitor 直接通过标签选择器匹配 Pod，不经过 Service。适用于不需要 Service 抽象的监控场景，例如直接采集 Sidecar 或 DaemonSet 的指标。

apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
  name: istio-sidecar-monitor
  namespace: istio-system
spec:
  selector:
    matchLabels:
      sidecar.istio.io/inject: "true"
  podMetricsEndpoints:
  - port: http-envoy-prom
    interval: 15s
    path: /stats/prometheus
  namespaceSelector:
    any: true

注意：PodMonitor 要求 Pod 直接暴露指标端口，且端口名称必须在 Pod 的 spec.containers.ports 中定义。如果 Pod 通过 Service 暴露指标，应优先使用 ServiceMonitor。

3.3.3 ServiceMonitor vs PodMonitor 对比

维度	ServiceMonitor	PodMonitor
发现对象	Service → Endpoints	Pod（直接）
依赖	需要 Service 存在	无需 Service
适用场景	有 Service 的微服务	Sidecar、DaemonSet、无头服务
标签继承	继承 Service 标签	继承 Pod 标签
Istio 典型用法	采集 Ingress/Egress Gateway	采集所有注入 Sidecar 的 Pod

最佳实践：在 Istio 网格中，通常组合使用：ServiceMonitor 采集 Istio 控制面组件（Pilot、Mixer）和 Gateway；PodMonitor 采集所有注入 Sidecar 的工作负载 Pod，确保每个 Envoy 的指标都被覆盖。

3.4 本章小结

拉取模型是 Prometheus 的核心设计，适合 Kubernetes 动态环境，Istio 网格中的 Envoy Sidecar 天然支持。
Counter / Gauge / Histogram / Summary 四种指标类型覆盖了从计数、仪表到延迟分位数的全部监控需求。
ServiceMonitor 和 PodMonitor 是 Prometheus Operator 在 Kubernetes 中的声明式目标发现机制，是集成 Istio 网格监控的基石。