)
作者没有四次元口袋的蓝胖日期2026-09-30标签Prometheus, 监控体系PrometheusGrafana知识梳理(1)监控系统是后端架构中不可或缺的一环。在微服务时代没有监控就等于裸奔——服务挂了不知道、性能瓶颈找不到、容量规划靠猜。Prometheus 是目前最主流的开源监控方案几乎所有中大型公司都在用也是 Kubernetes 生态的标配监控组件。这篇笔记聚焦 Prometheus 本身的架构设计与数据采集能力从 Pull 模型的设计哲学到时序数据模型再到 node_exporter 采集器的安装配置和常用 PromQL 指标帮你建立扎实的基础认知。核心掌握Prometheus Pull模型与时序数据库、四大核心组件的职责分工、数据模型与四种指标类型、node_exporter采集与常用PromQL查询。一、Prometheus核心架构1.1 什么是PrometheusPrometheus 是一个开源的系统监控和告警工具包最初由 SoundCloud 于 2012 年开发2016 年加入 CNCF云原生计算基金会是 Kubernetes 生态的标配监控组件。核心特点多维数据模型基于 metric name key/value labels 组织时序数据Pull 模型主动从目标拉取指标数据也支持 Push 场景服务发现自动发现监控目标K8s、Consul、DNS 等强大的查询语言 PromQL支持丰富的聚合、计算和过滤1.2 Pull模型 vs Push模型这是面试高频考点。Prometheus 的核心设计哲学是Pull拉取模型。┌─────────────┐ HTTP GET /metrics ┌─────────────┐ │ Prometheus │ ◄──────────────────────────────── │ 目标服务 │ │ Server │ 定期拉取指标数据默认15s │ (Exporter) │ └─────────────┘ └─────────────┘ Pull模型的工作流程 1. Prometheus Server 定时scrape_interval向目标发送 HTTP GET 请求 2. 目标暴露一个 /metrics 端点返回纯文本格式的指标数据 3. Prometheus 解析并存储到时序数据库TSDB中Pull vs Push 对比维度Pull模型PrometheusPush模型传统监控数据流向监控中心主动拉取被监控端主动推送目标存活感知拉不到 目标挂了天然感知需要额外心跳机制配置管理集中在监控端配置分散在各业务端配置网络要求监控端需要能访问目标目标需要能访问监控端适用场景基础设施监控、微服务定时任务、批处理作业为什么选 Pull 而不是 Push这个设计决策背后有几个关键思考天然存活感知Pull 不到数据就意味着目标挂了不需要额外的心跳机制。配置集中所有采集目标配置在 Prometheus Server 端管理不用分散到各个业务服务。便于调试开发者可以直接curl http://target:port/metrics查看原始指标排查问题方便。服务发现友好配合 Consul、K8s 等服务发现机制新实例上线自动纳入监控。1.3 核心组件Prometheus 生态由多个组件协作构成完整的监控体系┌──────────────────┐ │ Prometheus │ │ Server │◄── 拉取指标 │ (存储查询告警) │ └────────┬─────────┘ │ ┌────────────┼────────────┐ │ │ │ ┌─────▼─────┐ ┌──▼──────┐ ┌───▼────────┐ │ TSDB │ │Alertman │ │ Grafana │ │ (时序数据库)│ │ ager │ │ (可视化) │ └───────────┘ └────┬────┘ └────────────┘ │ ┌────▼────┐ │ 邮件/钉钉 │ │ /微信等 │ └─────────┘组件职责说明Prometheus Server数据拉取、存储、查询核心组件包含 TSDB 和 PromQL 引擎Exporter暴露指标数据各种类型的指标采集器node_exporter、mysql_exporter 等Pushgateway接收短生命周期任务的推送定时任务等不适合 Pull 的场景Alertmanager告警处理与通知去重、分组、静默、路由到不同通知渠道Grafana可视化展示Dashboard 面板、数据探索各组件的关系Prometheus Server 是整个体系的核心负责定时从各 Exporter 拉取数据存储到本地时序数据库TSDB同时支持 PromQL 查询引擎和告警规则评估。Exporter 是各类指标采集器它们暴露 HTTP/metrics端点等待 Prometheus 来拉取。Pushgateway 是一个特殊组件用于接收短生命周期任务如 CronJob主动推送的指标。这类任务可能在 Prometheus 来 Pull 之前就执行结束了所以需要主动 Push。Alertmanager 接收 Prometheus 评估告警规则后发来的告警负责去重、分组、静默、抑制最终路由到邮件/钉钉/微信等通知渠道。Grafana 是纯可视化层从 Prometheus 读取数据进行展示本身不存储数据。二、数据模型2.1 时序数据格式Prometheus 的数据模型非常简洁每一条时序数据 metric name labels timestamp value。# 数据格式示例 http_requests_total{methodGET, handler/api/users, status200} 1027 http_requests_total{methodPOST, handler/api/users, status201} 83 # 拆解 # metric name: http_requests_total # labels: methodGET, handler/api/users, status200 # timestamp: Prometheus自动添加 # value: 1027metric name指标名称描述监控什么如http_requests_total、node_cpu_seconds_total。labels键值对标签用于区分同一指标的不同维度如methodGET区分请求方法。timestampPrometheus 自动添加的采集时间戳不需要手动指定。value指标值一个 64 位浮点数。这种设计的好处是通过 labels 的组合可以在同一个指标下表达非常丰富的维度信息查询时用 PromQL 按 labels 过滤和聚合。2.2 四种核心指标类型类型说明典型场景Counter只增不减的计数器请求总数、错误总数Gauge可增可减的仪表盘CPU使用率、内存使用量、队列长度Histogram直方图预定义桶分布请求延迟分布、响应大小分布Summary摘要客户端计算分位数请求延迟的 P99/P95# Counter示例累计请求数只能增加或重置为0http_requests_total{methodGET}5000# Gauge示例当前内存使用可增可减node_memory_MemAvailable_bytes 8589934592# Histogram示例请求延迟分布http_request_duration_seconds_bucket{le0.1}2400 http_request_duration_seconds_bucket{le0.5}4800 http_request_duration_seconds_bucket{le1.0}4950 http_request_duration_seconds_bucket{leInf}5000 http_request_duration_seconds_sum 1200.5 http_request_duration_seconds_count 5000四种类型的选型建议Counter任何累计量场景。注意 Counter 只能增加除非进程重启归零不能直接读值需要用rate()计算增长率。Gauge任何当前值场景。如温度、内存使用量、队列长度等可以直接读取当前值。Histogram需要知道分布的场景如请求延迟。桶bucket的划分在服务端定义多个实例的数据可以在 Prometheus Server 端聚合。Summary对单实例的分位数精度要求极高时使用。分位数在客户端计算精度更高但无法跨实例聚合。三、node_exporter采集与常用指标3.1 什么是node_exporternode_exporter是 Prometheus 官方提供的硬件和操作系统指标采集器用于采集 Linux/Unix 服务器的 CPU、内存、磁盘、网络等基础指标。它是监控体系中最基础的一环——先监控主机再监控应用。3.2 安装与配置二进制安装了解即可# 下载wgethttps://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gztarxzvf node_exporter-1.8.2.linux-amd64.tar.gzcdnode_exporter-1.8.2.linux-amd64# 启动默认监听 9100 端口./node_exporter# 验证访问 http://localhost:9100/metrics 即可看到指标数据Docker安装推荐# docker-compose.yml 片段services:node_exporter:image:prom/node-exporter:latestcontainer_name:node_exporterports:-9100:9100# 关键挂载宿主机文件系统才能采集宿主机指标volumes:-/proc:/host/proc:ro-/sys:/host/sys:ro-/:/rootfs:rocommand:---path.procfs/host/proc---path.sysfs/host/sys---path.rootfs/rootfs---collector.filesystem.mount-points-exclude^/(sys|proc|dev|host|container)($$|/)restart:unless-stopped要点Docker 安装时必须将宿主机的/proc、/sys、/以只读方式挂载到容器内并通过--path.*参数指定路径。否则 node_exporter 采集到的是容器自身的指标而不是宿主机。3.3 配置Prometheus采集在prometheus.yml中添加采集任务scrape jobglobal:scrape_interval:15s# 全局默认采集间隔scrape_configs:# 采集 Prometheus 自身指标-job_name:prometheusstatic_configs:-targets:[localhost:9090]# 采集 node_exporter-job_name:nodestatic_configs:-targets:[node_exporter:9100]# Docker环境用容器名labels:env:production# 自定义标签instance:web-server-013.4 常用指标速查面试和实际工作中最高频的 PromQL 查询按场景分类CPU相关# CPU使用率百分比 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) # 各模式CPU时间占比 rate(node_cpu_seconds_total[5m]) # CPU核心数 count(node_cpu_seconds_total{modeidle}) by (instance)解读CPU 使用率的核心思路是100% - idle%。node_cpu_seconds_total是 Counter 类型记录了各模式user、system、idle、iowait 等下的 CPU 秒数。用rate()计算每秒增长率取modeidle的空闲占比再用 100 减去就是使用率。内存相关# 内存使用率 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 # 可用内存 node_memory_MemAvailable_bytes # 已用内存不含buffer/cache node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes # Swap使用率 (1 - node_memory_SwapFree_bytes / node_memory_SwapTotal_bytes) * 100解读注意用MemAvailable而不是MemFree。MemAvailable包含了可回收的 buffer/cache 空间更能反映实际可用内存。MemFree只是完全空闲的内存Linux 会把大量内存用于缓存所以MemFree通常很小直接用会导致误报。磁盘相关# 磁盘使用率 (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) * 100 # 磁盘IO速率读 rate(node_disk_read_bytes_total[5m]) # 磁盘IO速率写 rate(node_disk_written_bytes_total[5m]) # inode使用率 (1 - node_filesystem_files_free / node_filesystem_files) * 100解读磁盘使用率用avail而不是free。avail包含可回收的空间如 reserved for rootfree是完全空闲的。监控用avail更准确。fstype!~tmpfs|overlay过滤掉临时文件系统只关注真实磁盘。网络相关# 网络接收速率bytes/s rate(node_network_receive_bytes_total{device!~lo|veth.*|docker.*}[5m]) # 网络发送速率bytes/s rate(node_network_transmit_bytes_total{device!~lo|veth.*|docker.*}[5m]) # 网络错误率 rate(node_network_receive_errs_total[5m])解读device!~lo|veth.*|docker.*过滤掉 loopback、虚拟网卡和 Docker 网桥只关注真实物理网卡。四、PromQL关键函数速记PromQL 是 Prometheus 的查询语言以下是数据采集场景中最常用的函数函数作用适用类型说明rate()每秒平均增长率Counter取时间窗口内所有点做线性回归平滑irate()瞬时增长率Counter只取最后两个数据点对突变更敏感increase()时间段内的增量Counter等价于rate() * 时间窗口秒数histogram_quantile()分位数计算Histogram如histogram_quantile(0.99, ...)算 P99avg by()/sum by()聚合运算通用按指定 label 分组聚合rate()vsirate()irate()只取最后两个数据点对突变更敏感适合实时面板展示。rate()取时间窗口内所有点做线性回归更平滑适合告警规则。告警用rate()实时面板可以用irate()。五、常见面试注意点Pull模型的优势天然感知目标存活、配置集中、易于调试直接 curl /metrics 查看。Push模型的使用场景短生命周期的批处理任务如 CronJob这类任务可能还没等到 Pull 就结束了需要主动 Push 到 Pushgateway。Counter vs GaugeCounter 只能用rate()/increase()计算速率Gauge 可以直接读取当前值。Histogram vs SummaryHistogram 在服务端聚合适合多实例Summary 的分位数在客户端计算无法跨实例聚合。️ 思维导图速览Prometheus 架构与数据采集 ├── Pull模型 │ ├── 工作流程定时HTTP GET → /metrics → 解析存储 │ ├── 优势存活感知、配置集中、便于调试 │ └── Push场景短生命周期任务 → Pushgateway │ ├── 核心组件 │ ├── Prometheus Server拉取存储查询告警 │ ├── Exporter暴露指标node/mysql/redis exporter │ ├── Pushgateway接收短任务推送 │ ├── Alertmanager告警处理与通知见后续文章 │ └── Grafana可视化展示见后续文章 │ ├── 数据模型 │ ├── 格式metric_name{labels} value │ ├── Counter只增不减 → rate()/increase() │ ├── Gauge可增可减 → 直接读值 │ ├── Histogram桶分布 → 服务端聚合 │ └── Summary客户端分位数 → 无法跨实例聚合 │ ├── node_exporter │ ├── 安装二进制 / Docker挂载 /proc /sys / │ ├── 配置prometheus.yml 添加 scrape_configs │ └── 常用指标 │ ├── CPU100 - idle% → rate() │ ├── 内存1 - avail/total │ ├── 磁盘1 - avail/size → 过滤tmpfs │ └── 网络rate(receive/transmit_bytes_total) │ └── PromQL关键函数 ├── rate()平滑增长率告警推荐 ├── irate()瞬时增长率面板推荐 ├── increase()时间段增量 └── histogram_quantile()分位数 写在最后学习建议理解 Pull 模型的设计哲学为什么选 Pull 而不是 Push这个设计决策背后的思考服务发现、配置集中、存活感知是面试常考的架构设计题。熟悉四种指标类型Counter/Gauge/Histogram/Summary 各自适用什么场景、怎么查询这是基础知识中的基础。动手写 PromQL把上面的 CPU、内存、磁盘、网络 PromQL 在 Prometheus UI 里敲一遍看看返回结果。纸上得来终觉浅。搞清楚rate()和irate()的区别这在面试和实际工作中都非常高频。面试高频问题速答QPrometheus 的 Pull 模型和 Push 模型有什么区别Pull 模型Prometheus Server 定时主动拉取目标的 /metrics 端点数据。优势是天然感知目标存活拉不到就是挂了、配置集中、便于调试。Push 模型目标主动推送数据到 Pushgateway适用于短生命周期的批处理任务如 CronJob这类任务可能在 Pull 之前就执行完了。QCounter 和 Gauge 有什么区别Counter 是只增不减的计数器如请求总数只能通过rate()或increase()计算变化率。Gauge 是可增可减的仪表盘如 CPU 使用率可以直接读取当前值。QHistogram 和 Summary 有什么区别Histogram 在服务端维护预定义桶bucket的计数器多个实例的数据可以在 Prometheus Server 端聚合适合多副本场景。Summary 在客户端直接计算分位数如 P99精度更高但无法跨实例聚合。一般推荐用 Histogram。
作者没有四次元口袋的蓝胖日期2026-09-30标签Prometheus, 监控体系PrometheusGrafana知识梳理(1)监控系统是后端架构中不可或缺的一环。在微服务时代没有监控就等于裸奔——服务挂了不知道、性能瓶颈找不到、容量规划靠猜。Prometheus 是目前最主流的开源监控方案几乎所有中大型公司都在用也是 Kubernetes 生态的标配监控组件。这篇笔记聚焦 Prometheus 本身的架构设计与数据采集能力从 Pull 模型的设计哲学到时序数据模型再到 node_exporter 采集器的安装配置和常用 PromQL 指标帮你建立扎实的基础认知。核心掌握Prometheus Pull模型与时序数据库、四大核心组件的职责分工、数据模型与四种指标类型、node_exporter采集与常用PromQL查询。一、Prometheus核心架构1.1 什么是PrometheusPrometheus 是一个开源的系统监控和告警工具包最初由 SoundCloud 于 2012 年开发2016 年加入 CNCF云原生计算基金会是 Kubernetes 生态的标配监控组件。核心特点多维数据模型基于 metric name key/value labels 组织时序数据Pull 模型主动从目标拉取指标数据也支持 Push 场景服务发现自动发现监控目标K8s、Consul、DNS 等强大的查询语言 PromQL支持丰富的聚合、计算和过滤1.2 Pull模型 vs Push模型这是面试高频考点。Prometheus 的核心设计哲学是Pull拉取模型。┌─────────────┐ HTTP GET /metrics ┌─────────────┐ │ Prometheus │ ◄──────────────────────────────── │ 目标服务 │ │ Server │ 定期拉取指标数据默认15s │ (Exporter) │ └─────────────┘ └─────────────┘ Pull模型的工作流程 1. Prometheus Server 定时scrape_interval向目标发送 HTTP GET 请求 2. 目标暴露一个 /metrics 端点返回纯文本格式的指标数据 3. Prometheus 解析并存储到时序数据库TSDB中Pull vs Push 对比维度Pull模型PrometheusPush模型传统监控数据流向监控中心主动拉取被监控端主动推送目标存活感知拉不到 目标挂了天然感知需要额外心跳机制配置管理集中在监控端配置分散在各业务端配置网络要求监控端需要能访问目标目标需要能访问监控端适用场景基础设施监控、微服务定时任务、批处理作业为什么选 Pull 而不是 Push这个设计决策背后有几个关键思考天然存活感知Pull 不到数据就意味着目标挂了不需要额外的心跳机制。配置集中所有采集目标配置在 Prometheus Server 端管理不用分散到各个业务服务。便于调试开发者可以直接curl http://target:port/metrics查看原始指标排查问题方便。服务发现友好配合 Consul、K8s 等服务发现机制新实例上线自动纳入监控。1.3 核心组件Prometheus 生态由多个组件协作构成完整的监控体系┌──────────────────┐ │ Prometheus │ │ Server │◄── 拉取指标 │ (存储查询告警) │ └────────┬─────────┘ │ ┌────────────┼────────────┐ │ │ │ ┌─────▼─────┐ ┌──▼──────┐ ┌───▼────────┐ │ TSDB │ │Alertman │ │ Grafana │ │ (时序数据库)│ │ ager │ │ (可视化) │ └───────────┘ └────┬────┘ └────────────┘ │ ┌────▼────┐ │ 邮件/钉钉 │ │ /微信等 │ └─────────┘组件职责说明Prometheus Server数据拉取、存储、查询核心组件包含 TSDB 和 PromQL 引擎Exporter暴露指标数据各种类型的指标采集器node_exporter、mysql_exporter 等Pushgateway接收短生命周期任务的推送定时任务等不适合 Pull 的场景Alertmanager告警处理与通知去重、分组、静默、路由到不同通知渠道Grafana可视化展示Dashboard 面板、数据探索各组件的关系Prometheus Server 是整个体系的核心负责定时从各 Exporter 拉取数据存储到本地时序数据库TSDB同时支持 PromQL 查询引擎和告警规则评估。Exporter 是各类指标采集器它们暴露 HTTP/metrics端点等待 Prometheus 来拉取。Pushgateway 是一个特殊组件用于接收短生命周期任务如 CronJob主动推送的指标。这类任务可能在 Prometheus 来 Pull 之前就执行结束了所以需要主动 Push。Alertmanager 接收 Prometheus 评估告警规则后发来的告警负责去重、分组、静默、抑制最终路由到邮件/钉钉/微信等通知渠道。Grafana 是纯可视化层从 Prometheus 读取数据进行展示本身不存储数据。二、数据模型2.1 时序数据格式Prometheus 的数据模型非常简洁每一条时序数据 metric name labels timestamp value。# 数据格式示例 http_requests_total{methodGET, handler/api/users, status200} 1027 http_requests_total{methodPOST, handler/api/users, status201} 83 # 拆解 # metric name: http_requests_total # labels: methodGET, handler/api/users, status200 # timestamp: Prometheus自动添加 # value: 1027metric name指标名称描述监控什么如http_requests_total、node_cpu_seconds_total。labels键值对标签用于区分同一指标的不同维度如methodGET区分请求方法。timestampPrometheus 自动添加的采集时间戳不需要手动指定。value指标值一个 64 位浮点数。这种设计的好处是通过 labels 的组合可以在同一个指标下表达非常丰富的维度信息查询时用 PromQL 按 labels 过滤和聚合。2.2 四种核心指标类型类型说明典型场景Counter只增不减的计数器请求总数、错误总数Gauge可增可减的仪表盘CPU使用率、内存使用量、队列长度Histogram直方图预定义桶分布请求延迟分布、响应大小分布Summary摘要客户端计算分位数请求延迟的 P99/P95# Counter示例累计请求数只能增加或重置为0http_requests_total{methodGET}5000# Gauge示例当前内存使用可增可减node_memory_MemAvailable_bytes 8589934592# Histogram示例请求延迟分布http_request_duration_seconds_bucket{le0.1}2400 http_request_duration_seconds_bucket{le0.5}4800 http_request_duration_seconds_bucket{le1.0}4950 http_request_duration_seconds_bucket{leInf}5000 http_request_duration_seconds_sum 1200.5 http_request_duration_seconds_count 5000四种类型的选型建议Counter任何累计量场景。注意 Counter 只能增加除非进程重启归零不能直接读值需要用rate()计算增长率。Gauge任何当前值场景。如温度、内存使用量、队列长度等可以直接读取当前值。Histogram需要知道分布的场景如请求延迟。桶bucket的划分在服务端定义多个实例的数据可以在 Prometheus Server 端聚合。Summary对单实例的分位数精度要求极高时使用。分位数在客户端计算精度更高但无法跨实例聚合。三、node_exporter采集与常用指标3.1 什么是node_exporternode_exporter是 Prometheus 官方提供的硬件和操作系统指标采集器用于采集 Linux/Unix 服务器的 CPU、内存、磁盘、网络等基础指标。它是监控体系中最基础的一环——先监控主机再监控应用。3.2 安装与配置二进制安装了解即可# 下载wgethttps://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gztarxzvf node_exporter-1.8.2.linux-amd64.tar.gzcdnode_exporter-1.8.2.linux-amd64# 启动默认监听 9100 端口./node_exporter# 验证访问 http://localhost:9100/metrics 即可看到指标数据Docker安装推荐# docker-compose.yml 片段services:node_exporter:image:prom/node-exporter:latestcontainer_name:node_exporterports:-9100:9100# 关键挂载宿主机文件系统才能采集宿主机指标volumes:-/proc:/host/proc:ro-/sys:/host/sys:ro-/:/rootfs:rocommand:---path.procfs/host/proc---path.sysfs/host/sys---path.rootfs/rootfs---collector.filesystem.mount-points-exclude^/(sys|proc|dev|host|container)($$|/)restart:unless-stopped要点Docker 安装时必须将宿主机的/proc、/sys、/以只读方式挂载到容器内并通过--path.*参数指定路径。否则 node_exporter 采集到的是容器自身的指标而不是宿主机。3.3 配置Prometheus采集在prometheus.yml中添加采集任务scrape jobglobal:scrape_interval:15s# 全局默认采集间隔scrape_configs:# 采集 Prometheus 自身指标-job_name:prometheusstatic_configs:-targets:[localhost:9090]# 采集 node_exporter-job_name:nodestatic_configs:-targets:[node_exporter:9100]# Docker环境用容器名labels:env:production# 自定义标签instance:web-server-013.4 常用指标速查面试和实际工作中最高频的 PromQL 查询按场景分类CPU相关# CPU使用率百分比 100 - (avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100) # 各模式CPU时间占比 rate(node_cpu_seconds_total[5m]) # CPU核心数 count(node_cpu_seconds_total{modeidle}) by (instance)解读CPU 使用率的核心思路是100% - idle%。node_cpu_seconds_total是 Counter 类型记录了各模式user、system、idle、iowait 等下的 CPU 秒数。用rate()计算每秒增长率取modeidle的空闲占比再用 100 减去就是使用率。内存相关# 内存使用率 (1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 # 可用内存 node_memory_MemAvailable_bytes # 已用内存不含buffer/cache node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes # Swap使用率 (1 - node_memory_SwapFree_bytes / node_memory_SwapTotal_bytes) * 100解读注意用MemAvailable而不是MemFree。MemAvailable包含了可回收的 buffer/cache 空间更能反映实际可用内存。MemFree只是完全空闲的内存Linux 会把大量内存用于缓存所以MemFree通常很小直接用会导致误报。磁盘相关# 磁盘使用率 (1 - node_filesystem_avail_bytes{fstype!~tmpfs|overlay} / node_filesystem_size_bytes{fstype!~tmpfs|overlay}) * 100 # 磁盘IO速率读 rate(node_disk_read_bytes_total[5m]) # 磁盘IO速率写 rate(node_disk_written_bytes_total[5m]) # inode使用率 (1 - node_filesystem_files_free / node_filesystem_files) * 100解读磁盘使用率用avail而不是free。avail包含可回收的空间如 reserved for rootfree是完全空闲的。监控用avail更准确。fstype!~tmpfs|overlay过滤掉临时文件系统只关注真实磁盘。网络相关# 网络接收速率bytes/s rate(node_network_receive_bytes_total{device!~lo|veth.*|docker.*}[5m]) # 网络发送速率bytes/s rate(node_network_transmit_bytes_total{device!~lo|veth.*|docker.*}[5m]) # 网络错误率 rate(node_network_receive_errs_total[5m])解读device!~lo|veth.*|docker.*过滤掉 loopback、虚拟网卡和 Docker 网桥只关注真实物理网卡。四、PromQL关键函数速记PromQL 是 Prometheus 的查询语言以下是数据采集场景中最常用的函数函数作用适用类型说明rate()每秒平均增长率Counter取时间窗口内所有点做线性回归平滑irate()瞬时增长率Counter只取最后两个数据点对突变更敏感increase()时间段内的增量Counter等价于rate() * 时间窗口秒数histogram_quantile()分位数计算Histogram如histogram_quantile(0.99, ...)算 P99avg by()/sum by()聚合运算通用按指定 label 分组聚合rate()vsirate()irate()只取最后两个数据点对突变更敏感适合实时面板展示。rate()取时间窗口内所有点做线性回归更平滑适合告警规则。告警用rate()实时面板可以用irate()。五、常见面试注意点Pull模型的优势天然感知目标存活、配置集中、易于调试直接 curl /metrics 查看。Push模型的使用场景短生命周期的批处理任务如 CronJob这类任务可能还没等到 Pull 就结束了需要主动 Push 到 Pushgateway。Counter vs GaugeCounter 只能用rate()/increase()计算速率Gauge 可以直接读取当前值。Histogram vs SummaryHistogram 在服务端聚合适合多实例Summary 的分位数在客户端计算无法跨实例聚合。️ 思维导图速览Prometheus 架构与数据采集 ├── Pull模型 │ ├── 工作流程定时HTTP GET → /metrics → 解析存储 │ ├── 优势存活感知、配置集中、便于调试 │ └── Push场景短生命周期任务 → Pushgateway │ ├── 核心组件 │ ├── Prometheus Server拉取存储查询告警 │ ├── Exporter暴露指标node/mysql/redis exporter │ ├── Pushgateway接收短任务推送 │ ├── Alertmanager告警处理与通知见后续文章 │ └── Grafana可视化展示见后续文章 │ ├── 数据模型 │ ├── 格式metric_name{labels} value │ ├── Counter只增不减 → rate()/increase() │ ├── Gauge可增可减 → 直接读值 │ ├── Histogram桶分布 → 服务端聚合 │ └── Summary客户端分位数 → 无法跨实例聚合 │ ├── node_exporter │ ├── 安装二进制 / Docker挂载 /proc /sys / │ ├── 配置prometheus.yml 添加 scrape_configs │ └── 常用指标 │ ├── CPU100 - idle% → rate() │ ├── 内存1 - avail/total │ ├── 磁盘1 - avail/size → 过滤tmpfs │ └── 网络rate(receive/transmit_bytes_total) │ └── PromQL关键函数 ├── rate()平滑增长率告警推荐 ├── irate()瞬时增长率面板推荐 ├── increase()时间段增量 └── histogram_quantile()分位数 写在最后学习建议理解 Pull 模型的设计哲学为什么选 Pull 而不是 Push这个设计决策背后的思考服务发现、配置集中、存活感知是面试常考的架构设计题。熟悉四种指标类型Counter/Gauge/Histogram/Summary 各自适用什么场景、怎么查询这是基础知识中的基础。动手写 PromQL把上面的 CPU、内存、磁盘、网络 PromQL 在 Prometheus UI 里敲一遍看看返回结果。纸上得来终觉浅。搞清楚rate()和irate()的区别这在面试和实际工作中都非常高频。面试高频问题速答QPrometheus 的 Pull 模型和 Push 模型有什么区别Pull 模型Prometheus Server 定时主动拉取目标的 /metrics 端点数据。优势是天然感知目标存活拉不到就是挂了、配置集中、便于调试。Push 模型目标主动推送数据到 Pushgateway适用于短生命周期的批处理任务如 CronJob这类任务可能在 Pull 之前就执行完了。QCounter 和 Gauge 有什么区别Counter 是只增不减的计数器如请求总数只能通过rate()或increase()计算变化率。Gauge 是可增可减的仪表盘如 CPU 使用率可以直接读取当前值。QHistogram 和 Summary 有什么区别Histogram 在服务端维护预定义桶bucket的计数器多个实例的数据可以在 Prometheus Server 端聚合适合多副本场景。Summary 在客户端直接计算分位数如 P99精度更高但无法跨实例聚合。一般推荐用 Histogram。
