Rất nhiều hệ thống giám sát website hiện nay được cài đặt theo cách đơn giản nhất: cứ mỗi 1 đến 5 phút, một con bot tự động gửi một lệnh HTTP GET tới trang chủ, nếu máy chủ trả về mã trạng thái 200 OK thì đánh dấu là website đang sống và hiển thị chấm xanh trên màn hình.
Cách kiểm tra này cho cảm giác an tâm giả tạo. Mã HTTP 200 thực chất chỉ có ý nghĩa kỹ thuật ở tầng giao thức: máy chủ web hoặc dịch vụ CDN đã tiếp nhận request và trả về một gói tin phản hồi. Nó hoàn toàn không biết bên trong gói tin đó chứa thứ gì.
Thực tế đã có vô số sự cố dở khóc dở cười diễn ra: cơ sở dữ liệu bị sập hoặc cạn kết nối, ứng dụng web bắt lỗi và render ra một trang trắng tinh chỉ có dòng chữ "Error establishing a database connection" nhưng mã HTTP trả về vẫn là 200. Hay trường hợp website đang bị chuyển hướng (redirect) nhầm sang một trang thông báo bảo trì, trang cá cược, hoặc Cloudflare đang phục vụ một bản cache tĩnh từ 3 ngày trước trong khi máy chủ gốc (origin) bên dưới đã chết từ lâu. Trong tất cả các kịch bản đó, công cụ uptime check chỉ nhìn vào mã 200 sẽ vẫn tươi cười báo "hệ thống bình thường", trong khi khách hàng thì không thể xem sản phẩm hay đặt mua bất cứ thứ gì.
Một cấu hình uptime check thực sự bảo vệ được doanh nghiệp cần đi trọn vẹn theo hành trình truy cập của người dùng: từ phân giải DNS, bắt tay TLS, kiểm soát chuyển hướng đến việc quét đúng từ khóa nội dung và đo lường độ trễ phản hồi.
Một lượt kiểm tra tốt theo dõi cả hành trình, không chỉ dừng ở mã trạng thái HTTP.
Hành trình 4 bước của một lượt kiểm tra chuẩn
Người dùng vào website không bao giờ gõ trực tiếp vào địa chỉ IP của VPS hay gọi vào tiến trình container nội bộ. Họ gõ tên miền lên trình duyệt. Công cụ giám sát từ bên ngoài (Black-box Monitoring) cũng phải đi đúng 4 chặng đường đó để phát hiện điểm đứt gãy:
1. Phân giải tên miền (DNS Resolution)
Trước khi gửi bất kỳ gói tin nào, công cụ phải kiểm tra xem tên miền của bạn có trỏ về đúng địa chỉ IP mong đợi hay không. Tên miền quên gia hạn, bản ghi DNS bị đổi nhầm, hay hệ thống máy chủ DNS của nhà cung cấp gặp trục trặc sẽ khiến khách hàng mất dấu website ngay từ bước đầu tiên.
2. Bắt tay bảo mật (TLS/SSL Handshake)
Với các website chạy HTTPS, công cụ cần xác minh chứng chỉ SSL có hợp lệ không, tên miền trên chứng chỉ có khớp không, và quan trọng nhất là còn hạn sử dụng bao nhiêu ngày. Nhiều công cụ chỉ kiểm tra kết nối TCP thông thường mà bỏ qua tầng TLS, đến khi chứng chỉ hết hạn làm trình duyệt hiện màn hình cảnh báo đỏ lòm thì hệ thống giám sát vẫn báo xanh.
Chi tiết về cách theo dõi chứng chỉ trước khi bị động có thể xem tại bài viết Theo dõi SSL và domain hết hạn: Đặt cảnh báo bao nhiêu ngày trước?.
3. Chuỗi chuyển hướng (Redirect Chain)
Chuyển hướng từ http:// sang https:// hoặc từ www về tên miền chính là hành vi bình thường. Nhưng công cụ kiểm tra cần biết điểm đến cuối cùng của chuỗi chuyển hướng đó là ở đâu.
Nếu bạn chỉ bật tùy chọn tự động đi theo chuyển hướng ("follow redirects") mà không kiểm tra URL đích, website có thể bị chuyển hướng nhầm sang một trang đăng nhập tài khoản của bên thứ ba, hoặc bị hacker can thiệp cấu hình trỏ sang một trang web lạ, và công cụ giám sát vẫn nhận được mã 200 ở trang đích đó rồi báo là đạt. Hãy đảm bảo công cụ kiểm tra xác nhận được tên miền đích và giao thức cuối cùng vẫn là HTTPS của chính bạn.
4. Quét từ khóa nội dung (Content Match / Keyword Assertion)
Đây chính là bước chốt hạ để phân biệt giữa "máy chủ trả về mã 200" và "website thực sự đang phục vụ nội dung". Bạn cấu hình để công cụ quét trong nội dung HTML trả về xem có chứa một chuỗi văn bản cố định hay không.
Chọn từ khóa nội dung (Marker): Nên chọn từ nào để không báo động giả?
Kiểm tra nội dung không có nghĩa là bạn bắt công cụ phải so khớp từng chữ trong toàn bộ file HTML của trang. Các website hiện đại thường có nhiều thành phần thay đổi liên tục: ngày tháng, bài viết mới nhất trên trang chủ, banner quảng cáo xoay vòng, hoặc mã băm ngẫu nhiên của các file script sau mỗi lần build. Nếu so khớp toàn bộ trang, mỗi lần bạn đăng bài viết mới là công cụ uptime lại réo chuông báo hỏng.
Để kiểm tra hiệu quả, bạn nên chọn một chuỗi văn bản đặc trưng thỏa mãn hai điều kiện: không bao giờ đổi theo ngày và chỉ xuất hiện khi ứng dụng render thành công:
- Từ khóa nên chọn: Tên thương hiệu ở phần chân trang (footer), mã số đăng ký kinh doanh cố định, hoặc một đoạn text bản quyền dạng
© 2026 Tên Doanh Nghiệp. Bạn cũng có thể chọn một thuộc tính HTML đặc trưng nhưid="main-navigation"hoặcid="app-root". - Từ khóa không nên chọn: Tiêu đề bài viết mới, câu slogan tiếp thị thường xuyên thay đổi theo chiến dịch, hoặc các từ ngữ quá chung chung như
"Home"hay"Trang chủ"(vì ngay cả trang báo lỗi đôi khi vẫn có nút quay về "Trang chủ").
Ngoài ra, với các ứng dụng có trang thông báo lỗi riêng, bạn có thể thiết lập thêm một lớp kiểm tra phủ định: nếu nội dung xuất hiện các cụm từ như "Error establishing a database connection", "502 Bad Gateway" hay "Website đang bảo trì", công cụ phải lập tức đánh dấu là thất bại dù mã phản hồi có là 200 đi chăng nữa.
Bẫy CDN Cache: Khi trang chủ vẫn xanh nhưng bên trong đã sập
Nếu bạn sử dụng Cloudflare hay các dịch vụ CDN tương tự ở phía trước VPS, tính năng lưu cache trang tĩnh có thể trở thành một cái bẫy đối với uptime monitor.
Khi máy chủ gốc của bạn bị sập nguồn hoặc database quá tải, CDN vẫn có thể lưu bản sao của trang chủ và phục vụ cho công cụ giám sát trong nhiều giờ. Công cụ kiểm tra gọi vào trang chủ thấy mã 200, nội dung vẫn đầy đủ tên công ty nên báo xanh bình thường. Nhưng khi khách hàng thật vào trang sản phẩm, bấm vào giỏ hàng hoặc thực hiện tìm kiếm — những tính năng bắt buộc phải gọi về máy chủ gốc — thì toàn bộ đều bị treo hoặc báo lỗi.
Để tránh điểm mù này, bạn nên phối hợp 2 đầu kiểm tra:
- Một kiểm tra ở trang chủ (Homepage): Chạy thường xuyên mỗi 1–2 phút để kiểm tra lớp ngoài cùng (DNS, CDN, SSL, kết nối mạng toàn cầu).
- Một kiểm tra ở endpoint động hoặc trang sản phẩm cụ thể: Chạy thưa hơn (mỗi 3–5 phút) vào một đường dẫn không bị CDN cache cứng (ví dụ một trang chi tiết sản phẩm hoặc một URL tra cứu nhẹ). Request này bắt buộc ứng dụng phải kết nối vào database để lấy dữ liệu ra render. Nếu database chết hoặc connection pool cạn kiệt, kiểm tra này sẽ lập tức phát hiện ra ngay.
Kiểm tra Homepage công khai hay dùng endpoint /health?
Nhiều lập trình viên thích tạo một đường dẫn riêng như /health hoặc /api/healthz trả về JSON {"status": "ok"} để cho công cụ giám sát gọi vào. Cách này có ưu điểm là rất nhẹ cho máy chủ, không tốn băng thông và cấu trúc JSON rất dễ kiểm tra chính xác.
Tuy nhiên, bạn cần nhớ rõ endpoint /health trả lời cho câu hỏi nào:
- Nó chỉ xác nhận ứng dụng bên trong container hoặc tiến trình web đang chạy.
- Nó không kiểm tra được việc giao diện website có render được ra cho người dùng không, mã JavaScript có bị lỗi khiến trang trắng xóa hay không, và người dùng ngoài mạng Internet có bị chặn bởi CDN hay lỗi chứng chỉ SSL hay không.
Vì vậy, giải pháp tối ưu là dùng endpoint /health cho các hệ thống giám sát nội bộ (như Docker healthcheck để biết khi nào cần khởi động lại container — xem bài Healthcheck Docker Compose: Kiểm tra những gì?), còn với công cụ uptime giám sát từ bên ngoài Internet, bạn phải luôn kiểm tra một trang web thực tế mà người dùng truy cập.
Theo dõi độ trễ phản hồi (Response Latency)
Một trang web mất tới 20 hoặc 30 giây mới tải xong thì về mặt trải nghiệm người dùng, nó chẳng khác gì đã sập. Khách hàng sẽ tắt tab trình duyệt và rời đi chỉ sau 3 đến 5 giây chờ đợi.
Vì vậy, một công cụ uptime tốt không chỉ ghi nhận kết quả Đạt hay Trượt, mà còn phải ghi lại thời gian phản hồi:
- Đặt ngưỡng timeout hợp lý (ví dụ: nếu sau 10 giây không nhận được phản hồi thì tính là một lần thất bại).
- Khi thấy độ trễ tăng đột biến từ mức bình thường 200 ms lên 4.000 ms, bạn đã có một tín hiệu cảnh báo sớm rằng máy chủ đang bị quá tải hoặc database đang gặp câu lệnh truy vấn bị nghẽn (xem bài Monitoring Database: Những chỉ số quan trọng nhất).
Giảm thiểu cảnh báo giả từ mạng Internet
Hạ tầng mạng Internet không phải lúc nào cũng hoàn hảo 100%. Thỉnh thoảng có thể xảy ra tình trạng đứt cáp cục bộ, một trạm kiểm tra ở châu Âu bị lag trong 10 giây, hoặc mạng giữa công cụ giám sát và VPS bị rớt gói tin nhất thời. Nếu cứ có 1 request bị lỗi mà hệ thống đã gửi tin nhắn đánh thức bạn lúc 3h sáng thì rất phiền phức.
Để loại bỏ các cảnh báo nhiễu này, bạn nên áp dụng hai quy tắc:
- Kiểm tra lặp lại trước khi báo động: Chỉ kích hoạt cảnh báo khi công cụ ghi nhận thất bại liên tiếp trong 2 đến 3 lần kiểm tra (tương đương website bị lỗi liên tục từ 2 đến 5 phút).
- Xác nhận từ nhiều vị trí (Multi-location check): Nếu công cụ hỗ trợ nhiều điểm kiểm tra (Singapore, Nhật Bản, Mỹ), hãy chỉ phát cảnh báo khi ít nhất 2 địa điểm khác nhau cùng ghi nhận website không thể truy cập.
Bạn có thể đọc thêm bài viết Log, Metric và Uptime Check khác nhau thế nào? để hiểu cách kết hợp uptime check bên ngoài với các số liệu metric bên trong máy chủ.
Checklist cấu hình một lượt Uptime Check hoàn chỉnh
- ☐ Công cụ kiểm tra đặt ở bên ngoài máy chủ VPS, tốt nhất là dịch vụ giám sát đám mây độc lập.
- ☐ Kiểm tra đầy đủ từ tên miền (DNS), chứng chỉ bảo mật (SSL/TLS) đến mã trạng thái HTTP.
- ☐ Chuỗi chuyển hướng (redirect) được xác nhận điểm đến cuối cùng đúng là tên miền HTTPS của website.
- ☐ Có cấu hình kiểm tra từ khóa nội dung (chuỗi text cố định ở footer, mã bản quyền hoặc thẻ HTML nhận diện), không chỉ trông chờ vào mã HTTP 200.
- ☐ Có cơ chế phát hiện các trang báo lỗi database hoặc lỗi bảo trì giả dạng mã 200.
- ☐ Không chỉ kiểm tra trang chủ đã bị CDN cache; có thêm kiểm tra vào một trang động chạm tới cơ sở dữ liệu.
- ☐ Đặt ngưỡng timeout (tối đa 5–10 giây) để phát hiện tình trạng website bị treo đơ.
- ☐ Cài đặt điều kiện cảnh báo sau ít nhất 2 lần thất bại liên tiếp hoặc xác nhận từ 2 vị trí khác nhau để lọc bỏ kết nối chập chờn.
- ☐ Tin nhắn cảnh báo gửi về ghi rõ website bị lỗi ở bước nào: lỗi DNS, hết hạn SSL, lỗi mã phản hồi, hay không tìm thấy nội dung trang. Giám sát bên ngoài chỉ là một phần của hệ thống quan sát; bạn nên kết hợp với giám sát tài nguyên bên trong theo bài Nên monitoring những gì trên một VPS chạy website?.
