SystemInfoMonitor.sh - 系统资源监控告警脚本

脚本功能

SystemInfoMonitor.sh 是一个功能全面的系统资源持续监控脚本，实时检测 CPU 利用率、内存使用率、磁盘空间使用率和网络流量。当资源使用率连续超过设定阈值时，通过 Bark 推送告警通知，帮助管理员及时发现和处理系统资源瓶颈。

核心特性：

• 四项核心监控：CPU、内存、磁盘、网络流量
• 持续监控模式：后台持续运行，定期检查系统状态
• 智能告警机制：基于灵敏度阈值，避免误报
• 灵活配置：可自定义各项资源的告警阈值和检测间隔
• 网络接口过滤：自动排除 lo、docker0、veth 等虚拟接口
• Bark 集成：支持 iOS 推送告警通知
• 详细日志：输出带时间戳的监控日志

脚本依赖

系统工具依赖

• bash：脚本运行环境（需要 bash shell）
• top：用于获取 CPU使用率
• free：用于获取内存使用信息
• df：用于获取磁盘空间使用情况
• ip：用于获取网络接口列表
• curl：用于发送 Bark 告警请求
• date：用于时间戳和日志记录

外部服务依赖（可选）

• Bark 服务：iOS 推送通知服务（如不需要告警可禁用）
  • 服务地址：https://api.day.app/
  • 获取 Bark Key：安装 Bark App 后自动生成

环境变量依赖

.env 文件配置

脚本需要加载同目录下的 .env文件，该文件应包含以下变量：

1
2

# Bark 通知密钥（从 Bark App 获取）
bark_key=xxxxxxxxxx

配置文件位置：

• 优先加载当前工作目录的 .env文件
• 其次加载脚本所在目录的 .env文件

参考文档： Bark 使用教程

内置变量说明（可自定义配置）

脚本开头定义了以下可配置变量（第 2-7 行）：

1
2
3
4
5
6
7
8
9

# 资源使用率阈值（百分比）
CPU_THRESHOLD=80           # CPU 利用率阈值，默认 80%
MEMORY_THRESHOLD=80        # 内存利用率阈值，默认 80%
DISK_THRESHOLD=80          # 磁盘使用率阈值，默认 80%
NETWORK_THRESHOLD=1        # 网络流量阈值（MB/s），默认 1MB/s

# 灵敏度配置
SENSITIVITY_THRESHOLD=3    # 连续超标次数阈值，默认连续 3 次触发告警
CHECK_INTERVAL=10          # 检测时间间隔（秒），默认 10 秒检查一次

变量作用说明：

• 阈值变量：超过此百分比或数值会触发告警逻辑
• 灵敏度阈值：防止瞬时峰值导致误报，需连续 N 次检测超标才告警
• 检测间隔：两次检查之间的等待时间，影响监控频率和系统负载

参数用法

本脚本无命令行参数，通过修改脚本内变量和配置文件进行定制：

• 无参数模式：使用默认阈值和间隔进行持续监控
• 自定义配置：编辑脚本开头的变量定义部分
• 禁用告警：注释掉.env加载部分或Bark相关的curl命令

使用方法

快速安装与使用

1. 下载脚本：

   1 2 3 4 5

   # 使用主下载地址 bash <(curl -sL sc.eli1.top) SystemInfoMonitor download # 或使用备用地址 bash <(curl -sL download.elisky.cn) SystemInfoMonitor download

2. 创建配置文件：

   1 2 3 4 5 6

   # 复制模板文件 cp .env-template .env # 编辑.env文件，填入 Bark Key vim .env # 添加：bark_key=your_bark_key_here

3. 自定义配置（可选）： 编辑 SystemInfoMonitor.sh脚本，修改第 2-7 行的阈值：

   1 2 3 4 5 6 7 8

   # 调整 CPU 告警阈值为 90% CPU_THRESHOLD=90 # 调整内存告警阈值为 85% MEMORY_THRESHOLD=85 # 调整检测间隔为 30 秒 CHECK_INTERVAL=30

4. 运行脚本：

   1 2 3 4 5 6 7 8 9 10 11 12 13

   # 赋予执行权限 chmod +x SystemInfoMonitor.sh # 前台运行（查看实时日志） ./SystemInfoMonitor.sh # 后台运行（推荐） nohup ./SystemInfoMonitor.sh > /var/log/sysmonitor.log 2>&1 & # 或使用 screen/tmux screen -S sysmonitor ./SystemInfoMonitor.sh # 按 Ctrl+A 然后 D 分离会话

典型使用场景示例

场景 1：测试监控和告警通道

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 临时降低阈值进行测试
# 编辑脚本，将阈值改为很低的值
CPU_THRESHOLD=1
MEMORY_THRESHOLD=1
DISK_THRESHOLD=1
NETWORK_THRESHOLD=0

# 运行脚本查看是否触发告警
./SystemInfoMonitor.sh

# 观察 Bark 是否收到通知

场景 2：生产服务器监控（推荐配置）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# 编辑脚本，设置合理的生产环境阈值
CPU_THRESHOLD=85           # CPU 超过 85% 告警
MEMORY_THRESHOLD=90        # 内存超过 90% 告警
DISK_THRESHOLD=85          # 磁盘超过 85% 告警
NETWORK_THRESHOLD=10       # 网络流量超过 10MB/s 告警
SENSITIVITY_THRESHOLD=5    # 连续 5 次超标才告警（减少误报）
CHECK_INTERVAL=30          # 每 30 秒检查一次（降低监控开销）

# 后台运行
nohup ./SystemInfoMonitor.sh > /var/log/sysmonitor.log 2>&1 &

场景 3：禁用 Bark 告警仅记录日志

如果不需要 Bark 通知，只保留日志记录：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 方法 1：注释掉.env加载部分（脚本第 13-21 行）
# if [[ -f ./.env ]]; then
#     source ./.env
# elif [[ -f $SCRIPT_DIR/.env ]]; then
#     source $SCRIPT_DIR/.env
# else
#     echo ".env file not found!..."
#     exit 1
# fi

# 方法 2：注释掉所有 curl 告警命令
# 搜索并注释以下类似的行：
# curl "$url_cpu"...
# curl "$url_memory"...
# curl "$url_disk"...
# curl "$url_network"...

场景 4：监控关键业务服务器

对于关键服务器，设置更严格的监控策略：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 更低的阈值，更早发现问题
CPU_THRESHOLD=70
MEMORY_THRESHOLD=75
DISK_THRESHOLD=80
NETWORK_THRESHOLD=5

# 更快的检测频率
CHECK_INTERVAL=10

# 更高的灵敏度（更快告警）
SENSITIVITY_THRESHOLD=2

# 后台运行并确保日志轮转
nohup ./SystemInfoMonitor.sh > /var/log/sysmonitor.log 2>&1 &

# 配置 logrotate 防止日志过大
cat > /etc/logrotate.d/sysmonitor <<EOF
/var/log/sysmonitor.log {
    daily
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
}
EOF

场景 5：扩展其他告警通道

在脚本中添加钉钉机器人告警：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 找到 check_cpu()函数中的告警部分（约第 58 行）
if [ "$counter_cpu" -ge "$SENSITIVITY_THRESHOLD" ]; then
    echo "$(date +'%Y-%m-%d %H:%M:%S') === CPU usage exceeds threshold... === $cpu_usage%"
    
    # Bark 告警
    curl "$url_cpu"%3A"$cpu_usage"%25
    
    # 钉钉机器人告警（添加以下代码）
    curl 'https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN' \
      -H 'Content-Type: application/json' \
      -d '{
        "msgtype": "text",
        "text": {
            "content": "CPU 告警：使用率 '"$cpu_usage"'%，连续超标'"$counter_cpu"'次"
        }
      }'
    
    # 重置计数器
    counter_cpu=0
    timestamp_cpu=$(date +%s)
fi

场景 6：临时监控特定资源

只监控 CPU 和内存，暂时关闭磁盘和网络监控：

1
2
3
4
5
6
7
8

# 编辑脚本，注释掉 check_disk_space和check_network_activity调用
# 找到 main()函数（约第 197 行）
function main() {
    check_cpu
    check_memory
    # check_disk_space      # 临时禁用
    # check_network_activity # 临时禁用
}

监控函数详解

CPU 监控（check_cpu）

• 检测原理：使用top -bn1获取 CPU使用率
• 告警 URL：https://api.day.app/$bark_key/CPU报警/CPU持续利用率过高
• 触发条件：连续SENSITIVITY_THRESHOLD次超过CPU_THRESHOLD

内存监控（check_memory）

• 检测原理：使用free命令计算内存使用百分比
• 告警 URL：https://api.day.app/$bark_key/内存报警/内存持续利用率过高
• 触发条件：连续SENSITIVITY_THRESHOLD次超过MEMORY_THRESHOLD

磁盘监控（check_disk_space）

• 检测原理：使用df命令获取根分区（/）使用率
• 告警 URL：https://api.day.app/$bark_key/disk报警/disk持续利用率过高
• 触发条件：连续SENSITIVITY_THRESHOLD次超过DISK_THRESHOLD

网络监控（check_network_activity）

• 检测原理：读取/sys/class/net/*/statistics/rx_bytes和tx_bytes计算流量速率
• 监控接口：自动排除 lo、docker0、veth-*、br-*等虚拟接口
• 告警 URL：https://api.day.app/$bark_key/网络报警/网络持续利用率过高
• 触发条件：单个网卡连续SENSITIVITY_THRESHOLD次超过NETWORK_THRESHOLD

实际应用场景

• 生产服务器监控：7x24 小时持续监控关键业务服务器的资源状态
• 性能瓶颈识别：发现 CPU、内存、磁盘或网络的性能瓶颈
• 容量规划：跟踪资源使用趋势，为硬件升级提供数据支持
• 故障预警：在资源耗尽前提前告警，避免服务中断
• 异常检测：发现异常的资源使用模式（如挖矿病毒、DDoS攻击）
• 开发测试环境：监控开发服务器的资源使用，优化应用性能
• 容器宿主机监控：监控 Docker、Kubernetes节点的物理资源
• 数据库服务器：重点监控数据库服务器的内存和磁盘使用

注意事项

阈值配置建议

• CPU 阈值：

  • 一般服务器：80-85%
  • 计算密集型：90-95%
  • 关键业务：70-75%（更早预警）

• 内存阈值：

  • 一般服务器：85-90%
  • Java应用服务器：90-95%（考虑 JVM缓存）
  • 数据库服务器：80-85%

• 磁盘阈值：

  • 一般服务器：80-85%
  • 日志服务器：75-80%（日志增长快）
  • 关键业务：70-75%

• 网络阈值：

  • 根据网卡带宽设置
  • 百兆网卡：10-50MB/s
  • 千兆网卡：50-100MB/s
  • 万兆网卡：500MB/s以上

灵敏度调优

• 高灵敏度（SENSITIVITY_THRESHOLD=2-3）：

  • 优点：更快发现问题
  • 缺点：可能误报，告警频繁

• 低灵敏度（SENSITIVITY_THRESHOLD=5-10）：

  • 优点：减少误报，告警更可靠
  • 缺点：可能延迟发现问题

• 建议：根据实际环境调整，生产环境推荐 3-5 次

监控频率选择

• 高频监控（CHECK_INTERVAL=5-10 秒）：

  • 适用场景：关键业务、资源紧张环境
  • 缺点：监控脚本本身消耗资源

• 低频监控（CHECK_INTERVAL=30-60 秒）：

  • 适用场景：一般服务器、资源充足环境
  • 优点：监控开销小

Bark 服务配置

• Bark Key 保密性：不要将.env文件提交到代码仓库
• 网络可达性：确保服务器能访问https://api.day.app/
• 推送频率限制：避免过于频繁的告警触发限制

进程管理

• 后台运行：建议使用 nohup、screen或tmux运行脚本

  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

  # 使用 nohup nohup ./SystemInfoMonitor.sh > /var/log/sysmonitor.log 2>&1 & # 使用 systemd 服务（推荐） cat > /etc/systemd/system/sysmonitor.service <<EOF [Unit] Description=System Resource Monitor After=network.target [Service] Type=simple ExecStart=/path/to/SystemInfoMonitor.sh Restart=always User=root [Install] WantedBy=multi-user.target EOF systemctl enable sysmonitor systemctl start sysmonitor

• 开机自启：配置 systemd 服务实现开机自动监控

日志管理

• 日志轮转：配置 logrotate 防止日志文件过大

  1 2 3 4 5 6 7 8 9 10 11

  cat > /etc/logrotate.d/sysmonitor <<EOF /var/log/sysmonitor.log { daily rotate 7 compress delaycompress missingok notifempty create 0644 root root } EOF

• 日志分析：定期查看日志分析资源使用趋势

  1 2 3 4 5

  # 查看最近的告警记录 grep "exceeds" /var/log/sysmonitor.log | tail -20 # 统计 CPU 告警次数 grep "CPU usage" /var/log/sysmonitor.log | wc -l

扩展与定制

• 多通道告警：同时配置 Bark、钉钉、企业微信、邮件等多种告警方式
• Webhook集成：对接 Prometheus Alertmanager、Zabbix等监控系统
• 数据持久化：将监控数据写入 InfluxDB、Prometheus 等时序数据库
• 可视化展示：配合 Grafana 等工具制作监控仪表盘

局限性说明

• 单机监控：仅监控本地资源，不支持分布式监控
• 历史数据：不保存历史数据，仅提供实时监控
• 精度限制：基于系统命令的采样精度，不适合微秒级监控需求
• 容器感知：无法区分宿主机和容器的资源使用（需要在容器内运行）

安全提示

• 权限控制：建议使用 root 用户运行以获取完整系统信息

• 文件保护：确保.env文件和日志文件的权限设置合理

  1 2	chmod 600 .env chmod 644 /var/log/sysmonitor.log

• 网络安全：确保 Bark API调用使用 HTTPS加密传输