Quản lý log Linux bằng journald: đọc log, lọc sự cố và xây runbook vận hành

quản lý log Linux bằng journald là kỹ năng nền tảng của sysadmin khi vận hành server production. Khi website lỗi 502, SSH chập chờn, service tự restart hoặc database chậm bất thường, log thường là nơi cho biết chuyện gì đã xảy ra trước khi sự cố bùng lên.

Bài này hướng dẫn thực chiến cách dùng journalctl để đọc log systemd, lọc theo service, theo thời gian, theo mức độ lỗi, bật persistent log, trích xuất bằng chứng và biến thao tác điều tra thành runbook. Mục tiêu không chỉ là biết lệnh, mà là biết đặt câu hỏi đúng khi production có vấn đề.

1. Journald là gì và vì sao sysadmin nên dùng?

systemd-journald là thành phần thu thập log trên nhiều bản phân phối Linux hiện đại như Ubuntu, Debian, RHEL, AlmaLinux và Rocky Linux. Nó nhận log từ kernel, service systemd, syslog socket, stdout/stderr của daemon và lưu dưới dạng journal có metadata.

Khác với việc chỉ đọc file trong /var/log, journald cho phép lọc theo unit, PID, boot ID, priority, khoảng thời gian và xuất JSON để đưa vào pipeline khác. Vì vậy, quản lý log Linux bằng journald giúp rút ngắn thời gian điều tra sự cố.

2. Lab/production mẫu

  • OS: Ubuntu Server 22.04/24.04 hoặc Debian 12.
  • Service mẫu: nginx.service, ssh.service, mysql.service.
  • Quyền: user có sudo để xem log hệ thống đầy đủ.

3. Kiểm tra trạng thái journald

systemctl status systemd-journald
journalctl --disk-usage

Output mẫu:

Archived and active journals take up 256.0M in the file system.

Nếu journal quá lớn, cần cấu hình giới hạn dung lượng thay vì xóa thủ công vô tội vạ.

4. Đọc log cơ bản bằng journalctl

journalctl
journalctl -n 50
journalctl -f
  • journalctl: đọc toàn bộ log theo thứ tự thời gian.
  • -n 50: xem 50 dòng gần nhất.
  • -f: follow log realtime, hữu ích khi restart service hoặc tái hiện lỗi.

5. Lọc log theo service systemd

Khi Nginx lỗi, đừng grep toàn bộ log trước. Hãy lọc đúng unit:

journalctl -u nginx.service -n 100 --no-pager
journalctl -u nginx.service --since "1 hour ago"

Output mẫu:

nginx[1234]: nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Dòng này cho biết port 80 đã bị process khác chiếm, hướng xử lý là kiểm tra socket thay vì sửa file cấu hình lung tung.

6. Lọc theo thời gian khi có mốc sự cố

Nếu người dùng báo “web lỗi khoảng 14:10”, hãy khoanh vùng:

journalctl --since "2026-05-13 14:00" --until "2026-05-13 14:30" --no-pager

Kết hợp service:

journalctl -u php8.2-fpm --since "2026-05-13 14:00" --until "2026-05-13 14:30"

Cách này giảm nhiễu và giúp timeline rõ hơn trong postmortem.

7. Lọc theo mức độ lỗi

journalctl -p err -b
journalctl -p warning..alert --since today
  • -p err: chỉ lấy lỗi mức error trở lên.
  • -b: chỉ boot hiện tại.
  • warning..alert: lấy dải priority từ warning đến alert.

8. Xem log theo lần boot

journalctl --list-boots
journalctl -b -1 -p err

-b -1 xem boot trước đó. Rất hữu ích khi server vừa reboot bất thường hoặc kernel panic.

9. Bật persistent log để không mất log sau reboot

Một số hệ thống chỉ lưu journal tạm trong /run/log/journal. Kiểm tra và bật lưu bền vững:

sudo mkdir -p /var/log/journal
sudo systemctl restart systemd-journald
journalctl --disk-usage

Cấu hình trong /etc/systemd/journald.conf:

[Journal]
Storage=persistent
SystemMaxUse=1G
SystemKeepFree=2G
MaxRetentionSec=30day

Sau đó:

sudo systemctl restart systemd-journald

10. Troubleshooting tình huống production thường gặp

Service restart liên tục

systemctl status myapp.service
journalctl -u myapp.service --since "30 minutes ago" -p warning..alert

Tìm các dấu hiệu như thiếu biến môi trường, permission denied, port conflict hoặc dependency chưa sẵn sàng.

SSH bị dò mật khẩu

journalctl -u ssh.service --since today | grep -Ei "failed password|invalid user"

Nếu số lượng lớn, cân nhắc tắt password login, bật key-based auth, Fail2ban hoặc firewall allowlist.

Máy chậm bất thường

journalctl -k --since "2 hours ago" -p warning..alert

-k xem kernel log: OOM killer, disk error, network flap thường xuất hiện ở đây.

11. Xuất log để gửi đội khác hoặc lưu bằng chứng

journalctl -u nginx.service --since "2026-05-13 14:00" --until "2026-05-13 14:30" --no-pager > nginx-incident-20260513.log
journalctl -u nginx.service -o json --since "1 hour ago" > nginx.json

Lưu ý che thông tin nhạy cảm trước khi gửi log ra ngoài: token, cookie, IP nội bộ, email khách hàng.

12. Outbound tài liệu chính thống nên đọc

13. Checklist nghiệm thu

  • Biết xem log realtime bằng journalctl -f.
  • Lọc được log theo service, thời gian, priority và boot.
  • Persistent journal đã bật trên server quan trọng.
  • Dung lượng journal có giới hạn rõ ràng.
  • Có runbook thu thập log khi incident xảy ra.
  • Log xuất ra ngoài đã được rà soát thông tin nhạy cảm.

14. Bài tập lab cuối bài

  1. Chạy một service test bị lỗi cấu hình, dùng journalctl -u tìm nguyên nhân.
  2. Restart máy lab, dùng journalctl --list-boots so sánh boot hiện tại và boot trước.
  3. Bật persistent journal và đặt SystemMaxUse.
  4. Tạo file log incident theo khoảng thời gian cụ thể.

Kết luận: quản lý log Linux bằng journald không phải chỉ là nhớ vài câu lệnh. Đây là cách sysadmin dựng timeline, tìm tín hiệu trong nhiễu và đưa ra quyết định an toàn khi hệ thống production đang có vấn đề.

Tác giả: Mạnh Hoàng

Tôi là Hoàng Mạnh, người sáng lập blog SysadminSkills.com. Tôi viết về quản trị hệ thống, bảo mật máy chủ, DevOps và cách ứng dụng AI để tự động hóa công việc IT. Blog này là nơi tôi chia sẻ những gì đã học được từ thực tế – đơn giản, ngắn gọn và áp dụng được ngay.

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *