Đối với một Quản trị viên Cloud (Cloud Administrator), câu hỏi không phải là “liệu hệ thống có gặp sự cố hay không”, mà là “khi nào nó sẽ gặp sự cố và chúng ta sẽ phản ứng trong bao lâu?”. Trong những khoảnh khắc khủng hoảng đó – khi website ngừng hoạt động, khi ứng dụng báo lỗi 500, hay khi máy ảo đột ngột chậm đi – log và metrics chính là chiếc phao cứu sinh duy nhất. Không có chúng, bạn như một bác sĩ không có ống nghe, hoàn toàn mù tịt trước “bệnh nhân” của mình.

Trên Microsoft Azure, bộ công cụ quyền lực để giám sát và chẩn đoán chính là Azure Monitor và Log Analytics. Nắm vững chúng không phải là một tùy chọn, đó là yêu cầu cơ bản để tồn tại và phát triển trong vai trò quản trị hạ tầng cloud Azure.

Bộ ba quyền lực: Monitor, Log Analytics và Application Insights

Để hiểu rõ cách hoạt động, chúng ta cần phân biệt vai trò của từng thành phần:

• Azure Monitor: Hãy xem đây là dịch vụ “dù” bao trùm tất cả. Nó là trung tâm thu thập dữ liệu từ xa (telemetry) trên toàn bộ hệ sinh thái Azure. Azure Monitor thu thập hai loại dữ liệu chính:
  • Metrics: Dữ liệu dạng số, được thu thập theo từng khoảng thời gian đều đặn (ví dụ: % CPU, số lượng request, độ trễ mạng). Metrics rất nhẹ và lý tưởng cho việc cảnh báo gần như thời gian thực.
  • Logs: Dữ liệu có cấu trúc hoặc phi cấu trúc, ghi lại các sự kiện đã xảy ra (ví dụ: log của ứng dụng, log truy cập web server, log hệ điều hành). Logs chứa thông tin chi tiết để phân tích sâu và truy tìm nguyên nhân gốc rễ.
• Log Analytics Workspace: Đây là “bộ não” lưu trữ và phân tích log. Nó là một môi trường chuyên dụng để tổng hợp log từ nhiều nguồn khác nhau (máy ảo, App Services, tường lửa, Azure AD…). Sức mạnh thực sự của Log Analytics nằm ở ngôn ngữ truy vấn của nó: KQL.
• Application Insights: Đây là một tính năng chuyên sâu của Azure Monitor, thuộc loại APM (Application Performance Management). Nó được thiết kế cho các nhà phát triển để theo dõi hiệu suất và chẩn đoán lỗi ngay từ bên trong mã nguồn ứng dụng. Dữ liệu từ Application Insights cũng được gửi về và lưu trữ trong một Log Analytics Workspace.

Tóm lại: Azure Monitor thu thập dữ liệu, đưa vào kho chứa là Log Analytics Workspace, và chúng ta dùng KQL để “tra hỏi” dữ liệu đó.

KQL (Kusto Query Language): Ngôn ngữ cứu sinh

Nếu Log Analytics là bộ não, thì KQL chính là ngôn ngữ bạn dùng để giao tiếp với nó. Đừng để cái tên “ngôn ngữ truy vấn” làm bạn sợ hãi. KQL được thiết kế để trực quan và mạnh mẽ, với cú pháp dựa trên ”  đường ống” (pipeline), tương tự như cách bạn dùng “|” trong PowerShell hoặc Linux shell. Dữ liệu được truyền từ trái sang phải, qua từng bước xử lý .

Một vài truy vấn “sống còn”:

Giả sử bạn đang điều tra một sự cố trên Azure App Service.

1. Tìm kiếm tất cả các lỗi trong 24 giờ qua:

AppServiceConsoleLogs  #Truy vấn vào bảng chứa log console của App Service

| where TimeGenerated > ago(24h) #Lọc ra các bản ghi trong 24 giờ gần nhất

| where Message has “error” or Message has “failed” # Chỉ lấy các bản ghi có chứa từ “error” hoặc “failed”

| order by TimeGenerated desc # Sắp xếp theo thứ tự thời gian mới nhất lên đầu

2. Đếm số lượng request thất bại theo từng URL:

AppServiceHTTPLogs #// Truy vấn vào bảng chứa log HTTP của App Service

| where ScStatus >= 500 // Lọc các request có mã trạng thái là 5xx (Server Error)

| summarize count() by CsUriStem #Đếm số lượng request theo từng URL (CsUriStem)

| project-rename FailedCount = count_ # Đặt tên cho cột đếm là ‘FailedCount’

| order by FailedCount desc # Sắp xếp theo số lỗi giảm dần

Sức mạnh của KQL là khả năng cho phép bạn nhanh chóng cắt lớp, tổng hợp và tìm ra “kim trong đống cỏ khô” từ hàng gigabyte dữ liệu log.

Từ truy vấn đến hành động: Tạo cảnh báo tự động (Alerts)

Tìm ra vấn đề là một chuyện, nhưng được thông báo ngay khi nó xảy ra lại là chuyện khác. Azure Monitor cho phép bạn biến bất kỳ truy vấn KQL nào thành một Quy tắc cảnh báo (Alert Rule).

• Cơ chế hoạt động:
  1. Viết truy vấn: Bạn tạo một truy vấn KQL trả về một giá trị số (ví dụ: số lượng lỗi, CPU trung bình).
  2. Đặt ngưỡng (Threshold): Bạn xác định điều kiện kích hoạt. Ví dụ: “Kích hoạt cảnh báo nếu kết quả của truy vấn (số lỗi) lớn hơn 10”.
  3. Thiết lập tần suất: “Chạy truy vấn này mỗi 5 phút và xem xét dữ liệu trong 5 phút đó”.
  4. Cấu hình Action Group: Đây là phần “hành động”. Khi cảnh báo được kích hoạt, Action Group sẽ quyết định phải làm gì. Nó có thể:
     • Gửi email đến đội ngũ quản trị.
     • Gửi SMS hoặc push notification qua ứng dụng Azure.
     • Gọi một webhook, kích hoạt một Azure Function hoặc Logic App để thực hiện hành động khắc phục tự động (ví dụ: khởi động lại một dịch vụ).

Hệ thống này biến việc giám sát từ bị động (chờ sự cố rồi mới vào xem log) thành chủ động (hệ thống tự phát hiện và thông báo cho bạn, hoặc thậm chí tự sửa lỗi).

Kết luận: Giám sát không phải là tùy chọn, mà là yêu cầu để sống còn:

Trong thế giới đám mây linh hoạt nhưng cũng đầy biến động, việc dựa vào cảm tính hay may mắn là con đường ngắn nhất dẫn đến thảm họa. Việc làm chủ Azure Monitor, sử dụng thành thạo KQL để truy vấn Log Analytics, và thiết lập các cảnh báo tự động là những kỹ năng không thể thiếu của một Cloud Admin chuyên nghiệp.

Chúng không chỉ giúp bạn “sống sót” sau các sự cố mà còn giúp bạn xây dựng một hệ thống ổn định, đáng tin cậy và dễ quản lý hơn. Giám sát chủ động chính là nền tảng để bạn tự tin vận hành và mở rộng hạ tầng của mình trên Azure.