Log, metric và uptime check khác nhau ở điểm nào?

Khi website bất ngờ chạy chậm hoặc văng lỗi, phản xạ quen thuộc của không ít bạn lập trình viên là SSH ngay vào VPS, gõ lệnh tail -f để đọc file log của ứng dụng hoặc Nginx. Màn hình console bắt đầu tuôn ra hàng nghìn dòng chữ chạy vun vút. Giữa một rừng thông tin hỗn loạn gồm đủ thứ request từ người dùng, bot quét mạng, log debug và cảnh báo vặt vãnh, bạn rất khó biết dòng nào thực sự liên quan đến sự cố vừa xảy ra.

Đó là hậu quả của việc nhảy thẳng vào đọc chi tiết khi chưa nắm được bức tranh tổng thể.

Trong giám sát hệ thống, Uptime Check, Metric và Log không phải là ba cách hiển thị khác nhau của cùng một nguồn dữ liệu. Chúng là ba công cụ phục vụ ba mục đích hoàn toàn riêng biệt:

• Uptime Check trả lời câu hỏi: Người dùng bên ngoài có vào được website hay không?
• Metric trả lời câu hỏi: Sự cố xảy ra từ thời điểm nào, mức độ ảnh hưởng rộng hay hẹp, và thành phần nào đang bị nghẽn?
• Log trả lời câu hỏi: Chính xác dòng code nào, câu lệnh SQL nào, hay lỗi kỹ thuật cụ thể nào đã gây ra chuyện đó?

Biết cách phối hợp ba tín hiệu này theo thứ tự từ ngoài vào trong sẽ giúp bạn rút ngắn thời gian xử lý sự cố từ hàng giờ mò mẫm xuống chỉ còn vài phút khoanh vùng chính xác.

Uptime check phát hiện tác động, metric giúp khoanh vùng và log cung cấp chi tiết theo sự kiện.

Bảng so sánh nhanh 3 loại dữ liệu

1. Uptime Check: Chiếc chuông báo động từ bên ngoài

Uptime Check đứng ở vị trí của một vị khách bình thường ngoài Internet. Con bot kiểm tra này định kỳ gọi vào tên miền của bạn để xem trang web có mở được không.

Điểm mạnh không thể thay thế của Uptime Check là nó phát hiện được những sự cố "nằm ngoài tầm mắt" của máy chủ: tên miền hết hạn, bản ghi DNS trỏ nhầm, chứng chỉ SSL hết hạn, hoặc dịch vụ CDN Cloudflare gặp trục trặc chặn khách. Trong những trường hợp đó, VPS của bạn bên dưới vẫn hoàn toàn khỏe mạnh, CPU thấp, RAM trống và không hề sinh ra một dòng log lỗi nào. Nếu không có Uptime Check bên ngoài, bạn sẽ hoàn toàn mù tịt về việc website đã biến mất khỏi Internet.

Tuy nhiên, Uptime Check chỉ là tín hiệu báo động. Khi nó báo "Trang web phản hồi mã 502", nó không thể cho bạn biết Nginx bị lỗi, PHP-FPM bị quá tải hay container ứng dụng vừa bị sập.

Cách thiết lập các bước kiểm tra từ DNS, SSL đến quét nội dung đã được phân tích chi tiết trong bài Uptime monitoring: Kiểm tra HTTP 200 hay nội dung trang?.

2. Metric: Bản đồ radar khoanh vùng điểm nghẽn

Sau khi chiếc chuông Uptime Check réo lên, công cụ tiếp theo bạn cần mở ra là biểu đồ Metric, chứ chưa phải file log.

Metric là những con số đo lường liên tục được vẽ thành biểu đồ:

• Tỷ lệ lỗi HTTP 5xx trong 5 phút vừa qua là bao nhiêu %?
• Thời gian phản hồi trung bình và phân vị P95 tăng từ lúc mấy giờ?
• Bộ nhớ RAM khả dụng (MemAvailable) và mức dùng CPU đang ở ngưỡng nào?
• Số lượng kết nối đang mở tới MySQL có chạm mốc tối đa chưa?

Metric có giá trị cực lớn ở khả năng tổng hợp và so sánh: Thay vì phải đọc 100.000 request trong file log để đếm xem có bao nhiêu lỗi, biểu đồ Metric cho bạn thấy ngay một đường dốc đứng: "Vào đúng 14h20, tỷ lệ lỗi 5xx vọt từ 0.1% lên 25%, cùng lúc đó số kết nối database chạm trần 150/150".

Chỉ mất 30 giây nhìn vào biểu đồ Metric, bạn đã loại trừ được 90% các nghi can khác (CPU không nghẽn, ổ cứng không đầy, RAM vẫn còn dư) và chốt ngay hướng điều tra: vấn đề nằm ở tầng kết nối cơ sở dữ liệu bắt đầu từ 14h20.

Để nắm rõ các ngưỡng chỉ số phần cứng cần đặt trên VPS, bạn có thể xem bài Ngưỡng cảnh báo CPU, RAM và Disk cho VPS.

3. Log: Kính hiển vi soi từng chi tiết kỹ thuật

Khi Metric đã chỉ điểm cho bạn biết "Cơ sở dữ liệu bị nghẽn từ 14h20", đây mới là thời điểm vàng để bạn mở file log ra đọc.

Bây giờ bạn không cần mở log một cách vu vơ nữa. Bạn mở file log của ứng dụng và database, chỉ lọc đúng các dòng ghi nhận trong khoảng thời gian từ 14h18 đến 14h25.

Lúc này, từng dòng log sẽ cung cấp ngữ cảnh chi tiết mà Metric không thể có:

• Dòng code nào trong file xử lý đơn hàng đang bị lỗi?
• Câu lệnh SQL cụ thể nào đang chạy mất 45 giây và khóa (lock) toàn bộ bảng sản phẩm?
• Địa chỉ IP nào đang gửi hàng loạt request bất thường vào trang tìm kiếm?

Log chính là bằng chứng xác thực cuối cùng để lập trình viên mở mã nguồn ra sửa đúng dòng code bị lỗi hoặc tối ưu lại câu truy vấn.

Bài viết Monitoring Database: Những chỉ số quan trọng nhất sẽ giúp bạn biết cách cấu hình bật log các câu truy vấn chậm (slow query) có kiểm soát mà không làm nặng máy chủ.

Kịch bản thực tế: Website bỗng dưng chậm rì nhưng CPU chỉ có 15%

Hãy quan sát cách một kỹ sư vận hành có kinh nghiệm phối hợp 3 công cụ này khi xử lý một sự cố kinh điển:

• Bước 1 (Nhận tin từ Uptime Check): Điện thoại nhận cảnh báo Uptime Check: Trang tìm kiếm sản phẩm bị timeout sau 10 giây chờ đợi. Tuy nhiên, trang chủ vẫn tải bình thường. Kết luận sơ bộ: Hệ thống mạng và máy chủ web vẫn sống, nhưng tính năng tìm kiếm đang bị treo.
• Bước 2 (Khoanh vùng bằng Metric): Mở dashboard lên xem khung giờ 10 phút gần nhất. CPU máy chủ chỉ 15%, RAM vẫn còn trống 2 GB. Nhưng biểu đồ Database Active Connections vọt lên kịch trần, và hàng đợi xử lý request của PHP/Node.js bắt đầu dồn ứ hàng trăm tác vụ. Kết luận bước 2: Không phải do thiếu CPU, mà do database đã hết sạch chỗ nhận kết nối mới vì các câu query tìm kiếm đang bị nghẽn lại.
• Bước 3 (Bắt bệnh bằng Log): Mở file mysql-slow.log đúng vào khung giờ trên. Phát hiện ngay một câu lệnh query tìm kiếm sản phẩm theo tên không có index, đang quét qua bảng dữ liệu 2 triệu dòng và chạy mất 8 giây mỗi lượt. Khi có 20 khách hàng cùng gõ tìm kiếm, toàn bộ connection pool bị nuốt trọn.

Toàn bộ quá trình tìm ra đúng nguyên nhân diễn ra rất mạch lạc và chuẩn xác, không hề có thao tác reboot máy chủ cầu may hay ngồi đoán mò.

4 sai lầm phổ biến khi thiết kế hệ thống theo dõi

1. Cái gì cũng muốn ghi log và biến log thành alert: Nhiều đội ngũ cấu hình để cứ mỗi khi xuất hiện một dòng log ERROR là gửi tin nhắn Telegram. Hậu quả là bot mạng quét vài link không tồn tại hoặc người dùng gõ sai mật khẩu cũng làm rung chuông cả nhóm. Hãy tổng hợp lỗi thành tỷ lệ phần trăm (Metric) và chỉ alert khi tỷ lệ lỗi vượt ngưỡng cho phép.
2. Nhét quá nhiều nhãn chi tiết vào Metric (Bẫy High Cardinality): Đưa địa chỉ email khách hàng, số điện thoại hoặc ID đơn hàng vào làm nhãn (label) của Metric trong Prometheus sẽ khiến cơ sở dữ liệu metric phình to theo cấp số nhân và làm sập luôn hệ thống monitoring. Các thông tin chi tiết của từng người dùng thuộc về Log, không thuộc về Metric.
3. Chỉ tin vào Metric bên trong máy chủ: Thấy CPU và RAM xanh lè thì đinh ninh website vẫn ổn, trong khi khách hàng bên ngoài không vào được vì DNS hoặc SSL lỗi.
4. Để file log tự do nuốt trọn ổ đĩa: Không cấu hình xoay vòng log (logrotate) khiến file access log phình lên 30–40 GB, lấp đầy ổ đĩa và gián tiếp kéo sập toàn bộ VPS. Quy trình xử lý khi ổ đĩa bị log nuốt trọn có thể tham khảo tại bài VPS đầy ổ đĩa: Nguyên nhân, dấu hiệu và cách phòng ngừa.

Checklist thiết lập bộ ba công cụ giám sát

• ☐ Đã có công cụ Uptime Check độc lập bên ngoài kiểm tra định kỳ 1–3 phút vào domain chính.
• ☐ Metric thu thập đủ 4 chỉ số vàng: Lưu lượng truy cập (Traffic), Độ trễ (Latency), Tỷ lệ lỗi (Error Rate) và Mức tiêu hao tài nguyên (Saturation).
• ☐ Các thông tin chi tiết về từng request (User ID, IP, Order ID) được đưa vào Log, không nhồi vào nhãn của Metric.
• ☐ File log có cơ chế xoay vòng (logrotate) và giới hạn ngày lưu trữ để không làm tràn ổ cứng máy chủ.
• ☐ Không ghi các thông tin nhạy cảm (mật khẩu, token xác thực, số thẻ ngân hàng) vào nội dung log.
• ☐ Có quy trình xử lý sự cố rõ ràng: Kiểm tra triệu chứng từ Uptime Check → Khoanh vùng thời điểm và thành phần bằng Metric → Mở Log để đọc chi tiết lỗi kỹ thuật. Để chọn đúng danh sách chỉ số và tín hiệu cần thiết cho máy chủ của bạn mà không thu thập dư thừa, hãy đọc bài trụ cột Nên monitoring những gì trên một VPS chạy website?.