Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa deploy một ứng dụng thương mại điện tử lên cloud. Mọi thứ chạy trơn tru trong buổi demo. Nhưng đến 8 giờ tối cao điểm, khách hàng bắt đầu than phiền "trang tải chậm quá", "bấm thanh toán không được". Bạn mở terminal, SSH vào server, và... không biết bắt đầu từ đâu. CPU có cao không? Database có bị nghẽn không? Có bao nhiêu request đang bị lỗi? Bạn đang "mù" giữa lúc hệ thống đang chảy máu.
Đây chính là lý do Monitoring (giám sát) tồn tại. Monitoring là "hệ thần kinh" của hạ tầng cloud — nó cho bạn biết hệ thống đang khỏe hay đang ốm, ốm ở đâu, và ốm nặng đến mức nào, trước khi khách hàng phải nhắn tin than phiền. Trong DevOps, có một câu nói kinh điển: "You can't fix what you can't see" — bạn không thể sửa cái mà bạn không nhìn thấy.
Trong bài này, chúng ta sẽ tập trung vào lớp nền tảng của giám sát cloud: thu thập và quan sát metrics (số đo) qua ba nền tảng lớn — Amazon CloudWatch (AWS), Google Cloud Monitoring (trước đây gọi là Stackdriver), và Azure Monitor. Chúng ta cũng sẽ học tư duy giám sát chuẩn của Google SRE: 4 Golden Signals. Đây là kim chỉ nam để bạn biết nên đo cái gì, thay vì đo lung tung hàng trăm chỉ số rồi chết chìm trong dữ liệu.
Khái niệm cốt lõi
Monitoring là gì và khác gì với Logging, Tracing
Trước hết cần phân biệt rõ để không nhầm lẫn với các bài sau. Monitoring ở đây tập trung vào metrics — những con số được đo theo thời gian: CPU 75%, 1200 request/giây, độ trễ trung bình 250ms. Metrics là dữ liệu dạng số, gọn nhẹ, được lấy mẫu đều đặn (ví dụ mỗi 60 giây), rất phù hợp để vẽ biểu đồ và đặt cảnh báo.
Logging (Bài 34) là các dòng bản ghi văn bản chi tiết về từng sự kiện. Tracing (Bài 35) theo dõi hành trình một request đi qua nhiều dịch vụ. Trong bài này chúng ta chỉ nói về metrics và alerting — nền tảng đầu tiên và quan trọng nhất.
4 Golden Signals — bốn tín hiệu vàng
Cuốn sách Site Reliability Engineering của Google đưa ra bốn tín hiệu mà nếu chỉ được đo bốn thứ, bạn hãy đo bốn thứ này. Đây là "bộ khung tư duy" quan trọng nhất của bài học.
1. Latency (Độ trễ) — Thời gian để xử lý một request. Ví dụ: API trả kết quả trong bao nhiêu mili-giây. Một điểm cực kỳ quan trọng: bạn phải tách riêng độ trễ của request thành công và request thất bại. Một lỗi HTTP 500 trả về sau 5ms (server chết nhanh) rất khác với một request thành công mất 5ms. Nếu gộp chung, độ trễ trung bình sẽ đánh lừa bạn.
2. Traffic (Lưu lượng) — Mức độ nhu cầu đang đổ vào hệ thống. Với web service thường đo bằng requests per second (RPS). Với hệ thống streaming có thể là số message/giây, với database là số transaction/giây. Traffic cho bạn biết hệ thống đang "gánh" bao nhiêu tải.
3. Errors (Tỷ lệ lỗi) — Tỷ lệ request bị thất bại. Có thể là lỗi rõ ràng (HTTP 500), lỗi ngầm (HTTP 200 nhưng trả về nội dung sai), hoặc lỗi theo chính sách (request mất quá 1 giây bị coi là lỗi). Error rate thường tính theo phần trăm: "0.5% request bị lỗi trong 5 phút qua".
4. Saturation (Độ bão hòa) — Hệ thống đang "đầy" đến mức nào so với giới hạn tài nguyên. Ví dụ: RAM đã dùng 90%, hàng đợi (queue) đang tồn 5000 job, disk còn 5% dung lượng. Saturation là tín hiệu dự báo tương lai — nó cho bạn biết bao lâu nữa hệ thống sẽ sập nếu tải tiếp tục tăng.
Mẹo ghi nhớ: Latency và Errors nói về trải nghiệm người dùng ngay bây giờ, còn Traffic và Saturation nói về sức khỏe và khả năng chịu tải sắp tới.
Percentile — vì sao "trung bình" là kẻ nói dối
Đây là khái niệm mà rất nhiều bạn mới bỏ qua. Khi đo latency, đừng chỉ nhìn giá trị trung bình (average). Giả sử 99 request trả về trong 50ms, nhưng 1 request mất 10 giây. Trung bình vẫn đẹp (~150ms), nhưng có một khách hàng đang chịu trải nghiệm khủng khiếp.
Vì vậy hãy dùng percentile (phân vị): p50 (trung vị — 50% request nhanh hơn con số này), p95, p99. Con số p99 = 800ms nghĩa là "1% khách hàng chậm nhất của bạn phải chờ trên 800ms". Trong thực tế, p95 và p99 là hai chỉ số quan trọng nhất khi đánh giá trải nghiệm thật.
Ba nền tảng giám sát của ba đám mây lớn
Ba nhà cung cấp lớn đều có công cụ monitoring "built-in", đọc tự động metrics từ các dịch vụ của họ:
- Amazon CloudWatch (AWS): Metrics được tổ chức theo Namespace (ví dụ
AWS/EC2) và Dimensions (ví dụInstanceId). Bạn tạo CloudWatch Alarm để cảnh báo, và dùng Dashboard để vẽ biểu đồ. Với metrics tùy biến (custom metrics) từ ứng dụng, bạn đẩy lên qua APIPutMetricData.
- Google Cloud Monitoring / Stackdriver (GCP): Khái niệm tương tự nhưng gọi là Metric Type và Resource Labels. Cảnh báo được cấu hình qua Alerting Policy. GCP mạnh về ngôn ngữ truy vấn MQL (Monitoring Query Language) và PromQL.
- Azure Monitor (Microsoft): Gom cả metrics và logs. Metrics gọi là Azure Monitor Metrics, cảnh báo là Alert Rule dựa trên Signal. Truy vấn log nâng cao dùng ngôn ngữ KQL (Kusto Query Language).
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT Việt Nam sống sót qua đợt sale 12/12
Một công ty thương mại điện tử tại TP.HCM (giả định tên "ShopViet", chạy trên AWS) chuẩn bị cho đợt sale 12/12. Năm trước, đúng 20h khi flash sale mở màn, website "chết" 8 phút và họ mất khoảng 400 triệu đồng doanh thu. Điều tệ nhất: đội kỹ thuật không biết website chết cho đến khi CEO gọi điện.
Năm nay, họ áp dụng 4 Golden Signals trên CloudWatch. Họ tạo dashboard hiển thị: latency p95 của API checkout, RPS đổ vào Application Load Balancer, tỷ lệ HTTP 5xx, và saturation của cụm RDS database (CPU và số kết nối). Họ đặt CloudWatch Alarm: nếu p95 latency vượt 1 giây trong 3 phút liên tục, gửi cảnh báo qua SNS vào group Telegram của đội trực.
Đúng 20h, RPS tăng vọt từ 200 lên 3.500. Alarm về latency kêu sau 90 giây — không phải vì web chết, mà vì saturation của RDS chạm 95% CPU. Đội trực nhìn dashboard, thấy rõ nút thắt nằm ở database, lập tức tăng read-replica và bật cache. Website chỉ chậm chứ không sập.
Bài học: Monitoring không tự sửa lỗi, nhưng nó biến "mù mờ hoảng loạn" thành "nhìn thấy vấn đề và ra quyết định trong 90 giây". Đặc biệt, chính tín hiệu Saturation (CPU database) đã cảnh báo trước khi Errors bùng nổ.
Ví dụ 2 — Startup fintech và cái bẫy "average latency"
Một startup fintech ở Singapore chạy trên GCP có API xử lý giao dịch. Dashboard của họ hiển thị average latency luôn ở mức 120ms — trông rất đẹp, sếp yên tâm. Nhưng phòng chăm sóc khách hàng liên tục nhận phản ánh "app treo khi chuyển tiền".
Khi một kỹ sư mới vào chuyển dashboard từ average sang p99, sự thật lộ ra: p99 latency là 4.200ms. Cứ 100 giao dịch thì có 1 giao dịch mất hơn 4 giây — và với fintech, 4 giây chờ màn hình trắng khi đang chuyển tiền khiến khách hoảng loạn, bấm lại nhiều lần, thậm chí tạo ra giao dịch trùng.
Họ dùng Cloud Monitoring truy vấn theo label và phát hiện: các request chậm đều rơi vào những giao dịch phải gọi sang một dịch vụ chấm điểm rủi ro bên thứ ba. Họ thêm timeout và cache kết quả, kéo p99 xuống 600ms.
Bài học: Chỉ số trung bình che giấu nỗi đau của nhóm khách hàng chậm nhất. Luôn giám sát bằng percentile (p95, p99), đặc biệt trong lĩnh vực nhạy cảm như tài chính.
Ví dụ 3 — Cảnh báo quá nhiều dẫn tới "alert fatigue"
Một công ty SaaS chạy trên Azure đặt cảnh báo rất "chăm": mỗi lần CPU của bất kỳ VM nào vượt 70% trong 1 phút là gửi email. Kết quả: đội trực nhận 200+ email cảnh báo mỗi ngày. Vì phần lớn là báo động giả (CPU tăng nhẹ rồi tự hạ), nên họ tạo rule lọc tất cả email cảnh báo vào một folder... và không ai đọc nữa.
Rồi một đêm, một database thật sự bão hòa dẫn tới downtime 40 phút. Cảnh báo có được gửi — nhưng nó nằm lẫn giữa 200 báo động giả khác, không ai để ý.
Họ phải làm lại từ đầu với Azure Monitor Alert Rule: chỉ cảnh báo dựa trên triệu chứng ảnh hưởng người dùng (error rate và latency), yêu cầu điều kiện phải kéo dài (ví dụ 5 phút liên tục), và phân tầng mức độ nghiêm trọng (Sev 1 gọi điện, Sev 3 chỉ ghi log).
Bài học: Cảnh báo quá nhiều còn nguy hiểm hơn quá ít, vì nó làm con người mất niềm tin và bỏ qua cả cảnh báo thật. Hãy cảnh báo dựa trên triệu chứng (symptom-based), không phải nguyên nhân (cause-based).
Hướng dẫn từng bước
Dưới đây là quy trình thiết lập giám sát cho một dịch vụ mới, áp dụng được cho cả ba nền tảng.
Bước 1 — Xác định SLI cho dịch vụ. SLI (Service Level Indicator) là chỉ số phản ánh trải nghiệm người dùng. Với một web API, chọn: latency p95, error rate, RPS. Đây là điều bạn sẽ giám sát, quyết định trước khi đụng vào công cụ.
Bước 2 — Xác nhận metrics hạ tầng đã tự có. Trên CloudWatch/Cloud Monitoring/Azure Monitor, kiểm tra rằng CPU, RAM, network, disk của VM/container/database đã được thu thập tự động. Đây là nền tảng cho tín hiệu Saturation.
Bước 3 — Đẩy application metrics. Metrics hạ tầng không đủ để đo 4 Golden Signals của ứng dụng. Bạn cần code ứng dụng gửi metrics: số request, thời gian xử lý, số lỗi. Trên AWS dùng PutMetricData; các nền tảng đều hỗ trợ chuẩn mở như OpenTelemetry để thống nhất.
Bước 4 — Dựng dashboard theo 4 Golden Signals. Tạo một dashboard gồm bốn khung: Latency (vẽ p50/p95/p99), Traffic (RPS), Errors (% lỗi), Saturation (CPU/RAM/queue). Bố cục này giúp khi có sự cố, bạn liếc mắt là biết vấn đề nằm ở tín hiệu nào.
Bước 5 — Đặt alert dựa trên triệu chứng. Tạo alarm cho: error rate > 1% trong 5 phút, và p95 latency > ngưỡng SLO trong 5 phút. Gắn kênh thông báo (SNS → Telegram/Slack, hoặc PagerDuty). Thêm điều kiện kéo dài để tránh báo động giả.
Bước 6 — Kiểm thử alert. Đừng chờ sự cố thật mới biết alert có chạy không. Chủ động tạo tải giả hoặc tắt thử một instance để xác nhận cảnh báo thực sự đến tay người trực. Một alert chưa từng được test là một alert bạn không thể tin tưởng.
Bước 7 — Rà soát định kỳ. Mỗi tháng xem lại: alert nào kêu mà không cần hành động (nhiễu, nên bỏ), sự cố nào xảy ra mà không có alert (thiếu, nên thêm).
Lỗi thường gặp & mẹo
Chỉ nhìn average, bỏ qua percentile. Như ví dụ 2 đã thấy — average giấu nỗi đau. Luôn có ít nhất p95 và p99 cho latency.
Giám sát tài nguyên (cause) thay vì trải nghiệm (symptom). Cảnh báo "CPU 90%" đôi khi vô hại nếu người dùng vẫn được phục vụ tốt. Hãy ưu tiên cảnh báo dựa trên latency và error rate — thứ khách hàng thực sự cảm nhận. Saturation dùng để chẩn đoán, không nhất thiết để báo động chính.
Alert fatigue — cảnh báo quá nhiều. Mỗi cảnh báo phải "đáng để đánh thức ai đó lúc 3 giờ sáng". Nếu không cần hành động ngay, đừng để nó là cảnh báo — hãy để nó là dashboard hoặc log.
Không đo custom/business metrics. CPU đẹp không có nghĩa nghiệp vụ ổn. Một sàn TMĐT nên giám sát cả "số đơn hàng thành công/phút". Nếu con số này tụt về 0 dù CPU vẫn xanh, có thể luồng thanh toán đã hỏng.
Quên chi phí monitoring. Custom metrics, dashboard, số lần đọc API đều tính tiền. Trên CloudWatch, đẩy hàng nghìn custom metrics với độ phân giải cao (1 giây) có thể tốn bất ngờ. Mẹo: dùng độ phân giải 60 giây cho phần lớn metrics, chỉ 1 giây cho thứ thật sự cần.
Không đặt data retention hợp lý. Metrics chi tiết theo giây không cần giữ nhiều năm. Cấu hình aggregation và retention để tiết kiệm chi phí lưu trữ.
Mẹo — chuẩn hóa với OpenTelemetry. Nếu bạn dự định chạy multi-cloud hoặc có thể đổi nhà cung cấp, hãy dùng chuẩn mở OpenTelemetry để thu thập metrics thay vì khóa chặt vào SDK riêng của một hãng. Điều này giúp bạn không bị "vendor lock-in".
Bài tập thực hành
- Phân loại tín hiệu: Cho các chỉ số sau, hãy gán mỗi cái vào một trong 4 Golden Signals: (a) số kết nối đang mở tới database, (b) thời gian p99 của API
/checkout, (c) tỷ lệ HTTP 503, (d) số message/giây vào một message queue. Giải thích lựa chọn.
- Thiết kế dashboard: Bạn quản lý một API đặt vé xe khách. Hãy liệt kê 4–6 metrics bạn sẽ đưa lên dashboard theo khung 4 Golden Signals, gồm cả ít nhất một business metric.
- Thiết kế alert: Viết ra ba alert rule (điều kiện + thời lượng + mức độ nghiêm trọng + kênh thông báo) cho API ở bài 2. Giải thích vì sao mỗi cái đáng để cảnh báo, và tránh bẫy alert fatigue như thế nào.
- Suy luận từ số liệu: Dashboard cho thấy Traffic bình thường, Latency p95 bình thường, nhưng Errors tăng đột ngột lên 30% và Saturation của một backend service chạm 100% RAM. Bạn chẩn đoán chuyện gì đang xảy ra và hành động đầu tiên là gì?
- Thực hành (nếu có tài khoản cloud): Tạo một VM nhỏ trên AWS/GCP/Azure, dựng một dashboard với metric CPU, và đặt một alarm gửi email khi CPU vượt 80% trong 5 phút. Dùng lệnh tạo tải (ví dụ
stress) để kích hoạt và xác nhận email đến.
Tóm tắt
- Monitoring là hệ thần kinh của hạ tầng cloud: nó biến trạng thái hệ thống thành các con số (metrics) quan sát được, giúp bạn phát hiện và chẩn đoán sự cố trước khi khách hàng phản ánh.
- 4 Golden Signals của Google SRE là kim chỉ nam để biết nên đo gì: Latency (độ trễ), Traffic (lưu lượng), Errors (tỷ lệ lỗi), Saturation (độ bão hòa). Latency và Errors phản ánh trải nghiệm hiện tại; Traffic và Saturation dự báo sức chịu tải.
- Luôn dùng percentile (p95, p99) thay vì average khi đo latency — trung bình che giấu nỗi đau của nhóm khách hàng chậm nhất.
- Ba nền tảng lớn — CloudWatch (AWS), Cloud Monitoring/Stackdriver (GCP), Azure Monitor — đều tự thu thập metrics hạ tầng; việc của bạn là bổ sung application/business metrics và cấu hình alert hợp lý.
- Cảnh báo nên dựa trên triệu chứng ảnh hưởng người dùng (symptom-based), có điều kiện kéo dài để tránh alert fatigue. Một cảnh báo tốt là cảnh báo đáng để đánh thức ai đó lúc 3 giờ sáng.
- Đừng quên chi phí và retention của monitoring, và cân nhắc chuẩn mở OpenTelemetry để tránh vendor lock-in.