Building a Lightweight, Secure Infra Cluster Monitor with InfluxDB and Grafana

[ 一個受 CISS-Red_Cluster_Monitor 專案啟發的實用指南 ]

專案設計目的：本文將介紹一個輕量級、自託管的伺服器/VM 叢集監控系統，該系統使用 Python、InfluxDB 和 Grafana 構建，專門用於處理安全實驗室、CTF 環境、OT 網路或隔離叢集的特殊或客製化監控需求。您將不再依賴黑箱代理程式，而是構建自己的客製化資料收集器和監視器，從您需要的確切來源（無論是 IPMI、網路探針還是應用程式特定的端點）獲取指標，將它們推送到安全的本地時間序列資料庫，並使用客製化的儀表板視覺化資料。

本文中的實用範例靈感來自 CISS-Red_Cluster_Monitor 專案，該專案旨在監控用於支援紅隊網路安全 CTF 競賽的沙箱叢集（400 多個 VM）。為了使設計清晰且可重現，本文圍繞四個主要部分構建：

• 核心設計理念 – 整體系統架構，包括代理程式/提取器模型和通訊流程。

• 安全配置選擇 – 系統如何設計以防止參與者對代理程式進行逆向工程或傳送偽造指標。

• 技術堆疊 – 使用的工具 (Python, InfluxDB, Grafana, etc.) 以及如何安裝和配置它們。

• 資料和 UI – 資料如何儲存、在儀表板中視覺化，以及如何摘要或警示（例如，透過 Grafana 和 Telegram）。

# Author:           Yuancheng Liu
# Created:          2026/01/27
# Version:           v_0.2.1
# Copyright:       Copyright (c) 2025 Liu Yuancheng
# License:	   GNU General Public License

1. 簡介

市場上有幾種免費或商業工具可用於監控伺服器和 VM 叢集，例如 PM2，它可以監控物理伺服器、docker 或虛擬機器中的工作負載、網路延遲和服務，而只需很少的設定。但有時我們可能有一些特殊或客製化的需求，例如：

• 無法在某些特定裝置上直接安裝代理程式

• 需要從 IPMI 等來源收集電源和硬體遙測資料，而不是作業系統層級的代理程式

• 系統必須在完全本地/氣隙環境中執行，沒有網際網路存取

• 需要視覺化客製化的資料收集和驗證邏輯。

基於這些情境和需求，監控系統必須在競賽負載下簡單可靠，防止篡改或偽造資料注入，可部署在受限的網路環境中，並且易於管理員即時視覺化和稽核。

1.1 使用案例背景和目標

例如，CISS-Red 第一階段 CTF 活動需要持續監控多個物理伺服器和虛擬機器，時間長達 48 小時，以確保基礎架構穩定性並實現快速事件回應。監控目標是即時追蹤關鍵指標，包括主機伺服器的 CPU 和記憶體使用率、網路延遲、CTF 挑戰 VM 的服務可用性以及使用者 SSH 登入活動，並透過集中式、直觀的儀表板呈現所有這些資訊。每當檢測到異常情況時，系統會自動將警示通知傳送到支援和管理員 Telegram 群組。

2. 系統架構

監控系統採用基於資訊提取的代理程式架構，其中中央監控中心主動從分散式代理程式提取資料，而不是讓代理程式將資料向上推送。這種設計選擇主要是由安全考量驅動的：在 CTF 環境中，參與者可能會嘗試對代理程式程式碼進行逆向工程或偽造請求以注入偽造指標。透過將所有資料收集置於中央中心的控制之下，可以顯著減少可能的攻擊面，並有效防止未經授權的資料提交。

從架構的角度來看，系統遵循一個簡單的三層設計，如下所示：

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│  Physical    │         │  Physical    │         │  Physical    │
│  Server 1    │         │  Server 2    │         │  Server N    │
│  ┌────────┐  │         │  ┌────────┐  │         │  ┌────────┐  │
│  │ Agent  │  │         │  │ Agent  │  │         │  │ Agent  │  │
│  │(Python)│  │         │  │(Python)│  │         │  │(Python)│  │
│  └────────┘  │         │  └────────┘  │         │  └────────┘  │
│      │ Local │         │      │ Local │         │      │ Local │
│      │Storage│         │      │Storage│         │      │Storage│
└──────┼───────┘         └──────┼───────┘         └──────┼───────┘
       └────────────────┬───────┴────────────────────────┘
                        │ HTTP Fetch Requests(Pull Mode)
                        ▼
              ┌──────────────────────────┐
              │  Monitor Hub (Collector) │
              └────────┬─────────────────┘
                       │ Write Metrics
                       ▼
              ┌──────────────────────────────────┐
              │   InfluxDB(Time-Series Database) │
              └────────┬─────────────────────────┘
                       │ Query Data
                       ▼
              ┌──────────────────────────────────────┐
              │    Grafana Dashboard (Visualization) │
              └──────────────────────────────────────┘

• 代理程式層 – 部署在受監控節點上或連接到受監控節點的多個輕量級 Python 代理程式，用於收集系統和服務指標。

• 儲存層 – 一個 InfluxDB 時間序列資料庫，用於有效儲存和查詢監控資料。

• 視覺化層 – 一個 Grafana 儀表板，提供叢集的即時視覺化、歷史分析和操作概觀，以及一個訊息傳送器，用於透過 Telegram 訊息傳送可能的警示。

2.1 系統工作流程詳情

整體系統工作流程如下圖所示：

在 CISS-Red CTF 環境中，參與者首先透過防火牆 SSH 連線到公共 IP 閘道，然後存取他們分配的挑戰虛擬機器。每個託管挑戰 VM 或 Docker 容器的物理伺服器都配備了兩個 RJ45 網路介面，連接到兩個隔離的網路：

• 介面 1（圖中的藍色路徑） 專門用於參與者流量以存取挑戰服務。

• 介面 2（圖中的橘色路徑） 專用於監控流量，允許監控代理程式和中心收集操作資料，而不會干擾 CTF 參與者活動或暴露於 CTF 參與者活動。

此配置確保監控流量不會影響競賽環境的效能或公平性。從功能的角度來看，系統由三個主要元件組成：

• 服務探測器儲存庫：一個可重複使用的 python 服務檢查程式庫，提供多個探測功能（例如，NTP、FTP、VNC、SSH 和自訂服務檢查）。這些探測器用於驗證叢集中的特定節點、服務、程式或功能是否正常運作。

• 探測器代理程式：一個輕量級代理程式，負責排程和執行不同的探測器，以評估叢集中一個或多個目標的可用性和健康狀況。代理程式可以在伺服器上本地執行，以直接收集指標。對於無法安裝代理程式的節點，系統會退回到基於 SSH 的命令執行，以遠端檢索所需的資料。

• 監控中心：中央監控和分析元件，提供資料庫後端 (InfluxDB) 用於封存時間序列指標、一個基於 Web 的儀表板 (Grafana) 用於即時和歷史視覺化，以及可擴展的介面用於整合自訂邏輯，例如分數計算公式或競賽特定的評估函數。

2.2 技術堆疊

此專案中使用的程式庫和工具以及相關連結如下表所示：

3. 系統模組設計

本節介紹監控系統的三個核心元件的詳細設計：服務探測器儲存庫、探測器代理程式和監控中心。

3.1 服務探測器儲存庫設計

服務探測器儲存庫是一個可重複使用的 python 探測程式庫，提供廣泛的功能來檢查服務、程式和系統資源的狀態，然後插入到探測器代理程式中。所有探測函數都設計為模組化元件，可以分為三類：local service probers、child agent probers 和 network service probers。

3.1.1 本地服務探測器

本地服務探測器直接在目標節點上執行，並專注於監控節點的內部狀態，包括：

• 系統資源使用率（CPU、記憶體、磁碟、網路 I/O），

• 使用者活動（登入會話、命令執行、檔案系統變更），

• 本地程式和程序狀態（程序生命週期、服務埠、日誌狀態）。

主要的本地探測器總結如下：

3.1.2 子代理程式探測器

子代理程式探測器用於從其他探測器代理程式提取和聚合資料，並將結果合併到統一的視圖中。這種機制在分段網路環境中特別有用，在這些環境中，某些子網路只能透過跳躍主機訪問，並且沒有直接路由可用。透過將代理程式鏈接在一起，系統可以橋接隔離的網路段，而無需變更現有的路由配置。

3.1.3 網路服務探測器

網路服務探測器在目標節點外部執行，並驗證網路上的服務可用性和正確性。這些探測器模擬真實的用戶端行為，並檢查服務是否可訪問、響應迅速且按預期運作。

這些探測器共同提供基礎架構健康狀況和應用程式層級服務可用性的全面涵蓋。

3.2 探測器代理程式模組設計

探測器代理程式負責根據客製化的配置檔案收集、排程和執行不同的探測器。每個代理程式可以監控單個節點或多個目標，具體取決於部署需求。整體工作流程如下圖所示。

探測器代理程式提供以下五個關鍵功能：

• 基於配置檔案的配置：使用者可以定義客製化的配置檔案來控制執行哪些探測器、它們的執行間隔以及它們的目標範圍，從而使監控行為易於適應不同的環境。

• 內部/外部探測：代理程式可以在關鍵節點內部執行以檢查本地系統狀態，也可以在外部執行以探測多個節點的服務介面。這允許靈活的部署，而無需在每個節點上都安裝代理程式。

• 自訂探測器外掛程式：系統提供擴展介面，供使用者插入自己的自訂探測器，用於應用程式特定的檢查（例如，驗證計費服務或競賽評分服務的狀態）。

• 資料中繼匯流排：為了避免變更叢集的原始網路路由，探測器代理程式還可以從其他可訪問的代理程式提取資料並充當中繼，從而在分段網路中形成資料收集鏈。

• 多種通訊協定：代理程式支援多種資料提取和報告協定（TCP、UDP、HTTP、HTTPS），以適應網路安全策略和流量限制，這些策略和限制在網路演練環境中很常見。

3.3 監控中心模組設計

監控中心是負責資料擷取、處理、分析和視覺化的中央元件。所有探測器代理程式都透過通訊管理器將其監控結果報告給中心。然後，中心儲存、處理資料，並透過基於 Web 的介面（目前使用 Grafana）將資料呈現給管理員。

除了即時儀表板外，監控中心還提供：

• 一個拓撲視圖，顯示叢集服務的線上/離線狀態，

• 以及一個擴展介面，用於整合自訂評分或評估函數，這在 CTF 或網路演練情境中特別有用。

資料流程架構如下圖所示：

系統中使用了兩個資料庫：

• 原始資訊資料庫：儲存從探測器代理程式收集的所有原始監控資料，用於稽核、分析和歷史參考。

• 狀態資料庫：儲存經過處理和聚合的資料，這些資料直接用於視覺化和狀態顯示。

Data Manager 元件從原始資訊資料庫檢索資料，執行處理和分析，應用使用者定義的評分函數，然後在狀態資料庫中插入或更新結果。這種分離確保了原始資料得到保留，同時保持視覺化層的快速，並專注於有意義的高層級指標。

4. Grafana 儀表板 UI 和 Telegram 警報

為了使監控資料可操作且易於理解，系統使用 Grafana 構建一組專用於不同操作視圖的儀表板。每個儀表板都專注於叢集的特定方面，例如整體服務健康狀況、實體伺服器效能、網路狀態或 CTF 挑戰環境。歷史資料和即時指標都會視覺化，使管理員能夠快速識別趨勢、異常和事件。

除了儀表板之外，系統還整合了 Telegram alert mechanism，以便在檢測到異常情況（例如，高延遲、服務停機或健康評分降低）時立即通知支援團隊。

4.1 叢集主要狀態檢視儀表板

以下儀表板是整個叢集的 overview page：

此主頁面提供高層級的操作快照，包括：

• 叢集網路拓撲以及每個受監控的實體伺服器/路由器或子叢集的服務健康狀態，

• 與受監控的服務總數相比，線上挑戰服務的數量，

• 挑戰 Docker 容器、Pod 和容器的目前健康評分，以及它們的歷史評分趨勢，

• 按服務類型分類的挑戰虛擬機器的服務健康百分比。

4.2 實體伺服器叢集監控儀表板

對於每個實體伺服器，點擊「Physical Cluster Monitor」連結將開啟一個詳細的效能儀表板。此頁面包含 22 個小圖表，排列成四列，如下所示：

• 第 1 列和第 2 列顯示實體伺服器的 CPU 和 RAM 使用百分比，

• 第 3 列和第 4 列顯示網路延遲和頻寬使用指標以及相關的網路效能指標。

4.3 叢集網路裝置和連線儀表板

為了實現網路層級的可見性，「Network Nodes Monitor Dashboard」提供了基礎架構流量和連線的重點檢視。如下所示：

它對於診斷競賽期間的網路瓶頸、錯誤配置或異常流量模式特別有用，它可以視覺化輸出和輸入網路連線以及防火牆流量流動狀態。

4.4 CTF 挑戰 VM 和 Docker 服務儀表板

Challenge VM and Docker Service Dashboard 專注於實際的競賽環境（VM、Container 和 Dockers），如下面的範例所示：

此儀表板通常由技術支援團隊使用，以快速確認特定挑戰環境是否正常執行或遇到服務降級。它顯示挑戰虛擬機器、Docker 容器和相關服務的執行時間狀態和健康狀況，以及服務可用性和穩定性指標。

4.5 Telegram 警報通知

除了視覺化儀表板之外，系統還透過 Telegram 提供即時警報。當指標超過配置的閾值時（例如，網路延遲超出可接受的限制，或服務變得不可用），系統會自動向競賽技術支援群組傳送警報訊息。以下顯示了一個警報訊息範例：

5. 系統部署和配置

在本節中，我將介紹如何在運算叢集環境中部署監控系統，包括代理程式安裝、Hub 配置、資料庫設定和 Grafana 儀表板整合。

步驟 1：準備每個受監控伺服器上的基礎架構

首先，確保每個受監控的伺服器都安裝了正確的時區、Python 環境和所需的相依性：

sudo timedatectl set-timezone Asia/Singapore
sudo apt update && sudo apt install python3 python3-pip -y
sudo pip3 install influxdb pythonping ntplib psutil --break-system-package

注意：根據您的作業系統和安全性原則調整時區和套件安裝方法。

步驟 2：在監控和受監控節點上部署代理程式

在每個受監控的伺服器（或指定的探測節點）上，複製專案並配置代理程式：

# On each monitored server
mkdir -p ~/monitorAgent
cd ~/monitorAgent
git clone https://github.com/LiuYuancheng/CISSRed_Cluster_Monitor.git
cd CISSRed_Cluster_Monitor/src/client/
# Configure agent
cp config.template.json config.json
vim config.json  # Edit configuration
# Start agent
sudo nohup python3 AgentRun.py > agent.log 2>&1 &

代理程式配置檔案的簡化範例如下所示：

{
  "agent": {
    "hostname": "server1",
    "collection_interval": 60,
    "http_port": 8080,
    "log_level": "INFO",
    "log_file": "/var/log/monitoring/agent.log"
  },
  "metrics": {
    "system": {
      "enabled": true,
      "collect_cpu": true,
      "collect_memory": true,
      "collect_disk": false
    },
    "network": {
      "enabled": true,
      "ping_targets": [
        "192.168.1.1",
        "192.168.1.254"
      ],
      "ping_count": 4,
      "ping_interval": 60
    }
  },
  "storage": {
    "local_cache_size": 1000,
    "cache_directory": "./metrics_cache"
  },
  "time": {
    "ntp_server": "pool.ntp.org",
    "sync_interval": 3600
  }
}

步驟 3：配置並啟動監控 Hub

在中央監控伺服器上，配置代理程式端點的清單：

# On central monitoring server
cd ~/monitorAgent/CISSRed_Cluster_Monitor/src/hub/
# Configure agent endpoints
vim agents.json
# Example agents.json
[
  {
    "hostname": "server1",
    "url": "http://xxx.xxx.xxx.xxx:8080",
    "tags": {
      "role": "compute",
      "location": "rack1"
    }
  },
  {
    "hostname": "server2",
    "url": "http://xxx.xxx.xxx.xxx:8080",
    "tags": {
      "role": "compute",
      "location": "rack1"
    }
  }
]
# Start monitor hub
python3 MonitorHub.py

步驟 4：安裝 InfluxDB 並驗證資料收集

安裝 InfluxDB_1.8.10 並建立所需的資料庫（例如，monitorDB）後，驗證資料是否正確寫入：

influx
USE monitorDB
SHOW MEASUREMENTS
SELECT * FROM system_metrics LIMIT 10

如果列出了測量值且查詢傳回資料，則從代理程式到資料庫的資料管道運作正常。

步驟 5：匯入 Grafana 儀表板並配置 InfluxDB 資料來源

1. 安裝 Grafana 並存取以下網頁介面：http://:3000

2. 使用管理員憑證登入。

3. 導覽至 Dashboards → Import，然後上傳儀表板 JSON 檔案（或使用儀表板 ID 匯入）：

前往 Settings → Data Sources，建立新的 InfluxDB 資料來源，然後填寫資料庫伺服器 IP 和憑證，如下所示：

驗證所有面板是否正確顯示資料。如果面板顯示 “No data”，如下所示：

檢查每個代理程式是否正在執行且可連線，驗證是否在面板設定中選取了正確的資料來源：

您也可以手動插入測試資料，以驗證 InfluxDB 和 Grafana 是否運作正常：

InfluxDB shell version: 1.8.10
> SHOW MEASUREMENTS ON monitorDB
> SHOW MEASUREMENTS ON gatewayDB
> USE monitorDB
Using database monitorDB
> SHOW MEASUREMENTS
> INSERT cpu,host=serverA value=10
> SHOW MEASUREMENTS

完成這些步驟後，叢集監控系統即可完全運作，並準備好為您的基礎架構提供即時可見性和警報。

如果您對使用該模組感興趣，可以參考以下儲存庫：

• https://github.com/LiuYuancheng/Cluster_Service_Health_Monitor
• https://github.com/LiuYuancheng/CISSRed_Cluster_Monitor

感謝您花時間查看文章詳細資訊，如果您有任何問題和建議或發現任何程式錯誤，請隨時給我留言。如果您能提供一些意見並分享任何改進建議，以便我們改進工作，將不勝感激～