真正拖慢系统的往往是内存压力和磁盘i/o瓶颈，cpu需用idle反推更可靠，内存要按业务类型选指标（如数据库用memfree+buffers+cached），磁盘需分层监控io队列、吞吐与ssd寿命，并用avail_bytes计算真实空间使用率。

别只盯着CPU使用率看——真正拖慢系统的，往往是内存压力和磁盘I/O瓶颈。Prometheus监控的有效性，不在于指标数量多，而在于选对指标、算准数值、设对条件。

CPU：用idle反推比直接统计更可靠

node_cpu_seconds_total是Counter类型，记录各模式下累计耗时。直接加总user/system等状态容易受中断、steal干扰；用idle倒推更稳定：

• 公式：100 - 100 × avg by (instance)(irate(node_cpu_seconds_total{mode="idle"}[5m]))
• irate比rate更适合捕捉瞬时峰值，尤其对突发型负载
• 多核服务器必须avg聚合，否则单核飙高会误导整体判断
• 配合node_load1看任务排队情况：load1 / count by (instance)(count by (cpu)(node_cpu_seconds_total)) > 0.7 是早期预警信号

内存：MemAvailable不是万能解，得看业务类型

MemAvailable在内核3.14+才支持，且它已包含可回收缓存，对缓存服务友好，但对数据库可能掩盖真实压力：

• 通用公式（适合传统应用）：(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) / node_memory_MemTotal_bytes × 100
• 数据库类服务建议用：(node_memory_MemTotal_bytes - node_memory_MemFree_bytes - node_memory_Buffers_bytes - node_memory_Cached_bytes) / node_memory_MemTotal_bytes × 100
• 容器环境优先用container_memory_working_set_bytes，避免被宿主机缓存干扰
• 复合告警更准：内存剩余＜5% 且 每分钟缺页异常pgmajfault＞1000次，才触发OOM风险告警

磁盘IO：不能只看%util，要分层看压力来源

disk_io_time_seconds占比高，未必代表硬件瓶颈——可能是队列堆积、随机读写或SSD磨损：

• %util参考式：100 × rate(node_disk_io_time_seconds_total{device=~"sd.*|nvme.*"}[1m])
• 队列深度看node_disk_io_now，持续＞设备队列深度（如NVMe通常为64）说明请求积压
• 吞吐量用irate(node_disk_read_bytes_total[5m]) + irate(node_disk_write_bytes_total[5m])，对比硬件标称值
• SSD需额外查disk_ssd_life_remaining，低于20%应安排更换

磁盘空间：avail_bytes比free_bytes更贴近真实可用

node_filesystem_free_bytes不含保留块和可回收缓存，node_filesystem_avail_bytes才是普通用户实际能用的空间：

• 推荐公式：100 - (node_filesystem_avail_bytes{fstype=~"ext4|xfs", mountpoint="/"} / node_filesystem_size_bytes{fstype=~"ext4|xfs", mountpoint="/"} × 100)
• XFS文件系统注意reserved_blocks机制，相同使用率下比ext4更早触发警告
• 根分区告警阈值建议设为85%，/var或日志目录建议设为75%
• 配合inode使用率：100 - (node_filesystem_files_free{mountpoint="/"} / node_filesystem_files{mountpoint="/"}) × 100，避免小文件打满inode