Posted inCentos

Centralized Logging với Rsyslog trên CentOS Stream 9: Gom log về một mối cho ‘nhẹ đầu’

CentOS tutorial - IT technology blog
CentOS tutorial - IT technology blog

Ám ảnh mang tên “mò kim đáy bể” trong hàng chục file log

Anh em làm vận hành chắc chắn đều từng trải qua cảm giác hệ thống đang chạy ngon lành bỗng dưng “lăn đùng ra chết”. Cay nhất là không biết nó chết vì lý do gì. Lúc đó, việc đầu tiên là phải bới log để tìm nguyên nhân.

Nếu bạn chỉ quản lý 1-2 con server, việc SSH vào từng con rồi gõ tail -f /var/log/messages chỉ mất vài phút. Nhưng hãy tưởng tượng khi hệ thống lên tới 20, 50 hay hàng trăm máy ảo chạy microservices. Việc thủ công này thực sự là một cơn ác mộng. Bạn sẽ tốn cả tiếng đồng hồ chỉ để login qua lại giữa các cửa sổ terminal.

Mình nhớ hồi trước có cụm web server bị lỗi 502 liên tục vào lúc 2 giờ sáng. Mình phải mở 5 tab terminal, vừa ngái ngủ vừa soi từng con để xem máy nào báo lỗi upstream. Cảm giác lúc đó cực kỳ ức chế. Tệ hơn nữa, nếu server bị hỏng phần cứng đột ngột, toàn bộ bằng chứng (logs) cũng bay màu theo máy luôn. Đó là lúc mình hiểu: Centralized Logging không phải là tùy chọn, mà là bắt buộc.

Tại sao log cứ mãi rải rác và khó quản lý?

Mặc định, các bản phân phối Linux như CentOS Stream 9 đều lưu trữ log tại chỗ (local storage). Mọi dịch vụ từ SSH, Mail đến Kernel đều ghi vào các file riêng biệt trong /var/log/. Cách làm này bộc lộ 3 điểm yếu chí mạng:

  • Dữ liệu rời rạc: Để hiểu toàn bộ “bức tranh” hệ thống, bạn phải cặm cụi chắp vá thông tin từ 5-10 nguồn khác nhau.
  • Rủi ro bảo mật: Hacker khi chiếm được quyền root thường xóa sạch file log để xóa dấu vết. Nếu log chỉ nằm ở local, bạn coi như mất trắng khả năng điều tra.
  • Nguy cơ treo máy: Log ghi quá nhiều có thể làm đầy phân vùng /var. Điều này khiến các dịch vụ khác chết đứng vì không còn không gian lưu trữ.

Điểm danh các giải pháp phổ biến

Trên thị trường hiện có rất nhiều công cụ mạnh mẽ để giải quyết bài toán này:

  1. ELK Stack (Elasticsearch, Logstash, Kibana): Đứng đầu về khả năng tìm kiếm và biểu đồ. Tuy nhiên, ELK cực kỳ ngốn tài nguyên. Một cụm ELK cơ bản cần ít nhất 4-8GB RAM chỉ để khởi động.
  2. Graylog: Dễ quản lý hơn ELK nhưng vẫn yêu cầu hạ tầng đủ mạnh để vận hành ổn định.
  3. Loki + Grafana: Rất nhẹ, phù hợp cho môi trường Docker/Kubernetes, nhưng đòi hỏi bạn phải làm quen với ngôn ngữ truy vấn LogQL mới.

Rsyslog: Lựa chọn “ngon – bổ – rẻ” có sẵn

Với hệ thống quy mô vừa, hoặc nếu bạn ưu tiên sự ổn định và nhẹ nhàng, Rsyslog chính là chân ái. Công cụ này tiêu tốn chưa đến 50MB RAM nhưng lại cực kỳ mạnh mẽ. Nó được cài sẵn trên hầu hết các dòng RHEL-based như CentOS Stream 9, AlmaLinux hay Rocky Linux.

Khi CentOS 8 EOL, mình phải chuyển gấp một dàn server sang CentOS Stream 9. Việc đầu tiên mình làm là dựng lại cụm logging bằng Rsyslog. Nó chạy cực kỳ bền bỉ từ năm này qua năm khác mà gần như không cần bảo trì.

Bước 1: Cấu hình Log Server (Máy tiếp nhận log)

Chúng ta cần chọn một con server làm trung tâm. Toàn bộ cấu hình nằm tại file /etc/rsyslog.conf.

Mở file bằng trình soạn thảo bạn quen dùng:

sudo vi /etc/rsyslog.conf

Tìm và bỏ comment các dòng sau để Rsyslog mở cổng 514 cho cả UDP và TCP:

# For UDP
module(load="imudp")
input(type="imudp" port="514")

# For TCP
module(load="imtcp")
input(type="imtcp" port="514")

Để tránh việc log máy khách bị trộn lẫn với log máy chủ, mình sẽ dùng template để phân loại tự động. Thêm đoạn mã này vào cuối file:

$template RemoteLogs,"/var/log/remote/%HOSTNAME%/%PROGRAMNAME%.log"
*.* ?RemoteLogs
& ~

Cấu hình này giúp log tự động chia vào thư mục theo tên máy và tên ứng dụng. Lưu file lại và khởi động lại dịch vụ:

sudo systemctl restart rsyslog
sudo systemctl enable rsyslog

Bước 2: Mở Firewall trên CentOS Stream 9

Đừng quên mở cổng 514 trên firewall, nếu không máy khách sẽ bị chặn đường gửi log.

sudo firewall-cmd --permanent --add-port=514/udp
sudo firewall-cmd --permanent --add-port=514/tcp
sudo firewall-cmd --reload

Bước 3: Cấu hình Log Client (Máy gửi log)

Bây giờ, hãy sang các máy cần giám sát. Bạn cũng mở file /etc/rsyslog.conf ra:

sudo vi /etc/rsyslog.conf

Thêm dòng này xuống cuối cùng (nhớ thay IP bằng địa chỉ Log Server của bạn):

# Gửi log qua UDP (Nhanh nhưng có thể mất gói tin)
*.* @192.168.1.10:514

# Gửi log qua TCP (Chậm hơn nhưng tin cậy hơn)
*.* @@192.168.1.10:514

Khởi động lại Rsyslog trên client để áp dụng thay đổi:

sudo systemctl restart rsyslog

Bước 4: Kiểm tra thành quả

Trên máy Log Server, hãy kiểm tra thư mục /var/log/remote/:

ls -R /var/log/remote/

Để thử nghiệm ngay lập tức, bạn có thể bắn một thông điệp từ máy Client:

logger "Test thu centralized logging cho itfromzero!"

Quay lại Log Server, bạn sẽ thấy dòng này xuất hiện ngay trong file log của client đó. Cảm giác nhìn log từ mọi nơi đổ về một chỗ cực kỳ sướng, giống như bạn đang nắm trọn quyền kiểm soát toàn bộ hệ thống vậy.

Vài lưu ý “xương máu” từ thực tế

Khi triển khai cho hệ thống chạy thật (production), bạn cần chú ý 3 điều:

  1. Quản lý dung lượng: Log tập trung sẽ phình to rất nhanh. Hãy setup logrotate ngay lập tức để nén và xóa log cũ định kỳ (ví dụ giữ lại 30 ngày).
  2. Bảo mật đường truyền: Rsyslog mặc định gửi dữ liệu dạng text thuần. Nếu gửi qua Internet, bạn bắt buộc phải cấu hình TLS/SSL để tránh bị nghe lén thông tin nhạy cảm.
  3. SELinux: CentOS Stream 9 rất gắt về SELinux. Nếu bạn dùng port khác mặc định (514), đừng quên cập nhật lại nhãn cho port bằng lệnh semanage port.

Setup logging tập trung không khó, nhưng lợi ích mang lại là vô giá. Nó giúp bạn ngủ ngon hơn vì biết rằng nếu có sự cố, mọi bằng chứng đều đã nằm gọn một chỗ chờ bạn xử lý.

Share:
Tags: