Giám sát uptime và trang trạng thái server cho nhà cung cấp hosting nhỏ

Với nhà cung cấp hosting nhỏ, trang trạng thái server hiệu quả nhất khi Uptime Kuma chạy bên ngoài các server hosting, tốt nhất ở một nhà cung cấp khác, kiểm tra mọi dịch vụ khách hàng phụ thuộc (web, panel, email, DNS, SSL và backup), và công bố trang trạng thái trên subdomain riêng, nhóm theo server và dịch vụ. Khi có sự cố, bạn đăng thông báo lên trang đó trong vài phút và cập nhật đúng hẹn cho tới khi xử lý xong. Cách làm này giúp bạn biết sự cố trước khách hàng và giảm hẳn làn sóng tin nhắn "server sập à?".

Bài viết tập trung vào góc nhìn nhà cung cấp hosting: giám sát những gì, chuyển cảnh báo thế nào, bố cục trang trạng thái ra sao và viết cập nhật sự cố thế nào. Về cách cài và cấu hình Uptime Kuma, xem bài tự host Uptime Kuma.

Vì sao nhà cung cấp hosting cần cả giám sát lẫn trang trạng thái?

Giám sát và trang trạng thái giải quyết hai bài toán khác nhau.

• Giám sát là cho bạn. Nó trả lời "có gì đang hỏng không?" và gọi đúng người dậy xử lý.
• Trang trạng thái là cho khách hàng. Nó trả lời "lỗi do họ hay do mình?" mà không cần ticket, và cho thấy bạn đã biết và đang xử lý.

Khi bạn host vài trăm website, chỉ một sự cố ngắn cũng tạo ra hàng loạt tin nhắn qua email, Zalo, Telegram hay hệ thống ticket, tin nào cũng hỏi cùng một câu. Đặt link trang trạng thái trong email chào mừng, khu vực khách hàng và tin trả lời tự động của bộ phận hỗ trợ sẽ biến phần lớn số tin nhắn đó thành một lượt xem trang. Lâu dần nó còn tạo niềm tin: một lịch sử cập nhật sự cố trung thực thuyết phục hơn lời hứa "uptime 99,99%" trên trang bán hàng.

Nên chạy hệ thống giám sát ở đâu?

Quy tắc quan trọng nhất rất đơn giản: đừng giám sát server từ chính nó. Công cụ giám sát chạy trên server mà nó theo dõi sẽ sập cùng server đó và không báo được cho bạn. Tài liệu Uptime Kuma của ZoPanel cũng nói rõ: với giám sát production, hãy cài trên một server khác, tốt nhất ở nhà cung cấp khác.

Lớp	Phát hiện được	Bỏ sót
Kiểm tra ngay trên server (panel hoặc script nội bộ)	Website trả lỗi 5xx, pool PHP chết, dịch vụ bị dừng	Mất mạng, lỗi DNS, cả server sập
Giám sát bên ngoài, cùng nhà cung cấp	Server sập, dịch vụ sập, phần lớn sự cố mạng	Sự cố toàn vùng hoặc toàn mạng của nhà cung cấp
Giám sát bên ngoài, khác nhà cung cấp	Tất cả các lỗi trên, kể cả sự cố toàn nhà cung cấp	Lỗi chỉ một phần khách thấy (một quốc gia, một nhà mạng)

Cách làm thực tế cho hosting nhỏ: giữ các kiểm tra có sẵn của panel để có cảnh báo nhanh và chi tiết, và chạy Uptime Kuma trên một VPS nhỏ ở nhà cung cấp khác để có góc nhìn từ bên ngoài và trang trạng thái công khai. DNS của trang trạng thái cũng nên đặt ở nơi khác, không dùng nameserver của chính bạn, để trang vẫn phân giải được khi chính DNS server của bạn gặp sự cố.

Giám sát những gì trên mỗi server hosting?

Hãy giám sát những gì khách hàng dùng, không chỉ việc máy có trả lời ping hay không. Theo trang dự án, Uptime Kuma hỗ trợ các loại monitor HTTP(s), HTTP(s) keyword, TCP port, ping, DNS record, push và nhiều loại khác.

Monitor	Loại trong Uptime Kuma	Lý do
Một website canary trên mỗi server	HTTP(s) - Keyword	Chứng minh nginx, PHP và database đều trả lời; từ khóa bắt được trang lỗi vẫn trả mã 200
Control panel	HTTP(s)	Khách nhận ra ngay khi không đăng nhập được
SMTP (25), submission (465/587), IMAP (993)	TCP Port	Lỗi email sinh ra những ticket bực bội nhất
ns1 và ns2	DNS (truy vấn một bản ghi biết trước trên từng nameserver)	DNS lỗi thì mọi website trên mọi server đều như sập
Hạn SSL của panel và các website quan trọng	HTTP(s) bật cảnh báo hết hạn chứng chỉ	Phát hiện gia hạn thất bại trước trình duyệt
Backup hằng đêm và cron job quan trọng	Push	Job gọi một URL khi chạy xong; im lặng nghĩa là đã lỗi
Website công ty và khu vực khách hàng	HTTP(s)	Khách cần thanh toán và mở ticket ngay cả khi có sự cố

Với website canary, hãy tạo một trang PHP nhỏ chạy một truy vấn database và in ra một từ cố định, ví dụ canary-ok, rồi đặt monitor keyword vào đó. Đây là tín hiệu tốt hơn bất kỳ website khách hàng nào, vì website khách có thể lỗi vì lý do riêng.

Bạn không cần giám sát từng website khách hàng từ bên ngoài. Hãy theo dõi một canary cho mỗi server, cộng thêm những khách lớn hoặc quan trọng nếu hợp đồng có cam kết.

Quy tắc cảnh báo để không bị "ngợp"

Cảnh báo quá nhiều giết hệ thống giám sát nhanh hơn bất kỳ sự cố nào. Vài quy tắc:

• Thử lại trước khi báo. Đặt retries 1 hoặc 2 với chu kỳ 60 giây, để một phản hồi chậm không đánh thức ai.
• Phân luồng theo mức độ. Cả server sập thì báo lên điện thoại (Telegram hoặc gọi); một cảnh báo SSL thì gửi email là đủ.
• Dùng cửa sổ bảo trì. Uptime Kuma thêm tính năng bảo trì từ phiên bản 1.19.0, tạm tắt thông báo và hiện thông điệp bảo trì trên trang trạng thái. Hãy lên lịch cho các lần khởi động lại và nâng cấp có kế hoạch.
• Thử thông báo mỗi tháng. Nếu không, bot Telegram hết hạn token hay mật khẩu SMTP đã đổi chỉ bị phát hiện đúng lúc có sự cố thật.

Bố cục trang trạng thái thế nào?

Khách hàng nghĩ theo dịch vụ và server, nên hãy nhóm trang theo cách đó. Mỗi server một nhóm, mỗi dịch vụ một monitor, là cách phù hợp với hosting nhỏ:

Nhóm	Monitor hiển thị
Server hn1 (hosting dùng chung)	Websites, Control panel, Email (SMTP), Email (IMAP)
Server sg2 (hosting WordPress)	Websites, Control panel, Email
DNS	ns1.thuonghieu.vn, ns2.thuonghieu.vn
Dịch vụ công ty	Website, Khu vực khách hàng và thanh toán, Hỗ trợ

Đặt tên nhóm theo cách khách hàng biết. Nếu email chào mừng ghi "Server: hn1", trang trạng thái cũng nên ghi vậy. Đặt trang trên subdomain riêng, ví dụ status.thuonghieu.vn; Uptime Kuma hiển thị được các trang trạng thái khác nhau theo tên miền, như mô tả trong wiki status page. Cũng trang đó cho biết trang trạng thái công khai cache kết quả và tự làm mới mỗi năm phút, nên nó là công cụ thông báo, không phải bảng theo dõi thời gian thực.

Con số uptime nghĩa là gì?

Nếu bạn hiển thị phần trăm uptime, hãy biết nó cho phép bao nhiêu. Trong một tháng 30 ngày:

Uptime	Thời gian ngừng cho phép trong 30 ngày
99%	Khoảng 7 giờ 12 phút
99,9%	Khoảng 43 phút
99,95%	Khoảng 22 phút
99,99%	Khoảng 4 phút

Chỉ hứa những gì một server ở một nhà cung cấp có thể đạt được trên thực tế, và nhớ rằng trang trạng thái sẽ cho thấy sự thật dù thế nào.

Viết cập nhật sự cố

Trang trạng thái phát huy giá trị trong lúc có sự cố. Một mô hình được dùng rộng rãi đến từ Atlassian Statuspage, với tài liệu về sự cố định nghĩa bốn trạng thái:

Trạng thái	Ý nghĩa	Ví dụ cập nhật
Investigating	Thấy triệu chứng nhưng chưa rõ nguyên nhân	"Các website trên server hn1 không truy cập được. Chúng tôi đang kiểm tra."
Identified	Đã tìm ra nguyên nhân và đang sửa	"Một ổ đĩa trên hn1 bị hỏng. Chúng tôi đang chuyển sang ổ dự phòng, dự kiến 45 phút."
Monitoring	Đã khắc phục, đang theo dõi	"hn1 đã hoạt động trở lại. Chúng tôi đang theo dõi và kiểm tra hàng đợi email."
Resolved	Mọi thứ đã bình thường	"Đã xử lý xong. Gián đoạn từ 09:12 đến 09:58 (UTC+7). Báo cáo tóm tắt sẽ gửi qua email."

Những nguyên tắc giúp cập nhật thật sự hữu ích:

1. Đăng trong vài phút, dù điều duy nhất bạn biết là "đang kiểm tra". Im lặng mới là thứ khiến khách bực.
2. Nói rõ ai bị ảnh hưởng: server nào, dịch vụ nào. "Chỉ email trên hn1; website vẫn hoạt động" giúp bạn tránh cả trăm ticket.
3. Hẹn giờ cập nhật tiếp theo, ví dụ "cập nhật tiếp sau 30 phút", và giữ lời hẹn kể cả khi chưa có gì mới.
4. Dùng một múi giờ và ghi rõ. Với khách Việt Nam là UTC+7.
5. Viết báo cáo ngắn sau sự cố lớn: chuyện gì đã xảy ra, bạn đã thay đổi gì để không lặp lại.

Trong Uptime Kuma 1.x, sự cố là một thông báo được ghim trên đầu trang trạng thái, có tiêu đề, nội dung, kiểu hiển thị (như info, warning, danger) và thời điểm tạo, cập nhật lần cuối, như mã nguồn trang status page cho thấy. Hãy sửa cùng một thông báo cho mỗi lần cập nhật và ghi giờ ở từng dòng để lịch sử dễ đọc. Nếu cần tính năng như cho khách đăng ký nhận cập nhật sự cố, hãy kiểm tra phiên bản Uptime Kuma bạn dùng có hỗ trợ không, hoặc so sánh với dịch vụ status page có phí; dịch vụ có phí tốn tiền nhưng vẫn hoạt động độc lập với hạ tầng của bạn.

Giám sát và trang trạng thái với ZoPanel

ZoPanel tự lo phần giám sát bên trong. Nó kiểm tra từng website đang hoạt động qua nginx nội bộ và đánh dấu sập sau hai lần lỗi liên tiếp, có watchdog khởi động lại dịch vụ bị dừng hoặc treo, và gửi cảnh báo Website down, Service down or restarted, Disk almost full, SSL renewal failed và Fleet server unreachable qua email, Telegram hoặc webhook Discord/Slack. Khách hàng và đại lý có thể đăng ký cảnh báo riêng trong My account → Notifications (tài liệu vận hành).

Với góc nhìn bên ngoài và trang trạng thái, hãy cài Uptime Kuma từ App Store trên một server ZoPanel khác, tốt nhất ở nhà cung cấp khác. Ứng dụng cần 512 MB RAM, có subdomain riêng với chứng chỉ Let's Encrypt, nằm sau khóa thiết lập cho tới khi bạn tạo tài khoản quản trị, và được backup từ tab Docker (tài liệu ứng dụng Uptime Kuma).

Những hạn chế cần biết. Catalog của ZoPanel dùng dòng Uptime Kuma 1.x, trong khi Uptime Kuma 2.0 đã ra mắt tháng 10/2025, nên bạn sẽ không có tính năng của bản 2.0 từ image trong App Store. Và vì ứng dụng chạy trong container có tường lửa, nó không kiểm tra được SSH, MariaDB hay Redis trên cùng server, cũng như mạng nội bộ; đó thêm lý do để chạy nó trên server khác. Xem trang tính năng vận hành để biết những gì ZoPanel tự giám sát.

Kết luận

Một hệ thống giám sát hữu ích cho nhà cung cấp hosting nhỏ không phức tạp: kiểm tra có sẵn trên từng server, một Uptime Kuma bên ngoài ở nhà cung cấp khác theo dõi website canary, email, DNS, SSL và backup, và một trang trạng thái công khai trên subdomain riêng. Thói quen quan trọng nhất là giao tiếp: đăng sớm, nói rõ ai bị ảnh hưởng, và cập nhật đúng hẹn cho tới khi viết được chữ "Resolved".

Nếu bạn đang xây dựng doanh nghiệp hosting, bài bắt đầu kinh doanh hosting nói về các phần còn lại. Gói Free của ZoPanel có App Store, kiểm tra uptime và cảnh báo có sẵn, cho 3 tài khoản hosting, 10 website, không giới hạn thời gian.

Câu hỏi thường gặp

Có nên đặt trang trạng thái trên cùng server với website của khách không?

Được, nhưng nó sẽ sập đúng lúc khách cần nó nhất. Hãy chạy trang trạng thái và công cụ giám sát trên server riêng, tốt nhất ở nhà cung cấp khác, và để DNS của nó nằm ngoài nameserver của bạn.

Uptime Kuma có đủ tốt cho công ty hosting không?

Với hosting nhỏ và vừa thì thường là đủ: miễn phí theo giấy phép MIT, hỗ trợ nhiều loại monitor và hơn 90 dịch vụ thông báo, và phục vụ trang trạng thái công khai trên tên miền của bạn. Nhà cung cấp lớn hơn đôi khi chọn dịch vụ status page có phí vì cần thông báo cho người đăng ký và độc lập với hạ tầng của mình.

Monitor nên kiểm tra bao lâu một lần?

Cứ 60 giây một lần với một hoặc hai lần thử lại là mặc định tốt cho web và email. Backup và cron job dùng monitor push với khoảng thời gian khớp lịch chạy, ví dụ 25 giờ cho backup hằng đêm.

Nếu chính server giám sát bị sập thì sao?

Thêm một kiểm tra rất đơn giản cho nó từ một dịch vụ khác, ví dụ một công cụ kiểm tra uptime miễn phí trỏ vào trang trạng thái. Như vậy bạn sẽ biết khi hệ thống giám sát im lặng.

Có nên công khai phần trăm uptime không?

Có, nếu bạn tự tin vào con số. Số liệu trung thực trong 30 hoặc 90 ngày tạo niềm tin; lời hứa phóng đại thì ngược lại, vì khách có thể so với những gì họ thực sự trải qua.