Login

Healthcheck và alerting: báo động đúng lúc, không báo động giả

  • author-image

    Nguyễn Đình Cường

  • blog-tag
  • blog-comment 0 comment
  • created-date 09 Nov, 2026
blog-thumbnail

Hệ thống tốt nhất cũng sẽ có lúc hỏng. Điều tạo nên khác biệt là bạn biết ngay hay chỉ biết khi khách phàn nàn. Healthcheck và cảnh báo là cặp công cụ giúp bạn nhận tin xấu sớm, nhưng chỉ khi chúng được thiết kế cẩn thận để không biến thành tiếng ồn.

Healthcheck là gì?

Healthcheck (kiểm tra sức khỏe) là một điểm cuối hoặc lệnh đơn giản để hỏi 'ứng dụng còn khỏe không?'. Thường là đường dẫn như /health trả về mã 200 nếu mọi thứ ổn. Có hai mức nên phân biệt:

  • Liveness: tiến trình còn sống và không bị treo không? Nếu không, cần khởi động lại.
  • Readiness: ứng dụng đã sẵn sàng nhận yêu cầu chưa, như đã kết nối được database chưa? Nếu chưa, đừng gửi lưu lượng đến.

Ví dụ một endpoint đơn giản bằng Node.js với Express:

app.get('/health', async (req, res) => {
  try {
    await db.query('SELECT 1');
    res.status(200).json({ status: 'ok' });
  } catch (e) {
    res.status(503).json({ status: 'database_unavailable' });
  }
});

Điểm cần lưu ý: kiểm tra phải nhẹ và nhanh, không thực hiện công việc nặng, và không lộ thông tin nhạy cảm ra bên ngoài.

Healthcheck trong Docker

HEALTHCHECK --interval=30s --timeout=3s --retries=3 CMD wget -qO- http://localhost:3000/health || exit 1

Docker sẽ gắn nhãn container là healthy hoặc unhealthy. Các công cụ điều phối dựa vào đây để tự khởi động lại hoặc ngừng gửi lưu lượng. Hãy chắc rằng image có sẵn công cụ (như wget hoặc curl) để chạy lệnh kiểm tra.

Giám sát từ bên ngoài

Kiểm tra từ trong máy chủ không phát hiện được lỗi DNS, chứng chỉ hết hạn hay đường truyền. Hãy có một dịch vụ giám sát uptime bên ngoài, định kỳ truy cập địa chỉ công khai của bạn từ nhiều nơi và báo khi lỗi. Một số dịch vụ có gói miễn phí đủ dùng cho dự án nhỏ; hãy kiểm tra điều khoản hiện hành của từng nhà cung cấp.

Nguyên tắc thiết kế cảnh báo tốt

  1. Cảnh báo phải cần hành động: nếu nhận tin mà không cần làm gì, đó không phải cảnh báo mà là thông tin.
  2. Báo triệu chứng, không chỉ nguyên nhân: 'người dùng đang gặp lỗi' quan trọng hơn 'CPU 85%'.
  3. Có ngưỡng và thời gian kéo dài: chỉ báo khi tình trạng xấu kéo dài vài phút, để tránh báo lẻ tẻ do dao động ngắn.
  4. Mỗi cảnh báo kèm hướng dẫn: liên kết tới tài liệu xử lý hoặc bảng điều khiển liên quan.
  5. Phân mức độ: khẩn cấp cần báo ngay (gọi, nhắn tin), thông thường chỉ cần email hoặc kênh chat.

Mệt mỏi vì cảnh báo

Khi cảnh báo quá nhiều và phần lớn là báo giả, mọi người sẽ bắt đầu phớt lờ chúng, kể cả cảnh báo thật. Đây là hiện tượng 'alert fatigue' và nguy hiểm hơn nhiều so với việc thiếu cảnh báo. Hãy định kỳ rà soát: cảnh báo nào chưa bao giờ dẫn đến hành động thì xóa hoặc hạ mức; cảnh báo nào hay báo giả thì chỉnh ngưỡng.

Những cảnh báo nên có từ đầu

  • Trang web hoặc API không truy cập được.
  • Tỉ lệ lỗi 5xx tăng cao kéo dài.
  • Ổ đĩa sắp đầy.
  • Chứng chỉ SSL sắp hết hạn.
  • Sao lưu thất bại hoặc không chạy.
  • Hàng đợi tác vụ tồn đọng bất thường.

Chuẩn bị cho người nhận cảnh báo

Nếu đội có người trực (on-call), hãy quy định rõ ai nhận khi nào, cách chuyển giao và quy trình leo thang nếu người đầu tiên không phản hồi. Với dự án cá nhân, ít nhất hãy đảm bảo cảnh báo đến một kênh bạn thật sự nhìn thấy. Đừng quên thử nghiệm bằng cách gây lỗi giả để chắc chắn tin nhắn đến nơi.

Kết luận

Healthcheck cho hệ thống biết tình trạng của mình, cảnh báo cho con người biết khi cần ra tay. Làm đúng nghĩa là ít mà chất: chỉ báo điều quan trọng, báo kịp thời và kèm hướng xử lý.

Nếu bạn muốn học cách xây dựng quy trình vận hành đáng tin cậy, hãy tham khảo các khóa học tại codebem.com.

author_photo
Nguyễn Đình Cường

0 comment