Site icon ZingServer

Cách dùng journalctl để xem log và gỡ lỗi (Troubleshoot) VPS Linux

Team ZingServer
Cách dùng journalctl để xem log và gỡ lỗi (Troubleshoot) VPS Linux

Cách dùng journalctl để xem log và gỡ lỗi (Troubleshoot) VPS Linux

Khi VPS Linux gặp sự cố, biết cách dùng journalctl là kỹ năng quan trọng nhất giúp bạn tìm ra nguyên nhân. Dịch vụ web (Nginx/Apache) không khởi động? VPS bị treo? Hay bạn đang gặp phải tình huống không SSH được vào VPS Linux?

Thay vì đoán mò, bạn cần một công cụ chẩn đoán. journalctl chính là công cụ đó.

journalctl là “Event Viewer” (Trình xem sự kiện) của Linux. Nó thu thập và quản lý tập trung tất cả nhật ký (log) của hệ thống – từ lúc khởi động, log dịch vụ (sshd, nginx), đến các lỗi hệ thống – vào một nơi duy nhất. Nắm vững journalctl giúp bạn gỡ lỗi (troubleshoot) nhanh chóng và chính xác.

Lưu ý: journalctl giúp bạn XEM lỗi. Sau khi tìm ra nguyên nhân, bạn sẽ cần công cụ để SỬA nó (như khởi động lại dịch vụ). Hãy tham khảo bài viết Hướng dẫn systemctl: Sửa lỗi VPS bằng Start, Stop, Restart dịch vụ để biết cách thực hiện bước tiếp theo này.

Tóm tắt nhanh (Các lệnh journalctl phổ biến)

  • Làm thế nào để xem lỗi mới nhất? Dùng journalctl -xe. Tùy chọn -x cung cấp thêm giải thích lỗi.
  • Làm thế nào để theo dõi log trực tiếp (thời gian thực)? Dùng journalctl -f (tương tự tail -f).
  • Làm thế nào để chỉ xem log của một dịch vụ (ví dụ Nginx)? Dùng journalctl -u nginx.service.
  • Làm thế nào để xem log trong 10 phút qua? Dùng journalctl --since "10 minutes ago".

4 lệnh journalctl “cứu mạng” bắt buộc phải biết

Trước khi đi vào các bộ lọc phức tạp, 4 lệnh sau đây sẽ giải quyết 80% nhu cầu xem log hàng ngày của bạn. Chúng ta sẽ dùng bảng để bạn dễ tra cứu.

Lệnh Mục đích Ghi chú (Tại sao nó hữu ích)
journalctl -xe Xem lỗi nhanh nhất (Lệnh “thần kỳ”) Tùy chọn -e tự động nhảy đến cuối log. Tùy chọn -x thêm các giải thích và chi tiết cho các thông báo lỗi, giúp bạn dễ hiểu vấn đề hơn.
journalctl -f Theo dõi log thời gian thực Tương tự lệnh tail -f. Nó sẽ “treo” terminal và hiển thị các dòng log mới ngay khi chúng được tạo ra. Cực kỳ hữu ích khi gỡ lỗi trực tiếp.
journalctl -r Xem log mới nhất lên đầu Mặc định, journalctl hiển thị từ cũ đến mới. Dùng -r (reverse) sẽ đảo ngược lại, giúp bạn thấy lỗi mới nhất ngay dòng đầu tiên.
journalctl -n 50 Xem 50 dòng cuối cùng Tùy chọn -n (number) cho phép bạn xem chính xác số lượng dòng log cuối cùng mà bạn muốn. Rất nhanh để kiểm tra “vừa có chuyện gì xảy ra?”.

Cách dùng journalctl để lọc log: Tìm chính xác thứ bạn cần

Khi bạn đã biết các lệnh cơ bản, đây là lúc kết hợp chúng với các “bộ lọc” (flag) để tìm chính xác lỗi bạn đang săn lùng.

Lọc theo dịch vụ (Unit) – Quan trọng nhất

Đây là bộ lọc bạn sẽ dùng nhiều nhất. Hầu hết các sự cố VPS đều liên quan đến một dịch vụ cụ thể (như web server, SSH, database…). Tùy chọn -u (unit) cho phép bạn chỉ xem log của dịch vụ đó.

Kịch bản 1: Gỡ lỗi SSH (sshd)

Nếu bạn đang gặp lỗi “Connection Refused”, đây là bước đầu tiên để kiểm tra (sau khi đăng nhập bằng VNC/Console). Lệnh này sẽ cho bạn biết tại sao dịch vụ sshd không chạy hoặc từ chối kết nối.

journalctl -u sshd.service -n 20

Kịch bản 2: Gỡ lỗi Web Server (Nginx / Apache)

Website báo lỗi 502 Bad Gateway? Lệnh này sẽ hiển thị log của Nginx, thường chứa lý do (ví dụ: không kết nối được với PHP-FPM).

# Đối với Nginx
journalctl -u nginx.service

# Đối với Apache (trên Ubuntu/Debian)
journalctl -u apache2.service

# Đối với Apache (trên CentOS/RHEL)
journalctl -u httpd.service

Mẹo chuyên sâu: Nếu bạn xác định lỗi do PHP-FPM (như thiếu worker), việc xem log là chưa đủ. Hãy xem bài viết Sửa lỗi 502 Nginx trên VPS: Tối ưu config PHP-FPM & debug chuyên sâu để biết cách tính toán lại RAM và số lượng worker phù hợp.

Lọc theo thời gian (Time)

VPS của bạn gặp sự cố lúc 3 giờ chiều? Đừng đọc log cả ngày. Sử dụng cờ --since (từ) và --until (đến) để khoanh vùng chính xác thời điểm xảy ra lỗi.

journalctl hiểu các mốc thời gian rất “con người”:

Ví dụ thực tế:

# Xem tất cả log trong 1 giờ qua
journalctl --since "1 hour ago"

# Xem log lỗi của Nginx từ hôm qua đến giờ
journalctl -u nginx.service --since yesterday

Lọc theo mức độ nghiêm trọng (Priority)

Log của bạn đầy ắp các tin “info” (thông tin) vô hại. Để gỡ lỗi, bạn chỉ muốn xem lỗi (error). Tùy chọn -p (priority) cho phép bạn lọc theo mức độ nghiêm trọng. Bạn chỉ cần nhớ mức “err” (lỗi).

# Chỉ xem các LỖI trong hệ thống từ hôm qua đến giờ
journalctl -p err --since yesterday

Lệnh này cực kỳ mạnh mẽ, nó giúp bạn ngay lập tức bỏ qua 99% thông tin “rác” và tập trung vào vấn đề thực sự.

Lọc theo kernel (Tương tự dmesg)

Khi VPS gặp lỗi phần cứng, driver, hoặc các lỗi sâu liên quan đến khởi động, log kernel là thứ đầu tiên cần xem. Tùy chọn -k (kernel) chính là lệnh dmesg “phiên bản mới”.

# Xem toàn bộ log kernel
journalctl -k

Lọc theo từ khóa (Grep tích hợp)

Nhiều người có thói quen dùng journalctl | grep "lỗi". Đây là cách làm sai, vì nó sẽ lọc và làm mất context của log.

journalctl cung cấp cờ -g (grep) tích hợp để lọc đúng đắn. Nó sẽ tìm các dòng có chứa từ khóa của bạn và hiển thị toàn bộ mục log liên quan.

# Tìm mọi log hệ thống có chứa "failed password"
journalctl -g "failed password"

# Kết hợp: Tìm "failed password" CHỈ trong log SSH
journalctl -u sshd.service -g "failed password"

Lọc theo lần khởi động (Boot)

Đây là một “pro-tip” cực kỳ hữu ích. VPS của bạn tự nhiên bị reboot và bạn không biết tại sao? journalctl ghi lại log của tất cả các lần khởi động.

Kịch bản gỡ lỗi “Treo server”:

Bạn đăng nhập vào VPS và nghi ngờ nó vừa tự khởi động lại (ví dụ do lỗi VPS Linux CPU 100%).

# 1. Xem log của lần khởi động TRƯỚC ĐÓ
journalctl -b -1

# 2. Lọc ngay ra các lỗi kernel của lần khởi động trước
journalctl -k -b -1 -p err

Lệnh này sẽ cho bạn thấy chính xác các lỗi hệ thống (ví dụ: hết RAM, lỗi kernel…) đã xảy ra ngay trước khi VPS bị sập ở lần trước.

Kết hợp bộ lọc: Gỡ rối như chuyên gia (Các kịch bản thực tế)

Sức mạnh thực sự của journalctl nằm ở việc kết hợp các bộ lọc. Đây là các kịch bản thực tế bạn sẽ gặp trên VPS của mình.

Kịch bản 1: “Kiểm tra lỗi SSH trong 1 giờ qua.”

Thay vì xem mọi log của SSH, bạn chỉ muốn biết nó có báo lỗi (error) nào trong 1 giờ gần đây không.

journalctl -u sshd.service --since "1 hour ago" -p err

Kịch bản 2: “Theo dõi lỗi Nginx và PHP-FPM cùng lúc.”

Đây là kịch bản “kinh điển” khi gỡ lỗi 502 Bad Gateway. Lỗi có thể ở Nginx hoặc PHP-FPM. Bạn cần xem log của cả hai cùng lúc. journalctl cho phép bạn theo dõi nhiều dịch vụ!

journalctl -f -u nginx.service -u php-fpm.service

Kịch bản 3: “Kiểm tra xem SELinux có đang chặn gì không?”

Bạn đã làm mọi thứ nhưng dịch vụ vẫn không chạy? Rất có thể là do SELinux (trên CentOS, AlmaLinux, RHEL). Các lỗi SELinux thường được ghi lại với mức độ lỗi (error).

journalctl -p err --since "10 minutes ago"

Hãy chạy lệnh này và tìm các dòng chữ avc: denied trong kết quả. Nếu bạn thấy avc: denied, 100% đây là lỗi SELinux.

Khi đã xác định lỗi avc: denied, bạn cần “sống chung” với nó chứ không nên tắt đi. Hãy xem bài viết chi tiết của chúng tôi: SELinux là gì? Cách sửa lỗi SSH, Web Server (mà không cần ‘setenforce 0’) để biết cách sửa tận gốc.

Quản lý dung lượng log (Tránh đầy ổ đĩa VPS)

Một điều quan trọng khi dùng VPS là dung lượng ổ đĩa. Mặc định, journalctl có thể lưu trữ log chiếm tới vài GB dung lượng quý giá của bạn trong thư mục /var/log/journal.

Bạn cần dọn dẹp (vacuum) log định kỳ để tránh các lỗi “hết dung lượng” không đáng có.

Lưu ý: Các lệnh này cần quyền sudo để chạy.

Bước 1: Kiểm tra dung lượng log hiện tại

Trước khi dọn, hãy xem nó đang chiếm bao nhiêu dung lượng.

journalctl --disk-usage

Bạn sẽ thấy một kết quả tương tự: Archived and active journals take up 1.2G on disk.

Bước 2: Dọn dẹp log (Chọn 1 trong 2 cách)

Bạn có hai cách dọn dẹp: theo dung lượng (size) hoặc theo thời gian (time).

Cách 1: Giữ lại 100MB log mới nhất (Phổ biến)

Lệnh này sẽ xóa tất cả log cũ và chỉ giữ lại 100MB log mới nhất.

sudo journalctl --vacuum-size=100M

Cách 2: Giữ lại log trong 2 tuần gần nhất

Lệnh này sẽ xóa tất cả log cũ hơn 2 tuần.

sudo journalctl --vacuum-time=2weeks

Đây là một thao tác bảo trì VPS rất quan trọng mà bạn nên thực hiện định kỳ để tránh các lỗi “hết dung lượng” không đáng có.

Mẹo hay: Xem log không bị “bọc” (wrap) và tự động thoát

Bạn có thể thấy rằng khi journalctl hiển thị, nó dùng trình xem less. Có hai điều gây khó chịu:

  1. Các dòng log quá dài có thể bị “bọc” (wrap) xuống dòng, làm vỡ cấu trúc log, rất khó đọc.
  2. Nếu nội dung log ngắn (chỉ vài dòng), bạn vẫn phải gõ q để thoát.

Biến môi trường SYSTEMD_LESS=FRSMK là một “pro-tip” phổ biến để khắc phục điều này.

Giải thích các cờ:

Làm thế nào để xem phần log bị cắt?

Khi cờ S được bật, dòng log sẽ bị cắt ở lề màn hình. Mẹo thật sự ở đây là:

Hãy dùng phím mũi tên Trái ⬅️ và Phải ➡️ để cuộn ngang và xem toàn bộ nội dung. Cờ S chính là thứ đảm bảo hành vi này.

Vậy nếu tôi thấy dấu ... (ba chấm)?

Nếu bạn thấy dấu ... (ba chấm) ở giữa một dòng log, đó không phải là do less. Đó là do bản thân journalctl đang rút gọn (abbreviate) các trường quá dài.

Để buộc journalctl hiển thị đầy đủ, hãy dùng cờ -l hoặc --full:

journalctl -l -xe

Cách áp dụng mẹo (Vĩnh viễn):

Để không phải gõ lệnh export mỗi lần, hãy thêm nó vào file .bashrc của bạn:

echo 'export SYSTEMD_LESS=FRSMK' >> ~/.bashrc
source ~/.bashrc

Muốn tùy chỉnh Terminal “ngầu” hơn? File .bashrc còn làm được nhiều hơn thế. Xem ngay bài viết Mẹo Terminal Pro: Tùy chỉnh .bashrc thành trợ lý đắc lực cho SysAdmin để tạo các lệnh tắt (alias) giúp bạn gõ lệnh nhanh gấp đôi.

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

1. Lỗi “journalctl: command not found” nghĩa là gì?

Lỗi này có nghĩa là hệ thống của bạn không cài đặt journalctl, hoặc nó nằm ngoài đường dẫn (PATH) của bạn.

Lý do phổ biến nhất là bạn đang sử dụng một bản phân phối (OS) Linux rất cũ (ví dụ: CentOS 6) không sửu dụng systemd. journalctl là một phần của systemd, vốn là tiêu chuẩn trên hầu hết các OS hiện đại (như Ubuntu 16.04+, CentOS 7+, Debian 8+). Nếu gặp lỗi này, có thể VPS của bạn đang dùng hệ thống log cũ hơn như rsyslog (log nằm ở /var/log/messages).

Hãy tham khảo bài viết Rsyslog: Cấu hình log tập trung VPS để hiểu cách quản lý log trên các hệ thống này.

2. Log của journalctl được lưu ở đâu? Có mất khi reboot không?

Theo mặc định, nếu thư mục /var/log/journal tồn tại, log sẽ được lưu vĩnh viễn ở đó và không bị mất khi reboot. Nếu thư mục này không tồn tại, log sẽ được lưu tạm thời tại /run/log/journal và sẽ bị mất khi reboot. Hầu hết các bản phân phối Linux hiện đại đều tự động bật lưu trữ vĩnh viễn.

3. Lệnh dmesg và journalctl -k khác gì nhau?

dmesg là lệnh truyền thống để xem thông báo của kernel. journalctl -k là cách hiện đại hơn để truy cập cùng nguồn log đó. Ưu điểm của journalctl -k là bạn có thể kết hợp nó với các bộ lọc mạnh mẽ khác, ví dụ: journalctl -k -b -1 (xem log kernel của lần reboot trước).

4. Tại sao tôi chạy journalctl mà không thấy log của Nginx?

Có hai lý do phổ biến:

  1. Gõ sai tên dịch vụ: Hãy chắc chắn bạn gõ đúng tên unit, ví dụ journalctl -u nginx.service (thay vì chỉ nginx).
  2. Không có quyền: Người dùng thường chỉ thấy log của chính họ. Để xem log của các dịch vụ hệ thống như Nginx, SSH, bạn cần sử dụng sudo, ví dụ: sudo journalctl -u nginx.service.

5. Làm thế nào để xem log Nginx và PHP-FPM cùng lúc?

Đây là một kịch bản gỡ lỗi 502 Bad Gateway rất phổ biến. Bạn có thể truyền nhiều dịch vụ (cờ -u) vào cùng một lệnh. Để xem theo thời gian thực, hãy dùng cờ -f:

journalctl -f -u nginx.service -u php-fpm.service

6. journalctl có làm chậm VPS của tôi không?

Không. Dịch vụ chạy nền (systemd-journald) được thiết kế để cực kỳ nhẹ và hiệu quả. Việc chạy lệnh journalctl (để xem log) chỉ là một thao tác đọc file và hoàn toàn không ảnh hưởng đến hiệu suất VPS của bạn.

Kết luận

journalctl không phải là một công cụ đáng sợ, nó là người bạn đồng hành đáng tin cậy nhất của bạn khi quản trị VPS Linux. Thay vì mò mẫm trong bóng tối, bạn đã có một “đèn pin” siêu sáng có thể rọi vào bất kỳ ngóc ngách nào của hệ thống.

Chỉ với 5-6 lệnh và bộ lọc chính (như journalctl -xe, journalctl -u [service] -p err, và journalctl --since "1 hour ago"), bạn đã có thể tự tin chẩn đoán và tìm ra 90% nguyên nhân gây lỗi trên VPS của mình.

Bạn đã bao giờ dùng journalctl để “cứu” VPS của mình trong một tình huống khó khăn chưa? Hay bạn đã kết hợp nó với systemctl để tự động hóa việc sửa lỗi?

Hãy chia sẻ kinh nghiệm gỡ lỗi của bạn ở phần bình luận bên dưới!

Tài liệu tham khảo

Exit mobile version