SIEM/Log Management HỆ THỐNG GIÁM SÁT HẠ TẦNG ẢO HÓA: VSPHERE – TELEGRAF – PROMETHEUS

I. Các thành phần

• VMware vSphere (vCenter & ESXi): vSphere là nền tảng ảo hóa dùng để chia nhỏ các máy chủ vật lý cỡ lớn (gọi là ESXi Host) thành hàng chục, hàng trăm máy tính ảo chạy độc lập bên trong. Trung tâm điều khiển toàn bộ các máy chủ và máy ảo này được gọi là vCenter Server.
• Telegraf: Telegraf là một tác nhân thu thập dữ liệu (Server Agent) cực nhẹ, hoạt động theo kiến trúc Plugin. Nó có khả năng kết nối vào nhiều hệ thống khác nhau để lấy số liệu, chuyển đổi sang định dạng chuẩn và bày sẵn ra một cổng giao tiếp.
• Prometheus – "Trung tâm lưu trữ lịch sử và Phân tích dữ liệu": Prometheus là hệ thống giám sát và cơ sở dữ liệu chuỗi thời gian mã nguồn mở. Thay vì chờ các nơi gửi báo cáo về, Prometheus chủ động đi "cào" (Pull/Scrape) số liệu theo định kỳ, lưu trữ theo dòng thời gian và cung cấp ngôn ngữ truy vấn PromQL để vẽ biểu đồ, phân tích xu hướng và phát cảnh báo.

Hình 1: Mô hình kiến trúc kết nối giữa vSphere, Telegraf và Prometheus

II. Tại sao lại chọn bộ ba này và kết hợp chúng với nhau?​

1. Giải quyết bất đồng về giao thức (Tại sao Prometheus cần Telegraf?)​

• Prometheus chỉ thu thập dữ liệu bằng định dạng văn bản phẳng qua giao thức HTTP (Pull/Scrape).
• Ngược lại, vCenter (vSphere) là hệ thống đóng của VMware, chỉ cung cấp dữ liệu qua giao thức SOAP/SDK phức tạp và yêu cầu phiên đăng nhập bảo mật. Prometheus không thể tự mình đăng nhập vào vCenter để lấy dữ liệu.
• Telegraf xuất hiện làm "cầu nối trung gian": Đầu vào (inputs.vsphere) giao tiếp trực tiếp với vCenter SDK, còn đầu ra (outputs.prometheus_client) mở một endpoint HTTP nội bộ chuẩn xác để Prometheus đến kéo dữ liệu về.

2. Tại sao chọn Telegraf thay vì các công cụ khác (như vmware_exporter bằng Python)?​

• Hiệu năng vượt trội: Được viết bằng ngôn ngữ Go, Telegraf chạy dưới dạng một tiến trình duy nhất, tiêu tốn rất ít RAM/CPU và xử lý hàng chục nghìn chỉ số (metrics) mượt mà không bị nghẽn.
• Đa năng ("All-in-One"): Chỉ với một dịch vụ Telegraf cài trên máy chủ syslog, hệ thống vừa thu thập được chỉ số của chính máy chủ Linux đó (ổ cứng, RAM, CPU), vừa thu thập được toàn bộ cụm ảo hóa vCenter từ xa mà không cần cài đặt nhiều phần mềm rời rạc.

3. Tại sao dùng cơ chế Pull của Prometheus thay vì đẩy dữ liệu trực tiếp?​

• Chủ động kiểm soát tải: Giúp máy chủ giám sát tự chủ hoàn toàn tần suất lấy dữ liệu, tránh hiện tượng quá tải khi hạ tầng có biến động lớn.
• Dễ dàng khoanh vùng lỗi: Quản trị viên chỉ cần truy cập cổng :9273/metrics của Telegraf là xác định được ngay lỗi nằm ở khâu thu thập (vCenter -> Telegraf) hay khâu lưu trữ (Telegraf -> Prometheus).

III. CẤU HÌNH​

Hệ thống thực tế được triển khai trên máy chủ giám sát syslog (10.30.194.48) kết nối tới cụm ảo hóa vCenter (10.120.100.100) theo 4 giai đoạn nối tiếp nhau:

Bước 1: Kết nối Telegraf tới vCenter và tối ưu hóa truy vấn​

• Thiết lập kết nối an toàn: Sử dụng tài khoản phân quyền chỉ đọc (Read-only: test@vsphere.local) kết nối vào địa chỉ SDK 10.120.100.100/sdk nhằm đảm bảo an toàn cho hạ tầng ảo hóa.
• Xử lý giới hạn truy vấn (maxQueryMetrics): Mặc định, vCenter có cơ chế tự bảo vệ, từ chối các truy vấn lấy quá nhiều dữ liệu cùng lúc. Cấu hình Telegraf đã được tinh chỉnh để chỉ lọc lấy các chỉ số quan trọng của ESXi Host và VM, loại bỏ các đối tượng nặng chưa cần thiết (Cluster, Resource Pool) và giới hạn kích thước gói truy vấn (max_query_objects = 64, max_query_metrics = 64).

Hình 2: Trạng thái dịch vụ Telegraf đang hoạt động ổn định trên máy chủ giám sát (10.30.194.48)

Hình 3: Cấu hình plugin inputs.vsphere trong file telegraf.conf để kết nối và lọc chỉ số từ vCenter

Bước 2: Dữ liệu chuẩn Prometheus (​

• Cấu hình Telegraf mở một HTTP endpoint nội bộ tại cổng :9273 với đường dẫn /metrics.

Hình 4: Cấu hình plugin outputs.prometheus_client để mở cổng :9273/metrics

• Toàn bộ dữ liệu thô từ vCenter sau khi lấy về được Telegraf tự động chuẩn hóa thành tên metric có tiền tố vsphere_* kèm theo các nhãn định danh chi tiết (vcenter, dcname, esxhostname, vmname, dsname...).

Hình 5: Dữ liệu chỉ số được phơi bày dưới định dạng chuẩn Prometheus tại endpoint :9273/metrics

Bước 3: Cấu hình Prometheus Scrape Job và đồng bộ chu kỳ (​

• Khai báo job telegraf_vsphere trong file /etc/prometheus/prometheus.yml trỏ tới mục tiêu localhost:9273.
• Giải thích và tối ưu hóa Interval (Realtime vs. Historical metric):

• Realtime Metrics (VM và ESXi Host): vCenter cập nhật dữ liệu mới mỗi 20 giây, và Telegraf được cấu hình gom dữ liệu mỗi 60 giây (interval = "60s").
• Historical Metrics (Cluster, Datastore, Resource Pool): vCenter chỉ tổng hợp các chỉ số này mỗi 5 phút (300 giây) một lần.
• Thiết lập Interval tối ưu: Đặt scrape_interval: 60s cho job telegraf_vsphere trong Prometheus để khớp chính xác với chu kỳ thu thập của Telegraf (tránh để mặc định 15s khiến Prometheus cào trùng một giá trị cũ 4 lần liên tiếp gây lãng phí ổ cứng TSDB). Đồng thời, tăng expiration_interval = "120s" trong [[outputs.prometheus_client]] để dữ liệu không bị xóa khỏi bộ nhớ đệm trước khi Prometheus kịp cào tới.

Hình 6: Khai báo job telegraf_vsphere với scrape_interval 60s trong file prometheus.yml


Hình 7: Cấu hình outputs.prometheus_client để mở cổng 9273


Hình 8: Kết quả truy vấn {__name__=~"vsphere_.*"} trả về các chuỗi thời gian trên giao diện Prometheus UI

Bước 4: Truy vấn và Giám sát hạ tầng ESXi Host bằng PromQL​

• Kiểm tra trạng thái hoạt động (Power & Connection State): Sử dụng biểu thức vsphere_host_sys_uptime_latest > 0để xác nhận cả 5 máy chủ ESXi đều đang bật và kết nối

• Giám sát hiệu năng CPU (%): Câu lệnh avg by (esxhostname, source) (vsphere_host_cpu_usage_average) để theo dõi mức tải CPU thực tế của từng Host

• Giám sát hiệu năng RAM (%): Sử dụng chỉ số vsphere_host_mem_usage_average để theo dõi tỷ lệ bộ nhớ vật lý đang sử dụng trên từng ESXi Host.

​

IV. TRỰC QUAN HÓA BẰNG VEGA​

4.1. Cấu hình​

Mở rộng luồng xử lý của Vector theo mô hình 3 bước:

• Bước 1 – Source: Sử dụng thành phần prometheus_scrape để định kỳ kéo toàn bộ chỉ số của các ESXi Host từ cổng :9273/metrics của Telegraf với chu kỳ 60 giây
• Bước 2 – Transform: Do đầu vào prometheus_scrape sinh ra dữ liệu kiểu Metric trong khi đầu ra OpenSearch yêu cầu dữ liệu kiểu sự kiện (Log/Document JSON), bộ chuyển đổi metric_to_log được thiết lập để đóng gói các chỉ số vSphere thành các bản ghi JSON chuẩn (chứa trường tên chỉ số name, nhãn máy chủ tags.esxhostname và giá trị gauge.value)
• Bước 3 – Sink: Bổ sung đầu vào - convert_vsphere_to_log vào khối inputs của sink opensearch_output để ghi metric hạ tầng ESXi vào hệ thống Indexer

4.2. % CPU sử dụng trung bình của từng ESXi Host​

4.3. Biến động % RAM Usage theo thời gian​

4.4. Trạng thái Uptime của từng ESXi Host​