低配服务器（2核1G）如何有效监控CPU和内存使用率？

在 2 核 1G（2GB）内存的服务器上，监控工具本身占用的资源必须极低。如果监控进程吃掉了 50% 以上的资源，就失去了监控的意义。

以下是针对低配服务器的资源消耗从低到高的几种有效监控方案，以及具体的实施建议：

核心原则

1. 避免重型 Agent：不要安装 Prometheus Node Exporter + Grafana + Alertmanager 全套本地部署（除非你只监控单点且能接受稍高的开销），或者必须极其精简配置。
2. 利用系统原生工具：Linux 内核自带的 top、vmstat、sar 是最轻量的。
3. 外部化存储与展示：将数据推送到云端或轻量级服务，服务器端只负责采集和发送。

方案一：最轻量级 – 纯脚本 + Cron (推荐)

如果你只需要知道“过去几小时发生了什么”或者简单的阈值报警，不需要实时图表，这是最省资源的方案。

• 原理：使用 Shell 脚本定期抓取数据，写入文本文件，配合邮件或 Webhook 报警。
• 资源占用：< 1MB 内存，CPU 几乎为 0。
• 实现步骤：

创建一个脚本 /usr/local/bin/monitor.sh：

#!/bin/bash
# 获取当前时间
TIME=$(date +%Y-%m-%d %H:%M:%S)
# 获取 CPU 使用率 (1 分钟平均值)
CPU=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
# 获取内存使用率
MEM=$(free -m | awk 'NR==2{printf "%.2f%%", $3*100/$2}')
# 获取负载 (Load Average 1min)
LOAD=$(uptime | awk -F'load average:' '{print $2}' | cut -d',' -f1 | tr -d ' ')

# 记录到日志文件
echo "$TIME | CPU: ${CPU}% | MEM: ${MEM}% | LOAD: $LOAD" >> /var/log/system_monitor.log

# 简单报警逻辑 (例如：内存超过 90%)
if [ $(echo "$MEM > 90" | bc -l) -eq 1 ]; then
    echo "ALERT: Memory usage is critical ($MEM)!" >> /var/log/alert.log
    # 这里可以添加 curl 调用钉钉/企业微信/Slack 的 Webhook
fi

赋予执行权限并加入 Crontab：

chmod +x /usr/local/bin/monitor.sh
crontab -e
# 添加一行：每 5 分钟执行一次
*/5 * * * * /usr/local/bin/monitor.sh

方案二：折中方案 – 轻量级 Agent + 云监控

如果你需要可视化的历史曲线图，但服务器无法运行 Grafana。

选项 A：Telegraf (InfluxDB 生态)

Telegraf 是 Go 编写的，比 Python 写的 Prometheus 更轻量，内存占用通常在 20-40MB 左右。

• 配置技巧：
  • 只启用 cpu, mem, net, disk 插件。
  • 关闭 procstat (如果不需监控具体进程)。
  • 关键：不要本地存 InfluxDB，直接配置 Telegraf 将数据推送到云端的 InfluxDB 或 Graphite。
• 适用场景：需要长期趋势分析，且预算允许使用云服务存储。

选项 B：Netdata (极度优化版)

Netdata 默认非常强大但也较重，但在 1G 内存上可以通过配置优化运行。

• 限制：默认可能占用 50MB+ 内存。
• 优化：
  • 禁用不必要的模块（如磁盘 I/O 深度分析）。
  • 设置 memory limit = 30 (MB)。
  • 注意：对于 1G 机器，Netdata 可能会因为频繁刷新图表导致 IO 抖动，需谨慎评估。

方案三：外部化监控 (Serverless / SaaS)

这是最推荐的架构：服务器只做“探针”，不做“计算”和“存储”。

1. Prometheus Node Exporter (仅作为 Pushgateway)：

   • 在服务器上运行 node_exporter（约 10-15MB 内存）。
   • 配置它通过 pushgateway 将数据推送到外部的 Prometheus 实例（由另一台高配机器或云厂商托管）。
   • 或者直接使用 Pushgateway 模式，甚至直接用脚本定时 Push 数据。

2. 云厂商自带监控：

   • 如果你使用的是阿里云、腾讯云、AWS 等，强烈建议使用云厂商提供的免费基础监控。
   • 它们通常提供 1 分钟粒度的 CPU/内存监控，无需在服务器上安装任何软件，零资源占用。
   • 只需在控制台查看即可。

3. Uptime Kuma / Pingdom：

   • 主要用于监控“服务是否存活”。
   • 配合简单的 curl 命令检查端口，如果挂了再触发报警。

针对 2 核 1G 的特别优化建议

无论选择哪种方案，请务必关注以下系统层面的优化，防止监控工具把服务器“压死”：

1. 开启 Swap (虚拟内存)

   • 1G 物理内存非常紧张，一旦应用波动容易 OOM (Out Of Memory)。
   • 建议创建至少 1GB-2GB 的 Swap 分区。虽然 Swap 速度慢，但能防止程序崩溃。

     # 创建 1G swap 文件示例
     dd if=/dev/zero of=/swapfile bs=1M count=1024
     chmod 600 /swapfile
     mkswap /swapfile
     swapon /swapfile

2. 调整 Swappiness

   • 让系统尽量使用物理内存，只在必要时使用 Swap，减少磁盘 IO 压力。

     sysctl vm.swappiness=10

3. 限制监控工具的采样频率

   • 不要设置秒级采集。对于业务监控，1 分钟 或 5 分钟 间隔通常足够。高频采集（如 10 秒一次）在低配服务器上会显著增加 CPU 上下文切换和磁盘 IO。

4. 日志轮转 (Logrotate)

   • 如果使用方案一的脚本，务必配置 logrotate，防止 /var/log/system_monitor.log 无限增长占满磁盘。

总结推荐

最终建议：
如果是生产环境的 2 核 1G 服务器，首选云厂商自带的监控面板（零成本、零占用）。如果需要自定义报警，请使用 Shell 脚本 + 邮件/IM 推送 的方式。只有在必须拥有复杂的历史图表时，才考虑引入轻量级 Agent 并配合外部存储。