Cứ hỏi “giám sát server Linux bằng gì” là sẽ có người trả lời “dựng Zabbix đi”. Lời khuyên đó không sai, nhưng nó bỏ qua một câu hỏi quan trọng hơn: bạn có sẵn người để vận hành thêm một hệ thống nữa không? Bài này so sánh trung thực ba hướng phổ biến, kèm tiêu chí chọn cho từng hoàn cảnh.
Vì sao “cứ dựng Zabbix” không phải câu trả lời cho mọi người?
Một hệ thống giám sát tự dựng cũng là một hệ thống cần được giám sát. Nó cần máy chủ riêng, database lưu số liệu, quy trình backup, vá lỗi và nâng cấp phiên bản. Khi nó sập, bạn mù hoàn toàn, và không có gì báo cho bạn biết nó đã sập.
Với doanh nghiệp có đội vận hành riêng, đó là chi phí chấp nhận được để đổi lấy quyền kiểm soát tuyệt đối. Với đội 1-3 người vừa code vừa lo hạ tầng, đó thường là một dự án bị bỏ dở sau 2 tuần. Vậy nên hãy xem đủ cả ba hướng trước khi quyết.
Hướng 1: Tự dựng Zabbix hoặc Prometheus với Grafana?
Đây là hướng mạnh nhất về tính năng và cũng nặng nhất về công vận hành.
Zabbix là bộ trọn gói: server, web UI, cảnh báo, auto-discovery trong một sản phẩm. Cấu hình qua giao diện, template có sẵn cho hầu hết dịch vụ phổ biến. Đổi lại, học Zabbix không nhanh: khái niệm host, item, trigger, action cần thời gian làm quen, và database của nó phình rất nhanh nếu không tinh chỉnh housekeeping.
Prometheus + Grafana là chuẩn của thế giới cloud-native. Prometheus thu metric qua mô hình pull, Grafana vẽ dashboard, Alertmanager định tuyến cảnh báo. Ngôn ngữ truy vấn PromQL cực mạnh. Đổi lại, bạn phải tự ghép ít nhất 3 thành phần cộng với node_exporter trên mỗi server, tất cả cấu hình bằng YAML, và lưu trữ dài hạn cần thêm thành phần như Thanos.
Hợp với ai: đội có ít nhất một người chuyên trách hạ tầng, cần giữ số liệu trong mạng nội bộ, giám sát từ vài chục server trở lên, hoặc cần metric tùy biến sâu theo ứng dụng.
Không hợp với ai: đội nhỏ chỉ cần biết server còn sống, đĩa còn trống và website còn chạy. Dùng dao mổ trâu giết gà thì con dao lại thành gánh nặng bảo trì.
Hướng 2: Tự viết script giám sát?
Hướng này rẻ nhất khi bắt đầu và đắt dần theo thời gian. Một script kiểm tra đĩa gửi cảnh báo qua email trông thế này:
#!/bin/bash
# /etc/cron.d/check-disk: chạy mỗi 5 phút
USAGE=$(df / --output=pcent | tail -1 | tr -dc '0-9')
if [ "$USAGE" -gt 85 ]; then
echo "Đĩa / đã dùng ${USAGE}%" | mail -s "[CANH BAO] $(hostname)" ops@congty.vn
fiMười lăm phút là xong, và nó chạy thật. Vấn đề xuất hiện sau đó:
- Không có lịch sử. Bạn biết đĩa đang 86% nhưng không biết nó tăng từ bao giờ, nhanh hay chậm.
- Không ai giám sát người giám sát. Server chết thì script cũng chết theo, và im lặng.
- Cảnh báo lặp vô hạn. Script trên gửi email mỗi 5 phút cho đến khi bạn xử lý xong. Muốn chống spam phải viết thêm cơ chế ghi trạng thái.
- Mỗi nhu cầu mới là một script mới. Kiểm tra RAM, service, chứng chỉ SSL, container… mỗi thứ một file, mỗi server một bản sao, sửa một chỗ phải sửa mọi nơi.
Hợp với ai: người quản trị 1-2 server cá nhân, muốn hiểu hệ thống từ gốc, hoặc cần một kiểm tra rất đặc thù mà không công cụ nào có sẵn.
Hướng 3: Dùng dịch vụ giám sát có agent?
Mô hình này đảo ngược gánh nặng vận hành: bạn cài một agent nhỏ trên server, agent đọc CPU, RAM, đĩa, trạng thái dịch vụ và container rồi gửi về hạ tầng của nhà cung cấp. Dashboard, lưu trữ lịch sử, cảnh báo, trang trạng thái đều là việc của họ.
Ưu điểm rõ nhất là thời gian: từ lúc đăng ký đến lúc có cảnh báo đầu tiên tính bằng phút, không phải bằng buổi. Hệ thống giám sát nằm ngoài hạ tầng của bạn nên khi server sập, cảnh báo vẫn phát đi được. Nhược điểm cũng cần nói thẳng: số liệu nằm trên hạ tầng bên thứ ba, tính năng gói trong khung nhà cung cấp định sẵn, và vượt gói miễn phí thì phải trả phí định kỳ.
Nếu chọn hướng này, hãy soi kỹ ba điểm: agent có mở cổng trên server không (không nên), kênh cảnh báo có phải kênh bạn thật sự đọc không, và giới hạn gói miễn phí ở đâu. Ví dụ AgentWatch dùng agent binary tĩnh cho linux amd64 và arm64, chỉ gửi số liệu ra ngoài qua HTTPS, cảnh báo qua Zalo và email, gói Free cho 2 server với 10 check ở chu kỳ 5 phút. Chi tiết cách agent hoạt động có ở trang giới thiệu agent.
Hợp với ai: đội nhỏ và vừa, agency quản server cho khách, startup muốn dồn thời gian cho sản phẩm thay vì cho công cụ.
So sánh nhanh ba hướng thế nào?
| Tiêu chí | Zabbix / Prometheus | Script tự viết | Dịch vụ có agent |
|---|---|---|---|
| Thời gian có cảnh báo đầu tiên | Vài buổi đến vài ngày | 15-30 phút cho 1 check | Vài phút |
| Chi phí tiền | 0đ phần mềm, tốn máy chủ riêng | 0đ | Có gói free, trả phí khi vượt |
| Chi phí thời gian vận hành | Cao, liên tục | Tăng dần theo số check | Gần như 0 |
| Lịch sử, biểu đồ | Đầy đủ, tùy biến sâu | Không có sẵn | Có sẵn theo gói |
| Giám sát được cả khi server sập | Có, nếu đặt máy riêng | Không | Có |
| Kiểm soát dữ liệu | Toàn quyền | Toàn quyền | Nằm ở nhà cung cấp |
| Tùy biến metric đặc thù | Không giới hạn | Không giới hạn | Trong khung nhà cung cấp |
Chọn hướng nào cho đúng hoàn cảnh?
Ba câu hỏi giúp chốt nhanh:
- Có người chuyên trách hạ tầng không? Không có thì loại hướng tự dựng, trừ khi bạn muốn chính mình thành người đó.
- Bao nhiêu server? Dưới 10 server, chi phí dịch vụ thường thấp hơn hẳn tiền máy chủ cộng thời gian nuôi Zabbix. Trên vài chục server, bài toán bắt đầu nghiêng về tự dựng.
- Số liệu có bắt buộc ở trong mạng nội bộ không? Nếu có ràng buộc tuân thủ, tự dựng là lựa chọn duy nhất.
Và một lối đi thực dụng: bắt đầu bằng dịch vụ có agent để có giám sát ngay hôm nay, rồi nếu hệ thống phình đến mức cần Prometheus, bạn dựng sau với đầy đủ hiểu biết về những gì mình thật sự cần đo. Giám sát tồi nhất là loại chưa kịp dựng xong.