Chi phí tài nguyên của việc quản lý Log hiện đại
Quản lý log trên một dàn máy chủ Linux thường buộc chúng ta phải đưa ra những lựa chọn khó khăn. Bạn có thể trung thành với Rsyslog cổ điển, vốn ổn định nhưng gặp khó khăn với dữ liệu nhị phân có cấu trúc hiện đại. Ngoài ra, bạn có thể triển khai ELK Stack (Elasticsearch, Logstash, Kibana) hoặc Loki. Mặc dù các công cụ này cung cấp khả năng phân tích mạnh mẽ, chúng lại nổi tiếng với việc tiêu tốn một lượng lớn CPU và RAM.
Gần đây tôi đã vấp phải rào cản này khi quản lý một cụm máy chủ VPS 2GB RAM. Thách thức không chỉ là thu thập log, mà là thực hiện điều đó mà không phải hy sinh 30% bộ nhớ hệ thống cho một công cụ lập chỉ mục (indexing engine) dựa trên Java. Trên máy chủ Ubuntu 22.04 thực tế, phương pháp systemd nguyên bản này giữ mức chiếm dụng bộ nhớ dưới 50MB. So sánh với con số 2GB hoặc hơn thường thấy ở một node Elasticsearch cơ bản, lợi ích sẽ trở nên rõ ràng.
Sự ức chế thường bắt nguồn từ việc công cụ không tương xứng với quy mô thực tế của hạ tầng. Nếu bạn đang quản lý từ 5 đến 50 máy chủ, có lẽ bạn không cần một kho lưu trữ dữ liệu (data warehouse) đồ sộ. Bạn chỉ cần chạy journalctl từ một nơi duy nhất để xem điều gì đang xảy ra trong mạng của mình. Đây chính là vấn đề mà systemd-journal-remote được tạo ra để giải quyết.
So sánh các phương pháp quản lý Log
Để hiểu tại sao systemd-journal-remote phù hợp với các môi trường nhỏ, chúng ta cần xem cách nó xử lý dữ liệu khác với các “ông lớn” như thế nào.
Rsyslog đối đầu với systemd-journal-remote
Rsyslog chủ yếu dựa trên văn bản (text-based). Khi systemd-journald gửi log đến Rsyslog, nó thường loại bỏ các metadata phong phú để phù hợp với định dạng syslog cũ. Bạn sẽ mất đi ngữ cảnh có cấu trúc của sự kiện. Ngược lại, systemd-journal-remote truyền log ở định dạng nhị phân nguyên bản. Điều này bảo toàn mọi trường dữ liệu, bao gồm _PID, _BOOT_ID, _TRANSPORT và metadata tùy chỉnh của ứng dụng.
ELK/Loki đối đầu với systemd-journal-remote
ELK cung cấp giao diện đồ họa trau chuốt và khả năng truy vấn phức tạp. Tuy nhiên, sức mạnh đó đi kèm với “thuế Java” — bạn cần một máy chủ riêng biệt với tài nguyên đáng kể. systemd-journal-remote sử dụng các công cụ mà bạn đã quen thuộc. Nó không yêu cầu cơ sở dữ liệu riêng vì nó sử dụng hệ thống tệp (filesystem) làm công cụ lưu trữ. Đây là một cơ chế đơn giản giúp di chuyển các mục nhật ký nhị phân từ điểm A đến điểm B.
Ưu điểm và Hạn chế
Tại sao giải pháp này hiệu quả
- Mức độ học hỏi thấp: Nếu bạn biết sử dụng
journalctl, bạn đã có thể làm việc ngay lập tức. - Hiệu suất cao: Được viết bằng C và tích hợp vào hệ thống init, nó sử dụng tài nguyên không đáng kể.
- Đầy đủ ngữ cảnh: Mọi mẩu metadata từ máy chủ nguồn đều được giữ nguyên để phục vụ việc debug.
- Bảo mật mặc định: Hỗ trợ HTTPS và mutual TLS (mTLS) mà không cần plugin bên thứ ba.
Những điểm còn hạn chế
- Không có bảng điều khiển trực quan: Bạn sẽ không tìm thấy biểu đồ hình tròn nào ở đây. Đây là một công cụ ưu tiên giao diện dòng lệnh (CLI).
- Chế độ lưu giữ cơ bản: Bạn phải tự quản lý dung lượng đĩa thông qua cấu hình systemd hoặc các tác vụ cron thủ công.
- Giới hạn quy mô: Hoạt động tuyệt vời cho hàng chục máy chủ, nhưng thiếu các tính năng mở rộng quy mô theo chiều ngang như Elasticsearch cho hàng nghìn node.
Kiến trúc đề xuất
Trong thiết lập này, chúng ta chỉ định một máy chủ làm Collector (Bộ thu thập) và các máy chủ khác là Nodes (Nút). Chúng ta sẽ sử dụng mô hình “Push” (Đẩy). Mỗi node chạy dịch vụ systemd-journal-upload để gửi log đến collector qua một kết nối được mã hóa.
Tôi khuyên bạn nên gắn (mount) một phân vùng hoặc ổ đĩa riêng tại /var/log/journal/remote trên collector. Điều này ngăn hệ thống tệp gốc (root filesystem) bị đầy nếu một node bắt đầu gửi log dồn dập do lỗi dịch vụ.
Hướng dẫn triển khai
1. Cài đặt các thành phần
Cả Collector và các Node đều yêu cầu gói systemd-journal-remote. Trên các hệ thống Debian hoặc Ubuntu, hãy cài đặt bằng lệnh:
sudo apt update
sudo apt install systemd-journal-remote -yĐối với người dùng RHEL, AlmaLinux hoặc Fedora:
sudo dnf install systemd-journal-remote2. Cấu hình Collector
Collector phải được chỉ định để lắng nghe các kết nối đến. Theo mặc định, nó sử dụng cổng 19532. Mở tệp cấu hình để xác định cách lưu log:
sudo nano /etc/systemd/journal-remote.confThiết lập phần [Remote] như sau:
[Remote]
Seal=false
SplitMode=hostLưu ý: SplitMode=host là rất quan trọng. Nó tạo ra một tệp journal riêng biệt cho mỗi máy chủ từ xa, giúp việc lọc log theo hostname nhanh hơn nhiều.
Tiếp theo, kích hoạt socket và dịch vụ:
# Kích hoạt socket lắng nghe
sudo systemctl enable --now systemd-journal-remote.socket
# Khởi chạy dịch vụ quản lý
sudo systemctl enable --now systemd-journal-remote.service3. Cấu hình các Node
Trên mọi máy chủ bạn muốn giám sát, bạn phải trỏ bộ tải lên (uploader) tới địa chỉ IP của collector. Chỉnh sửa cấu hình upload:
sudo nano /etc/systemd/journal-upload.confCập nhật URL để khớp với collector của bạn:
[Upload]
URL=http://10.0.0.50:19532Kích hoạt uploader để bắt đầu gửi dữ liệu:
sudo systemctl enable --now systemd-journal-upload4. Bảo mật: Tăng cường với TLS
Gửi log qua HTTP thông thường là rủi ro trên các mạng công cộng. Tôi luôn khuyên bạn nên sử dụng chứng chỉ TLS. Cập nhật journal-remote.conf trên collector để trỏ tới các khóa của bạn:
[Remote]
ServerKeyFile=/etc/ssl/private/journal.key
ServerCertificateFile=/etc/ssl/certs/journal.crt
TrustedCertificateFile=/etc/ssl/certs/ca.crtTrên các node của bạn, hãy đổi URL thành https:// trong journal-upload.conf và cung cấp các chứng chỉ client tương ứng.
Truy vấn Log tập trung
Đây là lúc thiết lập phát huy tác dụng. Khi log bắt đầu được gửi đến, chúng sẽ xuất hiện trong /var/log/journal/remote/. Bạn không cần giải nén hay dùng lệnh cat để xem các tệp này; chỉ cần sử dụng journalctl.
Để kiểm tra log từ một máy chủ từ xa cụ thể:
journalctl --directory /var/log/journal/remote/ --file remote-host-10.0.0.101.journalĐể xem luồng dữ liệu trực tiếp của tất cả các log gửi đến từ toàn bộ cụm máy chủ:
journalctl --directory /var/log/journal/remote/ -fSử dụng cờ -o json cho phép bạn chuyển các log này qua đường ống (pipe) vào jq. Điều này giúp dễ dàng lọc các lỗi cụ thể mà không cần mở trình duyệt web.
Lời kết
Nếu bạn đang quản lý hàng trăm microservices, hãy tiếp tục với ELK hoặc Loki. Nhưng đối với những người đang vận hành một nhóm máy chủ Linux tập trung, nơi hiệu suất là ưu tiên hàng đầu, systemd-journal-remote là lựa chọn thông minh hơn. Nó tôn trọng tài nguyên hệ thống và tận dụng hệ sinh thái systemd hiện có. Công cụ này đã biến quy trình xử lý sự cố qua SSH nhiều bước của tôi thành một lệnh cục bộ duy nhất và nhanh chóng.
