[Google-SRE-bản dịch tiếng việt]-Monitoring Distributed Systems

📑 Mục Lục

Định nghĩa cơ bản
Tại sao cần monitoring?
Phân biệt triệu chứng và nguyên nhân
White-box vs Black-box
The Four Golden Signals
Hiệu suất, độ chi tiết, và đơn giản
Nguyên tắc thiết kế đơn giản
Tổng hợp triết lý monitoring
Giám sát dài hạn
Kết luận

🧾 Định nghĩa cơ bản

Monitoring là quá trình thu thập, xử lý, tổng hợp và hiển thị dữ liệu định lượng thời gian thực của hệ thống.

White-box monitoring: Dựa vào dữ liệu nội tại của hệ thống (metrics, logs, HTTP).
Black-box monitoring: Dựa vào hành vi quan sát được từ bên ngoài.
Alert: Thông báo yêu cầu con người hành động (qua email, ticket, page).
Dashboard: Giao diện trực quan hóa các chỉ số quan trọng.
Push: Mọi thay đổi về mã nguồn hoặc cấu hình triển khai.
Root Cause: Nguyên nhân gốc rễ cần được khắc phục để tránh lặp lại lỗi tương tự.

📡 Tại sao cần monitoring?

Phân tích xu hướng dài hạn
So sánh giữa các phiên bản hoặc nhóm thử nghiệm
Cảnh báo lỗi hoặc sự cố tiềm ẩn
Xây dựng dashboard tổng quan hệ thống
Hỗ trợ phân tích hậu kỳ (retrospective debugging)

Monitoring giúp hệ thống tự báo hiệu khi gặp sự cố, giảm thiểu phụ thuộc vào kiểm tra thủ công và giúp nhân sự tập trung vào cải tiến dài hạn.

🧩 Phân biệt triệu chứng và nguyên nhân

Triệu chứng (symptom) là những gì hệ thống thể hiện ra ngoài (ví dụ: HTTP 500), còn nguyên nhân (cause) là lỗi nội tại như database chậm hoặc lỗi cấu hình ACL.

⚪⚫ White-box vs Black-box

Black-box: Phát hiện lỗi đã xảy ra (symptom), đáng tin cậy để kích hoạt cảnh báo.
White-box: Phát hiện lỗi sắp xảy ra, hỗ trợ điều tra nguyên nhân và cải thiện dài hạn.

💡 The Four Golden Signals

Latency: Thời gian xử lý request
Traffic: Mức độ tải, số lượng request
Errors: Tỉ lệ lỗi (HTTP 500, nội dung sai, vượt timeout)
Saturation: Mức độ "no đủ" của tài nguyên hệ thống (CPU, memory, IO)

Đây là 4 chỉ số quan trọng nhất cần theo dõi trong mọi hệ thống người dùng cuối.

🧪 Hiệu suất và Chi tiết

Đừng chỉ theo dõi trung bình (mean), mà hãy quan sát tail latency (99th percentile).
Sử dụng histogram thay vì chỉ số tuyệt đối.
Cân bằng giữa độ chi tiết và chi phí lưu trữ/phân tích.

🧱 Nguyên tắc thiết kế đơn giản

Alert phải dễ hiểu, không gây nhiễu
Các rule ít được dùng nên xem xét loại bỏ
Không nên kết hợp monitoring với log tracing/profiling nếu không cần thiết

📌 Triết lý Monitoring

Một alert tốt phải:

Urgent, actionable, observable bởi người dùng
Có thể phản ứng ngay, không gây phiền nếu là false-positive
Ưu tiên triệu chứng hơn nguyên nhân
Không tạo thêm nợ kỹ thuật

🕰️ Giám sát dài hạn

Đừng để system "ngốn công sức" ngắn hạn để duy trì uptime.
Đôi khi chấp nhận downtime ngắn để cải tiến dài hạn.
Automate những thao tác phản xạ (rote) càng sớm càng tốt.

🔚 Kết luận

Hệ thống monitoring hiệu quả là hệ thống:

Ưu tiên simplicity
Theo dõi triệu chứng rõ ràng
Có dashboard trực quan
Giảm thiểu alert sai (false positive)
Hỗ trợ cải tiến hệ thống lâu dài thay vì chữa cháy liên tục