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

[ Hướng Dẫn Thực Tế Lấy Cảm Hứng từ Dự Án CISS-Red_Cluster_Monitor ]

Mục Đích Thiết Kế Dự Án : Bài viết này hướng dẫn cách xây dựng một hệ thống giám sát cụm máy chủ/VM tự lưu trữ, gọn nhẹ, được xây dựng bằng Python, InfluxDB và Grafana, được thiết kế đặc biệt để xử lý các yêu cầu đặc biệt hoặc tùy chỉnh để giám sát các phòng lab bảo mật, môi trường CTF, mạng OT hoặc các cụm bị cô lập. Thay vì dựa vào một agent hộp đen, bạn sẽ xây dựng các trình thu thập dữ liệu tùy chỉnh của riêng mình và giám sát để lấy các số liệu chính xác từ các nguồn bạn cần—cho dù đó là IPMI, các đầu dò mạng hay các điểm cuối dành riêng cho ứng dụng—đẩy chúng vào cơ sở dữ liệu chuỗi thời gian cục bộ, an toàn và trực quan hóa dữ liệu bằng các dashboard tùy chỉnh.

Ví dụ thực tế trong bài viết này được lấy cảm hứng từ dự án CISS-Red_Cluster_Monitor, được phát triển để giám sát một cụm sandboxes (400+ VM) được sử dụng để hỗ trợ một cuộc thi CTF an ninh mạng red team. Để làm cho thiết kế rõ ràng và có thể tái tạo, bài viết được cấu trúc thành bốn phần chính:

• Ý Tưởng Thiết Kế Cốt Lõi – Kiến trúc hệ thống tổng thể, bao gồm mô hình agent/fetcher và luồng giao tiếp.

• Lựa Chọn Cấu Hình Bảo Mật – Cách hệ thống được thiết kế để ngăn người tham gia đảo ngược kỹ thuật các agent hoặc gửi các số liệu giả mạo.

• Ngăn Xếp Công Nghệ – Các công cụ được sử dụng (Python, InfluxDB, Grafana, v.v.) và cách cài đặt và cấu hình chúng.

• Dữ Liệu và Giao Diện Người Dùng – Cách dữ liệu được lưu trữ, trực quan hóa trong các dashboard và tóm tắt hoặc cảnh báo (ví dụ: thông qua Grafana và 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. Giới Thiệu

Có một số công cụ miễn phí hoặc thương mại trên thị trường để giám sát các máy chủ và cụm VM như PM2 có thể giám sát khối lượng công việc, độ trễ mạng và các dịch vụ đang chạy trong máy chủ vật lý, docker hoặc máy ảo với rất ít thiết lập. Nhưng đôi khi chúng ta có thể có một số yêu cầu đặc biệt hoặc tùy chỉnh như:

• Không thể cài đặt trực tiếp các agent trên một số thiết bị nhất định

• Cần thu thập dữ liệu đo từ xa về nguồn điện và phần cứng từ các nguồn như IPMI thay vì các agent cấp hệ điều hành

• Hệ thống phải chạy trong một môi trường hoàn toàn cục bộ / cách ly không có truy cập internet

• Cần trực quan hóa logic thu thập và xác thực dữ liệu tùy chỉnh.

Dựa trên các kịch bản và yêu cầu này, hệ thống giám sát phải đơn giản và đáng tin cậy dưới tải cạnh tranh, an toàn trước sự giả mạo hoặc tiêm dữ liệu giả, có thể triển khai trong một môi trường mạng hạn chế và dễ dàng cho các quản trị viên trực quan hóa và kiểm tra theo thời gian thực.

1.1 Bối Cảnh và Mục Tiêu Sử Dụng

Ví dụ: sự kiện CISS-Red Stage One CTF yêu cầu giám sát liên tục nhiều máy chủ vật lý và máy ảo trong khoảng thời gian 48 giờ để đảm bảo tính ổn định của cơ sở hạ tầng và cho phép ứng phó sự cố nhanh chóng. Mục tiêu giám sát là theo dõi các số liệu chính theo thời gian thực—bao gồm mức sử dụng CPU và bộ nhớ của máy chủ lưu trữ, độ trễ mạng, tính khả dụng của dịch vụ của các VM thử thách CTF và hoạt động đăng nhập SSH của người dùng—và trình bày tất cả thông tin này thông qua một dashboard tập trung, trực quan. Bất cứ khi nào một điều kiện bất thường được phát hiện, hệ thống sẽ tự động gửi thông báo cảnh báo đến các nhóm Telegram hỗ trợ và quản trị viên.

2. Kiến Trúc Hệ Thống

Hệ thống giám sát áp dụng kiến trúc agent dựa trên tìm nạp thông tin, trong đó một trung tâm giám sát trung tâm chủ động kéo dữ liệu từ các agent phân tán thay vì để các agent đẩy dữ liệu lên trên. Lựa chọn thiết kế này chủ yếu được thúc đẩy bởi các cân nhắc về bảo mật: trong môi trường CTF, những người tham gia có thể cố gắng đảo ngược kỹ thuật mã agent hoặc giả mạo các yêu cầu để tiêm các số liệu giả. Bằng cách giữ tất cả việc thu thập dữ liệu dưới sự kiểm soát của trung tâm trung tâm, bề mặt tấn công có thể xảy ra sẽ giảm đáng kể và việc gửi dữ liệu trái phép có thể được ngăn chặn hiệu quả.

Từ góc độ kiến trúc, hệ thống tuân theo một thiết kế ba tầng đơn giản như hình dưới đây:

┌──────────────┐         ┌──────────────┐         ┌──────────────┐
│  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) │
              └──────────────────────────────────────┘

• Lớp Agent – Một số agent Python gọn nhẹ được triển khai trên hoặc kết nối với các node được giám sát để thu thập các số liệu hệ thống và dịch vụ.

• Lớp Lưu Trữ – Một cơ sở dữ liệu chuỗi thời gian InfluxDB được sử dụng để lưu trữ và truy vấn dữ liệu giám sát một cách hiệu quả.

• Lớp Trực Quan Hóa – Một dashboard Grafana cung cấp trực quan hóa theo thời gian thực, phân tích lịch sử và tổng quan hoạt động của cụm và một trình gửi tin nhắn để gửi cảnh báo có thể có qua tin nhắn Telegram.

2.1 Chi Tiết Quy Trình Làm Việc của Hệ Thống

Quy trình làm việc tổng thể của hệ thống được hiển thị trong sơ đồ bên dưới:

Trong môi trường CISS-Red CTF, những người tham gia trước tiên SSH vào một cổng IP công cộng thông qua tường lửa và sau đó truy cập các máy ảo thử thách được chỉ định của họ. Mỗi máy chủ vật lý lưu trữ các VM thử thách hoặc các container Docker được trang bị hai giao diện mạng RJ45 được kết nối với hai mạng bị cô lập:

• Giao diện 1 (đường màu xanh lam trong sơ đồ) được sử dụng độc quyền cho lưu lượng truy cập của người tham gia để truy cập các dịch vụ thử thách.

• Giao diện 2 (đường màu cam trong sơ đồ) được dành riêng cho lưu lượng giám sát, cho phép các agent và hub giám sát thu thập dữ liệu hoạt động mà không can thiệp hoặc tiếp xúc với hoạt động của người tham gia CTF.

Cấu hình này đảm bảo rằng lưu lượng giám sát không ảnh hưởng đến hiệu suất hoặc tính công bằng của môi trường cạnh tranh. Từ quan điểm chức năng, hệ thống bao gồm ba thành phần chính:

• Kho Lưu Trữ Service Prober : Một thư viện kiểm tra dịch vụ python có thể tái sử dụng cung cấp nhiều chức năng thăm dò (ví dụ: NTP, FTP, VNC, SSH và kiểm tra dịch vụ tùy chỉnh). Các prober này được sử dụng để xác minh xem một node, dịch vụ, chương trình hoặc chức năng cụ thể trong cụm có hoạt động chính xác hay không.

• Prober Agent : Một agent gọn nhẹ chịu trách nhiệm lên lịch và thực hiện các prober khác nhau để đánh giá tính khả dụng và tình trạng của một hoặc nhiều mục tiêu trong cụm. Agent có thể chạy cục bộ trên một máy chủ để thu thập các số liệu trực tiếp. Đối với các node mà agent không thể được cài đặt, hệ thống quay lại thực thi lệnh dựa trên SSH để truy xuất dữ liệu cần thiết từ xa.

• Monitor Hub : Thành phần giám sát và phân tích trung tâm, cung cấp một backend cơ sở dữ liệu (InfluxDB) để lưu trữ các số liệu chuỗi thời gian, một dashboard dựa trên web (Grafana) để trực quan hóa theo thời gian thực và lịch sử, và các giao diện có thể mở rộng để tích hợp logic tùy chỉnh, chẳng hạn như các công thức tính điểm hoặc các hàm đánh giá dành riêng cho cuộc thi.

2.2 Ngăn Xếp Công Nghệ

Thư viện và các công cụ được sử dụng trong dự án này và liên kết liên quan được hiển thị trong bảng dưới đây:

3. Thiết Kế Các Mô-đun Hệ Thống

Phần này mô tả thiết kế chi tiết của ba thành phần cốt lõi của hệ thống giám sát: Kho Lưu Trữ Service Prober, Prober Agent và Monitor Hub.

3.1 Thiết Kế Kho Lưu Trữ Service Prober

Kho Lưu Trữ Service Prober là một thư viện thăm dò python có thể tái sử dụng, cung cấp một loạt các chức năng để kiểm tra trạng thái của các dịch vụ, chương trình và tài nguyên hệ thống sau đó cắm vào agent thăm dò. Tất cả các chức năng thăm dò được thiết kế như các thành phần mô-đun và có thể được nhóm thành ba loại: local service probers, child agent probers và network service probers.

3.1.1 Local Service Probers

Local service probers chạy trực tiếp trên các node mục tiêu và tập trung vào việc giám sát trạng thái bên trong của node, bao gồm:

• Mức sử dụng tài nguyên hệ thống (CPU, bộ nhớ, đĩa, I/O mạng),

• Các hoạt động của người dùng (phiên đăng nhập, thực thi lệnh, thay đổi hệ thống tệp),

• Trạng thái chương trình và quy trình cục bộ (vòng đời quy trình, cổng dịch vụ, trạng thái nhật ký).

Các prober cục bộ chính được tóm tắt dưới đây:

3.1.2 Child Agent Prober

Child Agent Prober được sử dụng để tìm nạp và tổng hợp dữ liệu từ các agent thăm dò khác và hợp nhất các kết quả thành một chế độ xem thống nhất. Cơ chế này đặc biệt hữu ích trong các môi trường mạng phân đoạn, nơi một số mạng con chỉ có thể truy cập thông qua một jump host và không có định tuyến trực tiếp nào khả dụng. Bằng cách xâu chuỗi các agent lại với nhau, hệ thống có thể bắc cầu các phân đoạn mạng bị cô lập mà không thay đổi cấu hình định tuyến hiện có.

3.1.3 Network Service Probers

Network service probers chạy bên ngoài các node mục tiêu và xác minh tính khả dụng và tính chính xác của dịch vụ qua mạng. Các prober này mô phỏng hành vi của máy khách thực và kiểm tra xem các dịch vụ có thể truy cập, phản hồi và hoạt động như mong đợi hay không.

Các prober này cùng nhau cung cấp phạm vi bảo hiểm toàn diện về cả tình trạng cơ sở hạ tầng và tính khả dụng của dịch vụ cấp ứng dụng.

3.2 Thiết Kế Mô-đun Prober Agent

Prober Agent chịu trách nhiệm thu thập, lên lịch và thực hiện các prober khác nhau dựa trên một cấu hình tùy chỉnh. Mỗi agent có thể giám sát một node duy nhất hoặc nhiều mục tiêu, tùy thuộc vào nhu cầu triển khai. Quy trình làm việc tổng thể được hiển thị trong sơ đồ bên dưới.

Prober agent cung cấp năm tính năng chính sau:

• Cấu Hình Dựa Trên Hồ Sơ : Người dùng có thể xác định các hồ sơ tùy chỉnh để kiểm soát prober nào chạy, khoảng thời gian thực hiện của chúng và phạm vi mục tiêu của chúng, giúp hành vi giám sát dễ dàng thích ứng với các môi trường khác nhau.

• Thăm Dò Bên Trong/Bên Ngoài : Agent có thể chạy bên trong các node quan trọng để kiểm tra trạng thái hệ thống cục bộ hoặc bên ngoài để thăm dò các giao diện dịch vụ của nhiều node. Điều này cho phép triển khai linh hoạt mà không yêu cầu một agent trên mọi node.

• Các Plugin Prober Tùy Chỉnh : Hệ thống cung cấp các giao diện mở rộng để người dùng cắm các prober tùy chỉnh của riêng họ để kiểm tra dành riêng cho ứng dụng (ví dụ: xác minh trạng thái của dịch vụ thanh toán hoặc dịch vụ tính điểm cạnh tranh).

• Data Relay Bus : Để tránh thay đổi định tuyến mạng ban đầu của một cụm, một prober agent cũng có thể tìm nạp dữ liệu từ các agent có thể truy cập khác và hoạt động như một rơle, tạo thành một chuỗi thu thập dữ liệu trên các mạng phân đoạn.

• Nhiều Giao Thức Giao Tiếp : Agent hỗ trợ nhiều giao thức tìm nạp và báo cáo dữ liệu (TCP, UDP, HTTP, HTTPS) để thích ứng với các chính sách bảo mật mạng khác nhau và các hạn chế lưu lượng thường thấy trong môi trường diễn tập trên mạng.

3.3 Thiết Kế Mô-đun Monitor Hub

Monitor Hub là thành phần trung tâm chịu trách nhiệm thu thập, xử lý, phân tích và trực quan hóa dữ liệu. Tất cả các agent thăm dò báo cáo kết quả giám sát của họ cho hub thông qua một trình quản lý giao tiếp. Sau đó, hub lưu trữ, xử lý và trình bày dữ liệu cho các quản trị viên thông qua một giao diện dựa trên web (hiện đang sử dụng Grafana).

Ngoài các dashboard theo thời gian thực, Monitor Hub còn cung cấp:

• Chế độ xem cấu trúc liên kết hiển thị trạng thái trực tuyến/ngoại tuyến của các dịch vụ cụm,

• Và một giao diện mở rộng để tích hợp các chức năng tính điểm hoặc đánh giá tùy chỉnh, đặc biệt hữu ích trong các kịch bản CTF hoặc diễn tập trên mạng.

Kiến trúc luồng dữ liệu được minh họa dưới đây:

Hai cơ sở dữ liệu được sử dụng trong hệ thống:

• Raw Info Database : Lưu trữ tất cả dữ liệu giám sát thô được thu thập từ các agent thăm dò để kiểm tra, phân tích và tham khảo lịch sử.

• State Database : Lưu trữ dữ liệu đã xử lý và tổng hợp được sử dụng trực tiếp để trực quan hóa và hiển thị trạng thái.

Thành phần Data Manager truy xuất dữ liệu từ Raw Info Database, thực hiện xử lý và phân tích, áp dụng các hàm chấm điểm do người dùng xác định, sau đó chèn hoặc cập nhật kết quả vào State Database. Sự phân tách này đảm bảo rằng dữ liệu thô được bảo toàn trong khi vẫn giữ cho lớp trực quan hóa nhanh chóng và tập trung vào các số liệu có ý nghĩa, cấp cao.

4. Giao diện Grafana Dashboard UI và Cảnh báo Telegram

Để làm cho dữ liệu giám sát trở nên hữu ích và dễ hiểu, hệ thống sử dụng Grafana để xây dựng một bộ dashboard chuyên dụng cho các chế độ xem hoạt động khác nhau. Mỗi dashboard tập trung vào một khía cạnh cụ thể của cluster, chẳng hạn như tình trạng dịch vụ tổng thể, hiệu suất máy chủ vật lý, trạng thái mạng hoặc môi trường thử thách CTF. Dữ liệu lịch sử và số liệu thời gian thực đều được trực quan hóa, cho phép quản trị viên nhanh chóng xác định xu hướng, điểm bất thường và sự cố.

Ngoài dashboard, hệ thống tích hợp cơ chế cảnh báo Telegram để thông báo cho nhóm hỗ trợ ngay lập tức khi phát hiện thấy các điều kiện bất thường (ví dụ: độ trễ cao, thời gian ngừng hoạt động của dịch vụ hoặc điểm số sức khỏe bị giảm).

4.1 Dashboard Xem Trạng thái Chính của Cluster

Dashboard bên dưới đóng vai trò là trang tổng quan của toàn bộ cluster:

Trang chính này cung cấp ảnh chụp nhanh hoạt động cấp cao, bao gồm:

• Cấu trúc liên kết mạng cluster và trạng thái sức khỏe dịch vụ của từng máy chủ/router vật lý hoặc sub-cluster được giám sát,

• Số lượng dịch vụ thử thách trực tuyến so với tổng số dịch vụ được giám sát,

• Điểm sức khỏe hiện tại của các container, pod và Docker container thử thách, cùng với xu hướng điểm số lịch sử của chúng,

• Phần trăm sức khỏe dịch vụ của máy ảo thử thách, được phân loại theo loại dịch vụ.

4.2 Dashboard Giám sát Cluster Máy chủ Vật lý

Đối với mỗi máy chủ vật lý, việc nhấp vào liên kết “Physical Cluster Monitor” sẽ mở ra một dashboard hiệu suất chi tiết. Trang này chứa 22 biểu đồ nhỏ được sắp xếp thành bốn cột như hình bên dưới:

• Cột 1 và 2 hiển thị phần trăm sử dụng CPU và RAM của máy chủ vật lý,

• Cột 3 và 4 hiển thị số liệu độ trễ mạng và mức sử dụng băng thông cũng như các chỉ số hiệu suất mạng liên quan.

4.3 Dashboard Thiết bị và Kết nối Mạng Cluster

Để có khả năng hiển thị ở cấp độ mạng, “Network Nodes Monitor Dashboard” cung cấp chế độ xem tập trung vào lưu lượng truy cập và kết nối cơ sở hạ tầng. Như hình bên dưới:

Nó đặc biệt hữu ích để chẩn đoán các tắc nghẽn mạng, cấu hình sai hoặc các mẫu lưu lượng truy cập bất thường trong cuộc thi bằng cách trực quan hóa các kết nối mạng đi và đến cũng như trạng thái luồng lưu lượng tường lửa.

4.4 Dashboard Dịch vụ VM và Docker Thử thách CTF

Challenge VM and Docker Service Dashboard tập trung vào môi trường cạnh tranh thực tế (VM, Container và Docker) như ví dụ dưới đây:

Dashboard này thường được nhóm hỗ trợ kỹ thuật sử dụng để nhanh chóng xác nhận xem một môi trường thử thách cụ thể có đang chạy chính xác hay đang gặp phải tình trạng suy giảm dịch vụ hay không. Nó hiển thị trạng thái thời gian chạy và sức khỏe của máy ảo Challenge, Docker container và các dịch vụ liên quan cũng như các chỉ số về tính khả dụng và ổn định của dịch vụ.

4.5 Thông báo Cảnh báo Telegram

Ngoài dashboard trực quan, hệ thống còn cung cấp cảnh báo theo thời gian thực qua Telegram. Khi một số liệu vượt quá ngưỡng đã định cấu hình (ví dụ: độ trễ mạng vượt quá giới hạn chấp nhận được hoặc dịch vụ không khả dụng), hệ thống sẽ tự động gửi tin nhắn cảnh báo đến nhóm hỗ trợ kỹ thuật cuộc thi. Một tin nhắn cảnh báo mẫu được hiển thị bên dưới:

5. Triển khai và Cấu hình Hệ thống

Trong phần này, tôi sẽ giới thiệu cách triển khai hệ thống giám sát trong môi trường cluster điện toán, bao gồm cài đặt agent, cấu hình hub, thiết lập database và tích hợp dashboard Grafana.

Bước 1: Chuẩn bị Cơ sở hạ tầng trên Mỗi Máy chủ Được giám sát

Đầu tiên, hãy đảm bảo rằng mỗi máy chủ được giám sát đã cài đặt đúng múi giờ, môi trường Python và các dependency cần thiết:

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

Lưu ý: Điều chỉnh múi giờ và phương pháp cài đặt package theo OS và chính sách bảo mật của bạn.

Bước 2: Triển khai Agent trên các Node Giám sát và Được giám sát

Trên mỗi máy chủ được giám sát (hoặc trên các node thăm dò được chỉ định), hãy clone project và cấu hình agent:

# 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 &

Một ví dụ đơn giản về tệp cấu hình agent được hiển thị bên dưới:

{
  "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
  }
}

Bước 3: Cấu hình và Khởi động Monitor Hub

Trên máy chủ giám sát trung tâm, hãy cấu hình danh sách các endpoint agent:

# 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

Bước 4: Cài đặt InfluxDB và Xác minh Thu thập Dữ liệu

Sau khi cài đặt InfluxDB_1.8.10 và tạo database cần thiết (ví dụ: monitorDB), hãy xác minh rằng dữ liệu đang được ghi chính xác:

influx
USE monitorDB
SHOW MEASUREMENTS
SELECT * FROM system_metrics LIMIT 10

Nếu các measurement được liệt kê và các truy vấn trả về dữ liệu, thì pipeline dữ liệu từ agent đến database đang hoạt động chính xác.

Bước 5: Nhập Dashboard Grafana và Cấu hình Nguồn Dữ liệu InfluxDB

1. Cài đặt Grafana và truy cập giao diện web tại:http://:3000

2. Đăng nhập bằng thông tin đăng nhập quản trị viên.

3. Điều hướng đến Dashboards → Import, sau đó tải lên tệp JSON dashboard (hoặc nhập bằng ID Dashboard):

Chuyển đến Settings → Data Sources, tạo một nguồn dữ liệu InfluxDB mới và điền IP máy chủ database và thông tin đăng nhập như hình bên dưới:

Xác minh rằng tất cả các panel hiển thị dữ liệu chính xác. Nếu một panel hiển thị “No data” như bên dưới:

Kiểm tra xem mỗi agent có đang chạy và có thể truy cập được hay không, xác minh rằng nguồn dữ liệu chính xác được chọn trong cài đặt panel:

Bạn cũng có thể chèn dữ liệu thử nghiệm theo cách thủ công để xác minh rằng InfluxDB và Grafana đang hoạt động chính xác:

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

Sau khi hoàn thành các bước này, hệ thống giám sát cluster sẽ hoạt động đầy đủ và sẵn sàng cung cấp khả năng hiển thị và cảnh báo theo thời gian thực cho cơ sở hạ tầng của bạn.

Nếu bạn quan tâm đến việc sử dụng module, bạn có thể tham khảo các repo bên dưới:

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

Cảm ơn bạn đã dành thời gian xem chi tiết bài viết, nếu bạn có bất kỳ câu hỏi và đề xuất nào hoặc tìm thấy bất kỳ lỗi chương trình nào, vui lòng nhắn tin cho tôi. Rất cảm ơn nếu bạn có thể đưa ra một số nhận xét và chia sẻ bất kỳ lời khuyên cải thiện nào để chúng tôi có thể làm cho công việc của mình tốt hơn ~