前言在云原生与 Kubernetes 成为基础设施标准的今天Prometheus 已经成为集群监控领域的事实标准。但很多同学在实际部署使用时依然会遇到核心疑问Prometheus 的底层逻辑是什么监控 K8s 集群到底需要哪些组件kube-state-metrics 和 Metrics Server 有什么区别标签是如何生成的PromQL 该怎么写本文将基于真实 K8s 部署场景严谨、系统地讲解 Prometheus 的核心知识所有内容均来自实战落地经验无冗余扩展一篇帮你彻底搞懂 Prometheus 的全链路逻辑。一、Prometheus 基础背景与核心定位1.1 起源与发展历程Prometheus 诞生于 2012 年由音乐流媒体平台 SoundCloud 为解决传统监控无法适配动态微服务环境的痛点而自研。2016 年正式加入CNCF云原生计算基金会2018 年成为继 Kubernetes 之后CNCF第二个正式毕业的顶级项目如今已被全球主流云厂商原生支持是 Kubernetes 生态默认的监控方案。1.2 开源与技术栈开源协议Apache 2.0完全开源免费支持商用与二次开发无版权风险开发语言Go 语言具备静态编译无依赖、高并发、低内存占用的特性天然适配基础设施类场景核心定位开源的时序数据库TSDB与监控告警系统专注于指标Metric监控是可观测性三大支柱Metrics/Logs/Traces的核心一环采集模式以 HTTP Pull拉取模式为主Push推送模式为辅。1.3 解决的核心痛点传统监控方案Zabbix、Nagios 等在云原生时代存在致命短板无法自动发现动态扩缩容的 Pod/Service、不支持多维度标签查询、配置复杂扩展性差无法适配 K8s 高弹性、高动态的运行环境。而 Prometheus 正是为云原生动态基础设施而生的监控系统。二、Prometheus 核心架构与数据流向2.1 核心组件一览Prometheus 架构极简无复杂分布式依赖单节点即可支撑大规模集群监控核心组件包括Prometheus Server核心引擎负责指标抓取、时序数据存储、PromQL 查询、规则计算与告警判定Exporter各类指标采集器如 node-exporter、kube-state-metrics 等负责将监控目标的数据转化为 Prometheus 可识别的格式PushGateway短生命周期任务Job/CronJob的指标推送网关补充 Pull 模式的短板AlertManager负责告警的去重、抑制、聚合与分发支持邮件、企业微信、钉钉等通知渠道服务发现模块支持静态配置、Kubernetes、Consul 等多种服务发现方式自动更新监控目标Grafana生态标配的可视化面板不属于 Prometheus 原生组件但已成为监控体系的必备环节。2.2 标准数据流向应用/Exporter 暴露标准/metrics接口 ↓ Prometheus Server 按配置定时HTTP Pull拉取指标 ↓ 数据写入本地TSDB时序数据库 ↓ PromQL查询 / 告警规则计算 ↓ Grafana可视化展示 / AlertManager分发告警三、Prometheus 核心数据模型时序数据与标签机制3.1 时序数据的标准结构Prometheus 的所有数据都以时序数据的形式存储单条时序数据的格式为指标名{标签名1值1,标签名2值2,...} 数值 时间戳示例node_cpu_seconds_total{cpu0,modeidle,nodenode-1} 123456.7 17000000000003.2 时间戳的生成规则Pull 模式99% 生产场景时间戳由Prometheus Server 在拉取指标的那一刻自动生成无需客户端配置Push 模式仅短生命周期任务场景使用可由客户端携带时间戳。3.3 标签的定义与分类标签是 Prometheus 最核心的设计是实现多维度查询的基础分为两类系统 / 组件自带标签由 Exporter、Kubernetes 服务发现模块内置定义用户不可修改例如namespace、pod、node、mode等自定义应用标签完全由开发者在代码中通过 Prometheus 客户端 SDK 自定义例如methodGET、path/api/user、status200等。3.4 如何查看指标与标签查看指标与标签最准确、最直接的方式是直接访问监控目标的/metrics接口curl 监控目标IP:端口/metrics接口返回的内容中会完整展示所有指标名、标签、指标类型与帮助信息。四、Prometheus 四大指标类型Prometheus 仅定义了 4 种核心指标类型覆盖了所有监控场景是 PromQL 查询的基础Counter计数器特性只增不减重启后重置适用场景请求总数、错误数、流量总量、CPU 运行耗时等累计型指标注意事项必须配合rate()/increase()函数计算变化率直接查询无业务意义。Gauge仪表盘特性可增可减实时反映当前状态适用场景内存使用量、CPU 使用率、连接数、队列长度、Pod 副本数等状态型指标注意事项可直接查询当前值。Histogram直方图特性按预设分桶统计数据分布可在服务端聚合计算分位数适用场景接口请求延迟、响应耗时等需要统计 P99/P95 分布的指标。Summary摘要特性客户端直接计算分位数性能更优但无法跨实例聚合适用场景单实例的延迟分布统计企业生产环境使用较少。五、Prometheus 监控 K8s 集群的完整实现5.1 K8s 监控的三大核心数据源Prometheus 监控 K8s 集群的指标全部来自三个核心数据源缺一不可node-exporter作用采集节点级的硬件与系统指标包括 CPU、内存、磁盘、网络、系统负载、文件系统使用率等部署方式必须以 DaemonSet 形式部署确保每个 K8s 节点都运行一个实例。cadvisor作用采集 Pod 与容器级的资源使用指标包括容器 CPU、内存、网络、磁盘 IO 等部署方式无需单独部署已内置在 K8s 每个节点的 kubelet 组件中默认开启。kube-state-metricsKSM作用监听 K8s API Server将 K8s 资源对象的状态转化为 Prometheus 指标包括 Pod 运行状态、Deployment 副本数、Node 就绪状态、Service 端点数量、PV/PVC 绑定状态等部署方式必须手动单独部署K8s 集群默认不自带。5.2 高频混淆点kube-state-metrics vs Metrics Server这是生产部署与面试中最高频的易错点二者完全不是同一个东西核心区别如下表格组件核心作用数据来源服务对象Metrics Server采集节点与 Pod 的 CPU / 内存资源使用率kubeletkubectl top 命令、HPA 水平扩缩容kube-state-metrics采集 K8s 资源对象的状态信息K8s API ServerPrometheus 监控系统一句话总结Metrics Server 是看资源用了多少kube-state-metrics 是看资源现在是什么状态二者功能完全独立Metrics Server 与 Prometheus 监控无直接关联。5.3 K8s 服务发现原理Prometheus 无需手动配置监控目标通过Kubernetes SD服务发现实现动态目标管理核心流程为Prometheus 通过绑定的 RBAC 权限访问 K8s API Server实时监听集群内的 Node、Pod、Endpoints、Service 等资源的变更通过配置的relabel_configs规则对目标进行过滤、标签重写生成最终的采集任务动态更新采集目标新增 / 删除资源时无需重启 Prometheus。你部署配置中的这段内容就是开启 Pod 维度的服务发现kubernetes_sd_configs: - role: pod六、PromQL 核心语法与实战PromQLPrometheus Query Language是 Prometheus 的专属查询语言核心本质就是基于「指标名 标签过滤」实现时序数据的查询、过滤与计算。6.1 基础查询语法1. 直接查询指标名语法指标名作用查询该指标下所有标签组合的时序数据示例# 查询节点CPU总耗时指标的所有数据 node_cpu_seconds_total2. 标签过滤最核心操作语法指标名{标签名1匹配规则,标签名2匹配规则,...}支持 4 种匹配运算符表格运算符作用标签值精确匹配!标签值精确不匹配~标签值正则匹配!~标签值正则不匹配示例# 查询node-1节点的空闲CPU耗时 node_cpu_seconds_total{nodenode-1,modeidle} # 查询所有非kube-system命名空间下状态为Running的Pod指标 kube_pod_status_phase{namespace!~kube-system,phaseRunning}3. 范围查询语法指标名{标签过滤}[时间范围]时间单位支持s秒、m分钟、h小时、d天示例# 查询过去5分钟内的节点CPU指标数据 node_cpu_seconds_total{nodenode-1}[5m]6.2 常用核心函数1. 变化率计算函数Counter 类型专用rate(指标[时间范围])计算指标在时间范围内的每秒平均增长率是监控 CPU、请求量等指标的核心函数increase(指标[时间范围])计算指标在时间范围内的总增量。示例# 计算过去5分钟内非空闲CPU的每秒平均耗时 rate(node_cpu_seconds_total{mode!idle}[5m])2. 聚合函数支持sum()、avg()、max()、min()、count()配合by (标签)实现按维度分组聚合示例# 按节点分组计算每个节点的非空闲CPU总耗时 sum(rate(node_cpu_seconds_total{mode!idle}[5m])) by (node)6.3 常用核心标签标签名打标方含义示例值核心用途jobPrometheus Server被监控目标所属的 “任务组”jobnode-exporter区分指标来源的 “大类”instancePrometheus Server被监控目标的具体地址 端口instance10.244.1.5:9100区分同一 job 下的不同实例namespaceExporter/KSM/ 业务代码K8s 命名空间namespacemonitoring区分不同命名空间的资源podKSM / 业务代码K8s Pod 名称podmy-app-7f987d65c4-2xq8z定位指标所属的 PodmodeNode-ExporterCPU 使用模式Node-Exporter 专属modeidle/user/system区分 CPU 的不同使用场景phaseKSMPod 状态KSM 专属phaseRunning/Pending筛选不同状态的 Podmethod业务代码客户端HTTP 请求方法methodGET/POST分析不同请求方法的指标status_code业务代码客户端HTTP 响应码status_code200/500分析接口错误率path业务代码客户端HTTP 请求路径path/api/user分析不同接口的 QPS / 延迟cpuNode-ExporterCPU 核心编号Node-Exporter 专属cpu0/1/total分析单个 CPU 核心的使用率mountpointNode-Exporter磁盘挂载点Node-Exporter 专属mountpoint/分析不同挂载点的磁盘使用率6.4 生产高频实战语句# 1. 节点CPU使用率按节点分组 sum(rate(node_cpu_seconds_total{mode!idle}[5m])) by (node) / sum(rate(node_cpu_seconds_total[5m])) by (node) * 100 # 2. 节点内存使用率 100 - (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes * 100) # 3. 按命名空间分组统计Running状态的Pod数量 count(kube_pod_status_phase{phaseRunning}) by (namespace) # 4. 容器CPU使用率按Pod分组 sum(rate(container_cpu_usage_seconds_total[5m])) by (pod)七、自定义应用的 Prometheus 监控实现Prometheus 监控自研应用的核心逻辑是让应用暴露符合 Prometheus 格式标准的/metrics接口再由 Prometheus 拉取指标。7.1 实现步骤引入客户端 SDKPrometheus 提供了主流语言的官方 SDK包括 Go、Java、Python、Node.js 等代码埋点在业务代码中定义 Counter、Gauge 等类型的指标在业务逻辑中更新指标数值暴露 /metrics 接口通过 HTTP 服务暴露/metrics接口自动输出标准化的指标数据。7.2 K8s 环境自动发现配置只需给应用 Pod 添加以下注解即可被你部署的 Prometheus 自动发现并采集annotations: prometheus.io/scrape: true prometheus.io/port: 应用端口 prometheus.io/path: /metrics八、总结Prometheus 作为云原生监控的事实标准其核心价值在于极简的架构、强大的多维度标签模型、原生适配 K8s 的服务发现能力以及灵活的 PromQL 查询语言。本文完整覆盖了 Prometheus 的背景原理、数据模型、K8s 监控实现、PromQL 语法、自定义应用监控与部署清单所有内容均来自实战场景无冗余扩展帮你彻底打通 Prometheus 从原理到落地的全链路逻辑。