Node-RED:監控與告警：讓系統自己“喊救命”

文章目錄

• Node-RED:監控與告警：讓系統自己“喊救命”

• 摘要
• 一、為什麼需要監控？——Node-RED 的“盲區”
• 二、指標採集：讓 Node-RED “開口説話”

• 🔧 方案 1：使用 `node-red-contrib-prometheus`

• 安裝：
• 配置：

• 🔧 方案 2：自建 Health Check 端點

• 三、日誌聚合：從“翻文件”到“秒級檢索”

• ✅ 推薦架構：Fluentd / Filebeat → Elasticsearch → Kibana

• 步驟：

• 四、可視化看板：一眼看清系統狀態

• 📊 使用 Grafana + Prometheus

• 1. 部署 Prometheus
• 2. 導入 Grafana 看板

• 五、告警觸發：何時該“喊救命”？

• 🚨 推薦告警規則（Prometheus Alertmanager）

• 六、告警通知：讓消息觸達責任人

• 📧 1. 郵件告警（基礎必備）
• 💬 2. 微信/釘釘機器人（國內推薦）

• 微信企業號：
• 釘釘：

• 七、邊緣節點監控：解決“看不見”的難題

• ✅ 解決方案：心跳上報 + 反向探測

• 方案 A：主動心跳
• 方案 B：MQTT LWT（Last Will Testament）

• 八、監控告警清單（生產環境必備）
• 九、真實案例：從“被動救火”到“主動預防”
• 寫在最後：監控不是成本，而是保險

關鍵字：

Node-RED、

關鍵字2、

關鍵字3、

關鍵字4、

關鍵字5

關鍵字6、

關鍵字7

摘要

去年冬天，一個部署在偏遠變電站的 Node-RED 節點突然失聯。
因為沒人監控，直到三天後巡檢才發現：
Modbus 串口線鬆了，導致整個配電數據中斷。

如果當時有告警，
一條微信就能讓運維人員 10 分鐘內遠程重啓設備。

Node-RED 可以默默運行，但不能默默崩潰。
真正的生產系統，必須具備 “自診斷 + 自呼救” 能力。

今天這篇文章，就帶你構建 Node-RED 的全棧監控告警體系。
你將學會：

• 如何暴露 CPU、內存、消息速率等核心指標
• 如何用 Prometheus + Grafana 實現可視化
• 如何配置健康檢查（Health Check）端點
• 如何通過郵件、微信、釘釘發送實時告警
• 以及如何監控邊緣節點的離線狀態

這不是“工具拼湊”，而是一份 “從沉默到主動發聲”的運維升級指南。

一、為什麼需要監控？——Node-RED 的“盲區”

默認情況下，Node-RED 是“啞巴”系統：

• ❌ 不報告 CPU 使用率
• ❌ 不記錄消息積壓
• ❌ 不通知流程異常
• ❌ 不感知節點離線

一旦出問題，只能靠：

• 用户投訴
• 手動登錄查看
• 日誌翻到眼花

而現代運維要求：故障先於用户發現，恢復快於業務感知。

二、指標採集：讓 Node-RED “開口説話”

🔧 方案 1：使用 node-red-contrib-prometheus

這是最推薦的方式——直接暴露標準 Prometheus 指標。

安裝：

npm install node-red-contrib-prometheus

配置：

• 拖入 Prometheus Metrics 節點
• 默認監聽 http://localhost:1880/metrics
• 自動採集：

• nodered_message_count_total（各節點消息數）
• nodered_uptime_seconds（運行時長）
• process_cpu_usage、process_resident_memory_bytes

💡 支持自定義指標：

// 在 Function 節點中 global.set("custom_metric", { type: "gauge", value: queueLength });

🔧 方案 2：自建 Health Check 端點

用 HTTP In + Function 節點實現輕量級健康檢查：

// Function 節點邏輯
const os = require('os');
msg.payload = {
    status: "ok",
    uptime: process.uptime(),
    memory: process.memoryUsage().rss / 1024 / 1024,
    loadavg: os.loadavg(),
    timestamp: new Date().toISOString()
};
return msg;

訪問 GET /health 返回 JSON，供外部探針調用。

三、日誌聚合：從“翻文件”到“秒級檢索”

Node-RED 默認日誌輸出到控制枱，難以分析。

✅ 推薦架構：Fluentd / Filebeat → Elasticsearch → Kibana

步驟：

1. 將 Node-RED 日誌重定向到文件：

node-red >> /var/log/nodered.log 2>&1

1. 用 Filebeat 採集日誌：

# filebeat.yml
filebeat.inputs:
  - type: filestream
    paths: ["/var/log/nodered.log"]
output.elasticsearch:
  hosts: ["http://es:9200"]

1. 在 Kibana 中搜索 error 或 exception

💡 替代方案：小規模可用 Papertrail 或 Loggly（SaaS 日誌服務）

四、可視化看板：一眼看清系統狀態

📊 使用 Grafana + Prometheus

1. 部署 Prometheus

prometheus.yml 配置抓取目標：

scrape_configs:
  - job_name: 'nodered'
    static_configs:
      - targets: ['your-nodered-host:1880']

2. 導入 Grafana 看板

• ID: 12345（社區模板）或自建
• 關鍵面板：

• 消息吞吐率（按節點分組）
• 內存與 CPU 趨勢
• Uptime 與重啓次數
• 錯誤日誌計數

🖼️ 看板效果描述：
左上角顯示“今日處理消息 2,450,321 條”，
中間折線圖展示過去 24 小時 CPU 波動，
右下角紅色數字“Error Count: 3”自動閃爍——
一切盡在掌控。

五、告警觸發：何時該“喊救命”？

不是所有異常都需要告警。
設定合理閾值，避免“狼來了”。

🚨 推薦告警規則（Prometheus Alertmanager）

💡 技巧：對非關鍵流程，設置“僅工作日白天告警”

六、告警通知：讓消息觸達責任人

📧 1. 郵件告警（基礎必備）

Alertmanager 配置 SMTP：

receivers:
  - name: 'ops-team'
    email_configs:
      - to: 'ops@example.com'
        send_resolved: true

💬 2. 微信/釘釘機器人（國內推薦）

微信企業號：

• 創建應用，獲取 corp_id 和 secret
• 用 Webhook 發送：

// Node-RED 中用 HTTP Request 節點
msg.payload = {
    msgtype: "text",
    text: { content: "【告警】Node-RED 內存超限！" }
};
msg.headers = { "Content-Type": "application/json" };
return msg;

釘釘：

• 創建自定義機器人，複製 Webhook URL
• 同樣用 HTTP Request 節點 POST 消息

✅ 效果：手機彈出“【緊急】變電站數據中斷”，點擊直達 Grafana 看板。

七、邊緣節點監控：解決“看不見”的難題

部署在工廠、農田的邊緣 Node-RED，往往無公網 IP。

✅ 解決方案：心跳上報 + 反向探測

方案 A：主動心跳

邊緣節點每 30 秒 POST 一次狀態到中心服務器：

// Inject (30s) → Function → HTTP Request
msg.payload = { id: "edge-001", ts: Date.now() };

中心服務記錄最後心跳時間，超時即告警。

方案 B：MQTT LWT（Last Will Testament）

• 邊緣連接 MQTT 時設置 LWT 消息
• 斷連時 Broker 自動發佈“offline”消息
• 中心訂閲該主題並觸發告警

💡 優勢：無需邊緣主動上報，斷電也能感知。

八、監控告警清單（生產環境必備）

九、真實案例：從“被動救火”到“主動預防”

場景：某智慧水務平台，50+ 邊緣網關
問題：每月平均 3 次因內存泄漏導致數據中斷
解決方案：

1. 部署 Prometheus + Grafana
2. 設置 Memory > 800MB 告警
3. 告警自動觸發微信通知 + 自動重啓腳本（通過 SSH）

結果：

• 故障發現時間從 72 小時 → 2 分鐘
• 月均中斷次數降至 0
• 運維人力節省 60%

✅ 關鍵：告警不是終點，自動化恢復才是

寫在最後：監控不是成本，而是保險

很多人覺得監控“麻煩又沒用”，
直到系統崩潰、客户投訴、獎金泡湯。

但真正成熟的團隊知道：
最好的運維，是讓問題在造成損失前就被解決。

Node-RED 可以很輕量，但它的監控不能輕視。
因為你守護的，不只是代碼，
而是工廠的產線、城市的管網、家庭的安全。

在此之前，不妨做一次“告警演練”：
手動製造一個錯誤（如除零異常），驗證是否收到微信/郵件通知。
當你看到手機彈出告警時，你就擁有了“系統的眼睛和嘴巴”。