Posted inVMware

Cấu hình vSphere Alarms và Email Notification: Tự động cảnh báo SysAdmin khi CPU, RAM, Datastore ESXi vượt ngưỡng

VMware tutorial - IT technology blog
VMware tutorial - IT technology blog

Ba approach monitoring ESXi — và tại sao mình chọn native alarm trước

Hồi mới nhận quản lý cụm ESXi đầu tiên, mình từng bỏ qua phần Alarms vì nghĩ “tự động rồi chắc không cần setup thêm”. Kết quả là một sáng thứ Hai nhận điện thoại từ sếp thay vì email cảnh báo — datastore đã full từ đêm trước và 3 VM không thể ghi dữ liệu. Từ hôm đó mình không bao giờ xem mục Alarms là optional nữa.

Có ba cách phổ biến để theo dõi CPU/RAM/Datastore trên ESXi và nhận cảnh báo kịp thời:

Approach 1: vSphere Native Alarms (built-in vCenter)

Tích hợp sẵn trong vCenter Server, không cần cài thêm gì. Bạn định nghĩa condition, thiết lập action (gửi email, SNMP trap, chạy script), xong. Setup trong 15 phút.

Approach 2: Third-party Monitoring Stack (Zabbix / Prometheus)

Zabbix có sẵn VMware template, Prometheus dùng vmware_exporter để pull metrics. Dashboard trực quan hơn nhiều, alerting rule cũng linh hoạt hơn. Nhưng phải dựng thêm server monitoring riêng — và maintain nó song song với hệ thống ESXi hiện tại.

Approach 3: PowerCLI Script + Windows Task Scheduler

PowerCLI pull metrics định kỳ, so sánh threshold, gửi alert — email, Slack, Teams, hay bất cứ gì bạn muốn. Custom hoàn toàn. Cái giá phải trả: tự code từ đầu và tự maintain khi VMware ra API mới.

So sánh thực tế: chọn approach nào cho môi trường nào?

  • vSphere Native Alarms: Xong trong 15 phút, không cần bất kỳ server hay software nào thêm. Hợp với team dưới 20 host chưa có monitoring stack riêng. Điểm yếu: email thông báo plain text, không có dashboard, không lưu metrics dài hạn.
  • Zabbix / Prometheus: Dashboard trực quan, lưu metrics 6–12 tháng để phân tích trend, alerting rule linh hoạt tùy chỉnh được. Xứng đáng đầu tư cho production lớn. Nhưng phải cộng thêm 2–3 ngày setup ban đầu và cần người maintain song song.
  • PowerCLI Script: Muốn alert qua Slack, muốn format báo cáo theo ý mình — đây là con đường đó. Trade-off: phải biết PowerShell và tự update khi VMware thay đổi API.

Khi migrate từ VMware sang Proxmox cho lab cá nhân, mình nhận thấy nhiều điểm khác biệt thú vị — Proxmox có built-in alert system khá basic, không granular bằng vSphere Alarms. Bù lại Proxmox tích hợp tốt hơn với Grafana/Prometheus ngay từ đầu. Mỗi platform có trade-off riêng.

Lời khuyên thực tế: Với team mới và môi trường vừa, bắt đầu từ vSphere Native Alarms. Hoạt động ngay, không cần giải trình thêm với sếp tại sao lại cần một server Zabbix riêng. Sau này khi scale lên mới migrate sang stack monitoring chuyên biệt.

Setup vSphere Alarms thực tế — từ khai báo SMTP đến email đầu tiên trong inbox

Bước 1: Cấu hình SMTP cho vCenter

Alarm không thể gửi email nếu vCenter chưa biết dùng mail server nào. Đây là bước hay bị bỏ qua nhất — và là nguyên nhân số một khiến alarm trigger nhưng inbox vẫn im ắng.

Đăng nhập vSphere Client → click vCenter Server trong inventory → tab Configure → Settings → General → nút Edit. Cuộn xuống phần Mail:

  • SMTP Server: địa chỉ mail server (VD: smtp.gmail.com hoặc IP Exchange nội bộ)
  • SMTP Port: 587 cho TLS, 465 cho SSL, 25 cho relay không mã hóa
  • Sender account: email gửi đi, VD: [email protected]

Gmail cần thêm một bước: bật 2FA trước, rồi vào myaccount.google.com → Security → App Passwords để tạo mật khẩu riêng cho vCenter. Exchange nội bộ đơn giản hơn nhiều — nhập IP mail server và port relay là xong, không cần xác thực thêm.

Bước 2: Tạo Alarm cho CPU Usage của ESXi Host

Trong vSphere Client, chuyển sang tab Hosts and Clusters. Click chuột phải vào ESXi host (hoặc click vào Datacenter/Cluster để alarm áp dụng cho tất cả host bên trong) → Alarms → New Alarm Definition.

Tab General:

  • Alarm name: ESXi CPU Usage High
  • Monitor: chọn Host
  • Monitor for: chọn Specific conditions or state

Tab Triggers → click Add:

  • Trigger Type: Host CPU Usage (%)
  • Operator: Is Above
  • Warning (Yellow): 80
  • Critical (Red): 90
  • Tolerance: 5 (tránh flapping khi usage dao động quanh threshold)
  • Condition length: 5 minutes (chỉ trigger khi tình trạng kéo dài, không phải CPU spike 10 giây)

Tab Actions → click Add:

  • Action: Send a notification email
  • To: [email protected] (nên dùng shared mailbox, không phải email cá nhân)
  • Repeat this action: tick nếu muốn nhận reminder mỗi 30 phút khi vẫn đang trong tình trạng cảnh báo

Click OK để lưu.

Bước 3: Tạo Alarm cho RAM Usage

Quy trình tương tự CPU, chỉ thay trigger type và ngưỡng cảnh báo:

  • Alarm name: ESXi Memory Usage High
  • Trigger Type: Host Memory Usage (%)
  • Warning: 85% | Critical: 95%

RAM threshold thường đặt cao hơn CPU một bậc. ESXi có balloon driver và memory swap — host chạy 88% RAM vẫn ổn hơn nhiều so với CPU 88% kéo dài liên tục. Chỉ cần xem thêm balloon memory trong vSphere performance charts: nếu nó liên tục cao, 85% là ngưỡng hợp lý.

Bước 4: Tạo Alarm cho Datastore

Điểm khác biệt quan trọng: alarm datastore phải tạo trên object Datastore, không phải Host. Trong vSphere Client, chuyển sang tab Storage → click chuột phải vào Datastore → Alarms → New Alarm Definition:

  • Alarm name: Datastore Disk Usage High
  • Monitor: Datastore
  • Trigger Type: Datastore Disk Usage (%)
  • Warning: 75% | Critical: 85%

Datastore full là worst case không có recovery: VM đang ghi dữ liệu crash ngay, không có cơ chế tự phục hồi. Vì vậy threshold đặt thấp hơn CPU/RAM. Cảnh báo sớm ở 75% để có đủ thời gian dọn dẹp hoặc expand storage trước khi chạm mức 85% nguy hiểm.

Bước 5: Test trước khi để production chạy thật

Đừng chờ đến lúc có sự cố thật mới biết alarm có chạy không. Cách đơn giản nhất: hạ threshold xuống tạm thời để trigger alarm ngay.

Vào alarm vừa tạo → Edit → đổi Warning threshold = 10% → chờ 5–10 phút → kiểm tra email. Subject có dạng: [vCenter Alarm] ESXi CPU Usage High on esxi01 - Warning. Nhận được là SMTP và alarm đều ổn. Sau đó đổi lại threshold thật.

PowerCLI cũng dùng được để pull danh sách alarm đang active — hữu ích khi quản lý nhiều host:

# Kết nối vCenter
Connect-VIServer -Server vcenter.company.com -User [email protected] -Password "YourPassword"

# Xem tất cả alarm definitions đang enabled
Get-AlarmDefinition | Where-Object { $_.Enabled -eq $true } | Select-Object Name, Entity, Enabled | Format-Table -AutoSize

# Xem các alarm đang ở trạng thái Warning hoặc Critical
Get-VMHost | Get-AlarmAction | Where-Object { $_.Alarm.AlarmState -ne "Green" }

# Xem triggered alarms trên một host cụ thể
$vmhost = Get-VMHost "esxi01.company.com"
$alarmMgr = Get-View AlarmManager
$alarmMgr.GetAlarmState($vmhost.ExtensionData.MoRef) | Where-Object { $_.OverallStatus -ne "green" }

Bước 6: Fine-tune để tránh alert fatigue

Mình từng nhận 200+ email trong một ngày từ CPU alarm đặt ở 70% trên server production chạy thường xuyên ở 75–80%. Inbox ngập alarm, mình bắt đầu mark-as-read không đọc. Đó là failure mode tệ nhất: không phải thiếu monitoring, mà là nhiều quá đến mức không còn ai quan tâm.

Sau 1–2 tuần có dữ liệu thực tế, nên review lại:

  • Điều chỉnh threshold dựa trên baseline — nếu server thường chạy ở 75% CPU, đặt warning = 90% thay vì 80%
  • Dùng shared mailbox hoặc Slack/Teams channel cho alarm, không gửi thẳng vào email cá nhân
  • Cấu hình “green” action để nhận email khi vấn đề đã resolved — quan trọng để biết alarm đã tự clear hay chưa
  • Nhiều hơn 5 host: cân nhắc tạo alarm ở cấp Cluster hoặc Datacenter — config một lần, áp dụng cho tất cả host bên trong

Checklist trước khi go-live

  • SMTP đã cấu hình, đã nhận được ít nhất 1 test email
  • CPU alarm: Warning 80%, Critical 90%, Tolerance 5%, Condition length 5 phút
  • RAM alarm: Warning 85%, Critical 95%
  • Datastore alarm: Warning 75%, Critical 85% (tạo cho mỗi datastore riêng)
  • Email nhận cảnh báo là shared mailbox hoặc team channel
  • Đã cấu hình “green” action để biết khi vấn đề resolved
  • Threshold đã review dựa trên baseline thực tế sau 1 tuần quan sát

Share:
Tags: