Cảnh tượng “nhảy” qua từng server để bới log
Hồi mới vào nghề, mình quản lý khoảng 5 con VPS chạy web. Mỗi khi có lỗi, quy trình lặp đi lặp lại phát nản: SSH vào Server 1, gõ tail -f, không thấy gì lại thoát ra, rồi sang Server 2. Với 5 server thì còn chịu được, nhưng khi hệ thống scale lên 20-30 node kèm Switch, Router, cách làm này thực sự là một thảm họa về năng suất.
Rủi ro lớn hơn là vấn đề bảo mật. Nếu hacker xâm nhập và xóa sạch dấu vết trong /var/log/, hoặc server đột ngột hỏng phần cứng, bạn sẽ hoàn toàn “mù tịt” về nguyên nhân sự cố. Đó là lúc mình hiểu rằng một hệ thống lưu trữ log tập trung (Centralized Logging) không còn là tùy chọn, mà là bắt buộc.
Tại sao bạn cần một “kho chứa” log trung tâm?
Vấn đề lớn nhất là dữ liệu bị phân tán. Hãy tưởng tượng lỗi từ Load Balancer kéo theo lỗi ở Web App và Database. Việc xâu chuỗi sự kiện trên các dòng thời gian khác nhau là cực hình nếu bạn không nhìn thấy chúng ở cùng một nơi.
Bên cạnh đó, việc lưu log tại chỗ (local) rất dễ gây tràn đĩa cứng. Chỉ cần một dịch vụ bị loop lỗi và ghi log liên tục, nó có thể ngốn sạch 10-20GB dung lượng chỉ trong vài giờ, làm treo luôn server đó.
Rsyslog: Giải pháp “ngon – bổ – rẻ”
Hiện nay có nhiều công cụ quản lý log, nhưng mỗi loại lại phục vụ nhu cầu khác nhau:
- Cloud Solutions (Datadog, Splunk): Tính năng cực mạnh nhưng hóa đơn cuối tháng có thể lên tới hàng nghìn USD nếu lượng log lớn.
- ELK Stack (Elasticsearch, Logstash, Kibana): Chuyên nghiệp, tìm kiếm nhanh nhưng cực kỳ “ngốn” tài nguyên. Một cụm ELK cơ bản cần ít nhất 8GB RAM để chạy ổn định.
- Rsyslog: Có sẵn trên Ubuntu, cực nhẹ (chỉ tốn khoảng 10-20MB RAM) và cấu hình đơn giản.
Bước 1: Cấu hình Rsyslog Server (Máy nhận log)
Giả sử Log Server của bạn có IP là 192.168.1.100. Việc đầu tiên là mở cổng để đón log từ các máy khác gửi về.
Mở file cấu hình bằng lệnh:
sudo nano /etc/rsyslog.conf
Tìm và bỏ comment các dòng sau. Mình khuyên nên mở cả UDP (để đạt tốc độ cao) và TCP (để đảm bảo không mất log):
# Nhận log qua UDP
module(load="imudp")
input(type="imudp" port="514")
# Nhận log qua TCP
module(load="imtcp")
input(type="imtcp" port="514")
Để tránh việc log từ 50 server đổ chung vào một file syslog gây rối loạn, chúng ta sẽ phân loại chúng. Thêm đoạn template này vào trước phần GLOBAL DIRECTIVES:
$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& ~
Dòng này yêu cầu Rsyslog tự động tạo thư mục theo tên máy chủ và file theo tên ứng dụng. Dấu & ~ rất quan trọng. Nó yêu cầu hệ thống dừng xử lý log sau khi ghi vào template, tránh việc log bị ghi lặp lại vào file hệ thống cục bộ.
Khởi động lại service và mở firewall:
sudo systemctl restart rsyslog
sudo ufw allow 514/udp
sudo ufw allow 514/tcp
Bước 2: Cấu hình Rsyslog Client (Máy gửi log)
Trên các máy con, cấu hình cực kỳ tối giản. Bạn chỉ cần điều hướng log về server trung tâm.
sudo nano /etc/rsyslog.conf
Thêm dòng này vào cuối file (dùng một dấu @ cho UDP, hai dấu @@ cho TCP):
*.* @@192.168.1.100:514
Sau đó restart lại service: sudo systemctl restart rsyslog.
Bước 3: Kiểm tra kết quả
Tại máy Log Server, hãy kiểm tra thư mục /var/log/remote/. Bạn sẽ thấy các thư mục mang tên hostname của máy client xuất hiện ngay lập tức.
ls /var/log/remote/
Quản lý dung lượng với Logrotate
Gom log về một chỗ mà không dọn dẹp thì ổ cứng sẽ sớm “bốc hỏa”. Với khoảng 10 server gửi log liên tục, mỗi ngày bạn có thể mất vài GB dung lượng. Chúng ta sẽ dùng logrotate để nén và xóa log cũ.
Tạo file cấu hình mới:
sudo nano /etc/logrotate.d/remote-logs
Sử dụng nội dung sau:
/var/log/remote/*/*.log {
daily
missingok
rotate 30
compress
notifempty
sharedscripts
postrotate
/usr/lib/rsyslog/rsyslog-rotate
endscript
}
Cấu hình này sẽ xoay vòng log hàng ngày, giữ lại 30 bản gần nhất và nén chúng lại. Bạn có thể tiết kiệm tới 90% dung lượng nhờ việc nén log này.
Vài lưu ý “xương máu” khi vận hành
- Bảo mật là trên hết: Syslog mặc định không mã hóa. Nếu gửi log qua Internet, hãy chạy qua VPN (như WireGuard) hoặc cấu hình TLS. Tuyệt đối không phơi cổng 514 ra Public Internet.
- Đồng bộ thời gian: Hãy cài đặt NTP trên tất cả server. Nếu lệch múi giờ, việc điều tra lỗi giữa các server sẽ trở thành một mê cung không có lối thoát.
- Lọc log tại nguồn: Nếu ứng dụng log quá nhiều tin nhắn rác (debug log), hãy cấu hình lọc ngay tại máy client để tiết kiệm băng thông đường truyền.
Xây dựng Syslog Server là bước đầu tiên để bạn tiến lên làm quản trị hệ thống chuyên nghiệp. Nó không chỉ giúp bạn nhàn hơn khi fix bug mà còn là nền tảng để xây dựng các hệ thống cảnh báo (Alerting) sau này.

