Nỗi lo mang tên “Check Log” sáng thứ Hai
Hồi mới vào nghề quản trị VMware, mình từng “ăn hành” vì một kịch bản kinh điển: Sáng thứ Hai vừa mở máy tính, sếp đã đứng chờ sẵn hỏi: “Tại sao con VM Database sập từ 2 giờ sáng chủ nhật mà không ai hay biết?”.
Lúc đó, mình chỉ biết cuống cuồng mở vCenter, bới trong đống Tasks & Events lộn xộn để tìm nguyên nhân. Hóa ra một snapshot cũ bị quên lãng đã phình to tới hơn 200GB, làm tràn Datastore. Vấn đề là vCenter biết rõ sự cố này, nó ghi log hẳn hoi nhưng lại… im lặng. Nó không gõ cửa báo cho mình mà đợi mình tự đi tìm.
Nếu bạn đang quản lý hạ tầng vSphere và mệt mỏi vì phải làm mọi thứ bằng tay, bài viết này là giải pháp cho bạn. Đừng đợi đến khi người dùng cuối gọi điện phàn nàn mới bắt đầu đi sửa lỗi.
Tại sao cơ chế báo động của vCenter lại chưa đủ tốt?
Thực tế, vCenter Server là một kho dữ liệu sự kiện khổng lồ. Mọi hành động từ bật/tắt VM, vMotion cho đến lỗi phần cứng đều được ghi lại chi tiết. Tuy nhiên, cơ chế Alarms mặc định của VMware đã khá lỗi thời.
Bạn có thể gửi Email, nhưng hiếm ai ngồi canh Inbox 24/7. Cấu hình SNMP Trap thì lại là một “cơn ác mộng” với những người không chuyên về Network. Vấn đề cốt lõi là vCenter không được thiết kế theo kiến trúc Event-Driven (hướng sự kiện) hiện đại.
Nó giống như một cuốn nhật ký thụ động. Ai muốn biết gì thì phải tự mở ra đọc, chứ nó không tự động thông báo cho các ứng dụng khác khi có biến cố xảy ra.
Điểm yếu của các cách giải quyết truyền thống
Trước khi tìm thấy giải pháp tối ưu, mình đã thử qua nhiều phương án nhưng đều có lỗ hổng:
- vCenter Alarms (Email): Thông báo chậm, dễ bị rơi vào hòm thư rác và cực kỳ khó tùy biến nội dung.
- PowerCLI Scripting: Mình từng viết script chạy cron job để quét log 5 phút/lần. Kết quả là hệ thống vẫn có độ trễ, còn CPU của vCenter thì luôn trong tình trạng quá tải vì phải xử lý query liên tục.
- vRealize Operations (vROps): Công cụ này rất mạnh nhưng chi phí bản quyền lên tới hàng nghìn USD. Việc cấu hình cũng phức tạp đến mức bạn cần một khóa học chuyên biệt mới sử dụng thạo được.
VEBA: “Người phiên dịch” thông minh cho VMware
Trong một lần mày mò tối ưu hệ thống Lab, mình phát hiện ra VMware Event Broker Appliance (VEBA). Đây là dự án mã nguồn mở được phát triển bởi chính các kỹ sư hàng đầu tại VMware.
VEBA đóng vai trò trung gian giữa vCenter và các ứng dụng bên ngoài. Khi vCenter phát sinh bất kỳ sự kiện nào, VEBA sẽ bắt lấy ngay lập tức và kích hoạt một hàm (Function) để xử lý. Bạn có thể ra lệnh cho nó: “Nếu thấy VM bị tắt đột ngột, hãy nhắn tin vào Telegram cho tôi ngay lập tức!”.
Cơ chế vận hành
VEBA tận dụng sức mạnh của Knative hoặc OpenFaaS để chạy các Serverless Functions. Bạn không cần quản lý server phức tạp. Chỉ cần đẩy code (Python, PowerShell, Go…) lên và nó sẽ tự động thực thi khi có event tương ứng được kích hoạt.
Các bước triển khai cảnh báo Telegram tự động
Dưới đây là hướng dẫn thiết lập hệ thống: Khi có ai đó xóa một máy ảo (VM Removed), Telegram sẽ gửi cảnh báo tức thì cho nhóm quản trị.
Bước 1: Khởi tạo Telegram Bot
- Chat với @BotFather trên Telegram, gõ lệnh
/newbotđể tạo bot. - Lưu lại API Token được cấp.
- Gửi một tin nhắn bất kỳ cho bot, sau đó truy cập URL này để lấy
chat_id:https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates
Bước 2: Triển khai VEBA Appliance
Tải file OVA từ trang chủ vmware.github.io/event-broker-appliance. Khi import vào vCenter, bạn cần lưu ý các thông số quan trọng:
- vCenter Server: Địa chỉ IP hoặc FQDN của vCenter.
- vCenter User: Tài khoản có quyền tối thiểu là Read-only đối với Events.
- Provider: Hãy chọn
knativeđể đạt độ ổn định cao nhất.
Bước 3: Viết Function xử lý bằng Python
Đoạn code dưới đây sẽ nhận dữ liệu từ VEBA và chuyển tiếp thành tin nhắn Telegram sinh động:
import requests
import os
def handler(context, event):
# Lấy thông tin chi tiết từ sự kiện vCenter
data = event.data
vm_name = data.get('Vm', {}).get('Name', 'N/A')
user = data.get('UserName', 'N/A')
msg = f"⚠️ CẢNH BÁO: Máy ảo {vm_name} vừa bị xóa bởi user {user}!"
token = os.getenv('TELEGRAM_TOKEN')
chat_id = os.getenv('TELEGRAM_CHAT_ID')
url = f"https://api.telegram.org/bot{token}/sendMessage"
requests.post(url, data={"chat_id": chat_id, "text": msg})
return "OK", 200
Bước 4: Cấu hình Map sự kiện (stack.yaml)
Bạn cần một file cấu hình để định nghĩa khi nào thì chạy code. Ở đây, chúng ta nhắm vào sự kiện VmRemovedEvent.
functions:
telegram-notifier:
runtime: python3
handler: handler
image: your-docker-hub/telegram-notifier:v1
environment:
TELEGRAM_TOKEN: "secret_token_here"
TELEGRAM_CHAT_ID: "your_id"
annotations:
topic: "com.vmware.vsphere.VmRemovedEvent"
Dùng lệnh kn service apply để kích hoạt. Từ giờ, chỉ cần một con VM bị xóa, điện thoại bạn sẽ rung báo động ngay lập tức.
Lưu ý thực tế để tránh “spam” thông báo
Sau một thời gian vận hành VEBA cho hệ thống hơn 100 Host, mình rút ra vài kinh nghiệm sau:
- Lọc sự kiện thông minh: Đừng bắt mọi event! Một hệ thống lớn có thể sinh ra 10.000 event mỗi giờ. Nếu bạn bắt cả log đăng nhập, bot Telegram sẽ bị treo vì spam. Chỉ tập trung vào các lỗi Critical như
VmPoweredOffEventhoặc lỗi Datastore. - Bảo mật thông tin: Không bao giờ để Token Telegram trực tiếp trong code. Hãy sử dụng Kubernetes Secrets tích hợp sẵn trong VEBA để lưu trữ an toàn.
- Phân loại theo Tag: Kết hợp với vSphere Tags là một mẹo cực hay. Bạn có thể lập trình để chỉ gửi cảnh báo với những VM có tag “Production”, còn máy ảo “Test” thì chỉ cần ghi log im lặng.
Lời kết
Nhiệm vụ của một kỹ sư IT không phải là ngồi canh màn hình log. Chúng ta nên tập trung xây dựng những hệ thống tự vận hành. VEBA chính là mảnh ghép giúp hạ tầng VMware trở nên chủ động và thông minh hơn.
Từ ngày có VEBA, mình không còn lo lắng mỗi sáng thứ Hai. Thậm chí, mình đã mở rộng hệ thống để tự động mở ticket trên Jira khi phát hiện lỗi phần cứng. Nếu bạn đang quản lý vSphere, hãy thử cài đặt VEBA ngay hôm nay để giải phóng sức lao động của chính mình!

