从node_cpu_seconds_total到告警手把手教你用PromQL计算Node Exporter核心指标当你第一次打开Node Exporter的/metrics端点时那些密密麻麻的指标数据可能会让你感到无从下手。作为Prometheus监控体系中最基础的数据采集组件Node Exporter提供了数百个系统指标但如何将这些原始数据转化为有业务意义的监控图表和告警规则这正是PromQL大显身手的地方。本文将聚焦CPU、内存、磁盘三大核心系统指标通过数学推导式的讲解带你一步步理解如何从原始Counter类型指标开始经过层层计算最终得到可直接用于监控的可视化数据。不同于简单的查询语句复制粘贴我们会深入每个计算步骤背后的设计思路让你真正掌握PromQL的精髓。1. CPU使用率从时间计数器到百分比理解CPU使用率的计算逻辑是掌握系统监控的第一步。Node Exporter提供的node_cpu_seconds_total是一个典型的Counter类型指标它记录了CPU在各种模式下累积消耗的时间单位秒。当我们看到这样的数据时node_cpu_seconds_total{cpu0,modeidle} 13172.76 node_cpu_seconds_total{cpu0,modeuser} 79.93 node_cpu_seconds_total{cpu1,modesystem} 309.38首先需要明确几个关键点这是一个累积值从系统启动开始不断累加每个CPU核心都有独立的统计cpu0, cpu1等区分了多种工作模式idle, user, system等1.1 Counter类型的特点与处理Counter类型指标的特点是只增不减除非系统重启。要计算CPU使用率这类百分比指标我们需要关注的是时间窗口内的变化量而非绝对值。这就是为什么PromQL提供了rate()和increase()函数# 计算5分钟内CPU空闲时间的平均增长速率单位秒/秒 rate(node_cpu_seconds_total{modeidle}[5m]) # 计算5分钟内CPU空闲时间的总增量单位秒 increase(node_cpu_seconds_total{modeidle}[5m])提示在大多数场景下rate()比increase()更推荐使用因为它能更好地处理Counter重置如进程重启的情况。1.2 多核CPU的聚合计算现代服务器通常都有多个CPU核心我们需要将所有核心的数据聚合起来才能反映整体CPU使用情况。这里就需要用到sum()聚合运算符sum(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)这个查询做了三件事使用rate()计算5分钟时间窗口内idle模式的CPU时间增长率使用sum()聚合所有CPU核心的数据通过by (instance)保留实例标签确保不同主机的数据不会混在一起1.3 最终使用率计算公式CPU使用率的本质是非空闲时间占总时间的比例。因此最直观的计算方式是( 1 - sum(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance) / sum(rate(node_cpu_seconds_total[5m])) by (instance) ) * 100这个查询可以分解为分母计算所有模式的总CPU时间分子计算空闲CPU时间用1减去空闲比例得到使用比例乘以100转换为百分比2. 内存使用率理解available与free的区别内存监控比CPU稍微复杂一些因为Linux内存管理机制中有buffer和cache的概念。Node Exporter提供了多个内存相关指标node_memory_MemTotal_bytes # 总内存 node_memory_MemFree_bytes # 完全空闲内存 node_memory_Buffers_bytes # 缓冲区内存 node_memory_Cached_bytes # 页面缓存 node_memory_MemAvailable_bytes # 估算的可用内存2.1 可用内存的准确计算free命令输出的available内存是一个估算值表示在不使用swap的情况下应用程序可以实际使用的内存量。它的计算逻辑大致是可用内存 ≈ MemFree Buffers Cached - 不可回收部分在PromQL中我们可以用以下查询近似计算可用内存node_memory_MemFree_bytes node_memory_Buffers_bytes node_memory_Cached_bytes注意这只是一个近似值精确值应该直接使用node_memory_MemAvailable_bytes指标如果内核版本支持。2.2 内存使用率的最佳实践与CPU不同内存使用率的计算应该基于已用内存/总内存而非1 - 空闲比例因为buffer和cache也属于被使用的内存尽管可以被回收。推荐的计算公式是( (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes ) * 100这个查询更准确地反映了系统内存压力因为它考虑了buffer/cache等可回收内存的实际使用情况。3. 磁盘空间与IO监控磁盘监控通常分为两部分存储空间使用情况和IO性能指标。Node Exporter为两者都提供了详细的指标。3.1 磁盘空间使用率磁盘空间相关的主要指标包括node_filesystem_size_bytes # 文件系统总大小 node_filesystem_avail_bytes # 可用空间 node_filesystem_files # inode总数 node_filesystem_files_free # 空闲inode数计算磁盘使用率时通常需要过滤掉特殊文件系统如tmpfs( 1 - node_filesystem_avail_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} ) * 100对于inode使用率的计算也类似( 1 - node_filesystem_files_free{fstype~ext4|xfs} / node_filesystem_files{fstype~ext4|xfs} ) * 1003.2 磁盘IO性能指标磁盘IO监控主要关注读写操作的吞吐量和延迟node_disk_read_bytes_total # 读取字节数 node_disk_written_bytes_total # 写入字节数 node_disk_io_time_seconds_total # IO耗时 node_disk_reads_completed_total # 完成读操作数 node_disk_writes_completed_total # 完成写操作数计算磁盘读写吞吐量单位MB/s# 读吞吐量 sum by(instance) ( rate(node_disk_read_bytes_total[5m]) ) / 1024 / 1024 # 写吞吐量 sum by(instance) ( rate(node_disk_written_bytes_total[5m]) ) / 1024 / 1024监控IO延迟单位毫秒# 平均读延迟 ( rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) ) * 1000 # 平均写延迟 ( rate(node_disk_write_time_seconds_total[5m]) / rate(node_disk_writes_completed_total[5m]) ) * 10004. 从监控到告警关键指标的阈值设置有了基础监控指标后下一步就是设置合理的告警规则。以下是几个核心指标的告警建议4.1 CPU告警规则- alert: HighCPUUsage expr: | 100 - ( avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100 ) 80 for: 10m labels: severity: warning annotations: summary: High CPU usage on {{ $labels.instance }} description: CPU usage is {{ $value }}% for last 10 minutes4.2 内存告警规则- alert: HighMemoryUsage expr: | ( (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes ) * 100 90 for: 15m labels: severity: warning annotations: summary: High memory usage on {{ $labels.instance }} description: Memory usage is {{ $value }}% for last 15 minutes4.3 磁盘空间告警规则- alert: LowDiskSpace expr: | ( node_filesystem_avail_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} ) * 100 10 for: 1h labels: severity: critical annotations: summary: Low disk space on {{ $labels.instance }} {{ $labels.mountpoint }} description: Only {{ $value }}% space left在实际生产环境中我发现磁盘空间告警的for时间应该设置得比CPU/内存更长一些因为磁盘空间问题通常不会在短时间内自动恢复而且误报可能会引发不必要的紧急响应。
从`node_cpu_seconds_total`到告警：手把手教你用PromQL计算Node Exporter核心指标
从node_cpu_seconds_total到告警手把手教你用PromQL计算Node Exporter核心指标当你第一次打开Node Exporter的/metrics端点时那些密密麻麻的指标数据可能会让你感到无从下手。作为Prometheus监控体系中最基础的数据采集组件Node Exporter提供了数百个系统指标但如何将这些原始数据转化为有业务意义的监控图表和告警规则这正是PromQL大显身手的地方。本文将聚焦CPU、内存、磁盘三大核心系统指标通过数学推导式的讲解带你一步步理解如何从原始Counter类型指标开始经过层层计算最终得到可直接用于监控的可视化数据。不同于简单的查询语句复制粘贴我们会深入每个计算步骤背后的设计思路让你真正掌握PromQL的精髓。1. CPU使用率从时间计数器到百分比理解CPU使用率的计算逻辑是掌握系统监控的第一步。Node Exporter提供的node_cpu_seconds_total是一个典型的Counter类型指标它记录了CPU在各种模式下累积消耗的时间单位秒。当我们看到这样的数据时node_cpu_seconds_total{cpu0,modeidle} 13172.76 node_cpu_seconds_total{cpu0,modeuser} 79.93 node_cpu_seconds_total{cpu1,modesystem} 309.38首先需要明确几个关键点这是一个累积值从系统启动开始不断累加每个CPU核心都有独立的统计cpu0, cpu1等区分了多种工作模式idle, user, system等1.1 Counter类型的特点与处理Counter类型指标的特点是只增不减除非系统重启。要计算CPU使用率这类百分比指标我们需要关注的是时间窗口内的变化量而非绝对值。这就是为什么PromQL提供了rate()和increase()函数# 计算5分钟内CPU空闲时间的平均增长速率单位秒/秒 rate(node_cpu_seconds_total{modeidle}[5m]) # 计算5分钟内CPU空闲时间的总增量单位秒 increase(node_cpu_seconds_total{modeidle}[5m])提示在大多数场景下rate()比increase()更推荐使用因为它能更好地处理Counter重置如进程重启的情况。1.2 多核CPU的聚合计算现代服务器通常都有多个CPU核心我们需要将所有核心的数据聚合起来才能反映整体CPU使用情况。这里就需要用到sum()聚合运算符sum(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)这个查询做了三件事使用rate()计算5分钟时间窗口内idle模式的CPU时间增长率使用sum()聚合所有CPU核心的数据通过by (instance)保留实例标签确保不同主机的数据不会混在一起1.3 最终使用率计算公式CPU使用率的本质是非空闲时间占总时间的比例。因此最直观的计算方式是( 1 - sum(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance) / sum(rate(node_cpu_seconds_total[5m])) by (instance) ) * 100这个查询可以分解为分母计算所有模式的总CPU时间分子计算空闲CPU时间用1减去空闲比例得到使用比例乘以100转换为百分比2. 内存使用率理解available与free的区别内存监控比CPU稍微复杂一些因为Linux内存管理机制中有buffer和cache的概念。Node Exporter提供了多个内存相关指标node_memory_MemTotal_bytes # 总内存 node_memory_MemFree_bytes # 完全空闲内存 node_memory_Buffers_bytes # 缓冲区内存 node_memory_Cached_bytes # 页面缓存 node_memory_MemAvailable_bytes # 估算的可用内存2.1 可用内存的准确计算free命令输出的available内存是一个估算值表示在不使用swap的情况下应用程序可以实际使用的内存量。它的计算逻辑大致是可用内存 ≈ MemFree Buffers Cached - 不可回收部分在PromQL中我们可以用以下查询近似计算可用内存node_memory_MemFree_bytes node_memory_Buffers_bytes node_memory_Cached_bytes注意这只是一个近似值精确值应该直接使用node_memory_MemAvailable_bytes指标如果内核版本支持。2.2 内存使用率的最佳实践与CPU不同内存使用率的计算应该基于已用内存/总内存而非1 - 空闲比例因为buffer和cache也属于被使用的内存尽管可以被回收。推荐的计算公式是( (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes ) * 100这个查询更准确地反映了系统内存压力因为它考虑了buffer/cache等可回收内存的实际使用情况。3. 磁盘空间与IO监控磁盘监控通常分为两部分存储空间使用情况和IO性能指标。Node Exporter为两者都提供了详细的指标。3.1 磁盘空间使用率磁盘空间相关的主要指标包括node_filesystem_size_bytes # 文件系统总大小 node_filesystem_avail_bytes # 可用空间 node_filesystem_files # inode总数 node_filesystem_files_free # 空闲inode数计算磁盘使用率时通常需要过滤掉特殊文件系统如tmpfs( 1 - node_filesystem_avail_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} ) * 100对于inode使用率的计算也类似( 1 - node_filesystem_files_free{fstype~ext4|xfs} / node_filesystem_files{fstype~ext4|xfs} ) * 1003.2 磁盘IO性能指标磁盘IO监控主要关注读写操作的吞吐量和延迟node_disk_read_bytes_total # 读取字节数 node_disk_written_bytes_total # 写入字节数 node_disk_io_time_seconds_total # IO耗时 node_disk_reads_completed_total # 完成读操作数 node_disk_writes_completed_total # 完成写操作数计算磁盘读写吞吐量单位MB/s# 读吞吐量 sum by(instance) ( rate(node_disk_read_bytes_total[5m]) ) / 1024 / 1024 # 写吞吐量 sum by(instance) ( rate(node_disk_written_bytes_total[5m]) ) / 1024 / 1024监控IO延迟单位毫秒# 平均读延迟 ( rate(node_disk_read_time_seconds_total[5m]) / rate(node_disk_reads_completed_total[5m]) ) * 1000 # 平均写延迟 ( rate(node_disk_write_time_seconds_total[5m]) / rate(node_disk_writes_completed_total[5m]) ) * 10004. 从监控到告警关键指标的阈值设置有了基础监控指标后下一步就是设置合理的告警规则。以下是几个核心指标的告警建议4.1 CPU告警规则- alert: HighCPUUsage expr: | 100 - ( avg by(instance) (rate(node_cpu_seconds_total{modeidle}[5m])) * 100 ) 80 for: 10m labels: severity: warning annotations: summary: High CPU usage on {{ $labels.instance }} description: CPU usage is {{ $value }}% for last 10 minutes4.2 内存告警规则- alert: HighMemoryUsage expr: | ( (node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes ) * 100 90 for: 15m labels: severity: warning annotations: summary: High memory usage on {{ $labels.instance }} description: Memory usage is {{ $value }}% for last 15 minutes4.3 磁盘空间告警规则- alert: LowDiskSpace expr: | ( node_filesystem_avail_bytes{fstype~ext4|xfs} / node_filesystem_size_bytes{fstype~ext4|xfs} ) * 100 10 for: 1h labels: severity: critical annotations: summary: Low disk space on {{ $labels.instance }} {{ $labels.mountpoint }} description: Only {{ $value }}% space left在实际生产环境中我发现磁盘空间告警的for时间应该设置得比CPU/内存更长一些因为磁盘空间问题通常不会在短时间内自动恢复而且误报可能会引发不必要的紧急响应。
