3、资源利用率监控：CPU利用率、内存利用率、磁盘IO、网络带宽的监控指标与工具（Prometheus/Grafana）

做SaaS，说白了就是在卖资源。你卖的是计算能力、存储空间、网络吞吐。如果连自己卖出去多少、还剩多少都搞不清楚，那成本控制就是一句空话。

我个人习惯，接手任何一个SaaS系统，第一件事就是搭一套完整的资源监控体系。不是那种“哦，CPU高了报警”的粗放监控，而是能精确到每个租户、每个服务实例的资源画像。今天我们就聊聊这件事。

3.1 四大核心指标：到底该看什么？

很多团队一上来就堆指标，CPU、内存、磁盘、网络全拉满，结果Grafana面板上花花绿绿一片，真出问题时反而找不到重点。我建议你聚焦四个维度，每个维度盯住最关键的那几个指标。

3.1.1 CPU利用率：别被平均值骗了

CPU利用率是最基础的指标，但也是最容易被误解的。我曾经遇到一个案例，某服务的CPU平均利用率只有30%，但用户投诉响应慢。查了半天才发现，是某个租户的批量任务每隔5分钟就占满所有核，持续30秒。平均值把峰值给平滑掉了。

所以，我建议你关注这几个指标：

• CPU使用率（%）：按核粒度看，别只看整体。用node_cpu_seconds_total这个指标，配合mode="user"和mode="system"区分用户态和内核态。
• CPU负载（Load Average）：1分钟、5分钟、15分钟。如果1分钟负载远高于15分钟，说明系统正在经历突发压力。
• CPU饱和度：这个指标很多人忽略。说白了就是CPU在排队等待的时间比例。用node_pressure_cpu_waiting_seconds_total可以算出来。

3.1.2 内存利用率：注意“已用”和“可用”的陷阱

内存监控有个经典误区：Linux会把空闲内存用作文件缓存（Cache），导致free -m显示的“可用”内存远低于实际可用。你想想看，如果直接拿used除以total，那内存利用率可能长期在80%以上，但其实系统并不缺内存。

正确的做法是：

• 实际内存使用率：用(total - available) / total，其中available是真正可分配给新进程的内存，包括空闲内存和可回收的缓存。
• Swap使用率：如果Swap开始被大量使用，说明物理内存真的不够了。这是需要立刻响应的信号。
• 内存分配失败次数：用node_vmstat_oom_kill监控OOM Killer触发的次数。一旦出现，说明系统已经处于极度饥饿状态。

3.1.3 磁盘IO：延迟比吞吐量更重要

对于SaaS系统，尤其是数据库和日志服务，磁盘IO往往是瓶颈。很多人只盯着IOPS和吞吐量，但我告诉你，延迟才是用户体验的关键。

重点关注：

• 磁盘读写延迟（await）：用node_disk_read_time_seconds_total和node_disk_writes_completed_total可以算出平均每次IO的耗时。如果超过10ms，就该查查了。
• IO队列长度（avgqu-sz）：这个指标反映磁盘的积压情况。如果队列长度持续大于磁盘的并发能力（通常机械盘是1，SSD是32左右），说明磁盘已经过载。
• 磁盘利用率（%util）：注意，这个指标不是磁盘“用了多少”，而是磁盘“忙了多久”。100% util不代表磁盘满了，而是说磁盘一直在干活，没有空闲时间。

3.1.4 网络带宽：别只看流量，要看丢包和重传

网络监控最容易犯的错就是只看带宽利用率。其实对于SaaS系统，网络质量比带宽大小更重要。

我建议你盯住：

• 带宽利用率：用node_network_receive_bytes_total和node_network_transmit_bytes_total算出入向和出向的流量，除以接口带宽。超过70%就要考虑扩容了。
• 丢包率：用node_network_receive_drop_total和node_network_transmit_drop_total。丢包意味着网络拥塞或硬件故障。
• TCP重传率：这个指标非常关键。用node_netstat_Tcp_RetransSegments除以node_netstat_Tcp_OutSegments。重传率超过1%就说明网络质量有问题。

3.2 工具选型：为什么是Prometheus + Grafana？

市面上监控工具很多，Zabbix、Nagios、Datadog……但我个人最推荐Prometheus + Grafana的组合。为什么？

• Prometheus：拉模式采集，天然适合云原生环境。它的多维数据模型（指标名+标签）可以轻松实现按租户、按服务、按实例的细粒度监控。
• Grafana：可视化之王。面板灵活，告警规则强大，而且支持多数据源。

说白了，这套组合是开源界的“黄金搭档”。你想想看，一个SaaS系统可能有几百个微服务，每个服务又有多个实例。如果用Zabbix那种推模式，配置管理就是一场噩梦。而Prometheus的服务发现机制，配合Kubernetes，可以自动发现新实例，省心太多。

3.3 实战：搭建一套完整的资源监控

光说不练假把式。下面我带你走一遍从采集到可视化的完整流程。

3.3.1 部署Prometheus和Node Exporter

首先，在每个节点上部署Node Exporter，用于采集系统级别的指标。

# 下载并启动Node Exporter
wget https://github.com/prometheus/node_exporter/releases/download/v1.6.0/node_exporter-1.6.0.linux-amd64.tar.gz
tar xvf node_exporter-1.6.0.linux-amd64.tar.gz
cd node_exporter-1.6.0.linux-amd64
./node_exporter --web.listen-address=":9100"

然后，配置Prometheus来抓取这些指标。

# prometheus.yml
scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['192.168.1.10:9100', '192.168.1.11:9100']
    # 如果是Kubernetes环境，可以用服务发现
    # kubernetes_sd_configs:
    #   - role: node

3.3.2 配置Grafana面板

Grafana的配置我就不赘述了，直接说几个关键点：

• 导入官方仪表盘：Grafana官网有Node Exporter的官方仪表盘（ID: 1860），直接导入就能用。但注意，这个面板是通用型的，对于SaaS场景，我建议你在此基础上自定义。
• 按租户分组：如果你的Node Exporter打了租户标签（比如tenant="customer_a"），可以在Grafana里用变量实现租户切换。
• 设置告警：在Grafana里配置告警规则，比如CPU利用率超过80%持续5分钟，就发送通知到钉钉或Slack。

3.4 避坑指南：我踩过的那些坑

最后，分享几个我亲身经历过的教训：

• 采集频率别太高：我曾经把Prometheus的采集间隔设成5秒，结果Node Exporter本身占用了大量CPU，反而影响了业务。建议15秒一次，够用了。
• 注意时间序列的基数：Prometheus的标签组合如果太多（比如每个Pod的IP都作为标签），会导致时间序列爆炸。我见过一个案例，因为标签设计不合理，Prometheus的内存直接撑爆了。
• 磁盘IO监控要区分设备：系统盘和数据盘要分开监控。系统盘满了会影响整个节点，数据盘满了只影响特定服务。
• 网络监控别忘了出口带宽：很多SaaS系统只监控入向流量，忽略了出向。结果用户下载数据时，出向带宽被打满，导致响应变慢。

嗯，资源利用率监控这件事，说难不难，说简单也不简单。关键是你要知道每个指标背后的含义，以及它们对SaaS成本的影响。下一章，我们会聊聊如何基于这些监控数据做成本分摊和优化决策。