Nên monitoring những gì trên một VPS chạy website?

Website vừa dựng xong, bạn cấu hình xong Nginx, database và Docker Compose rồi mở trình duyệt thấy trang chủ load mượt mà. Trong trang quản trị của nhà cung cấp VPS, biểu đồ tài nguyên hiển thị CPU chỉ 10%, RAM còn trống một nửa. Cảm giác lúc đó thường là mọi thứ đã đâu vào đấy và có thể yên tâm để hệ thống tự chạy.

Thực tế vận hành thường không êm ả như vậy. Vài tuần sau, khách hàng nhắn tin báo không đặt được hàng từ tối qua. Bạn vào kiểm tra: máy chủ vẫn đang bật, CPU vẫn thấp, nhưng chứng chỉ SSL đã hết hạn lúc nửa đêm khiến trình duyệt chặn người dùng từ ngoài cửa. Hoặc một lần khác, Nginx vẫn sống nhưng container ứng dụng crash ngầm, trả về trang lỗi 502 suốt nhiều giờ mà không một ai trong nội bộ hay biết.

Một chiếc VPS đang bật nguồn không đồng nghĩa với việc website đang phục vụ được khách. Giám sát máy chủ vì thế không phải là mở dashboard lên ngắm biểu đồ cho yên tâm, mà là để trả lời hai việc rất thực tế: người dùng bên ngoài có vào được web không, và nếu sắp có sự cố thì bạn có phát hiện ra trước khi khách hàng phàn nàn hay không.

Phân biệt giữa theo dõi, xem biểu đồ và nhận cảnh báo

Nhiều người mới làm hệ thống thường gom chung việc theo dõi, xem dashboard và nhận cảnh báo lại làm một. Ba việc này phục vụ các mục đích khác nhau khi bạn làm việc:

• Monitoring (Thu thập dữ liệu): Hệ thống âm thầm ghi lại các chỉ số theo chu kỳ: mã phản hồi HTTP, dung lượng đĩa còn lại, thời gian chạy query database hay mức RAM khả dụng.
• Dashboard (Bảng tra cứu): Nơi gom các chỉ số đó thành biểu đồ. Dashboard chủ yếu dùng để đối chiếu khi có sự cố hoặc để xem xu hướng tăng trưởng theo tuần, theo tháng. Bạn không thể ngồi nhìn dashboard cả ngày.
• Alert (Cảnh báo gọi người): Tin nhắn gửi thẳng vào Telegram, Slack hoặc email khi có việc cần người vào can thiệp.

Vấn đề phổ biến nhất khi mới bắt đầu là cái gì cũng muốn gửi cảnh báo. Thấy CPU chạm 85% trong vài chục giây hay có bot quét vài đường link 404 cũng bắn thông báo về nhóm chat. Chỉ sau vài ngày, tiếng chuông thông báo liên tục sẽ khiến mọi người bấm tắt chuông (mute kênh). Đến khi website sập thật, tin nhắn quan trọng nhất lại bị trôi mất.

Một cảnh báo đáng để gửi đi phải gắn với hành động cụ thể. Đó có thể là tác động người dùng, tài nguyên đang tiến gần giới hạn, backup hoặc job nghiệp vụ không chạy đúng hạn, hay một dấu hiệu bảo mật cần được kiểm tra. Các chỉ số chỉ dùng để giải thích bối cảnh nên nằm trên dashboard thay vì gửi thành notification riêng.

Bài viết Thiết kế cảnh báo có thể hành động trình bày kỹ hơn cách lọc bớt thông báo rác và chọn kênh gửi tin phù hợp.

Lớp 1: Khách hàng bên ngoài có vào được website không? (Black-box Monitoring)

Đây thường là lớp nên triển khai đầu tiên vì nó phản ánh điều người dùng nhìn thấy. Điểm kiểm tra phải nằm ngoài chiếc VPS đang được giám sát, chẳng hạn một dịch vụ uptime độc lập hoặc script chạy từ hạ tầng khác; nếu đặt cùng VPS, nó có thể ngừng hoạt động đúng lúc máy chủ gặp sự cố.

Công cụ này đóng vai trò như một trình duyệt của khách hàng, định kỳ 1 đến 5 phút gửi request qua Internet vào website để kiểm tra các yếu tố:

1. DNS có phân giải đúng địa chỉ IP không: Tránh tình trạng tên miền hết hạn hoặc bản ghi DNS bị cấu hình sai.
2. Chứng chỉ SSL/TLS có hợp lệ và còn hạn không: Chứng chỉ hết hạn, sai hostname hoặc thiếu chain đều có thể khiến trình duyệt chặn kết nối.
3. Mã phản hồi HTTP có đúng không: Kiểm tra xem trang có trả về mã 200 OK hay đang văng mã lỗi 502 Bad Gateway, 500 Internal Server Error, 503 Service Unavailable.
4. Nội dung trang web có thực sự hiển thị không: Đây là lỗi mà rất nhiều người bỏ qua. Đôi khi ứng dụng bị lỗi database hoặc Cloudflare trả về trang lỗi có sẵn, mã HTTP trả về vẫn là 200 nhưng toàn bộ nội dung chỉ là trang trắng hoặc dòng chữ "Error establishing a database connection". Vì vậy, bộ kiểm tra cần quét thêm xem trong mã HTML trả về có chứa một chuỗi văn bản đặc trưng của trang (ví dụ tên thương hiệu hoặc một thẻ HTML cố định) hay không.

Để hiểu sâu hơn về lý do mã 200 vẫn có thể là website đang sập và cách cấu hình kiểm tra nội dung đúng chuẩn, bạn có thể xem bài Uptime monitoring: Kiểm tra HTTP 200 hay kiểm tra nội dung?.

Lớp 2: VPS có đang cạn kiệt hoặc nghẽn tài nguyên không?

Song song với kiểm tra bên ngoài, agent hoặc collector bên trong máy chủ giúp quan sát nguyên nhân khả dĩ. Với một VPS thông thường, bốn nhóm tín hiệu sau nên được theo dõi theo thời gian:

1. Dung lượng ổ đĩa (Disk Space) và Inode

Ổ đĩa đầy có thể làm nhiều thành phần lỗi theo những cách khác nhau: database không ghi được dữ liệu, ứng dụng không tạo được session hoặc Nginx không ghi được log. Đừng chờ tới 100%; cảnh báo cần đủ sớm để người vận hành còn thời gian xác định thư mục tăng nhanh và xử lý an toàn.

Ngoài số gigabyte dung lượng, bạn còn phải theo dõi cả Inode (số lượng file tối đa hệ thống cho phép tạo). Rất nhiều trường hợp ổ đĩa dung lượng 100 GB mới dùng hết 30 GB, nhưng thư mục cache của ứng dụng hoặc session sinh ra hàng triệu file rác nhỏ li ti khiến inode chạm mức 100%, máy chủ vẫn rơi vào tình trạng tê liệt hoàn toàn.

Quy trình phát hiện và dọn dẹp khi gặp sự cố này được trình bày cụ thể trong bài VPS đầy ổ đĩa: Nguyên nhân, dấu hiệu và cách phòng ngừa.

2. Bộ nhớ RAM và Swap

Đừng chỉ nhìn vào con số RAM used. Linux có cơ chế tận dụng RAM trống để làm cache cho file hệ thống, vì vậy nhìn vào lệnh free -m bạn sẽ thường thấy RAM bị chiếm gần hết.

Con số cần quan tâm là RAM Available và mức độ sử dụng Swap theo thời gian. Swap activity kéo dài có thể làm tăng latency. Khi hệ thống không còn đáp ứng được nhu cầu cấp phát bộ nhớ, OOM Killer sẽ chọn tiến trình dựa trên điểm ưu tiên và các điều chỉnh của kernel; đó không nhất thiết là tiến trình đang dùng nhiều RAM nhất. Hãy cảnh báo cả tình trạng bộ nhớ suy giảm lẫn sự kiện OOM thực tế.

3. CPU và Load Average

Một đợt tăng CPU ngắn có thể phù hợp với cron job hoặc traffic tăng. Cảnh báo nên xét mức sử dụng kéo dài, baseline, số vCPU, load average và tác động lên latency; không có một khoảng 5–15 phút phù hợp cho mọi workload.

Khi CPU tăng cao, hãy đối chiếu với traffic, deploy gần nhất, cron job và tiến trình đang sử dụng CPU. Những dữ kiện này giúp thu hẹp giả thuyết trước khi kết luận lỗi nằm ở code, database hay traffic bất thường.

Bạn có thể tham khảo ngưỡng cảnh báo chuẩn cho từng loại tài nguyên tại bài viết Ngưỡng cảnh báo CPU, RAM và Disk cho VPS.

4. Disk I/O (Nghẽn đọc ghi ổ đĩa)

Khi CPU còn thấp nhưng website chậm và terminal phản hồi trễ, I/O Wait là một tín hiệu cần kiểm tra cùng với latency database, network và dependency bên ngoài. Nếu I/O tăng, tiếp tục đối chiếu throughput, queue, tiến trình đọc ghi và thay đổi workload để xác định đây là nghẽn storage hay chỉ là triệu chứng đi kèm.

Lớp 3: Các tiến trình dịch vụ cốt lõi có sẵn sàng không?

Một chiếc VPS còn dư tài nguyên không có nghĩa là các dịch vụ bên trong đang lắng nghe và phản hồi tốt. Request từ người dùng đi qua một chuỗi các trạm trung chuyển, và bạn cần theo dõi từng trạm này:

• Web server / Reverse Proxy (Nginx, Caddy, Apache): Tiến trình có đang chạy không? File cấu hình có bị lỗi sau lần cập nhật gần nhất không? Cổng 80 và 443 có đang mở để nhận kết nối không?
• Bộ xử lý ứng dụng (PHP-FPM, Node.js, Python, container Docker): Nếu bạn chạy ứng dụng qua Docker, một container ở trạng thái Up chỉ có nghĩa là tiến trình chính chưa thoát ra, chứ không đảm bảo ứng dụng bên trong đã nạp xong mã nguồn hoặc kết nối được tới database. Bạn cần cấu hình lệnh healthcheck bên trong container để kiểm tra khả năng phục vụ thực tế (tham khảo thêm bài Healthcheck Docker Compose: Kiểm tra những gì?).
• Tình trạng restart liên tục (CrashLoop): Nếu container hoặc tiến trình ứng dụng liên tục tự tắt rồi tự khởi động lại hàng chục lần trong vài phút (thường do lỗi cấp phát bộ nhớ hoặc thiếu biến môi trường), bạn cần nhận được cảnh báo ngay.

Lớp 4: Ứng dụng đang phục vụ request ra sao?

Khi đi sâu vào tầng ứng dụng, bạn không nên chỉ nhìn vào số lượng người online. Có 4 tín hiệu vàng (Golden Signals) kinh điển mà bất kỳ người vận hành nào cũng nên nắm rõ:

1. Latency (Thời gian phản hồi): Đo xem một request mất bao lâu để hoàn thành và tách request thành công khỏi request lỗi. Giá trị trung bình có thể che phần đuôi phân phối. P95 cho biết 95% request hoàn thành không chậm hơn giá trị đó; P99 làm tương tự với 99%. Hãy đọc percentile cùng loại endpoint và khoảng thời gian đo, không coi một con số duy nhất là toàn bộ trải nghiệm người dùng.
2. Traffic (Lưu lượng truy cập): Số lượng request gửi đến hệ thống mỗi giây (RPS). Nắm được nhịp traffic ngày thường sẽ giúp bạn nhận ra ngay các đợt tăng đột biến (chiến dịch khuyến mãi, bài viết viral) hoặc các đợt tụt dốc bất thường (hỏng cổng thanh toán, lỗi mạng nhà mạng).
3. Errors (Tỷ lệ lỗi): Theo dõi lỗi 5xx và các lỗi nghiệp vụ quan trọng theo tỷ lệ trên tổng request. Mức nào cần cảnh báo phụ thuộc baseline, SLO, lưu lượng và hành trình bị ảnh hưởng; một lỗi trên endpoint thanh toán có thể quan trọng hơn nhiều lỗi trên một tác vụ không thiết yếu.
4. Saturation (Mức độ bão hòa): Đo xem các hàng đợi nội bộ đã đầy đến mức nào. Ví dụ: số lượng kết nối đang mở tới database đã chạm ngưỡng max_connections chưa, queue xử lý việc nền (gửi email, resize ảnh) có bị ùn ứ hàng nghìn tác vụ tồn đọng hay không.

Lớp 5: Dữ liệu và các tác vụ ngầm có tiến triển không?

Một website bán hàng có thể vẫn hiển thị banner và xem được sản phẩm bình thường, nhưng toàn bộ hệ thống ngầm phía sau đã ngừng chạy từ lâu mà không ai hay biết. Đây là lớp giám sát thứ năm mà các hệ thống nhỏ thường bỏ quên:

• Trạng thái Database: Ngoài việc tiến trình MySQL hay PostgreSQL còn sống, bạn cần theo dõi số lượng kết nối đang mở, các câu truy vấn bị lock (chờ nhau khóa bảng) và danh sách slow query. Chi tiết các thông số cần lưu tâm được tổng hợp tại bài viết Monitoring Database: Những chỉ số quan trọng nhất.
• Hàng đợi công việc (Queue Worker): Nếu khách hàng bấm đặt hàng nhưng worker gửi email xác nhận hoặc đồng bộ đơn về phần mềm kế toán bị treo, đơn hàng sẽ bị dồn ứ. Cần theo dõi độ sâu của hàng đợi (queue size) và thời gian của tin nhắn cũ nhất chưa được xử lý.
• Tiến trình chạy định kỳ (Cron Job): Script đồng bộ tồn kho mỗi đêm có chạy không? Đừng chỉ kiểm tra xem lệnh có trả về mã lỗi hay không. Rất nhiều trường hợp daemon cron của hệ điều hành bị tắt, hoặc đường dẫn file cấu hình bị sai khiến script hoàn toàn không được gọi dậy, và hệ thống sẽ không sinh ra bất kỳ file log lỗi nào. Tín hiệu bạn cần theo dõi ở đây là: Thời điểm hoàn thành thành công gần nhất là lúc nào?
• Hoạt động Backup: Tương tự như cron job, bạn cần một cơ chế giám sát xác nhận file backup của đêm hôm trước đã thực sự được tạo ra, dung lượng có bị tụt đột ngột về 0 byte hay không, và file đã được đẩy lên dịch vụ lưu trữ từ xa an toàn chưa. Xem thêm bài viết Chiến lược backup VPS cho doanh nghiệp nhỏ để xây dựng quy trình kiểm soát này.

Phối hợp giữa Log và Metric khi điều tra sự cố

Khi website gặp vấn đề, bạn cần hiểu rõ vai trò của hai loại dữ liệu này để không mất thời gian mò mẫm:

• Metric cho bạn biết "Khi nào hỏng và mức độ nghiêm trọng ra sao": Nhìn vào biểu đồ metric, bạn thấy ngay: từ 14h15 chiều nay, tỷ lệ lỗi 502 bắt đầu vọt lên 18%, cùng lúc đó CPU của VPS tăng từ 20% lên 98%. Metric giúp bạn khoanh vùng mốc thời gian và thành phần bị nghẽn.
• Log cung cấp chi tiết để kiểm tra giả thuyết: Error log có thể chỉ ra exception, upstream lỗi hoặc truy vấn liên quan tại thời điểm bất thường. Tuy nhiên, log có thể thiếu ngữ cảnh; hệ thống phức tạp còn cần trace, query plan, profile hoặc dữ liệu từ dependency.

Đừng bao giờ cố gắng biến toàn bộ dòng log thành alert. Nếu ứng dụng ghi 5.000 dòng log lỗi mỗi phút, gửi hết số đó vào tin nhắn sẽ làm tê liệt việc theo dõi. Hãy dùng metric để phát hiện bất thường và kích hoạt cảnh báo, sau đó dùng log để mổ xẻ nguyên nhân kỹ thuật.

Bạn có thể đọc thêm bài so sánh chi tiết tại Log, Metric và Uptime Check khác nhau thế nào?.

Bộ giám sát tối thiểu theo 3 giai đoạn triển khai

Nếu đang phải tự mình quản trị máy chủ cho doanh nghiệp và chưa có nhiều thời gian, bạn không cần phải làm tất cả mọi thứ cùng một lúc. Hãy chia lộ trình ra làm 3 bước thực tế:

Bắt đầu bằng một kiểm tra bên ngoài cho hành trình công khai quan trọng nhất. Sau khi xác nhận alert đến đúng người và có bước xử lý rõ ràng, hãy bổ sung các lớp tài nguyên, ứng dụng và dữ liệu theo rủi ro thực tế của hệ thống.

Checklist rà soát hệ thống monitoring

• ☐ Đã có công cụ kiểm tra uptime độc lập nằm bên ngoài máy chủ VPS.
• ☐ Uptime check có kiểm tra chuỗi nội dung văn bản đặc trưng trong trang HTML, không chỉ dựa vào mã HTTP 200.
• ☐ Đã đặt cảnh báo theo dõi ngày hết hạn của tên miền và chứng chỉ SSL trước ít nhất 15 đến 30 ngày.
• ☐ Ổ đĩa máy chủ có cảnh báo dung lượng (ngưỡng 80%–85%) và có theo dõi cả số lượng Inode.
• ☐ Bộ nhớ có theo dõi chỉ số RAM Available và mức độ sử dụng Swap, không chỉ nhìn con số RAM đã cấp phát.
• ☐ Các dịch vụ cốt lõi (Nginx/Apache, PHP/Node/Docker, MySQL/Postgres) có cơ chế kiểm tra tiến trình đang chạy và cổng kết nối.
• ☐ Đã xác định được "thời điểm thành công gần nhất" cho các tác vụ chạy ngầm như cron job và backup dữ liệu hàng ngày.
• ☐ Cảnh báo được gửi tới đúng người phụ trách, có hướng dẫn xử lý sơ bộ và không bị lẫn với các thông báo rác không cần hành động.
• ☐ Có phương án dự phòng khi chính công cụ monitoring hoặc đường truyền thông báo bị gián đoạn.