Giám sát CPU, RAM, Disk I/O, Uptime và thiết lập Alerting thực chiến trên VPS nhỏ

Hồ sơ thực nghiệm trên lab: Thu thập số liệu tài nguyên hệ thống và kiểm tra HTTP request từ bên ngoài máy chủ vào ngày 01/10; dựng thêm bộ ba Prometheus + Alertmanager + Node Exporter trên máy lab ngày 02/10 để diễn tập trọn vẹn kịch bản mất metrics → bắn cảnh báo firing → khôi phục dịch vụ và webhook nhận sự kiện resolved. Đến ngày 06/10, bổ sung thêm bài test bắn email cảnh báo miễn phí trên LAB03: hộp thư người nhận đã xác nhận nhận đủ cả email báo sự cố lẫn email báo phục hồi. Lưu ý rằng bộ số liệu này là thực nghiệm ngắn hạn, chưa phải chuỗi dữ liệu lịch sử giám sát nhiều tuần.

Làm quản trị VPS nhỏ chạy WordPress mà không có giám sát (Monitoring & Alerting) thì chẳng khác nào lái xe ban đêm mà tắt đèn pha: lúc đường vắng thì tưởng mình lụa, tới khi ổ đĩa đầy 100% làm MariaDB sập cái rầm hoặc PHP-FPM bị OOM Killer tiễn lên đường vì cạn RAM thì mới ngửa cổ kêu trời. Muốn ăn ngon ngủ kỹ, anh em phải soi cả hai mặt: sức khỏe nội tại bên trong máy chủ (CPU, RAM, Disk I/O, Inode) lẫn trải nghiệm thực tế từ ngoài Internet (Uptime, mã phản hồi HTTP). Nhớ kỹ một chân lý xương máu: systemd báo service còn active (running) chưa chắc trang web đã trả về đúng giao diện, mà CPU đang rảnh rỗi 99% cũng chẳng đảm bảo được là khách hàng không bị treo ở bước thanh toán.

Trong bài viết này, chúng ta sẽ đi từ những câu lệnh đọc nhanh tài nguyên trong khung thời gian giới hạn, rồi tiến tới dựng thử hệ thống Alerting thực thụ trên máy lab độc lập. Toàn bộ số liệu từ máy chủ thử nghiệm LAB-CF-02 được ghi nhận thực tế qua các đợt đo ngày 01–02/10/2026, còn kịch bản bắn cảnh báo qua email ngày 06/10 được thực hiện trên LAB03 và tách thành mục riêng bên dưới. Các ngưỡng cảnh báo (threshold) đưa ra trong bài chỉ đóng vai trò điểm xuất phát để anh em tinh chỉnh theo tải thực tế của từng website, tuyệt đối không phải công thức cứng áp cho mọi con VPS trên đời.

Điều kiện cần chuẩn bị trước khi vọc

Trước khi bắt tay vào làm, anh em nên nắm vững nền tảng từ lộ trình cài WordPress trên VPS từ A đến Z và chuẩn bị sẵn quyền quản trị trên một máy lab riêng biệt. Môi trường chuẩn trong bài sử dụng Ubuntu 24.04 LTS, NGINX, PHP 8.3 và MariaDB 10.11. Đừng quên đối chiếu phiên bản phần mềm, tên systemd unit và đường dẫn thư mục thực tế trên máy của bạn trước khi gõ lệnh, bởi mỗi bản distro hoặc cách cài đặt sẽ có chút khác biệt.

Nguyên tắc an toàn của đàn anh: luôn thử nghiệm bằng dữ liệu giả lập, dùng tài khoản tách biệt và đặt thư mục làm việc nằm ngoài vùng dữ liệu đang chạy production. Các biến môi trường viết hoa cần được thay bằng giá trị thực tế đã xác minh trên lab; tuyệt đối không lưu mật khẩu, token hay thông tin nhạy cảm vào bài viết, lịch sử gõ lệnh shell (~/.bash_history) hoặc đẩy nhầm lên Git. Nếu gõ lệnh mà gặp báo lỗi “command not found”, hãy bình tĩnh đọc tài liệu chính thức để cài gói công cụ tương ứng và kiểm tra phiên bản — thiếu binary công cụ trên shell không có nghĩa là website WordPress đang bị lỗi. Các sơ đồ minh họa trong bài được vẽ để làm rõ luồng tư duy kỹ thuật, đi kèm với ảnh chụp màn hình thực nghiệm bên dưới.

Sơ đồ kỹ thuật 1: Bốn trụ cột cần quan sát khi giám sát VPS nhỏ. Sơ đồ do đội ngũ localhost.vn biên soạn để tóm tắt quy trình.

Soi dung lượng ổ đĩa (df -h) và Inode trước tiên

Thứ giết chết một con VPS WordPress nhanh nhất và ngớ ngẩn nhất thường không phải là hacker, mà là hết dung lượng ổ đĩa. Khi ổ đĩa chạm đáy 100%, MariaDB không thể ghi bảng tạm hay transaction log, NGINX ngừng ghi log, còn người dùng thì bất lực nhìn lỗi không thể upload ảnh. Nhưng hiểm hóc hơn cả là bệnh cạn sạch Inode: bạn gõ df -h thấy ổ cứng vẫn còn trống cả chục GB ngon lành, nhưng hệ thống vẫn báo No space left on device chỉ vì hàng triệu file rác nhỏ li ti (session PHP, cache file, thư mục tạm) đã ăn hết sạch bảng chỉ mục Inode. Do đó, thao tác đầu tiên luôn là kiểm tra đồng thời cả dung lượng lẫn Inode trên đúng phân vùng filesystem đang chứa mã nguồn WordPress và thư mục dữ liệu MariaDB.

df -hT
df -i
free -h
uptime
systemctl --failed --no-pager

Khi nhìn vào kết quả của lệnh free, anh em mới vào nghề rất hay hoảng hốt khi thấy cột free tụt xuống thấp lè tè. Bình tĩnh nào! Nhân Linux cực kỳ thông minh: RAM đang rảnh sẽ được hệ điều hành mượn tạm để làm bộ nhớ đệm (buff/cache) giúp tăng tốc độ đọc/ghi đĩa. Chỉ số thực sự phản ánh lượng bộ nhớ có thể cấp phát ngay cho ứng dụng mới chính là cột available. Ngoài ra, nếu thấy hệ thống bắt đầu ăn vào Swap, hãy quan sát xem tốc độ swap in/swap out có diễn ra liên tục hay không trước khi quyết định can thiệp, đừng thấy có vài chục MB swap mà vội vàng tắt phụp đi kẻo OOM Killer lại ghé thăm. Và thêm một sự thật mất lòng: chỉ số Uptime vài trăm ngày không phải lúc nào cũng đáng tự hào đâu, đôi khi nó chỉ tố cáo rằng chủ server đã lười cập nhật bản vá bảo mật kernel suốt cả năm trời mà chưa chịu reboot đấy thôi.

Đo lường CPU và RAM theo cửa sổ thời gian ngắn

Bấm chụp một tấm ảnh màn hình top hoặc htop đúng giây phút cronjob của WordPress hay tiến trình nén backup vừa chạy qua rồi kết luận “server quá tải rồi, phải nâng gói thôi” là sai lầm kinh điển. Để bắt mạch chuẩn xác, bạn cần lấy nhiều mẫu liên tiếp (sampling window) trên máy chủ, đồng thời ghi chú rõ mốc thời gian (timestamp) và tác vụ mà website đang xử lý lúc đó. Luôn nhớ giới hạn số lần lấy mẫu để tránh việc treo lệnh ghi log vô thời hạn làm đầy ổ đĩa.

vmstat 1 6
ps -eo pid,comm,%cpu,%mem,rss --sort=-rss | head -n 12

Một mẹo đọc vmstat mà nhiều anh em hay nhầm: dòng số liệu đầu tiên của vmstat luôn hiển thị giá trị trung bình của CPU và Disk I/O tính từ thời điểm máy chủ mới boot lên, trong khi các cột về tiến trình (procs) và bộ nhớ (memory) ở dòng đó lại là con số tức thời. Phải từ dòng thứ hai trở đi (tương ứng với 5 mẫu đo cách nhau mỗi 1 giây trong lệnh trên), bạn mới thấy được nhịp đập thực tế của hệ thống ngay lúc đó. Hãy tập trung soi hàng đợi tiến trình đang chờ chạy (r), tiến trình bị nghẽn chờ I/O (b), hoạt động trao đổi swap (si/so), tỷ lệ CPU user/system, độ trễ I/O wait (wa) và đặc biệt là chỉ số CPU steal time (st) trên môi trường ảo hóa VPS. Cũng đừng đánh đồng Load average với phần trăm CPU: nó là độ dài hàng đợi công việc trung bình, phải đem so sánh tương quan với tổng số vCPU hiện có và phân tích xem hệ thống đang nghẽn ở tính toán CPU hay đang xếp hàng đợi ổ đĩa Disk I/O.

Sơ đồ kỹ thuật 2: Nguyên tắc đọc mẫu đo tài nguyên có ngữ cảnh. Sơ đồ do đội ngũ localhost.vn biên soạn.

Kiểm tra Uptime và phản hồi HTTP từ bên ngoài VPS

Đứng ở bên trong VPS gõ lệnh thấy mọi thứ êm ru vẫn chưa đủ — thứ khách hàng của bạn chạm vào là giao diện web đi qua tầng DNS, tường lửa mạng, bắt tay chứng chỉ SSL/TLS, qua NGINX rồi mới tới PHP-FPM. Bởi vậy, một công cụ Uptime Monitor đặt bên ngoài máy chủ nên định kỳ gọi tới một URL công khai (không bị cache cứng vô nghĩa nhưng cũng không chứa dữ liệu cá nhân hóa nhạy cảm), vừa kiểm tra mã trạng thái HTTP vừa xác thực một đoạn văn bản đặc trưng trong nội dung trả về. Tần suất hợp lý cho mục đích canh gác Uptime là vài phút một lần — đừng đặt 1 giây quét 10 lần kẻo công cụ giám sát lại biến thành kịch bản tự DDoS chính mình! Nếu dùng dịch vụ giám sát bên thứ ba, hãy đảm bảo URL kiểm tra không làm lộ token bảo mật hay thông tin nội bộ.

: "${LAB_URL:?URL HTTPS của lab được phép}"
curl --max-time 10 -sS -o /dev/null   -w 'code=%{http_code} ttfb=%{time_starttransfer} total=%{time_total}
'   "$LAB_URL"

Khi chạy curl để bắt bệnh, nếu lệnh văng lỗi kết nối, hãy lưu lại cả mã thoát (exit code) của shell lẫn thông báo lỗi chi tiết; thấy code=000 tức là curl còn chưa chạm tới tầng HTTP để nhận phản hồi từ server (do lỗi phân giải DNS, đứt mạng hoặc timeout bắt tay TCP/TLS), chứ chẳng có mã HTTP nào là 000 cả. Ngoài ra, kinh nghiệm đau thương với WordPress là nhiều khi giao diện bị lỗi trắng trang hoặc văng thông báo lỗi database nhưng cấu hình tồi vẫn trả về mã HTTP 200 OK ngon lành — bởi vậy mới cần kiểm tra khớp nội dung (keyword check). Và quan trọng nhất: cài xong Alerting thì phải giả lập sự cố để xem tin nhắn hay email có thực sự tinh tinh trong điện thoại người trực hay không, chứ đừng chỉ ngắm cái dashboard màu xanh lá cây rồi tự ru ngủ mình.

Thiết lập Alerting thực chiến: Cảnh báo phải gắn liền với hành động

Một hệ thống Alerting tốt không phải là hệ thống hơi tí là réo, mà là hệ thống mỗi khi kêu lên thì kỹ sư trực biết ngay phải làm gì. Chẳng hạn, đặt ngưỡng ổ đĩa trên 80% làm mức cảnh báo sớm (Warning) để nhắc bạn vào rà soát tốc độ phình to của dữ liệu. Nhưng ngưỡng nguy cấp (Critical) cần xử lý ngay lập tức lại phụ thuộc vào dung lượng trống tuyệt đối và tốc độ ghi file: 20% còn trống của cái ổ 20 GB nó mong manh hơn rất nhiều so với 20% của ổ 500 GB. Hãy kết hợp tỷ lệ phần trăm đã dùng với số GB dự phòng tối thiểu và ước tính thời gian còn lại trước khi ổ đĩa chạm mức 100%.

Mỗi quy tắc cảnh báo (alert rule) khi viết ra cần trả lời rành mạch 4 câu hỏi: Điều kiện bất thường phải kéo dài liên tục bao lâu (for duration)? Ai là người nhận tin? Câu lệnh đầu tiên cần gõ khi mở terminal lên là gì? Và tiêu chí nào xác nhận sự cố đã được giải quyết xong? Ví dụ, CPU vọt lên 95% trong vòng 30 giây lúc nửa đêm khi cronjob đang nén cục backup tar.gz là chuyện hoàn toàn bình thường trong dự tính; nhưng CPU kẹt cứng ở 95% suốt 10 phút đi kèm hàng loạt lỗi HTTP 502/504 lại là câu chuyện hoàn toàn khác cần xử lý ngay. Hãy tránh xa căn bệnh “bão cảnh báo” (alert fatigue) — khi bạn cấu hình nhạy tới mức mỗi cú nhích nhẹ của hệ thống đều bắn thông báo, hậu quả tất yếu là anh em vận hành sẽ bấm Mute (tắt tiếng) toàn bộ kênh cảnh báo và bỏ lỡ luôn sự cố thật sự.

Lưu trữ lịch sử số liệu vừa đủ để ra quyết định nâng cấp

Khi vận hành lâu dài, hãy tập thói quen ghi nhật ký thay đổi (changelog) kèm mốc thời gian chuẩn cho các sự kiện như: bật Redis Object Cache, nâng cấp plugin WooCommerce, hay đổi giờ chạy lịch sao lưu. Khi ghép dòng sự kiện này vào biểu đồ tài nguyên lịch sử, bạn sẽ phân biệt được ngay đâu là tình trạng thiếu hụt tài nguyên thực sự do lưu lượng truy cập tăng trưởng bền vững (cần rút ví nâng cấp VPS), và đâu chỉ là một tiến trình PHP bị rò rỉ bộ nhớ (memory leak) sau đợt cập nhật plugin hôm qua. Hãy thu thập chỉ số dựa trên những câu hỏi vận hành bạn thực sự cần trả lời, thay vì ôm đồm gom mọi thứ rác rưởi về làm ngập ổ cứng.

Đừng quên một nghịch lý hài hước: trên những con VPS nhỏ (1 vCPU, 1–2 GB RAM), chính các agent giám sát nặng nề đôi khi lại là thủ phạm ngốn sạch RAM và CPU của WordPress! Hãy luôn kiểm tra mức tiêu thụ RAM (RSS), CPU và dung lượng lưu trữ (retention) mỗi khi cài thêm công cụ theo dõi. Tuyệt đối không cài chồng chéo 3–4 bộ agent giám sát cùng lúc trên một máy chủ nhỏ. Hãy khởi đầu gọn nhẹ từ những chỉ số sống còn nhất, và chỉ mở rộng thêm khi có bài toán cụ thể cần giải quyết.

Nghiệm thu hệ thống giám sát và hiểu rõ giới hạn của số liệu

Để nghiệm thu một quy trình giám sát đạt chuẩn, bạn cần có bộ mẫu đo rõ ràng về mốc thời gian, đúng URL mục tiêu, sổ tay hướng dẫn xử lý sự cố (runbook) ngắn gọn và bằng chứng xác nhận người trực đã nhận được thông báo thử nghiệm. Hãy thu thập số liệu nền (baseline) trong những khung giờ hoạt động tiêu biểu của website trước khi chốt các ngưỡng cảnh báo cố định. Một buổi đo thử nghiệm trên môi trường lab vắng vẻ chỉ vài phút sẽ không bao giờ đủ cơ sở để bạn vỗ ngực kết luận rằng cấu hình VPS hiện tại đang dư thừa tài nguyên nếu chưa trải qua chuỗi ngày theo dõi tải thực tế.

Sơ đồ kỹ thuật 3: Chuyển hóa tín hiệu cảnh báo thành quy trình hành động cụ thể. Sơ đồ do đội ngũ localhost.vn biên soạn.

Bản ghi số liệu thực tế trên LAB-CF-02 ngày 01/10/2026

Biên bản đo đạc tài nguyên nội bộ và kiểm tra HTTP từ bên ngoài dưới đây được ghi nhận trên VPS LAB-CF-02 trong khung thời gian từ 00:21:30 đến 00:21:35 (giờ Việt Nam, UTC+7). Máy chủ thử nghiệm có 1 vCPU khả dụng theo kết quả lệnh nproc, và tại thời điểm đo máy vừa chạy liên tục (uptime) được 3 giờ 9 phút.

Nhìn vào bảng trên, bạn sẽ thấy rõ câu chuyện kinh điển về RAM trên Linux: con số available 1291 MiB mới là lượng bộ nhớ thực tế sẵn sàng cấp phát cho các tiến trình ứng dụng mới, còn 149 MiB ở cột free chỉ là phần RAM chưa được dùng vào bất cứ việc gì (kể cả cache). Do đó, nếu chỉ nhìn con số 149 MiB rồi cuống cuồng đi mua thêm RAM là mất tiền oan! Việc Swap bằng 0 ở đây đơn thuần phản ánh cấu hình mặc định lúc đo của máy lab, không mang hàm ý khuyên bạn nên bật hay tắt Swap. Ngoài ra, đơn vị G trong df -h được tính và làm tròn theo lũy thừa cơ số 1024 (GiB), nên đừng lấy máy tính cộng trừ thập phân rồi thắc mắc sao tổng số bị lệch nhẹ.

Ngay sau đó, vào lúc 00:22:40–00:22:41, một lệnh kiểm tra HTTP được bắn từ máy trạm macOS bên ngoài VPS tới đường dẫn /bai-thu/. Kết quả trả về mã trạng thái HTTPS 200, quá trình xác thực chứng chỉ TLS hoàn tất trơn tru và nội dung bài viết mẫu hiển thị chuẩn xác. Thời gian phản hồi byte đầu tiên (TTFB) đạt 0,239192 giây, và tổng thời gian hoàn tất request là 0,245583 giây. Cần lưu ý đây là kết quả đo đơn lẻ từ một điểm mạng tại một thời điểm, không đại diện cho tốc độ trung bình dài hạn hay cam kết tỷ lệ Uptime cả tháng.

Cửa sổ lấy mẫu CPU chỉ kéo dài đúng 5 giây khi máy lab đang ở trạng thái nghỉ ngơi và chỉ chạy chính các lệnh đọc số liệu. Nó hoàn toàn không phản ánh sức chịu tải (stress test) hay hiệu năng dài hạn, và càng không dùng để đem ra so sánh hơn thua giữa các nhà cung cấp VPS. Trong ngày 01/10, máy chủ vẫn chưa cài đặt dịch vụ giám sát liên tục; phần thực hành dựng Prometheus ngày 02/10 nằm ở mục riêng bên dưới. Để đưa vào vận hành thực tế, bạn luôn cần tích lũy biểu đồ nhiều ngày kết hợp xác nhận kênh liên lạc tới tận tay người trực.

Đối chiếu mẫu đo tài nguyên lần hai lúc 10:14 ngày 01/10

Đợt lấy mẫu tiếp theo bắt đầu vào lúc 10:14:03 (UTC+7) trên cùng máy chủ LAB-CF-02 nhằm ghi nhận trạng thái hệ thống sau hơn 10 tiếng hoạt động. Đợt đo này độc lập hoàn toàn với mẫu lúc 00:21 và chỉ tập trung vào chỉ số nội bộ, không kèm phép thử HTTP từ bên ngoài.

Ảnh chụp màn hình terminal thực tế của đợt đo bắt đầu lúc 10:14:03 ngày 01/10/2026 (UTC+7); giữ nguyên từng pixel vùng dữ liệu console và chỉ gắn thêm dải logo nhận diện. Tập lệnh tự động gọi tuần tự các công cụ đọc chỉ số và in tiêu đề phân tách để dễ đối chiếu. Lưu ý dòng đầu tiên của vmstat tính trung bình từ lúc khởi động máy chỉ áp dụng cho các cột CPU và Disk I/O, còn cột tiến trình và bộ nhớ vẫn là trạng thái tức thời. Bấm vào ảnh để phóng to toàn màn hình.

Một lần nữa, hãy để ý sự khác biệt rõ rệt giữa available 1455 MiB và free 270 MiB; tuyệt đối không tự ý lấy buff/cache cộng dồn thủ công vào available vì bản thân công thức tính available của nhân Linux đã tính toán phần bộ nhớ đệm có thể thu hồi được rồi. Các con số hiển thị theo đơn vị G đều đã qua làm tròn. Khi xem phần chú thích vmstat ngắn gọn trong ảnh, hãy kết hợp với nguyên tắc phân tích CPU, Disk I/O và RAM đã giải thích ở phần trên.

Hai lát cắt số liệu rời rạc lúc 00:21 và 10:14 tất nhiên chưa thể tạo thành một chuỗi thời gian (time-series) liên tục. Trong ngày 01/10 chúng ta mới chỉ dừng ở bước đọc chỉ số bằng công cụ có sẵn của hệ điều hành. Ngay phần tiếp theo dưới đây, đợt thực nghiệm ngày 02/10 sẽ nâng cấp cuộc chơi lên một tầm cao mới với bộ công cụ Prometheus, trước khi tiến tới bài test gửi email thực tế cho người trực vào ngày 06/10.

Thực hành dựng Prometheus: Từ thu thập metrics đến phát cảnh báo có trạng thái

Vào ngày 02/10/2026, chúng tôi triển khai một phiên thực nghiệm thu thập dữ liệu liên tục theo chuỗi thời gian thực trong vài phút. Bộ công cụ được sử dụng gồm Prometheus 3.13.3, Alertmanager 0.34.1 và Node Exporter 1.12.1 — tất cả đều tải từ kho lưu trữ bản phát hành chính thức dành cho kiến trúc Linux amd64 và được kiểm tra mã băm SHA-256 nghiêm ngặt trước khi giải nén. Đây là các phiên bản cụ thể được dùng để xác minh trong bài lab, và tất nhiên anh em dùng máy chủ kiến trúc ARM (arm64) sẽ cần tải đúng gói binary tương ứng chứ không bê nguyên bản amd64 sang chạy được.

Kiến trúc phối hợp của bộ ba này rất mạch lạc: Node Exporter đóng vai trò người gác đền đọc các thông số của nhân Linux, Prometheus định kỳ kéo (scrape) số liệu về lưu trữ và đánh giá các quy tắc cảnh báo (alert rules), còn Alertmanager nhận sự kiện cảnh báo để gom nhóm và đẩy thông báo tới kênh nhận tin. Để đảm bảo an toàn tuyệt đối trên môi trường thử nghiệm, cả ba tiến trình này đều chỉ lắng nghe trên giao diện nội bộ loopback 127.0.0.1. Khi cần quan sát giao diện web, chúng tôi mở trình duyệt Chromium riêng trên máy cá nhân và nối qua đường hầm SSH local port forwarding, tuyệt đối không mở toang các cổng quản trị này ra ngoài Internet.

1. Chuẩn bị thư mục tách biệt, quy hoạch Port và giới hạn tài nguyên

Toàn bộ file thực thi binary, file cấu hình YAML và dữ liệu lưu trữ tạm đều được gom gọn vào một thư mục riêng nằm ngoài webroot của WordPress. Trước khi khởi chạy, hãy rà soát để chắc chắn các cổng 9090, 9093, 9095 và 9100 chưa bị dịch vụ nào khác chiếm dụng, đồng thời lưu lại mã tiến trình (PID) của từng thành phần để sau khi thực hành xong có thể dừng và dọn dẹp sạch sẽ. Cách chạy trực tiếp này giúp giữ nguyên môi trường hệ thống, không cài thêm gói phần mềm toàn cục hay tạo systemd service khởi động cùng máy.

Để tiết kiệm tài nguyên tối đa cho VPS nhỏ, Node Exporter được khởi chạy kèm cờ --collector.disable-defaults nhằm tắt toàn bộ các bộ thu thập rườm rà mặc định, sau đó chỉ bật tường minh đúng 5 collector cốt lõi gồm: cpu, meminfo, filesystem, stat và time, kết hợp với cờ --web.listen-address=127.0.0.1:9100. Nhờ chỉ giao tiếp qua loopback nên bạn không cần đụng chạm gì tới cấu hình tường lửa UFW bên ngoài.

Về phía Prometheus, chúng tôi cấu hình thời gian lưu trữ (retention) gọn nhẹ ở mức 15m (15 phút) hoặc giới hạn dung lượng khối dữ liệu 32MB, kèm kích thước WAL segment là 10MB. Mỗi tiến trình Go binary đều được gắn biến môi trường GOMEMLIMIT=128MiB và GOMAXPROCS=1. Lưu ý kỹ thuật quan trọng: GOMEMLIMIT chỉ là ngưỡng mục tiêu mềm (soft memory limit) để bộ thu gom rác (Garbage Collector) của Go hoạt động tích cực hơn, chứ nó không phải là bức tường giới hạn cứng (hard limit) như cgroup; nếu tải tăng đột biến vượt khả năng thu hồi, dung lượng RAM thực tế (RSS) vẫn có thể vượt qua con số này. Tương tự, giới hạn retention của chuỗi thời gian chưa bao gồm dung lượng của chính file binary, nhật ký ghi trước (WAL) và các file tạm đang mở, nên việc theo dõi dung lượng ổ đĩa thực tế bằng df -h vẫn là bắt buộc.

2. Cấu hình Prometheus thu thập số liệu và xác thực cú pháp YAML

Hãy đặt file cấu hình prometheus.yml dưới đây nằm chung thư mục với file chứa quy tắc cảnh báo rules.yml. Chu kỳ quét (scrape_interval) được chỉnh xuống mức rất ngắn (5 giây) để phục vụ mục đích quan sát nhanh trong phòng lab, còn khi chạy thực tế lâu dài bạn hoàn toàn có thể giãn ra 15–60 giây cho nhẹ máy.

global:
  scrape_interval: 5s
  scrape_timeout: 3s
  evaluation_interval: 5s
rule_files: ["rules.yml"]
alerting:
  alertmanagers:
  - static_configs:
    - targets: ["127.0.0.1:9093"]
scrape_configs:
- job_name: lab-node
  static_configs:
  - targets: ["127.0.0.1:9100"]

Trước khi cho Prometheus cất cánh, thói quen tốt của kỹ sư chuyên nghiệp là dùng công cụ promtool check config trỏ vào file cấu hình vừa tạo để rà soát lỗi cú pháp YAML. Trong phiên thực nghiệm, tiến trình Prometheus được gọi kèm các cờ --config.file, --storage.tsdb.path, các tham số giới hạn retention kể trên và --web.listen-address=127.0.0.1:9090 ngay tại thư mục làm việc riêng. Nếu bước kiểm tra cú pháp báo lỗi, hãy sửa cho tới khi báo SUCCESS rồi mới khởi chạy tiến trình.

Khi mở giao diện web ở mục Status → Targets, bạn sẽ thấy job lab-node xuất hiện với trạng thái UP màu xanh mát mắt. Tuy nhiên, hãy tỉnh táo: trạng thái UP ở đây chỉ xác nhận rằng Prometheus vừa gọi HTTP tới cổng 9100 của Node Exporter và đọc được danh sách metrics hệ thống thành công; nó hoàn toàn không nói lên điều gì về việc tên miền DNS có phân giải được không, chứng chỉ HTTPS có hết hạn chưa, hay trang chủ WordPress có đang hiển thị đúng bài viết cho khách truy cập hay không.

Ảnh chụp giao diện Prometheus thực tế qua trình duyệt Chromium ngày 02/10/2026. Giữ nguyên độ phân giải gốc của vùng hiển thị và bổ sung nhãn localhost.vn; bấm vào ảnh để xem kích thước đầy đủ.

3. Thiết lập quy tắc cảnh báo khi mất kết nối kéo dài

Tiếp theo, chúng ta định nghĩa quy tắc cảnh báo trong file rules.yml như bên dưới. Nhờ tham số for: 10s, biểu thức điều kiện phải duy trì trạng thái vi phạm liên tục suốt 10 giây thì cảnh báo mới chính thức chuyển từ trạng thái chờ (PENDING) sang phát hỏa (FIRING). Thời gian thực tế từ lúc sự cố xảy ra cho tới khi tin nhắn đến tay bạn sẽ bằng tổng độ trễ của chu kỳ scrape, chu kỳ đánh giá rule (evaluation_interval) cộng với thời gian gom nhóm (group_wait) bên phía Alertmanager.

groups:
- name: lab-only
  rules:
  - alert: LabNodeExporterDown
    expr: up{job="lab-node"} == 0
    for: 10s
    labels:
      severity: lab
    annotations:
      summary: Lab node exporter is unreachable
      action: Check the owned exporter process and loopback port; check the website separately.

Biểu thức up == 0 sẽ kích hoạt khi Node Exporter bị dừng đột ngột, đổi cổng lắng nghe hoặc bị tường lửa chặn kết nối — ngay cả khi bản thân website WordPress vẫn đang chạy phà phà không hề hấn gì. Bởi vậy, sổ tay vận hành cho cảnh báo LabNodeExporterDown luôn yêu cầu kiểm tra tiến trình/cổng của exporter song song với việc kiểm tra phản hồi HTTP của website, tuyệt đối không nhìn thấy cảnh báo này mà vội vàng hô hoán rằng cả trang web đã sập.

Ở tầng tiếp theo, file cấu hình alertmanager.yml được thiết lập để đẩy dữ liệu cảnh báo về một dịch vụ nhận webhook nội bộ:

global:
  resolve_timeout: 10s
route:
  receiver: lab-local-webhook
  group_by: [alertname]
  group_wait: 1s
  group_interval: 5s
  repeat_interval: 1h
receivers:
- name: lab-local-webhook
  webhook_configs:
  - url: http://127.0.0.1:9095/alerts
    send_resolved: true

Trong bài diễn tập này, đường dẫn http://127.0.0.1:9095/alerts là một HTTP listener nhỏ gọn được viết riêng để hứng các gói tin JSON từ Alertmanager gửi sang, lọc đúng tên cảnh báo LabNodeExporterDown và ghi nhận trạng thái firing hoặc resolved. Hãy nhớ một nguyên tắc rất đời thường: việc bạn copy-paste đoạn YAML trên vào máy chủ không tự động sinh ra bộ nhận tin ở cổng 9095! Trong thực tế, nếu bạn chưa cấu hình đầu nối tới Slack, Telegram, Email hay một dịch vụ On-call thực thụ thì chuỗi cảnh báo sẽ cụt đường ngay tại đây. Hơn nữa, việc đặt bộ nhận webhook nằm chung trên chính con VPS đang được giám sát chỉ phục vụ mục đích kiểm tra luồng đi của dữ liệu; nếu cả con VPS bị rút dây mạng hoặc tắt nguồn ở tầng vật lý, bạn bắt buộc phải có một đầu dò độc lập từ bên ngoài mới phát hiện được.

Trước khi chạy Alertmanager, hãy dùng lệnh amtool check-config để rà soát file cấu hình. Tiến trình Alertmanager được khởi chạy cùng các cờ --config.file, --storage.path, --web.listen-address=127.0.0.1:9093 và đặc biệt là truyền rỗng --cluster.listen-address= để tắt tính năng lắng nghe cụm HA (high-availability cluster) không cần thiết trên môi trường thử nghiệm đơn lẻ.

Kết quả diễn tập bắn cảnh báo thực tế trên LAB-CF-02 ngày 02/10

Để diễn tập kịch bản sự cố một cách văn minh mà không làm gián đoạn website đang chạy, chúng tôi chỉ gửi tín hiệu dừng đúng tiến trình PID của Node Exporter vừa tạo, giữ nguyên toàn bộ stack NGINX, PHP-FPM và MariaDB hoạt động bình thường. Ngay sau khi hệ thống ghi nhận đầy đủ sự kiện báo lỗi (firing), tiến trình Node Exporter được khởi chạy lại với nguyên cấu hình cũ để quan sát quá trình tự động khép lại sự cố (resolved). Tuyệt đối không dùng các trò đốt CPU nhân tạo, bơm rác làm đầy ổ cứng hay tắt dịch vụ web chỉ để lấy một tấm ảnh chụp màn hình.

Ảnh chụp giao diện mục Alerts của Prometheus khi đang phát cảnh báo lỗi; tên quy tắc và trạng thái FIRING cần được đọc đối chiếu cùng trang Targets và nhật ký nhận tin của webhook. Nhắc lại: đây là tín hiệu mất kết nối tới bộ thu thập metrics, không phải bằng chứng website WordPress ngừng phục vụ.

Ảnh chụp giao diện Alertmanager thực tế khi đã tiếp nhận sự kiện cảnh báo. Tuy nhiên, việc cảnh báo xuất hiện trên màn hình này chưa đồng nghĩa với việc kỹ sư trực ca đã nhận được email hay cuộc gọi đánh thức.

Ảnh chụp giao diện khi quy tắc cảnh báo quay trở về trạng thái bình thường (INACTIVE) sau khi khôi phục exporter. Trang Targets đồng thời xanh trở lại (UP), và đầu nhận webhook cũng ghi nhận bản tin resolved để khép kín vòng đời sự cố.

Tại mốc 09:27:39, truy vấn trực tiếp qua API metrics ghi nhận lượng RAM khả dụng node_memory_MemAvailable_bytes = 1336983552, phân vùng gốc / còn trống 36963803136 byte cùng 4985963 inode, và tổng thời gian máy chạy từ lúc boot đạt khoảng 130548 giây. Đây là các thông số nguyên bản (raw metrics) tại một thời điểm, không dùng để phán đoán kích thước gói VPS cần mua nếu thiếu dữ liệu dài hạn.

Có một chi tiết kỹ thuật rất thú vị trong đợt đo này: ngay sau khi vừa khởi động bộ công cụ giám sát, biểu thức truy vấn PromQL tính mức sử dụng CPU 100*(1-avg(rate(node_cpu_seconds_total{mode="idle"}[30s]))) trả về con số lên tới khoảng 76,43%! Tại sao lại cao thế? Bởi vì hàm rate(...[30s]) yêu cầu cửa sổ dữ liệu 30 giây, nhưng tại thời điểm vừa bật Prometheus thì chuỗi dữ liệu lịch sử chưa tích lũy đủ 30 giây; lúc này Prometheus chỉ lấy các mẫu đầu tiên sẵn có rồi ngoại suy ra, mà ngay sát trước đó máy chủ lại vừa tốn CPU cho việc tải file, giải nén và khởi tạo tiến trình. Do đó, tuyệt đối không lấy con số 76,43% ở những giây đầu tiên này làm mức nền (baseline) của CPU, mức tải của WordPress hay chi phí tài nguyên cố định của bộ giám sát. Muốn đặt ngưỡng chuẩn xác, bạn luôn phải đợi hệ thống chạy ổn định đủ lâu rồi mới đem so sánh các khung giờ tương đồng.

Về mức tiêu thụ bộ nhớ, con số tổng RSS khoảng 140,19 MiB ở mốc cuối chỉ tính riêng 3 tiến trình binary là Prometheus, Alertmanager và Node Exporter đang chạy trên VPS. Nó chưa bao gồm bộ nhận webhook viết bằng Python, script điều phối phiên thử, trình duyệt Chromium mở trên máy Mac hay phần bộ nhớ đệm page cache của hệ điều hành, nên đừng hiểu nhầm đó là toàn bộ lượng RAM hệ thống tăng thêm. Trước phiên chính thức này, có hai lượt chạy chuẩn bị đã được chủ động dừng sớm do giao diện chụp màn hình chưa sẵn sàng và toàn bộ dữ liệu tạm của chúng đã được xóa sạch — chúng tôi không ghép nối số liệu giữa các lần chạy rời rạc thành một chuỗi giả tạo.

Ngay sau khi hoàn tất phiên thực nghiệm ngày 02/10, toàn bộ các tiến trình binary, PID và dịch vụ nhận webhook đều đã được dừng hẳn, thư mục runtime tạm thời bị xóa bỏ, đồng thời trình duyệt Chromium cùng đường hầm SSH port forwarding cũng được đóng lại. Bốn cổng lắng nghe nội bộ hoàn toàn giải phóng; mã băm (hash) cấu hình của WordPress gốc, bản clone và NGINX vẫn giữ nguyên vẹn 100%, trang web thử nghiệm tiếp tục trả về HTTP 200. File nhật ký kết quả được trích xuất đủ thông tin phục vụ bài viết trước khi dọn dẹp.

Điểm khuyết của phiên thử ngày 02/10: Việc bắn cảnh báo vào một webhook nằm ngay trên cùng VPS mới chỉ chứng minh luồng kỹ thuật nội bộ thông suốt, chứ chưa chứng minh được tin nhắn đã vượt ra ngoài Internet để đến tay người trực. Chính vì thế, chúng tôi đã thực hiện tiếp nhánh thử nghiệm gửi email thực tế vào ngày 06/10 ngay dưới đây.

Chốt hạ đường truyền cảnh báo: Gửi Email thực tế tới hộp thư người trực (Miễn phí)

Vào ngày 06/10/2026, trên máy chủ thử nghiệm LAB03, chúng tôi kết nối đầu nhận webhook nội bộ (loopback receiver) với một Cloudflare Worker được gắn quyền gửi thư (Email Routing / Send Email binding) tới đúng địa chỉ email của người quản trị đã xác minh trước. Để đảm bảo an toàn bảo mật, Worker này được lập trình khóa cứng chỉ nhận request từ đúng địa chỉ IP của máy lab, lọc đúng loại sự kiện cảnh báo, giới hạn dung lượng payload tối đa và cài đặt mốc thời gian tự động hết hạn. Địa chỉ email người nhận được cất giữ trong biến môi trường bí mật (Secret), hoàn toàn không cho phép bên gửi truyền địa chỉ email tùy ý qua tham số request. Toàn bộ giải pháp này tận dụng tầng miễn phí (Cloudflare Free tier), không tốn một xu chi phí thuê bao và cũng không cần tạo tài khoản mật khẩu SMTP truyền thống.

Hành trình của một bản tin cảnh báo lúc này đi trọn một vòng khép kín: Node Exporter → Prometheus → Alertmanager → Loopback Receiver → Cloudflare Worker → Hộp thư Gmail của người phụ trách. Toàn bộ cấu hình chu kỳ lấy mẫu và quy tắc bắt lỗi mất kết nối exporter vẫn giữ nguyên như phần trước. Bộ nhận nội bộ đảm bảo chỉ chuyển tiếp đúng một thông báo đại diện cho mỗi lần chuyển trạng thái (từ bình thường sang lỗi, và từ lỗi về bình thường), đồng thời ghi nhật ký đầy đủ mã phản hồi HTTP kèm Message-ID của bức thư. Nguyên tắc kỷ luật ở đây là: nếu dịch vụ gửi thư trả về mã lỗi, hệ thống phải báo lỗi rõ ràng chứ tuyệt đối không được báo cáo khống là “đã gửi cảnh báo thành công” chỉ vì thấy chữ FIRING đỏ chót trên màn hình Alertmanager.

Cả hai bức thư điện tử đều được gắn chung mã định danh phiên LAB03-ALERT-20261006. Người trực đã mở hộp thư Gmail cá nhân và xác nhận nhận được đầy đủ cả hai bức thư: một thư báo phát sinh sự cố (firing) và một thư báo hệ thống đã hồi phục (resolved). Đây là bằng chứng xác thực toàn diện về khả năng chuyển phát thông báo tới tận tay con người (end-to-end human delivery); phạm vi bài thử này chưa đi sâu vào việc phân tích chi tiết từng dòng header SMTP của thư, đo thời gian phản xạ của kỹ sư trực hay diễn tập kịch bản phân ca trực nhiều người (on-call rotation). Lưu ý thêm rằng bộ ảnh chụp màn hình giao diện ở mục trước là của máy LAB-CF-02 ngày 02/10, không dùng lẫn lộn làm ảnh minh họa cho phiên bắn email trên LAB03 ngày 06/10.

Trong suốt khoảng thời gian Node Exporter bị dừng để tạo cảnh báo, trang web HTTPS thử nghiệm trên LAB03 vẫn trả về mã HTTP 200 mượt mà. Điều này một lần nữa khẳng định sự cố vừa diễn ra đơn thuần là đứt nguồn thu thập chỉ số (metrics collection failure), không phải sập dịch vụ web. Đồng thời, vì bộ thu thập và bộ chuyển tiếp tin vẫn nằm chung trên một con VPS, kiến trúc này sẽ bị “câm” nếu cả con VPS bị mất kết nối mạng hoàn toàn — để lấp lỗ hổng đó, bạn luôn cần kết hợp thêm một dịch vụ Uptime Monitor độc lập đặt ở bên ngoài máy chủ.

Kết thúc đợt thử nghiệm trên LAB03, cả 4 cổng loopback đều đã đóng hoàn toàn; toàn bộ PID tiến trình, bộ nhận webhook và thư mục runtime đều được xóa sạch. Mã băm (hash) của các file cấu hình NGINX và mã nguồn WordPress hiện hữu trên máy chủ không thay đổi một byte nào. Riêng đầu cầu Cloudflare Worker còn được giữ lại thêm vài giờ để phục vụ bài kiểm tra gửi email từ WordPress trong cùng ngày (với cơ chế tự động từ chối mọi request sau mốc 13:20) trước khi được gỡ bỏ hoàn toàn. Tất nhiên, một dòng code giới hạn thời gian trong script chỉ là chốt chặn logic, không bao giờ thay thế cho thao tác xóa hẳn tài nguyên đám mây sau khi hết nhu cầu sử dụng.

Khi bạn quyết định đưa mô hình này vào vận hành dài hạn cho dự án thật, hãy lập bảng phân công rõ ràng: ai là người nhận cảnh báo chính, ai trực dự phòng, cơ chế gửi lại (retry) khi kênh thông báo đầu tiên thất bại là gì, và mục tiêu thời gian phản hồi tối đa (SLA/SLO) là bao nhiêu phút. Chẳng hạn, khi nhận được email báo LabNodeExporterDown, quy trình chuẩn cho người trực là: kiểm tra ngay trạng thái PID và cổng lắng nghe của Node Exporter, kiểm tra độc lập xem website có vào được bình thường không, khắc phục nguyên nhân làm dừng exporter rồi chờ nhận bức thư xác nhận resolved. Tuyệt đối không bao giờ tắt cảnh báo đi ngủ khi chưa tìm ra lý do vì sao hệ thống ngừng báo cáo số liệu.

Xử lý sự cố phát sinh và quy trình khôi phục trạng thái an toàn

Trong quá trình vận hành, nếu công cụ giám sát bên ngoài bất ngờ báo website bị Down trong khi bạn mở trình duyệt trên máy cá nhân vẫn thấy trang web chạy vèo vèo, đừng vội kết luận công cụ bị điên: hãy bình tĩnh kiểm tra sự khác biệt về máy chủ phân giải DNS ở các vùng địa lý, vị trí đặt node đo (probe location), hạn sử dụng chứng chỉ TLS hoặc xem tường lửa (WAF / Fail2ban) trên VPS có vô tình chặn nhầm dải IP của dịch vụ giám sát hay không. Ngược lại, nếu sau khi cài thêm agent giám sát mà thấy VPS bỗng nhiên ì ạch, hãy dừng ngay tiến trình agent vừa thêm vào rồi đo đạc lại để đối chứng.

Hãy nhớ sự khác biệt về mức độ tác động: các lệnh đọc chỉ số như df, free, vmstat hoàn toàn vô hại vì chúng chỉ đọc thông tin mà không sửa đổi dữ liệu; trong khi việc dựng một hệ thống giám sát như Prometheus sẽ sinh ra các tiến trình chạy nền và ghi dữ liệu liên tục xuống ổ đĩa. Khi muốn tháo gỡ môi trường thử nghiệm để đưa máy về trạng thái ban đầu, hãy tắt đúng các mã tiến trình PID mà bạn đã khởi tạo, đóng đường hầm SSH tunnel, và chỉ xóa đúng thư mục chứa bản thử nghiệm sau khi đã sao lưu lại những đoạn log cần thiết. Đối với hệ thống giám sát đang chạy chính thức, nếu cấu hình mới gây nhiễu, hãy khôi phục lại file cấu hình chứa chu kỳ quét và ngưỡng cảnh báo từ bản sao lưu ổn định trước đó rồi nạp lại dịch vụ. Và nguyên tắc tối thượng: không bao giờ tắt dịch vụ web đang phục vụ khách hàng chỉ để làm im tiếng kêu của công cụ cảnh báo!

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

Thấy cột RAM free còn rất ít có phải là dấu hiệu cần nâng cấp VPS ngay không?

Hoàn toàn không nên kết luận vội vàng như vậy! Trên Linux, hãy nhìn vào cột available kết hợp với việc theo dõi xem hệ thống có đang phải đẩy dữ liệu ra vào Swap liên tục hay không, có xuất hiện sự kiện OOM Killer giết tiến trình trong log nhân hệ điều hành không, và thời gian phản hồi thực tế của ứng dụng WordPress có bị chậm đi hay không.

CPU chạm ngưỡng bao nhiêu phần trăm thì được coi là nguy hiểm?

Chẳng có một con số phần trăm cố định nào đúng cho mọi hoàn cảnh cả. Mức độ nguy hiểm phụ thuộc vào việc đỉnh CPU đó kéo dài liên tục bao lâu, độ dài hàng đợi tiến trình (runnable queue / Load average) có bị ứ đọng không, và quan trọng nhất là người dùng cuối truy cập website có đang bị chậm hoặc gặp lỗi HTTP hay không.

Chỉ kiểm tra trạng thái dịch vụ bằng lệnh systemctl có đủ để khẳng định Uptime của website không?

Chắc chắn là chưa đủ! Lệnh systemctl chỉ cho biết tiến trình trên máy vẫn còn sống, chứ không phát hiện được lỗi hết hạn tên miền DNS, đứt cáp mạng, lỗi chứng chỉ SSL/TLS hay lỗi trắng trang bên trong mã nguồn PHP/WordPress. Bạn bắt buộc phải kết hợp kiểm tra truy vấn URL từ ngoài Internet và đối chiếu nội dung trang trả về.

Bước tiếp theo trong lộ trình làm chủ VPS

Ngay sau bài viết này, hãy tự lập một trang ghi chú ngắn gọn xác định rõ mục tiêu giám sát cho website của bạn, ghi lại các thông số đo đạc thực tế làm mốc chuẩn (baseline) và luôn so sánh các chỉ số trên cùng một phạm vi, cùng một đơn vị đo trước khi quyết định thay đổi cấu hình. Hạng mục nào chưa trực tiếp kiểm tra thì cứ ghi rõ là chưa kiểm chứng; nếu thử nghiệm thực tế cho kết quả khác với suy đoán ban đầu, hãy trân trọng giữ lại số liệu đó để hiểu rõ giới hạn của hệ thống. Khi đã nắm chắc bộ tiêu chí theo dõi sức khỏe máy chủ, mời anh em đi tiếp sang các bài chuyên sâu kế tiếp trong series WordPress từ A đến Z.

Tài liệu tham khảo và trạng thái đối chiếu kỹ thuật

Tài liệu đã đối chiếu ngày 02/10/2026: Prometheus: Hướng dẫn khởi đầu (First steps), Hướng dẫn triển khai Node Exporter, Alertmanager: Cấu hình kết nối Webhook, và Trang tải các bản phát hành kèm mã kiểm tra checksum. Toàn bộ cấu hình, ảnh chụp giao diện và bảng số liệu của phiên thực nghiệm trên máy lab đều được ghi rõ mốc thời gian thực hiện; lưu ý rằng kết quả thu nhận tại webhook nội bộ không thay thế cho bước xác nhận tin nhắn đến tay người trực.

Tài liệu đã đối chiếu ngày 01/10/2026: Ubuntu Noble Manpages: Công cụ free(1), Ubuntu Noble Manpages: Công cụ vmstat(8), và GNU Coreutils: Cách hoạt động của lệnh df. Các bảng số liệu thực tế và giới hạn của từng phép đo đã được phân tích chi tiết ở trên; không suy diễn kết quả của một mẫu đo ngắn cho các kịch bản vận hành dài hạn chưa được thực nghiệm.

Tài liệu nền tảng đã đối chiếu ngày 30/09/2026:

• Tài liệu chính thức của curl: Đo lường các mốc thời gian và bắt lỗi giao thức HTTP.
• GNU Coreutils: Phương pháp thống kê dung lượng thư mục bằng lệnh du.
• Tài liệu systemd: Truy vấn và lọc nhật ký hệ thống với journalctl.