使用n8n搭建服务器监控系统：从Webhook到Telegram告警的完整实现

todoitbo2025-11-12 9:55

欢迎来到我的博客，代码的世界里，每一行都是一个故事

🎏：你只管努力，剩下的交给时间

🏠 ：小破站

使用n8n搭建服务器监控系统：从Webhook到Telegram告警的完整实现

本文介绍如何使用n8n工作流自动化工具搭建一个完整的服务器监控系统，实现从数据采集、告警判断到Telegram消息推送的全流程自动化，整个方案无需编写复杂代码，配置完成后可实现7x24小时实时监控。

前言

传统的服务器监控方案通常需要部署专门服务武器监控系统（如Prometheus、Zabbix），配置复杂且资源消耗较大。对于中小规模服务器监控需求，使用n8n可以快速搭建一套轻量级的监控告警系统，通过可视化的工作流编排实现数据采集、处理和告警。

适用场景：

  • 中小规模服务器（1-50台）的资源监控
  • 需要快速搭建监控告警系统
  • 希望通过Telegram接收告警通知
  • 对监控系统有定制化需求

环境准备

基础环境：

  • n8n 工作流平台（本文基于最新稳定版）
  • Telegram Bot（用于接收告警消息）
  • 支持HTTPS的域名（用于Webhook接收）

配置信息获取：

  • n8n域名 ：替换your-n8n-domain.com为你的n8n实际部署域名
  • 认证Token ：使用openssl rand -hex 32命令生成强随机字符串
  • Telegram Chat ID ：与Bot对话后访问 https://api.telegram.org/bot<YOUR_BOT_TOKEN>/getUpdates 获取
  • Telegram User ID ：同上述方法获取，在返回的JSON中查找from.id字段

监控数据格式：

系统通过Webhook接收JSON格式的监控数据，包含以下字段：

  • server_name: 服务器名称
  • cpu_usage: CPU使用率（百分比）
  • memory_usage: 内存使用率（百分比）
  • disk_usage: 磁盘使用率（百分比）
  • network_in: 入站流量（字节/秒）
  • network_out: 出站流量（字节/秒）
  • load_average: 系统负载
  • uptime: 运行时间
  • timestamp: 数据采集时间
  • auth_token: 认证令牌

核心流程设计

整个监控系统采用模块化设计，由7个核心节点组成完整的数据处理链路。

1. 接收服务器监控数据

在n8n中创建Webhook节点作为数据接收入口，配置方式如下：

具体操作如下：

从配置界面可以看到，Webhook节点生成了测试URL和生产URL两个地址。测试URL示例：

复制代码 
https://your-n8n-domain.com/webhook-test/server-monitor

关键配置说明：

  • HTTP方法：POST
  • 路径：server-monitor（可自定义）
  • 认证方式：None（在后续节点中处理Token认证）
  • 响应模式：使用"Respond to Webhook"节点

这种设计将认证逻辑与数据接收分离，方便后续灵活控制认证策略。

2. 配置和验证Token

接收到数据后，需要对请求进行身份验证。使用JavaScript代码节点实现Token验证和配置初始化：

执行以下配置和验证逻辑：

核心代码逻辑如下：

javascript 复制代码 
const CONFIG = {
  // 监控系统认证Token（使用openssl rand -hex 32生成）
  MONITOR_AUTH_TOKEN: 'YOUR_SECURE_TOKEN_HERE',

  // Telegram Chat ID（接收通知的Chat）
  TELEGRAM_CHAT_ID: 'YOUR_TELEGRAM_CHAT_ID',

  // 允许使用机器人的用户ID列表
  ALLOWED_USER_IDS: ['YOUR_TELEGRAM_USER_ID'],

  // 告警阈值配置
  THRESHOLDS: {
    cpu: 80,      // CPU使用率阈值（%）
    memory: 85,   // 内存使用率阈值（%）
    disk: 90      // 磁盘使用率阈值（%）
  }
};

// 验证Token
const requestToken = $input.item.json.body.auth_token;
const authorized = requestToken === CONFIG.MONITOR_AUTH_TOKEN;

// 返回验证结果和配置
return {
  authorized: authorized,
  body: $input.item.json.body,
  config: CONFIG
};

安全说明： 使用openssl rand -hex 32命令生成强随机Token，确保监控数据接口的安全性。在生产环境中，建议定期更换Token。

3. 认证分流处理

验证完成后，使用IF节点根据认证结果进行流程分流：

执行以下命令进行安装/配置：

从节点配置可以看到，判断条件为：

复制代码 
{{$json.authorized}} === true
  • True分支：认证通过，继续处理监控数据
  • False分支：认证失败，返回错误响应

这种设计可以有效防止未授权的数据推送，保护监控系统安全。

4. 处理监控数据

认证通过后，对监控数据进行解析和告警判断：

执行以下命令进行安装/配置：

核心处理逻辑包含以下几个步骤：

javascript 复制代码 
const data = $input.item.json.body;
const config = $input.item.json.config;
const thresholds = config.THRESHOLDS;

// 解析监控数据
const serverName = data.server_name || 'Unknown';
const cpu = parseFloat(data.cpu_usage || 0);
const memory = parseFloat(data.memory_usage || 0);
const disk = parseFloat(data.disk_usage || 0);
const networkIn = parseFloat(data.network_in || 0);
const networkOut = parseFloat(data.network_out || 0);
const loadAvg = data.load_average || 'N/A';
const uptime = data.uptime || 'N/A';

// 检查告警
let alerts = [];
let status = '正常';
let alertLevel = 'info';

if (cpu > thresholds.cpu) {
  alerts.push(`CPU使用率过高: ${cpu.toFixed(2)}%`);
  alertLevel = 'warning';
  status = '警告';
}

if (memory > thresholds.memory) {
  alerts.push(`内存使用率过高: ${memory.toFixed(2)}%`);
  alertLevel = 'warning';
  status = '警告';
}

if (disk > thresholds.disk) {
  alerts.push(`磁盘使用率过高: ${disk.toFixed(2)}%`);
  alertLevel = 'critical';
  status = '严重';
}

// 生成告警消息
const message = `
## 服务器监控报告

## 服务器: ${serverName}
## 时间: ${new Date(data.timestamp).toLocaleString('zh-CN')}

## 系统资源
------------------------------------
CPU: ${cpu.toFixed(2)}%
内存: ${memory.toFixed(2)}%
磁盘: ${disk.toFixed(2)}%
负载: ${loadAvg}
运行: ${uptime}

## 网络流量
------------------------------------
入站: ${(networkIn / 1024).toFixed(2)} KB/s
出站: ${(networkOut / 1024).toFixed(2)} KB/s

## 状态: ${status}

${alerts.join('\n')}
`;

return {
  message: message,
  hasAlert: alerts.length > 0,
  alertLevel: alertLevel,
  serverName: serverName,
  chatId: config.TELEGRAM_CHAT_ID,
  timestamp: new Date().toISOString(),
  metrics: {
    cpu: cpu,
    memory: memory,
    disk: disk,
    networkIn: networkIn,
    networkOut: networkOut,
    loadAvg: loadAvg,
    uptime: uptime
  }
};

这段代码实现了三个核心功能：数据解析、阈值检查和消息格式化。告警级别分为info（正常）、warning（警告）、critical（严重）三个等级。

5. 检查是否需要告警

处理完数据后，判断是否需要发送告警通知：

执行以下命令进行安装/配置：

判断条件为：

复制代码 
{{$json.hasAlert}} === true

只有当存在告警时（CPU、内存或磁盘超过阈值）才会触发Telegram消息发送，避免频繁推送正常状态消息。

6. 发送告警到Telegram

当检测到告警时，通过Telegram Bot发送通知消息：

执行以下命令进行安装/配置：

从配置可以看到，Telegram节点的关键设置：

  • Resource: Message
  • Operation: Send Message
  • Chat ID : {``{$json.chatId}}（从配置中读取）
  • Text : {``{$json.message}}（格式化的监控消息）
  • Parse Mode: Markdown (Legacy)

使用Markdown格式可以让消息展示更清晰，支持加粗、标题等格式化效果。

7. 返回成功响应

无论是否发送告警，都需要给监控客户端返回响应：

执行以下命令进行安装/配置：

使用"Respond to Webhook"节点返回HTTP 200状态码，告知客户端数据已成功接收。配置项：

  • Respond With: First Incoming Item
  • Response Code: 200

这样可以确保监控脚本能够正确判断数据是否提交成功。

测试验证

配置完成后，使用curl命令测试整个流程：

执行以下命令进行安装/配置：

测试命令示例：

bash 复制代码 
curl -X POST https://your-n8n-domain.com/webhook/server-monitor \
-H "Content-Type: application/json" \
-d '{
  "auth_token": "YOUR_SECURE_TOKEN_HERE",
  "server_name": "test-server",
  "cpu_usage": 85.5,
  "memory_usage": 70.3,
  "disk_usage": 50.9,
  "network_in": 1024000,
  "network_out": 512000,
  "load_average": "1.5",
  "uptime": "5 days",
  "timestamp": "'$(date -u +%Y-%m-%dT%H:%M:%SZ)'"
}'

从返回结果可以看到，n8n成功处理了请求并发送了Telegram消息，返回JSON包含了完整的消息发送结果。

告警效果展示

具体操作如下：

Telegram Bot成功收到告警消息，显示内容包括：

  • 服务器名称和监控时间
  • 系统资源使用情况（CPU、内存、磁盘、负载、运行时间）
  • 网络流量数据（入站/出站）
  • 告警状态和具体告警项

消息格式清晰，关键信息一目了然。

完整工作流视图

执行以下命令进行安装/配置：

从n8n编辑器界面可以看到完整的监控工作流，包含主流程和扩展功能：

主流程：

  1. 接收服务器数据
  2. 配置和验证Token
  3. 认证分流
  4. 处理监控数据
  5. 检查是否需要告警
  6. 发送告警到Telegram
  7. 返回成功响应

扩展功能：

  • 每日汇总（定时生成和发送监控摘要）
  • Telegram命令触发器（支持通过Telegram控制）

整个工作流采用可视化配置，所有节点通过连线表示数据流向，维护和调试都非常直观。

服务器端监控脚本

在被监控的服务器上，需要部署数据采集脚本，定期收集系统指标并推送到n8n：

bash 复制代码 
#!/bin/bash

# n8n Webhook地址
WEBHOOK_URL="https://your-n8n-domain.com/webhook/server-monitor"

# 认证Token（与n8n中配置保持一致）
AUTH_TOKEN="YOUR_SECURE_TOKEN_HERE"

# 服务器名称
SERVER_NAME=$(hostname)

# 采集系统指标
CPU_USAGE=$(top -bn1 | grep "Cpu(s)" | sed "s/.*, *\([0-9.]*\)%* id.*/\1/" | awk '{print 100 - $1}')
MEMORY_USAGE=$(free | grep Mem | awk '{printf("%.2f", ($3/$2) * 100.0)}')
DISK_USAGE=$(df -h / | awk 'NR==2 {print $5}' | sed 's/%//')
NETWORK_IN=$(cat /sys/class/net/eth0/statistics/rx_bytes)
NETWORK_OUT=$(cat /sys/class/net/eth0/statistics/tx_bytes)
LOAD_AVERAGE=$(uptime | awk -F'load average:' '{print $2}' | awk -F',' '{print $1}' | xargs)
UPTIME=$(uptime -p | sed 's/up //')
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)

# 发送数据到n8n
curl -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d "{
    \"auth_token\": \"$AUTH_TOKEN\",
    \"server_name\": \"$SERVER_NAME\",
    \"cpu_usage\": $CPU_USAGE,
    \"memory_usage\": $MEMORY_USAGE,
    \"disk_usage\": $DISK_USAGE,
    \"network_in\": $NETWORK_IN,
    \"network_out\": $NETWORK_OUT,
    \"load_average\": \"$LOAD_AVERAGE\",
    \"uptime\": \"$UPTIME\",
    \"timestamp\": \"$TIMESTAMP\"
  }"

部署方式：

  1. 将脚本保存为/usr/local/bin/server-monitor.sh

  2. 添加执行权限：chmod +x /usr/local/bin/server-monitor.sh

  3. 配置crontab定时执行（每5分钟）：

    bash 复制代码 
    */5 * * * * /usr/local/bin/server-monitor.sh >> /var/log/server-monitor.log 2>&1

常见问题

Q: 如何修改告警阈值？

A: 在"配置和验证Token"节点的JavaScript代码中修改THRESHOLDS对象，保存后即可生效，无需重启n8n。

Q: 如何支持多台服务器监控？

A: 在每台服务器上部署监控脚本，设置不同的SERVER_NAME，所有服务器向同一个Webhook地址推送数据。系统会根据server_name字段区分不同服务器。

Q: 如何避免告警消息过多？

A: 可以在"检查是否需要告警"节点前增加一个节点，记录上次告警时间，实现告警频率限制（如同一告警30分钟内只发送一次）。

Q: 如何查看历史监控数据？

A: n8n的"Executions"标签页会记录所有工作流执行历史，可以查看每次监控数据的详细内容。如需长期存储，可以添加数据库节点将数据写入MySQL或PostgreSQL。

总结

使用n8n搭建服务器监控系统的优势在于配置简单、可视化程度高、易于扩展。整个方案不需要部署复杂的监控组件，通过Webhook和工作流编排就能实现完整的监控告警功能。从实际使用效果来看，这套方案完全满足中小规模服务器监控需求，响应及时且维护成本低。后续可以根据业务需要，扩展更多功能，比如添加数据库存储、生成图表报表、集成钉钉或企业微信等其他通知渠道。

感谢

感谢你读到这里，说明你已经成功地忍受了我的文字考验！🎉

希望这篇文章没有让你想砸电脑，也没有让你打瞌睡。

如果有一点点收获，那我就心满意足了。

未来的路还长，愿你
遇见难题不慌张，遇见bug不抓狂，遇见好内容常回访。

记得给自己多一点耐心，多一点幽默感，毕竟生活已经够严肃了。

如果你有想法、吐槽或者想一起讨论的，欢迎留言，咱们一起玩转技术，笑对人生！😄

祝你代码无bug，生活多彩，心情常青！🚀

相关推荐
dessler2 小时前
MYSQL-主键（Primary Key）
linux·运维·mysql
CoderJia程序员甲2 小时前
GitHub 热榜项目 - 日榜(2025-11-11)
ai·开源·大模型·github·ai教程
only-code2 小时前
MCP驱动的Rgentic RRG（向量数据库+网络搜索）
数据库·python·大模型·函数调用·mcp
全栈小52 小时前
【C#】从一次异步锁逐渐展开浅谈服务器架构解决重复编码问题，我与AI的一次深度讨论得出的一些解决方案
服务器·架构·c#
安丘贾队长2 小时前
json啊啊啊啊啊啊啊啊啊
运维
weixin_537765802 小时前
【负载均衡】LVS原理与配置
服务器·负载均衡·lvs
我什么都学不会2 小时前
DNS主从服务器练习
linux·运维·服务器
zt1985q2 小时前
外网访问项目研发管理软件 codes
运维·服务器·windows·网络协议·tcp/ip
华纳云IDC服务商2 小时前
DNS记录更新后为什么还是访问不到新服务器？
运维·服务器
热门推荐
01GitHub 镜像站点02UV安装并设置国内源03综合整理：pdf预览显示：你尝试预览的文件可能对你的计算机有害。如果你信任此文件以及其来源，请打开此文件以看其内容，如何解决以正常预览文件04Linux下V2Ray安装配置指南05安娜的档案(Anna’s Archive) 镜像网站/国内最新可访问入口（持续更新）06BongoCat - 跨平台键盘猫动画工具07Labelme从安装到标注：零基础完整指南08《大数据技术原理与应用》实验报告三 熟悉HBase常用操作09智能库存管理的需求预测模型：从业务痛点到落地代码的完整实践10看了下昨日泄露的苹果 App Store 源码……