Log hệ thống và cách đọc lỗi: lab journalctl, auth log, kernel log và quy trình điều tra sự cố

Log hệ thống và cách đọc lỗi là kỹ năng phân biệt người chỉ biết chạy lệnh với người thật sự biết điều tra sự cố. Nhiều anh em mới nhìn log thấy rất nhiều dòng nên hoảng, nhưng nếu biết cách lọc theo thời gian, service, mức độ ưu tiên và sự kiện gần nhất, anh sẽ tìm ra vấn đề nhanh hơn rất nhiều.

Bài này tập trung vào cách đọc log có hệ thống: tạo timeline, lọc log, nhận diện lỗi thật và tránh bị nhiễu bởi các dòng không liên quan.

1. Nguyên tắc đọc log khi có sự cố

xác định mốc thời gian lỗi xảy ra
xác định service hoặc thành phần liên quan
lọc log theo service và thời gian trước, trong, sau sự cố
ưu tiên warning/error/critical
đối chiếu với thay đổi gần nhất

2. Các nguồn log quan trọng

journalctl cho service systemd
/var/log/auth.log hoặc /var/log/secure cho xác thực
kernel log cho OOM, I/O error, network driver
log ứng dụng riêng như Nginx, PHP, database

3. Các lệnh nền tảng

journalctl -n 50 --no-pager
journalctl -p err -b --no-pager
journalctl -u nginx --since "30 minutes ago" --no-pager
journalctl -k -p warning --since today --no-pager
grep -i error /var/log/auth.log | tail -20

4. Tạo timeline sự cố

Ví dụ người dùng báo lỗi lúc 14:20. Anh nên xem log từ 14:10 đến 14:30 thay vì đọc cả ngày:

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

Khi đã xác định service nghi ngờ, thu hẹp tiếp phạm vi bằng -u service.

5. Phân biệt triệu chứng và nguyên nhân

Ví dụ website trả 502. Access log có thể chỉ cho thấy triệu chứng. Log quan trọng hơn có thể nằm ở PHP-FPM bị OOM, ứng dụng crash, hoặc disk đầy làm socket không ghi được. Vì vậy phải đọc log theo chuỗi nhân quả, không chỉ một file.

6. Lab step-by-step

Cài hoặc dùng service sẵn có như Nginx.
Xem log gần nhất bằng journalctl -n 50.
Dừng service rồi xem log trong 5 phút gần nhất.
Cố tình nhập sai mật khẩu SSH vài lần từ máy khác và đọc auth.log.
Xem kernel warning bằng journalctl -k.
Viết lại timeline 3-5 mốc thời gian của bài lab.

7. Mẫu grep và lọc log hữu ích

grep -iE "error|fail|denied|timeout" /var/log/syslog | tail -50
journalctl -u ssh --since today | grep -i "failed password"

Đừng grep vô tội vạ rồi kết luận quá sớm. Hãy luôn giữ ngữ cảnh service và thời gian.

8. Lỗi thường gặp khi đọc log

đọc quá rộng nên bị nhiễu
chỉ nhìn một dòng lỗi mà bỏ qua các dòng ngay trước đó
không kiểm tra kernel log
không đối chiếu với thay đổi mới deploy hoặc update

9. Tài liệu chính thống

10. Checklist điều tra lỗi

đã xác định mốc thời gian lỗi
đã lọc theo service liên quan
đã xem warning/error và kernel log
đã đối chiếu thay đổi gần nhất
đã ghi lại timeline để chia sẻ cho team

11. Phân biệt các loại log để khỏi đọc sai chỗ

Access log: ghi request đi qua hệ thống, tốt để thấy triệu chứng.
Error log: ghi lỗi ứng dụng hoặc web server, tốt để thấy biểu hiện kỹ thuật.
System log / journal: cho cái nhìn mức hệ điều hành và service systemd.
Kernel log: quan trọng khi có OOM, I/O error, network driver hoặc lỗi mức thấp.

Nhiều sự cố không thể giải bằng một loại log duy nhất; anh cần ghép nhiều nguồn lại thành chuỗi sự kiện.

12. Ví dụ 1: Nginx trả 502 Bad Gateway

Đây là một case rất điển hình:

tail -50 /var/log/nginx/error.log
journalctl -u nginx -n 50 --no-pager
journalctl -u php8.2-fpm -n 50 --no-pager

Nếu access log chỉ cho thấy nhiều dòng 502, nguyên nhân thật có thể nằm ở PHP-FPM bị chết, socket không tồn tại, process worker treo hoặc hết RAM. Bài học ở đây là: access log cho anh biết điều gì đang xảy ra với người dùng, còn error log/journal mới giúp lần ra vì sao.

13. Ví dụ 2: nhiều lần SSH fail trong auth log

grep -i "Failed password" /var/log/auth.log | tail -20
journalctl -u ssh --since "1 hour ago" --no-pager

Nếu thấy rất nhiều lần thử sai từ cùng một IP, đó có thể là brute-force. Lúc này log không chỉ để chữa lỗi mà còn để nhận diện rủi ro bảo mật.

14. Ví dụ 3: ứng dụng chậm do OOM hoặc disk

journalctl -k -p warning --since "2 hours ago" --no-pager
df -h

Nếu kernel log có dấu hiệu OOM killer hoặc filesystem đầy, log ứng dụng phía trên chỉ là phần ngọn. Luôn nhớ kiểm tra cả log hệ điều hành khi triệu chứng ở tầng ứng dụng có vẻ vô lý.

15. Runbook đọc log khi có incident

chốt mốc thời gian người dùng báo lỗi
xác định service hoặc thành phần liên quan
xem log 10–15 phút trước và sau sự cố
lọc warning/error trước, rồi mở rộng ra dòng ngay trước đó
đối chiếu với deploy, restart, update, cron hoặc thay đổi cấu hình gần nhất
ghi lại timeline ngắn: 14:12 deploy, 14:15 error tăng, 14:17 service restart fail…

16. Mẫu suy luận từ log thay vì chỉ grep

Khi gặp log, anh nên tự hỏi theo chuỗi:

dòng này là triệu chứng hay nguyên nhân?
nó xuất hiện lần đầu từ khi nào?
trước đó có thay đổi gì trong hệ thống?
có log nào ở tầng thấp hơn xác nhận nghi ngờ này không?

Đó là lúc kỹ năng đọc log chuyển từ “tìm chữ error” sang “điều tra sự cố”.

Kết luận: thành thạo Log hệ thống và cách đọc lỗi sẽ giúp anh điều tra sự cố có cấu trúc, giảm thời gian downtime và giao tiếp rõ ràng hơn với đội dev hoặc hạ tầng.