Site icon ZingServer

Rsyslog: Cấu hình log tập trung VPS (Gửi log từ Client sang Server)

Team ZingServer
Rsyslog Cấu hình log tập trung VPS (Gửi log từ Client sang Server)

Rsyslog Cấu hình log tập trung VPS (Gửi log từ Client sang Server)

Bạn gõ lệnh journalctl -xe để kiểm tra lỗi VPS và nhận về thông báo bash: journalctl: command not found?

Nếu bạn gặp phải tình huống này, đừng lo lắng. Điều này không có nghĩa là VPS của bạn bị lỗi, mà rất có thể bạn đang sử dụng một hệ điều hành (OS) không dùng systemd-journald làm trình ghi log mặc định (ví dụ: CentOS 6).

Chào mừng bạn đến với Rsyslog – hệ thống log “kiểu cũ” nhưng cực kỳ mạnh mẽ, và vẫn là lựa chọn hàng đầu cho một tác vụ quản trị hệ thống quan trọng bậc nhất: Log tập trung (Centralized Logging).

Trong hướng dẫn chuyên sâu này, chúng ta sẽ đi từ A-Z: từ cách đọc log trong /var/log đến việc thiết lập một hệ thống log tập trung hoàn chỉnh, hiệu suất cao và đáng tin cậy, sử dụng 100% cú pháp RainerScript hiện đại.

Rsyslog là gì? Tại sao log tập trung VPS lại quan trọng?

Rsyslog (viết tắt của Rocket-fast System for log processing) là một dịch vụ ghi log hệ thống mã nguồn mở, hiệu suất cao, được sử dụng trên phần lớn các bản phân phối Linux/Unix.

Trong khi journalctl (ở các OS mới) rất tiện lợi cho việc xem log cục bộ, thì Rsyslog là “nhà vô địch” không thể thay thế khi bạn cần chuyển tiếp log qua mạng.

Đây là lúc khái niệm log tập trung (Centralized Log) phát huy sức mạnh. Thay vì phải SSH vào 10 VPS khác nhau để xem 10 file log, bạn chỉ cần cấu hình cả 10 VPS đó (gọi là Client) gửi toàn bộ log của chúng về một VPS Server duy nhất.

Lợi ích của mô hình này là rất lớn:

Rsyslog trong hệ sinh thái log: Phân biệt các “đối thủ”

Để cấu hình chuyên nghiệp, bạn cần hiểu rõ vị trí của Rsyslog.

Rsyslog vs. Journald (systemd-journald)

Điểm khác biệt lớn nhất nằm ở cách chúng lưu trữ log.

Tính năng Rsyslog (Kiểu cũ / Truyền thống) Journald (Kiểu mới / systemd)
Định dạng log Văn bản thuần túy (Plain Text) Nhị phân (Binary)
Nơi lưu trữ Thư mục /var/log (ví dụ: messages, secure) Thư mục /var/log/journal hoặc /run/log/journal
Cách đọc log Dùng lệnh Linux cơ bản: cat, tail, grep, less Dùng lệnh chuyên dụng: journalctl
OS mặc định CentOS 6, RHEL 6, Ubuntu cũ (trước 15.04) Hầu hết OS hiện đại: CentOS 7+, RHEL 7+, Ubuntu 16.04+, Debian 8+
Điểm mạnh Log tập trung cực kỳ mạnh mẽ và linh hoạt. Quản lý log dịch vụ systemd rất tốt, lọc mạnh mẽ.

Điểm mấu chốt:

Hai “ngôn ngữ” cấu hình của Rsyslog: Legacy vs. RainerScript

Đây là điểm “cạm bẫy” lớn nhất cho người mới. Rsyslog có hai cách viết cấu hình:

  1. Legacy (Cũ): Dùng các chỉ thị (directive) bắt đầu bằng dấu $ (ví dụ: $ModLoad, $template, $ActionQueueType) và cú pháp @@server để gửi log. Bạn sẽ thấy cú pháp này ở 90% các hướng dẫn cũ trên mạng.
  2. RainerScript (Mới/Hiện đại): Dùng cú pháp module(...), input(...), template(...), ruleset(...), và action(...). Đây là cú pháp được tài liệu chính thức của Rsyslog khuyến nghị vì nó rõ ràng, mạnh mẽ, hiệu suất cao và cho phép kiểm soát toàn diện (như hàng đợi, đa luồng).

Để đảm bảo hiệu suất và độ tin cậy cao nhất, hướng dẫn này sẽ sử dụng 100% cú pháp RainerScript hiện đại.

Hướng dẫn đọc log Rsyslog cơ bản (Dành cho người mới)

Trước khi cấu hình, bạn cần biết cách đọc log “cục bộ” trong /var/log.

Các file log quan trọng nhất

Giải mã log: Facility và Priority

Làm sao Rsyslog biết log SSH phải ghi vào secure? Đó là nhờ hai khái niệm:

Khái niệm Ý nghĩa Ví dụ
Facility (Nguồn) Chương trình/dịch vụ nào tạo ra log? auth (bảo mật), cron, kern (kernel), mail, local0-local7
Priority (Mức độ) Mức độ nghiêm trọng của log? debug, info, notice, warning, err, crit, emerg (khẩn cấp)

Khi bạn thấy cú pháp *.* trong các file cấu hình, nó có nghĩa là: Tất cả Facilities (*) và Tất cả Priorities (.*).

3 lệnh Linux “bất hủ” để đọc log

  1. tail (Xem đuôi file): Lệnh tail -f (follow) là quan trọng nhất, cho phép bạn xem log theo thời gian thực. 
    # Theo dõi log đăng nhập SSH real-time
tail -f /var/log/secure
  2. grep (Lọc): Dùng để tìm một từ khóa cụ thể trong một file log lớn. 
    # Tìm tất cả các lần đăng nhập SSH thất bại
grep "Failed password" /var/log/secure
  3. less (Xem file lớn): Cho phép bạn xem từng trang, cuộn lên/xuống và tìm kiếm (gõ / để tìm). 
    less /var/log/messages

Hướng dẫn cấu hình Rsyslog gửi log tập trung (Client-Server)

Đây là phần cốt lõi của bài viết. Chúng ta sẽ thiết lập một mô hình gồm:

Bước 1: Cấu hình VPS Server (Phiên bản RainerScript 100%)

Chúng ta sẽ thiết lập Server bằng cách định nghĩa một Template, một Ruleset (bộ quy tắc) riêng cho log từ xa, và sau đó “gắn” cổng đầu vào (input) vào ruleset đó.

  1. Mở file cấu hình:sudo nano /etc/rsyslog.conf
  2. Thêm cấu hình RainerScript hoàn chỉnh: Thêm toàn bộ khối sau vào đầu file, ngay dưới mục #### MODULES ####. 
    #### MODULES ####
# Tải module imtcp và thiết lập đa luồng (cho hiệu suất cao)
# WorkerThreads="2": Dùng 2 luồng để xử lý kết nối đến
# StarvationProtection.MaxReads="2000": Ngăn 1 client "hung hãn" chiếm hết tài nguyên
module(load="imtcp"
       WorkerThreads="2"
       StarvationProtection.MaxReads="2000")

# === (HIỆN ĐẠI) ĐỊNH NGHĨA TEMPLATE VÀ RULESET ===
# 1. Định nghĩa Template (Khuôn mẫu) lưu log bằng RainerScript
template(name="RemoteLogs"
         type="string"
         string="/var/log/%HOSTNAME%/%PROGRAMNAME%.log")

# 2. Định nghĩa Ruleset (Bộ quy tắc) CHỈ DÀNH CHO LOG TỪ XA
# Ruleset này sẽ xử lý TẤT CẢ log được input "remote" gửi đến.
ruleset(name="remote") {

    # Hành động: Ghi ra file, sử dụng "dynaFile" để
    # áp dụng template "RemoteLogs" đã định nghĩa ở trên.
    action(type="omfile"
           dynaFile="RemoteLogs")

    # Dừng xử lý (stop), không cho log này chạy vào
    # ruleset mặc định (tránh ghi vào /var/log/messages)
    stop
}
# =================================================

#### INPUTS ####
# Mở cổng 514 và "gắn" (bind) nó vào ruleset "remote"
# Toàn bộ log vào cổng 514 sẽ được đưa thẳng vào ruleset "remote"
input(type="imtcp" port="514" ruleset="remote")

# (Tùy chọn) Nếu bạn CẦN nhận cả UDP
# module(load="imudp")
# input(type="imudp" port="514" ruleset="remote")

    Giải thích: Cấu hình này tạo ra một ruleset (bộ quy tắc) tên là “remote”. Bất cứ log nào đi vào cổng 514 (TCP) sẽ được input “gắn” thẳng vào ruleset="remote". Ruleset này chỉ có một hành động là ghi log ra file theo template “RemoteLogs”, sau đó stop (dừng lại), đảm bảo log từ xa được cô lập hoàn toàn.

  3. Khởi động lại Rsyslog:
     
    sudo systemctl restart rsyslog

    (Nếu bạn chưa rõ về restart hoặc gặp lỗi start-limit-hit khi khởi động lại, hãy xem Hướng dẫn systemctl: Sửa lỗi VPS bằng Start, Stop, Restart dịch vụ.)

Bước 2: Cấu hình VPS Client (Phiên bản RainerScript hiện đại)

Giờ hãy qua từng VPS Client và “ra lệnh” cho chúng gửi log đến Server. Chúng ta dùng khối action() hiện đại để kiểm soát toàn diện, bao gồm cả hàng đợi (queues).

  1. Tạo file cấu hình mới: (Cách này sạch sẽ hơn là sửa file rsyslog.conf chính). 
    sudo nano /etc/rsyslog.d/10-remote-log.conf
  2. Thêm khối action() (Gửi log với hàng đợi): Thêm toàn bộ khối mã sau vào file. Đây là cấu hình duy nhất bạn cần cho Client, nó đã bao gồm sẵn tính năng “Queue” (hàng đợi) để chống mất log khi Server bị offline. 
    # === CẤU HÌNH GỬI LOG (HIỆN ĐẠI) ===
# Quy tắc: Gửi TẤT CẢ log (*.*) đến action() bên dưới
*.* action(type="omfwd"
    # --- Cấu hình Kết nối (Connection) ---
    target="<ĐỊA-CHỈ-IP-VPS-SERVER>"
    port="514"
    protocol="tcp"

    # --- Tăng độ tin cậy (Pro-Tip) ---
    # Gửi lại tin nhắn cuối cùng khi kết nối lại (giảm mất log)
    ResendLastMSGOnReconnect="on"

    # --- Cấu hình Hàng đợi (Queue) ---
    # Bật hàng đợi (queue) để chống mất log khi Server offline
    queue.type="linkedList"     # Dùng hàng đợi trên bộ nhớ (nhanh)
    queue.filename="fwdRule1"   # Tên file đệm (trên ổ đĩa) nếu tràn bộ nhớ
    queue.saveOnShutdown="on"   # Lưu lại hàng đợi khi tắt máy
    queue.resumeRetryCount="-1" # Cố gắng kết nối lại MÃI MÃI
    queue.maxDiskSpace="1g"     # Giới hạn file đệm là 1GB
)
# ========================================

    Ghi chú: Đừng quên thay <ĐỊA-CHỈ-IP-VPS-SERVER> bằng IP thật của Log Server của bạn.

  3. Khởi động lại Rsyslog trên Client:
     
    sudo systemctl restart rsyslog

Bước 3: Nâng cao (Tùy chọn): Gửi log Nginx/Apache bằng imfile

Mặc định, *.* chỉ gửi log hệ thống. Các log ứng dụng như Nginx (nằm ở /var/log/nginx/access.log) cần được cấu hình riêng bằng module imfile (Input Module File).

Trên VPS Client, hãy tạo một file cấu hình khác cho imfile:

sudo nano /etc/rsyslog.d/20-nginx-log.conf

Thêm nội dung sau:

# === CẤU HÌNH ĐỌC LOG NGINX ===

# Tải module imfile
module(load="imfile")

# --- Theo dõi file access.log ---
input(type="imfile"
      File="/var/log/nginx/access.log"
      Tag="nginx-access"
      Facility="local1"
      # Pro-Tip: Lưu "vị trí đọc" sau mỗi 100 dòng
      # Tránh đọc lại cả file nếu rsyslog bị crash
      PersistStateInterval="100"
)

# --- Theo dõi file error.log ---
input(type="imfile"
      File="/var/log/nginx/error.log"
      Tag="nginx-error"
      Facility="local1"
      PersistStateInterval="100"
)

# --- Quy tắc GỬI log Nginx ---
# Gửi TẤT CẢ log của Facility "local1" (mà ta vừa định nghĩa)
# đến Server, sử dụng cùng cấu hình action() đáng tin cậy ở trên.
local1.* action(type="omfwd"
             target="<ĐỊA-CHỈ-IP-VPS-SERVER>"
             port="514"
             protocol="tcp"
             ResendLastMSGOnReconnect="on"
             queue.type="linkedList"
             queue.filename="fwdNginx"  # Phải dùng tên queue khác!
             queue.saveOnShutdown="on"
             queue.resumeRetryCount="-1"
             queue.maxDiskSpace="1g"
           )

Lưu ý: Chúng ta dùng Facility local1 để “đánh dấu” log Nginx và fwdNginx làm tên file queue riêng biệt.

Bước 4: Kiểm tra và xử lý sự cố (Troubleshooting)

Làm thế nào để biết hệ thống đã hoạt động?

  1. Trên VPS Server: Kiểm tra xem Rsyslog đã thực sự lắng nghe trên cổng 514 chưa. 
    sudo ss -tulnp | grep rsyslog

    Bạn sẽ thấy kết quả LISTEN trên cổng 514 (hoặc *:514).

  2. Trên VPS Client: Gửi một log thử nghiệm. Lệnh logger được sinh ra chính là để làm việc này. 
    logger "Alo, day la log test tu VPS Client gui di"
  3. Trên VPS Server: Kiểm tra kết quả! Nếu tên hostname của Client là vps-client-01, bạn sẽ thấy một thư mục mới được tạo. Hãy tail file log của logger: 
    # (Đợi khoảng 30 giây để Rsyslog flush log)
tail -f /var/log/vps-client-01/logger.log

    Nếu bạn thấy dòng: Alo, day la log test tu VPS Client gui di, bạn đã thành công!

Log không đến? 2 “cạm bẫy” chí mạng cần kiểm tra NGAY LẬP TỨC

Nếu bạn đã làm đúng các bước trên mà log vẫn không đến Server, 99% bạn đã rơi vào một trong hai “cạm bẫy” kinh điển sau:

1. Firewall (Tường lửa) trên SERVER:

VPS Server của bạn có thể đang chặn kết nối đến cổng 514. Bạn phải “mở cổng” tường lửa.

2. SELinux (Trên CentOS/RHEL Server):

Đây là “cạm bẫy” đau đớn nhất. Bạn đã mở firewall-cmd nhưng log vẫn không đến? Rất có thể SELinux (Security-Enhanced Linux) đang âm thầm chặn Rsyslog nhận log từ mạng.

Bạn sẽ thấy các lỗi avc: denied trong log audit (hoặc khi dùng journalctl -p err như trong bài hướng dẫn journalctl).

Để sửa, bạn cần “bảo” SELinux rằng cổng 514 là cổng được phép cho syslogd sử dụng.

# Cài công cụ quản lý SELinux (nếu chưa có)
sudo yum install policycoreutils-python-utils -y

# Cho phép dịch vụ syslogd chạy trên cổng 514/tcp
sudo semanage port -a -t syslogd_port_t -p tcp 514

# Khởi động lại rsyslog để nhận chính sách mới
sudo systemctl restart rsyslog

Sau khi chạy 2 lệnh trên (Firewall và SELinux), hãy quay lại Client và logger một lần nữa. Log sẽ về ngay lập tức.

Lưu ý quan trọng và các bước nâng cao

Bạn đã có một hệ thống log tập trung mạnh mẽ. Đây là các bước tiếp theo để hoàn thiện nó.

Phân tích cấu hình hàng đợi (Queue) của chúng ta

Như đã thấy, chúng ta không cấu hình Queue (hàng đợi) như một “bước nâng cao”, mà chúng ta đã tích hợp nó ngay từ đầu vào khối action() của Client.

Đây là ý nghĩa của các tham số đó:

Cấu hình này đảm bảo độ tin cậy rất cao, chống mất log hiệu quả.

Cảnh báo bảo mật: Mã hóa log với TLS

Cấu hình chúng ta vừa làm gửi log qua mạng dưới dạng văn bản thuần túy (plain text). Kẻ tấn công có thể “nghe lén” và đọc được toàn bộ log của bạn.

Trong môi trường production, bạn bắt buộc phải mã hóa đường truyền này bằng TLS/SSL. Rsyslog hỗ trợ việc này một cách hoàn hảo (gọi là syslog-tls).

Việc này đòi hỏi bạn phải tạo Key và Certificate, sau đó thêm các tham số StreamDriver vào cả Server (imtcp) và Client (omfwd). Đây là một chủ đề phức tạp và bạn nên tham khảo tài liệu chính thức của Rsyslog về “Encrypting Syslog Traffic with TLS”.

“Gold Standard”: Sử dụng RELP

Ngay cả khi dùng TCP (với ResendLastMSGOnReconnect), vẫn có một số trường hợp cực đoan có thể gây mất log. Nếu bạn cần sự đảm bảo 100% tuyệt đối (ví dụ: log tài chính, ngân hàng), hãy sử dụng RELP (Reliable Event Logging Protocol).

RELP là một giao thức chạy trên TCP, yêu cầu Server phải “Xác nhận” (ACK) đã nhận được log thì Client mới xóa log đó khỏi hàng đợi. Rsyslog hỗ trợ RELP nguyên bản qua các module imrelp (Server) và omrelp (Client).

Log Rotation (Xoay vòng log)

Ổ cứng của Log Server sẽ bị đầy rất nhanh. Bạn cần thiết lập logrotate (một công cụ có sẵn trên Linux) để tự động nén (gzip) và xóa các file log cũ (ví dụ: log cũ hơn 30 ngày) trên Server.

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

1. Rsyslog có hoạt động trên CentOS 7 và Ubuntu 22.04 không?

Có, và chúng được thiết kế để hoạt động cùng nhau. Các OS hiện đại này dùng journald để thu thập log hệ thống (từ systemd). Sau đó, journald sẽ tự động chuyển tiếp một bản sao của log cho rsyslog để ghi ra các file text truyền thống (/var/log/messages, /var/log/secure…) và để thực hiện các hành động gửi log tập trung (như chúng ta vừa cấu hình).

2. Rsyslog và Syslog khác gì nhau?

Syslog là giao thức và dịch vụ ghi log truyền thống, rất cũ. Rsyslog là phiên bản thay thế hiện đại (“Rocket-fast”), mạnh mẽ hơn rất nhiều, hỗ trợ TCP, TLS, RELP, Queues, imfile và cú pháp RainerScript. Ngày nay, khi nói “syslog” trên Linux, hầu hết mọi người đều đang ngụ ý đến Rsyslog.

3. Cổng 514 là TCP hay UDP?

Cả hai. Cổng 514 là cổng tiêu chuẩn được gán cho giao thức syslog.

4. Làm sao để kiểm tra lỗi cấu hình Rsyslog (trước khi restart)?

Đây là một bước rất quan trọng. Sau khi sửa file .conf, hãy chạy lệnh sau để Rsyslog tự kiểm tra cú pháp. Nó sẽ báo cho bạn biết file nào và dòng nào bị lỗi:

rsyslogd -N1

Nếu mọi thứ ổn, nó sẽ báo “configuration syntax OK”.

5. Tôi có thể đổi cổng 514 không?

Có. Bạn có thể dùng bất kỳ cổng nào (ví dụ: 6514 cho TLS). Miễn là bạn phải:

Kết luận

journalctl có thể là công cụ xem log tiện lợi hàng ngày, nhưng Rsyslog vẫn là “nhà vô địch” không thể thay thế khi nói đến log tập trung.

Bằng cách sử dụng 100% cú pháp RainerScript hiện đại, bạn không chỉ thiết lập một hệ thống log tập trung, mà còn xây dựng một đường ống (pipeline) log mạnh mẽ, đáng tin cậy (với Queues), và hiệu suất cao. Đây là một kỹ năng quản trị hệ thống cốt lõi giúp bạn kiểm soát hoàn toàn “dấu vết” kỹ thuật số trên toàn bộ hạ tầng VPS của mình.

Bạn đang tìm kiếm một giải pháp VPS ổn định, hiệu suất cao để xây dựng máy chủ Log Server hoặc triển khai các ứng dụng quan trọng? Tham khảo ngay các gói VPS cấu hình cao tại ZingServer để trải nghiệm sự ổn định và tốc độ vượt trội!

Tài liệu tham khảo

Exit mobile version