n8n 网站宕机监控工作流深度分析

概述

本文将深入分析一个基于 n8n 构建的网站宕机监控系统。该工作流能够自动监控多个网站的可用性，记录宕机时间，并通过多种渠道（Email、Slack、Telegram）发送告警通知。

系统架构

核心功能

1. 定时监控：每分钟检查一次网站状态
2. 状态检测：通过 HTTP 请求判断网站是否可访问
3. 日志记录：使用 Google Sheets 记录宕机和恢复时间
4. 多渠道通知：支持 Gmail、Slack、Telegram、Ntfy 等多种通知方式
5. 宕机时长计算：自动计算网站的总宕机时长

数据存储结构

工作流使用 Google Sheets 作为数据存储，包含两个工作表：

• Sheet1：存储需要监控的网站 URL 列表
• Sheet2：记录所有宕机事件的详细日志

Sheet2 的数据结构：

字段	说明
Website URL	网站地址
Down Time	宕机时间 (HH:MM:SS)
Up Time	恢复时间 (HH:MM:SS)
Total downtime	总宕机时长 (Xh Ym Zs)

工作流程图

整体流程

状态判断逻辑

关键节点详解

1. 定时触发器 (Schedule Trigger)

{
  "rule": {
    "interval": [{}]
  }
}

配置为每分钟执行一次，确保及时发现网站问题。

2. 网站状态检查 (HTTP Request)

{
  "url": "={{ $json['Website URL'] }}",
  "options": {
    "response": {
      "fullResponse": true
    },
    "timeout": 5000
  },
  "onError": "continueRegularOutput"
}

关键配置：

• timeout: 5000：5秒超时，避免长时间等待
• onError: continueRegularOutput：即使请求失败也继续执行，确保能记录宕机事件

3. 宕机时长计算逻辑

工作流使用了一段精巧的 JavaScript 代码来计算宕机时长：

(() => {
  const downTimeStr = $input.first().json['Down Time'];
  const now = new Date();
  const upTimeStr = now.toLocaleTimeString('en-GB', { hour12: false });

  function parseTime(timeStr) {
    const [h, m, s] = timeStr.split(":").map(Number);
    const date = new Date();
    date.setHours(h, m, s, 0);
    return date;
  }

  const downTime = parseTime(downTimeStr);
  const upTime = parseTime(upTimeStr);

  // 处理跨午夜场景
  if (upTime < downTime) {
    upTime.setDate(upTime.getDate() + 1);
  }

  const diffMs = upTime - downTime;
  const totalMinutes = Math.floor(diffMs / 60000);
  const hours = Math.floor(totalMinutes / 60);
  const minutes = totalMinutes % 60;
  const seconds = Math.floor((diffMs % 60000) / 1000);

  return `${hours}h ${minutes}m ${seconds}s`;
})()

亮点：

• 自动处理跨午夜的宕机事件
• 精确到秒的时长计算
• 友好的时间格式输出

4. 重复记录检测

使用 Code 节点检测是否已存在未完成的宕机记录：

let hasIncompleteRecord = false;

for (const item of $input.all()) {
  const url = item.json['Website URL']?.trim();
  const downTime = item.json['Down Time']?.trim();
  const upTime = item.json['Up Time']?.trim();
  const totalDowntime = item.json['Total downtime']?.trim();

  // 如果有 Down Time 但没有 Up Time，说明是未完成记录
  if (url && downTime && (!upTime || !totalDowntime)) {
    hasIncompleteRecord = true;
  }
}

return [{
  json: {
    status: hasIncompleteRecord ? "yes" : "no",
    websites: $input.first().json['Website URL']
  }
}];

这个逻辑确保：

• 不会为同一次宕机创建多条记录
• 只在网站恢复时更新现有记录

通知系统设计

宕机告警通知

当检测到网站宕机时，系统会通过 4 个渠道并行发送告警：

恢复通知

网站恢复时发送 3 个渠道的通知：

通知内容模板：

We're excited to announce that the {{ Website URL }} is now live! 
Feel free to visit and explore.

数据流转图

技术亮点

1. 循环批处理 (Split In Batches)

使用 splitInBatches 节点逐个处理网站列表，优势：

• 避免并发请求过多
• 每个网站独立处理，互不影响
• 便于追踪单个网站的处理流程

2. 条件分支设计

工作流使用了多层 IF 节点实现复杂的业务逻辑：

检查状态码
  ├─ 200 OK
  │   └─ 检查是否有未完成宕机记录
  │       ├─ 有 → 更新记录 + 发送恢复通知
  │       └─ 无 → 继续循环
  └─ 非 200
      └─ 检查是否已有宕机记录
          ├─ 有 → 跳过（避免重复）
          └─ 无 → 创建记录 + 发送告警

3. 错误处理

HTTP 请求节点配置了 onError: "continueRegularOutput"，确保：

• 网络错误不会中断工作流
• 超时、DNS 解析失败等都会被视为宕机
• 工作流具有高可用性

4. 时间格式统一

所有时间记录使用 en-GB 格式的 24 小时制：

new Date().toLocaleTimeString('en-GB', { hour12: false })
// 输出: "14:30:45"

确保时间计算的准确性和一致性。

优化建议

1. 添加重试机制

当前工作流在首次请求失败时立即判定为宕机，建议：

// 伪代码
for (let i = 0; i < 3; i++) {
  const response = await httpRequest(url);
  if (response.statusCode === 200) {
    return 'UP';
  }
  await sleep(10000); // 等待 10 秒
}
return 'DOWN';

2. 支持自定义监控间隔

不同网站可能需要不同的监控频率，可以在 Sheet1 中添加 Interval 字段。

3. 添加响应时间监控

除了可用性，还可以记录响应时间：

{
  "url": "={{ $json['Website URL'] }}",
  "options": {
    "response": {
      "fullResponse": true
    }
  }
}
// 使用 $json.headers['x-response-time'] 或计算时间差

4. 历史数据分析

可以添加一个定期任务，统计：

• 每个网站的月度可用率
• 平均宕机时长
• 宕机频率趋势

5. 告警降噪

对于频繁抖动的网站，可以设置：

• 连续失败 N 次才发送告警
• 告警静默期（避免短时间内重复通知）

部署注意事项

1. Google Sheets API 配额

Google Sheets API 有调用限制：

• 每分钟 60 次读取
• 每分钟 60 次写入

如果监控网站数量较多，需要注意配额限制。

2. 通知渠道配置

需要提前配置好各个通知渠道的凭证：

• Gmail OAuth2 认证
• Slack API Token
• Telegram Bot Token
• Ntfy 服务器地址

3. 时区设置

确保 n8n 实例的时区设置正确，否则时间记录会有偏差。

4. 监控 n8n 本身

建议使用外部服务监控 n8n 实例本身的可用性，避免监控系统自身宕机。

实际应用场景

1. 个人博客监控

监控个人网站、博客的可用性，及时发现服务器问题。

2. 客户网站维护

为客户提供网站监控服务，自动生成可用性报告。

3. 内部服务监控

监控公司内部的各种服务（API、管理后台等）。

4. 竞品监控

监控竞争对手网站的可用性，了解其服务质量。

成本分析

该方案的成本极低：

服务	费用
n8n (自托管)	服务器成本 (~$5/月)
Google Sheets	免费
Gmail	免费
Slack	免费版
Telegram	免费
Ntfy	免费

总成本：约 $5/月（仅服务器费用）

相比商业监控服务（如 Pingdom、UptimeRobot 付费版），成本节省 90% 以上。

总结

这个 n8n 工作流展示了如何用低代码工具构建一个功能完整的网站监控系统。通过合理的流程设计和多渠道通知，能够有效保障网站的可用性。

核心优势：

• ✅ 完全可视化配置，无需编写大量代码
• ✅ 多渠道通知，确保告警不遗漏
• ✅ 详细的日志记录，便于事后分析
• ✅ 成本极低，适合个人和小团队
• ✅ 高度可定制，易于扩展

适用人群：

• 个人开发者
• 小型团队
• 预算有限的初创公司
• 需要监控少量网站的场景

如果你也在寻找一个简单、经济的网站监控方案，不妨试试这个 n8n 工作流！

参考资源

• n8n 官方文档
• Google Sheets API
• PlantUML 语法指南
• 工作流示例 Google Sheets

---

本文基于实际 n8n 工作流配置编写，所有代码和配置均经过验证。