Giám sát uptime website là việc để một công cụ tự động kiểm tra xem website có truy cập được không, theo một chu kỳ cố định, và báo cho bạn ngay khi trang không trả lời đúng cách. Đây khác với việc theo dõi xem nội dung trang có bị ai đó chỉnh sửa trái phép hay không — phần theo dõi nội dung thay đổi là một việc riêng, không nằm trong bài này.
Bài này nói về phần giám sát khả năng truy cập (uptime): cách một vòng kiểm tra diễn ra, mã trạng thái nào nên cảnh báo, và cách đặt ngưỡng cảnh báo để không bị báo động giả. Việc này thường được đưa vào lịch chăm sóc website cùng các việc kỹ thuật khác.
Giám sát uptime website là gì
Một công cụ giám sát uptime gửi yêu cầu tới website của bạn theo chu kỳ đều đặn, từ một hoặc nhiều vị trí, rồi ghi lại trang có trả lời đúng không và mất bao lâu để trả lời. Khi một lần kiểm tra thất bại, công cụ gửi cảnh báo qua email, tin nhắn hoặc ứng dụng, để bạn biết sự việc ngay, không phải chờ khách hàng báo trang không vào được nữa.
Một vòng kiểm tra uptime diễn ra thế nào
Mỗi lần kiểm tra đi qua bốn bước:
- Tra địa chỉ (DNS): tìm địa chỉ IP tương ứng với tên miền.
- Kết nối: mở kết nối tới server, bắt tay TLS nếu trang dùng HTTPS.
- Gửi yêu cầu: gửi một yêu cầu, thường là GET, tới địa chỉ cần kiểm tra.
- Đánh giá kết quả: xem mã trạng thái trả về, thời gian phản hồi, và đôi khi cả nội dung trang có đúng như kỳ vọng không.
Một lần kiểm tra được tính là “qua” khi trang trả lời đúng mã mong đợi trong thời gian cho phép, và tính là “lỗi” khi trang trả mã lỗi, không trả lời (hết thời gian chờ), hoặc trả lời nhưng thiếu nội dung mong đợi.
Mã trạng thái HTTP nào cần cảnh báo, mã nào không
| Nhóm mã | Ý nghĩa | Có nên cảnh báo không |
|---|---|---|
| 2xx (ví dụ 200) | Server xử lý thành công yêu cầu | Không, đây là trạng thái bình thường |
| 3xx (chuyển hướng) | Trang đã chuyển sang địa chỉ khác | Không, trừ khi bạn không chủ ý đặt chuyển hướng ở đó |
| 4xx (ví dụ 404) | Lỗi phía yêu cầu, ví dụ địa chỉ không tồn tại | Có, nếu xảy ra ở URL quan trọng đang cần hoạt động |
| 5xx (ví dụ 500, 502, 503) | Lỗi phía server, server gặp sự cố hoặc quá tải | Có, đây là dấu hiệu rõ nhất của một sự cố thật |
| Hết thời gian chờ (timeout) | Server không trả lời trong thời gian cho phép | Có, thường nghiêm trọng hơn cả mã lỗi vì trang có thể đã treo hẳn |
Một ngoại lệ cần nhớ: nếu bạn chủ động bật chế độ bảo trì và trả về mã 503 có chủ đích (xem mẫu thông báo bảo trì website và bài lỗi 503 Service Unavailable), đừng để công cụ giám sát hiểu đó là sự cố ngoài ý muốn — nên tạm dừng cảnh báo trong đúng khoảng thời gian bảo trì đã lên lịch trước.
Vì sao mã 200 chưa chắc là site đang chạy đúng
Một trang có thể trả về mã 200 (thành công) nhưng vẫn đang hỏng: trang trắng, thông báo lỗi hiển thị trong một khung có mã 200 bên ngoài, trang cache cũ không cập nhật, hoặc trang hiển thị đúng cho máy chủ giám sát nhưng sai cho người dùng thật ở một khu vực khác. Vì vậy, ngoài kiểm mã trạng thái, nên thêm kiểm từ khoá: xem trang trả về có chứa một đoạn chữ cố định mong đợi không, ví dụ tên sản phẩm hoặc một đoạn chữ ở chân trang. Nếu đoạn chữ đó biến mất trong khi mã vẫn là 200, đó vẫn là một sự cố cần biết sớm.
Thiết lập cảnh báo tránh báo động giả
- Xác nhận lại trước khi báo: yêu cầu vài lần kiểm tra liên tiếp đều lỗi mới gửi cảnh báo, tránh báo động vì một lần mạng chập chờn.
- Kiểm từ nhiều vị trí: nếu chỉ một vị trí báo lỗi còn các vị trí khác vẫn thấy trang hoạt động, nhiều khả năng vấn đề nằm ở đường truyền tới vị trí đó, không phải ở server của bạn.
- Theo dõi luôn chứng chỉ bảo mật: thêm cảnh báo khi chứng chỉ SSL/TLS sắp hết hạn, vì hết hạn chứng chỉ cũng làm trang không truy cập được dù server vẫn chạy bình thường.
- Đặt thời gian chờ hợp lý: dựa theo thời gian phản hồi thực tế của trang, để một trang chạy chậm nhưng vẫn lên được không bị tính nhầm thành lỗi.
- Kiểm đúng đường dẫn người dùng thật ghé: không chỉ kiểm trang chủ, mà cả các trang quan trọng như trang sản phẩm, form liên hệ, hoặc luồng đặt hàng nếu trang có bán hàng.
Chu kỳ kiểm tra theo mức độ quan trọng của site
Không phải website nào cũng cần kiểm tra cùng một nhịp. Website có bán hàng hoặc nhận đơn trực tiếp cần chu kỳ ngắn hơn, vì mỗi phút không vào được là mất khách ngay lúc đó. Website chủ yếu để giới thiệu, ít giao dịch trực tiếp, có thể chấp nhận chu kỳ dài hơn mà không ảnh hưởng nhiều tới hoạt động kinh doanh. Nguyên tắc chung: chu kỳ ngắn phát hiện sự cố nhanh hơn, nhưng cũng tạo nhiều yêu cầu hơn tới server và nhiều cảnh báo hơn nếu không đặt ngưỡng xác nhận hợp lý như phần trên đã nói.
Các kiểu kiểm tra bổ sung ngoài kiểm tra HTTP
Kiểm tra HTTP là kiểu phổ biến nhất, nhưng không phải kiểu duy nhất. Tuỳ vào website và hạ tầng phía sau, có thể kết hợp thêm:
- Kiểm tra ping hoặc TCP: xem một cổng cụ thể trên server có mở và trả lời không, thường dùng cho các dịch vụ không phải trang web như email hoặc cơ sở dữ liệu chạy cùng server.
- Kiểm tra DNS: phát hiện khi bản ghi DNS của tên miền bị đổi sai, hoặc tên miền gần tới ngày hết hạn mà quên gia hạn, đều có thể khiến website không truy cập được dù server vẫn chạy bình thường.
- Kiểm tra từ khoá trong nội dung: như đã nói ở phần mã 200 phía trên, xác nhận trang vẫn chứa đúng nội dung mong đợi, không chỉ dựa vào mã trạng thái.
- Kiểm tra chứng chỉ SSL/TLS: cảnh báo trước khi chứng chỉ hết hạn, tách riêng khỏi cảnh báo trang không truy cập được, vì nguyên nhân và cách xử lý khác nhau.
Kết hợp vài kiểu kiểm tra này cho một bức tranh đầy đủ hơn một kiểm tra HTTP đơn lẻ, đặc biệt với website có nhiều dịch vụ chạy cùng lúc trên cùng một hạ tầng.
Việc cần làm khi có cảnh báo downtime
- Xác nhận sự cố thật bằng cách tự mở trang từ một thiết bị hoặc mạng khác, tránh trường hợp chỉ máy giám sát bị lỗi.
- Xem mã lỗi trả về là gì, so với bảng ở trên, để đoán hướng xử lý: 5xx thường do server, 4xx thường do cấu hình hoặc đường dẫn.
- Kiểm xem có đang trong cửa sổ bảo trì đã lên lịch không, để tránh xử lý nhầm một việc đã biết trước.
- Nếu nguyên nhân liên quan tới một thay đổi gần đây, vừa cập nhật plugin hoặc vừa đổi cấu hình, ưu tiên lùi lại thay đổi đó trước khi tìm nguyên nhân khác.
- Ghi lại thời điểm, nguyên nhân và cách xử lý sau khi sự cố kết thúc, để lần sau xử lý nhanh hơn.
Thêm giám sát uptime vào lịch chăm sóc website của bạn
Gửi brief: website đang chạy ở đâu, mức độ quan trọng của việc trang phải luôn truy cập được. VIDCO trao đổi phạm vi giám sát và báo giá theo nhu cầu thực tế.
Nguồn tham khảo
Thông tin trong bài được đối chiếu với các nguồn chính thức dưới đây tại thời điểm biên soạn; văn bản và chính sách có thể thay đổi.
- Pause Your Online Business Gracefully (Google Search Central)
- How to Deal with Planned Site Downtime (Google Search Central Blog)
- Retry-After Header – HTTP References (MDN)
Câu hỏi thường gặp
Giám sát uptime có phải là giám sát bảo mật không?
Không hoàn toàn. Giám sát uptime chỉ trả lời câu hỏi trang có truy cập được không. Phát hiện lỗ hổng hay mã độc cần công cụ quét riêng, xem bài kiểm tra bảo mật website.
Nên kiểm tra uptime bao lâu một lần?
Tuỳ mức độ quan trọng của trang. Trang có bán hàng hoặc nhận đơn nên kiểm chu kỳ ngắn, trang giới thiệu đơn giản có thể chấp nhận chu kỳ dài hơn, miễn vẫn kịp phát hiện sự cố trước khi ảnh hưởng nhiều khách.
Bật chế độ bảo trì có bị công cụ giám sát báo lỗi không?
Có thể, nếu bạn không tạm dừng giám sát trong đúng khoảng bảo trì. Mã 503 khi bảo trì có chủ đích khác với 503 do sự cố ngoài ý muốn, nên cần phân biệt rõ khi đọc cảnh báo.
Uptime 100 phần trăm có thực tế không?
Không nền tảng nào đảm bảo tuyệt đối mọi lúc, vì còn phụ thuộc hosting, mạng, và cả các dịch vụ bên ngoài website kết nối tới. Mục tiêu thực tế là phát hiện và xử lý sự cố nhanh, không phải triệt tiêu hoàn toàn khả năng xảy ra sự cố.
