Module 29: Alerting trên Azure | AZ-104

Lý Thuyết Cốt Lõi

1. Tổng Quan Azure Monitor Alerts

Azure Monitor Alerts chủ động thông báo khi điều kiện quan trọng xảy ra trong tài nguyên Azure. Mỗi alert rule gồm 3 phần: Condition (khi nào kích hoạt), Action Group (làm gì khi kích hoạt), và Alert Details (tên, severity, mô tả).

Metric Alert

Kích hoạt khi metric value vượt ngưỡng (CPU > 80%, Memory < 10%)

Log Alert

Kích hoạt khi KQL query trên Log Analytics trả về số hàng vượt ngưỡng

Activity Log Alert

Kích hoạt khi có event cụ thể trong Activity Log (xóa VM, tắt service health)

Alert Severity	Mức độ	Ví dụ điển hình
Sev 0 — Critical	Ảnh hưởng ngay lập tức đến service	VM bị tắt đột ngột, database unreachable
Sev 1 — Error	Lỗi cần xử lý trong vài giờ	CPU > 95% kéo dài, disk full > 90%
Sev 2 — Warning	Cần chú ý nhưng chưa khẩn cấp	CPU > 80%, response time tăng
Sev 3 — Informational	Thông tin tham khảo	Scale-out event, backup completed
Sev 4 — Verbose	Debug / diagnostic	Configuration change logged

2. Ba Loại Alert — Cấu Hình Chi Tiết

Metric Alerts

Metric alerts evaluate một metric theo chu kỳ (evaluation frequency: 1/5/15/30 phút). Khi metric vi phạm condition trong cửa sổ thời gian (aggregation granularity), alert fires.

Static Threshold

So sánh metric với giá trị cố định. VD: CPU > 80% trong 5 phút. Đơn giản, phù hợp ngưỡng rõ ràng.

Dynamic Threshold

Azure ML tự động tính ngưỡng dựa theo lịch sử. Phù hợp traffic có pattern (cao ban ngày, thấp ban đêm). Sensitivity: Low/Medium/High.

Log Search Alerts

Log alerts chạy KQL query định kỳ trên Log Analytics Workspace. Alert fires khi số rows kết quả vượt ngưỡng hoặc một giá trị đo được (metric measure) đạt điều kiện.

KQL query mẫu — phát hiện login thất bại nhiều lần:

SecurityEvent
| where EventID == 4625  // Failed logon
| where TimeGenerated > ago(15m)
| summarize FailedAttempts = count() by Computer, Account
| where FailedAttempts > 5

Alert condition: Number of results > 0 trong 15 phút. Severity 1. Action: email + Teams webhook.

Activity Log Alerts

Activity log alerts kích hoạt khi event cụ thể xuất hiện trong Activity Log. Không dựa theo ngưỡng số — mà dựa theo event pattern match (operation name, status, resource type).

Administrative Events

• "Alert khi ai đó xóa VM production"
• "Alert khi NSG rule bị thay đổi"
• "Alert khi tạo Public IP address mới"

Service Health Events

• "Alert khi Azure region southeastasia có incident"
• "Alert khi có planned maintenance tác động VM"
• "Alert khi service degradation ảnh hưởng subscription"

3. Action Groups & Alert Processing Rules

Action Group là tập hợp các hành động được thực hiện khi alert fires. Nhiều alert rules có thể share cùng Action Group. Alert Processing Rules cho phép suppression (im lặng trong giờ bảo trì) hoặc thêm Action Groups vào alerts theo filter.

Các loại Action trong Action Group

Email/SMS/Push/Voice: thông báo tới on-call engineer qua nhiều kênh
Webhook: gọi HTTP endpoint — tích hợp PagerDuty, OpsGenie, Teams
Azure Function: chạy custom logic (tự restart VM, scale out)
Automation Runbook: chạy PowerShell runbook trong Azure Automation
ITSM: tạo ticket trong ServiceNow, Jira Service Management
Logic App: workflow phức tạp multi-step tự động

Alert Processing Rules

Alert Processing Rules (trước đây gọi là Action Rules) áp dụng thay đổi lên fired alerts — KHÔNG phải lên alert rules.

• Suppression: tắt notification trong khoảng thời gian bảo trì. VD: thứ 7 23:00–03:00 chủ nhật không gửi alert
• Action Group Override: thêm Action Group vào tất cả alerts match filter. VD: mọi Sev 0 alert đều notify CTO
• Scope có thể là Resource, Resource Group, hoặc Subscription
• Schedule: one-time hoặc recurring (weekly, daily)

Best Practice — Alert Fatigue: Không tạo quá nhiều alerts. Dùng Alert Processing Rules để suppress alerts không quan trọng trong giờ thấp điểm. Nhóm alerts liên quan vào cùng Action Group. Dùng Dynamic Threshold thay Static để giảm false positives.

Bài Tập Thực Hành (Lab)

Lab 29-A: Action Group Lab 29-B: Metric Alert Lab 29-C: Log Alert Lab 29-D: Activity Log Alert

Tạo Resource Group, Log Analytics Workspace và Action Group

Azure CLI— Cloud Shell hoặc terminal đã login az

# Tạo Resource Group
az group create \
  --name rg-az104-m29 \
  --location southeastasia \
  --tags Course=AZ-104 Module=29 Environment=Lab

# Tạo Log Analytics Workspace
az monitor log-analytics workspace create \
  --resource-group rg-az104-m29 \
  --workspace-name law-az104-m29 \
  --location southeastasia \
  --sku PerGB2018 \
  --retention-time 30

# Tạo VM để tạo tải CPU
az vm create \
  --resource-group rg-az104-m29 \
  --name vm-alert-lab29 \
  --image Ubuntu2204 \
  --size Standard_B1s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --location southeastasia

VM_ID=$(az vm show \
  --resource-group rg-az104-m29 \
  --name vm-alert-lab29 \
  --query id -o tsv)

# Tạo Action Group — gửi email khi alert fires
# Thay YOUR_EMAIL bằng email thực của bạn
az monitor action-group create \
  --name "ag-az104-m29-ops" \
  --resource-group rg-az104-m29 \
  --short-name "OpsTeam" \
  --action email admin-email [email protected]

echo "Action Group tạo thành công."
echo "VM ID: $VM_ID"

Verify Portal: Azure Portal → Monitor → Action groups → xác nhận "ag-az104-m29-ops" xuất hiện với email receiver. Vào VM vm-alert-lab29 → xác nhận running.

Tạo Metric Alert — CPU Percentage vượt 80%

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

VM_ID=$(az vm show \
  --resource-group rg-az104-m29 \
  --name vm-alert-lab29 \
  --query id -o tsv)

AG_ID=$(az monitor action-group show \
  --name "ag-az104-m29-ops" \
  --resource-group rg-az104-m29 \
  --query id -o tsv)

# Tạo Metric Alert — CPU > 80% trong 5 phút
az monitor metrics alert create \
  --name "alert-cpu-high-vm-lab29" \
  --resource-group rg-az104-m29 \
  --scopes "$VM_ID" \
  --condition "avg Percentage CPU > 80" \
  --window-size 5m \
  --evaluation-frequency 1m \
  --severity 2 \
  --description "CPU vượt 80% trong 5 phút — cần kiểm tra VM" \
  --action "$AG_ID"

# Tạo thêm Metric Alert — Disk đầy (OS disk bytes remaining < 5GB)
az monitor metrics alert create \
  --name "alert-disk-low-vm-lab29" \
  --resource-group rg-az104-m29 \
  --scopes "$VM_ID" \
  --condition "avg OS Disk Queue Depth > 50" \
  --window-size 15m \
  --evaluation-frequency 5m \
  --severity 1 \
  --description "Disk queue depth cao — disk I/O bottleneck" \
  --action "$AG_ID"

# Kiểm tra alerts đã tạo
az monitor metrics alert list \
  --resource-group rg-az104-m29 \
  --output table

Verify Portal: Azure Portal → Monitor → Alerts → Alert rules → lọc Resource group = rg-az104-m29 → xác nhận 2 metric alerts. Có thể SSH vào VM và chạy stress --cpu 2 --timeout 600 để trigger CPU alert.

Tạo Log Search Alert — phát hiện error trong syslog

Bash— Cloud Shell hoặc Linux/macOS terminal

LAW_ID=$(az monitor log-analytics workspace show \
  --resource-group rg-az104-m29 \
  --workspace-name law-az104-m29 \
  --query id -o tsv)

AG_ID=$(az monitor action-group show \
  --name "ag-az104-m29-ops" \
  --resource-group rg-az104-m29 \
  --query id -o tsv)

# Tạo Log Alert — phát hiện error level events trong Syslog
# Query: tìm syslog events có severity error/critical trong 15 phút
az monitor scheduled-query create \
  --name "alert-syslog-errors-lab29" \
  --resource-group rg-az104-m29 \
  --scopes "$LAW_ID" \
  --condition-query "Syslog | where SeverityLevel in ('err','crit','alert','emerg') | where TimeGenerated > ago(15m) | summarize ErrorCount = count() by Computer" \
  --condition-time-aggregation "Count" \
  --condition-operator "GreaterThan" \
  --condition-threshold 5 \
  --evaluation-frequency "PT15M" \
  --window-size "PT15M" \
  --severity 2 \
  --description "Syslog errors vượt ngưỡng trong 15 phút" \
  --action-groups "$AG_ID" \
  --location southeastasia

# Tạo Log Alert — phát hiện VM heartbeat mất (VM offline)
az monitor scheduled-query create \
  --name "alert-vm-heartbeat-loss-lab29" \
  --resource-group rg-az104-m29 \
  --scopes "$LAW_ID" \
  --condition-query "Heartbeat | where TimeGenerated > ago(5m) | summarize LastHeartbeat = max(TimeGenerated) by Computer | where LastHeartbeat < ago(5m)" \
  --condition-time-aggregation "Count" \
  --condition-operator "GreaterThan" \
  --condition-threshold 0 \
  --evaluation-frequency "PT5M" \
  --window-size "PT10M" \
  --severity 0 \
  --description "VM mất heartbeat — có thể offline" \
  --action-groups "$AG_ID" \
  --location southeastasia

az monitor scheduled-query list \
  --resource-group rg-az104-m29 \
  --output table

Verify Portal: Azure Portal → Monitor → Alerts → Alert rules → filter Type = "Log search" → xác nhận 2 log alerts. Vào Log Analytics Workspace → Logs → chạy thử KQL query xem kết quả.

Tạo Activity Log Alert và Alert Processing Rule (suppression)

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

SUB_ID=$(az account show --query id -o tsv)

AG_ID=$(az monitor action-group show \
  --name "ag-az104-m29-ops" \
  --resource-group rg-az104-m29 \
  --query id -o tsv)

# Tạo Activity Log Alert — cảnh báo khi VM bị xóa
az monitor activity-log alert create \
  --name "alert-vm-delete-lab29" \
  --resource-group rg-az104-m29 \
  --scope "/subscriptions/$SUB_ID" \
  --condition "category=Administrative and operationName=Microsoft.Compute/virtualMachines/delete and status=Succeeded" \
  --action-group "$AG_ID" \
  --description "VM đã bị xóa thành công — kiểm tra ngay"

# Tạo Activity Log Alert — Service Health southeastasia
az monitor activity-log alert create \
  --name "alert-service-health-sea-lab29" \
  --resource-group rg-az104-m29 \
  --scope "/subscriptions/$SUB_ID" \
  --condition "category=ServiceHealth and properties.incidentType=Incident" \
  --action-group "$AG_ID" \
  --description "Azure service incident tác động southeastasia"

# Tạo Alert Processing Rule — Suppress notifications thứ 7/CN 22:00-06:00
az monitor alert-processing-rule create \
  --name "apr-maintenance-weekend-lab29" \
  --resource-group rg-az104-m29 \
  --rule-type Suppression \
  --scopes "/subscriptions/$SUB_ID/resourceGroups/rg-az104-m29" \
  --schedule-recurrence-type Weekly \
  --schedule-recurrence Saturday Sunday \
  --schedule-start-time "2026-06-27 22:00:00" \
  --schedule-end-time "2026-06-29 06:00:00" \
  --description "Suppress alerts trong giờ bảo trì cuối tuần"

echo "Activity Log Alerts và Processing Rule đã tạo thành công."

Verify Portal: Monitor → Alerts → Alert rules → filter Type = "Activity log" → xác nhận 2 alerts. Monitor → Alerts → Alert processing rules → xác nhận "apr-maintenance-weekend-lab29" với schedule cuối tuần.

Cleanup — Dọn dẹp tài nguyên Lab 29

Azure CLI— Chạy được trên PowerShell, CMD, Bash hoặc Azure Cloud Shell

SUB_ID=$(az account show --query id -o tsv)

# Xóa Alert Processing Rule (subscription-scoped, xóa riêng)
az monitor alert-processing-rule delete \
  --name "apr-maintenance-weekend-lab29" \
  --resource-group rg-az104-m29 \
  --yes

# Xóa Activity Log Alerts
az monitor activity-log alert delete \
  --name "alert-vm-delete-lab29" \
  --resource-group rg-az104-m29

az monitor activity-log alert delete \
  --name "alert-service-health-sea-lab29" \
  --resource-group rg-az104-m29

# Xóa Resource Group — kéo theo VM, Log Analytics, Metric Alerts, Log Alerts, Action Group
az group delete --name rg-az104-m29 --yes --no-wait

echo "Cleanup hoàn tất."

Kết Quả Đầu Ra

Phân biệt 3 loại Alert

Chọn đúng loại alert cho từng tình huống: metric (số liệu), log (KQL query), activity log (sự kiện ARM)

Cấu hình Metric Alert

Tạo static và dynamic threshold, chọn aggregation granularity và evaluation frequency phù hợp

Viết Log Search Alert với KQL

Viết KQL query phát hiện security events, heartbeat loss, error patterns trong Log Analytics

Tạo Action Group đa kênh

Cấu hình email, SMS, webhook, Azure Function, Automation Runbook làm response action

Activity Log Alert cho governance

Alert khi resource bị xóa, NSG thay đổi, Service Health incident tác động subscription

Alert Processing Rules

Cấu hình suppression window bảo trì, thêm action group vào alerts theo filter, giảm alert fatigue

Ứng Dụng Thực Tế

Tình huống 1: Sàn thương mại điện tử — Alert phòng ngừa downtime

Flash sale Black Friday — hệ thống cần phát hiện tải cao sớm 15 phút để scale trước khi ảnh hưởng khách hàng.

Giải pháp

Metric alert CPU > 70% (warning) và > 90% (critical). Log alert khi HTTP 5xx responses > 50/phút từ App Service logs. Activity log alert khi autoscale scale-out event fire.

Triển khai

Action Group: email Ops team + webhook PagerDuty (Sev 1) + Azure Automation Runbook tự scale-out (Sev 0). Alert Processing Rule suppress Sev 3-4 trong giờ cao điểm để giảm noise.

Lợi ích

Black Friday xử lý 50,000 đơn/giờ không downtime. Scale-out tự động xảy ra trong 3 phút khi CPU vượt 90%. Ops team nhận alert SMS, gộp case trong PagerDuty.

Tình huống 2: Công ty bảo hiểm — Alert bảo mật real-time

Phát hiện truy cập bất thường vào hệ thống hồ sơ khách hàng và phản ứng trong vòng 5 phút.

Giải pháp

Log alert KQL phát hiện: failed login > 10 lần/5 phút từ cùng IP, access ngoài giờ hành chính (trước 07:00 và sau 22:00), download nhiều file > 100MB/phiên. Activity log alert khi RBAC role assignment thay đổi.

Triển khai

Action Group Sev 0: email CISO + SMS Security team + Logic App tạo ticket ServiceNow + Azure Function tự block IP nghi ngờ qua NSG. Alert Processing Rule: không suppress security alerts, bao giờ cũng notify.

Lợi ích

MTTD (Mean Time to Detect) giảm từ 8 giờ xuống 4 phút. Tự động block IP tấn công trong 2 phút. Đáp ứng yêu cầu ISO 27001 về incident response SLA.

Tình huống 3: Nhà máy sản xuất — Alert bảo trì định kỳ không noise

Hệ thống MES chạy 24/7, bảo trì thứ 7 hàng tuần 02:00–06:00, cần tránh alert storm trong giờ bảo trì.

Giải pháp

Alert Processing Rule suppression scope = rg-prod, schedule = thứ 7 02:00–06:00 recurring. Alerts vẫn fire (ghi lại) nhưng không gửi notification. Chỉ Sev 0 Critical override suppression.

Triển khai

Dynamic threshold metric alerts cho CPU/Memory — tự học pattern ca ngày/ca đêm. Activity log alert riêng cho delete operations (không bao giờ suppress). Teams webhook cho non-critical alerts ban ngày.

Lợi ích

Alert fatigue giảm 80% — từ 200 notification/tuần xuống 40. Ops team không bị đánh thức oan lúc 03:00 thứ 7. Critical alerts vẫn xuyên qua suppression để bảo vệ production.

Module 28: Azure Monitor Module 30: Log Analytics