从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{cpu="0",mode="idle"} 13172.76 node_cpu_seconds_total{cpu="0",mode="user"} 79.93 node_cpu_seconds_total{cpu="1",mode="system"} 309.38首先需要明确几个关键点：
- 这是一个累积值，从系统启动开始不断累加
- 每个CPU核心都有独立的统计（cpu="0", cpu="1"等）
- 区分了多种工作模式（idle, user, system等）
1.1 Counter类型的特点与处理
Counter类型指标的特点是只增不减（除非系统重启）。要计算CPU使用率这类百分比指标，我们需要关注的是时间窗口内的变化量而非绝对值。这就是为什么PromQL提供了rate()和increase()函数：
# 计算5分钟内CPU空闲时间的平均增长速率（单位：秒/秒） rate(node_cpu_seconds_total{mode="idle"}[5m]) # 计算5分钟内CPU空闲时间的总增量（单位：秒） increase(node_cpu_seconds_total{mode="idle"}[5m])提示：在大多数场景下，
rate()比increase()更推荐使用，因为它能更好地处理Counter重置（如进程重启）的情况。
1.2 多核CPU的聚合计算
现代服务器通常都有多个CPU核心，我们需要将所有核心的数据聚合起来才能反映整体CPU使用情况。这里就需要用到sum()聚合运算符：
sum(rate(node_cpu_seconds_total{mode="idle"}[5m])) by (instance)这个查询做了三件事：
- 使用
rate()计算5分钟时间窗口内idle模式的CPU时间增长率 - 使用
sum()聚合所有CPU核心的数据 - 通过
by (instance)保留实例标签，确保不同主机的数据不会混在一起
1.3 最终使用率计算公式
CPU使用率的本质是"非空闲时间占总时间的比例"。因此最直观的计算方式是：
( 1 - sum(rate(node_cpu_seconds_total{mode="idle"}[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{mode="idle"}[5m])) * 100 ) > 80 for: 10m labels: severity: warning annotations: summary: "High CPU usage on {{ $labels.instance }}" description: "CPU usage is {{ $value }}% for last 10 minutes"4.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 minutes"4.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/内存更长一些，因为磁盘空间问题通常不会在短时间内自动恢复，而且误报可能会引发不必要的紧急响应。
