Posted inLinux

Tập trung Log Linux với systemd-journal-remote: Giải pháp ‘nhẹ cân’ thay thế ELK

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

Nỗi ám ảnh mang tên “mỗi server một nẻo”

Hồi mới làm sysadmin cho một startup, mình quản lý cụm 10 server chạy microservices. Mỗi khi hệ thống gặp sự cố, mình phải SSH vào từng con, gõ journalctl -u app -f để soi lỗi. Mọi chuyện vẫn ổn cho đến khi một lỗi dây chuyền (cascading failure) xảy ra. Mình cuống cuồng nhảy qua lại giữa 10 cái terminal, hoa cả mắt mà vẫn không tìm ra điểm khởi phát lỗi.

Lúc đó mình hiểu rằng: Nếu không gom log về một mối, việc debug chẳng khác nào mò kim đáy bể. Tuy nhiên, các server này chỉ có 1GB RAM. Cài bộ ELK (Elasticsearch – Logstash – Kibana) hay Grafana Loki vào là server “ngáp” ngay lập tức. Mình cần một giải pháp cực nhẹ, có sẵn và phải giữ được metadata của systemd.

Tại sao log nhị phân của systemd lại đặc biệt?

Đa số distro Linux hiện đại như Ubuntu, Debian hay AlmaLinux đều dùng systemd-journald. Khác với file text thuần túy tại /var/log/syslog, log của systemd lưu dưới dạng nhị phân (binary).

Định dạng này sở hữu ưu điểm vượt trội. Nó lưu kèm ID process, tên Unit, thời gian chính xác đến micro giây và user thực thi. Nếu dùng rsyslog để đẩy log, bạn thường phải convert chúng sang dạng text. Việc này vô tình làm mất đi cấu trúc dữ liệu giàu có mà journalctl có thể khai thác.

systemd-journal-remote sinh ra để giải quyết vấn đề này. Nó truyền tải nguyên vẹn file nhị phân qua mạng. Mọi metadata từ máy khách (Client) sẽ được giữ nguyên khi về tới máy chủ tập trung (Collector).

So sánh các phương án quản lý log

Trước khi bắt tay vào cấu hình, hãy nhìn qua các lựa chọn phổ biến:

  • Rsyslog: Rất nhẹ nhưng cấu hình phức tạp. Nó thường biến log thành dạng text thô, mất metadata.
  • ELK Stack: Cực kỳ mạnh mẽ nhưng là “quái vật” ngốn tài nguyên. Một node Elasticsearch cần tối thiểu 4GB RAM để chạy ổn định.
  • Loki + Promtail: Hiện đại và tiết kiệm hơn ELK. Tuy nhiên, bạn vẫn phải cài thêm agent bên thứ ba.

systemd-journal-remote là lựa chọn tối giản nhất. Nó thuộc hệ sinh thái systemd, không cần database ngoài và chỉ tiêu tốn vài chục MB RAM.

Hướng dẫn cấu hình chi tiết

Giả sử bạn có 2 server:

  • Log-Server (192.168.1.10): Nơi nhận log.
  • Client-Node (192.168.1.20): Server gửi log.

Bước 1: Cài đặt package

Công cụ này thường không có sẵn trên các bản cài rút gọn. Bạn cần cài nó trên cả hai máy.

Với Ubuntu/Debian:

sudo apt update && sudo apt install systemd-journal-remote -y

Với RHEL/AlmaLinux:

sudo dnf install systemd-journal-remote -y

Bước 2: Thiết lập Log-Server (Máy nhận)

Chúng ta sẽ cấu hình máy chủ lắng nghe qua HTTP để triển khai nhanh trong mạng nội bộ. Lưu ý: Đừng dùng HTTP nếu truyền log qua Internet công cộng.

Mở port 19532 bằng cách chỉnh sửa socket:

sudo systemctl edit systemd-journal-remote.socket

Thêm nội dung sau:

[Socket]
ListenStream=19532

Kích hoạt dịch vụ:

sudo systemctl enable --now systemd-journal-remote.socket
sudo systemctl start systemd-journal-remote.service

Cấp quyền cho thư mục lưu trữ log:

sudo mkdir -p /var/log/journal/remote
sudo chown systemd-journal-remote:systemd-journal-remote /var/log/journal/remote

Bước 3: Thiết lập Client-Node (Máy gửi)

Tại máy khách, chúng ta dùng systemd-journal-upload để đẩy log đi.

Mở file /etc/systemd/journal-upload.conf và sửa dòng URL:

[Upload]
URL=http://192.168.1.10:19532

Sau đó, khởi chạy service:

sudo systemctl enable --now systemd-journal-upload

Bước 4: Kiểm tra kết quả

Quay lại Log-Server, bạn hãy kiểm tra thư mục lưu trữ:

ls -l /var/log/journal/remote/

Một file mới có tên remote-192.168.1.20.journal sẽ xuất hiện. Để xem log từ xa trong thời gian thực, hãy gõ:

journalctl --file /var/log/journal/remote/remote-192.168.1.20.journal -f

Lúc này, mọi log từ máy client sẽ hiện ra đầy đủ metadata như đang gõ trực tiếp tại máy đó.

Kinh nghiệm thực tế khi triển khai

Mình từng tốn cả buổi chiều chỉ để debug lỗi log không về. Dưới đây là 3 điểm bạn cần lưu ý:

  1. Firewall: Luôn nhớ mở port 19532. Nếu dùng ufw, hãy chạy sudo ufw allow 19532/tcp ngay lập tức.
  2. Quyền ghi file: Nếu systemd-journal-remote không có quyền ghi vào thư mục remote, nó sẽ dừng hoạt động mà không báo lỗi rõ ràng. Hãy kiểm tra bằng journalctl -u systemd-journal-remote.
  3. Bảo mật TLS: Khi truyền log qua môi trường không tin cậy, HTTPS là bắt buộc. Bạn sẽ cần tạo certificate (.pem) để mã hóa đường truyền, tránh rò rỉ thông tin nhạy cảm.

Kết luận

Tập trung log không nhất thiết phải dùng đến những hệ thống cồng kềnh. Với systemd-journal-remote, bạn có một giải pháp “nhà làm” mạnh mẽ và tốn ít tài nguyên. Đây là bước đệm quan trọng để bạn quản trị hệ thống chuyên nghiệp hơn, thay vì tốn thời gian SSH thủ công vào từng máy mỗi khi có biến.

Share:
Tags: