Cách Dùng journalctl Xem & Quản Lý Log systemd Linux Chi Tiết, Toàn Tập

Việc sử dụng journalctl để xem và thao tác với nhật ký systemd trên Linux là kỹ năng sống còn giúp quản trị viên gỡ rối tình trạng dịch vụ đột ngột sập nguồn hay ứng dụng báo lỗi ngầm mà không rõ nguyên nhân. Thay vì phải lục tung hàng chục file log phân mảnh truyền thống, công cụ này gom toàn bộ sự kiện hệ thống về một nơi duy nhất. Nắm vững kỹ thuật tra cứu tại ThueVPSGiaRe.vn sẽ giúp bạn vận hành hệ thống luôn mượt mà và an toàn.

Journal của systemd là gì và tại sao quan trọng?

Journal của systemd là hệ thống ghi nhật ký tập trung, do tiến trình nền journald thu thập mọi thông báo từ kernel, initrd, các dịch vụ và ứng dụng người dùng, rồi lưu ở định dạng nhị phân để truy vấn linh hoạt. Nhờ đó, bạn có thể xem, lọc và xuất nhật ký bằng một công cụ duy nhất là journalctl, thay vì lần tìm từng tệp log rải rác trên hệ thống.

Một số ưu điểm nổi bật nhất của systemd nằm ở phần ghi nhật ký tiến trình và hệ thống. Với các công cụ truyền thống, nhật ký thường bị phân tán, do nhiều daemon khác nhau xử lý và khá khó hiểu khi trải rộng trên nhiều ứng dụng. systemd khắc phục điều này bằng giải pháp quản lý tập trung dành cho tất cả các tiến trình kernel và userland, và hệ thống thu thập, quản lý các nhật ký này được gọi là journal.

• Thu thập tập trung: journald tiếp nhận dữ liệu từ tất cả các nguồn có sẵn, kể cả nhật ký khởi động ban đầu, kernel, initrd cũng như đầu ra chuẩn và lỗi chuẩn của ứng dụng.
• Hiển thị linh hoạt: quản trị viên có thể xem dữ liệu khởi động từ ba lần khởi động trước đó, hoặc xen kẽ các mục nhật ký theo trình tự thời gian từ hai dịch vụ liên quan để gỡ lỗi sự cố giao tiếp.
• Xuất nhiều định dạng: vì dữ liệu lưu dạng nhị phân chứ không phải văn bản thuần, bạn có thể xem theo kiểu syslog quen thuộc hằng ngày, hoặc xuất từng mục dưới dạng JSON để lập biểu đồ mà không cần chuyển đổi.
• Kết hợp hoặc thay thế syslog: journal của systemd đáp ứng hầu hết nhu cầu ghi nhật ký, đồng thời vẫn có thể bổ sung cho cơ chế hiện có, chẳng hạn máy chủ syslog tập trung tổng hợp dữ liệu nhiều máy chủ, kết hợp cùng journal trên từng hệ thống.

Chuẩn hóa thời gian máy chủ bằng timedatectl trước khi tra cứu log

Một trong những ưu điểm lớn của nhật ký nhị phân là hiển thị dấu thời gian (timestamp) linh hoạt theo múi giờ địa phương hoặc UTC. Để tránh nhầm lẫn khi đối chiếu thời điểm xảy ra sự cố, bạn cần đảm bảo múi giờ hệ thống đã được đồng bộ chính xác bằng công cụ timedatectl.

Trước tiên, hãy kiểm tra danh sách các múi giờ được hỗ trợ trên hệ điều hành:

timedatectl list-timezones

Khi đã xác định được khu vực phù hợp (ví dụ múi giờ Việt Nam hoặc múi giờ máy chủ quốc tế), hãy thiết lập lại bằng lệnh sau:

sudo timedatectl set-timezone Asia/Ho_Chi_Minh

Kiểm tra lại trạng thái đồng bộ thời gian và dịch vụ NTP của máy chủ:

timedatectl status

               Local time: Fri 2021-07-09 14:44:30 EDT
           Universal time: Fri 2021-07-09 18:44:30 UTC
                 RTC time: Fri 2021-07-09 18:44:31
                Time zone: America/New_York (EDT, -0400)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Dòng đầu tiên phải hiển thị đúng thời gian hiện tại của bạn.

Kết quả trả về sẽ hiển thị đầy đủ giờ địa phương (Local time), giờ quốc tế (Universal time), múi giờ hiện tại cũng như trạng thái đồng bộ xung nhịp System clock synchronized: yes. Điều này giúp các mốc thời gian lọc trong journalctl luôn chính xác từng giây.

Các thao tác đọc nhật ký cơ bản bằng lệnh journalctl

Lệnh journalctl là cánh cửa duy nhất bạn cần để tương tác với kho nhật ký của systemd. Khi chạy lệnh độc lập không kèm tham số, toàn bộ sự kiện đã ghi nhận sẽ xuất hiện trong trình điều hướng phân trang (mặc định là less), hiển thị từ sự kiện cũ nhất đến mới nhất.

journalctl

-- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
. . .

Bạn có thể phải cuộn qua hàng trang dữ liệu, thậm chí hàng chục hoặc hàng trăm nghìn dòng nếu journal đã được lưu trữ trên hệ thống trong thời gian dài. Định dạng này sẽ quen thuộc với người dùng syslog, nhưng thực tế nó thu thập từ nhiều nguồn hơn so với triển khai syslog truyền thống.

Tất cả dấu thời gian hiển thị theo giờ địa phương, và vì giờ địa phương đã được thiết lập đúng ở bước trước, mọi mục nhật ký đều có thông tin này.

Nếu muốn hiển thị dấu thời gian theo múi giờ UTC, dùng cờ --utc:

journalctl --utc

Lọc nhật ký theo thời gian và các lần khởi động

Truy cập lượng dữ liệu lớn rất hữu ích, nhưng xử lý thủ công thì gần như bất khả thi, vì thế các tùy chọn lọc là tính năng quan trọng nhất của journalctl. Nếu bạn muốn có môi trường riêng để luyện tập an toàn các lệnh bên dưới, có thể tham khảo bảng giá thuê VPS trước khi bắt tay vào thực hiện.

Hiển thị nhật ký từ phiên khởi động hiện tại

Công cụ cơ bản nhất là cờ -b, hiển thị toàn bộ mục nhật ký được thu thập kể từ lần khởi động gần nhất:

journalctl -b

Nếu hệ thống lưu nhiều hơn một lần khởi động và bạn xem toàn bộ, journalctl sẽ chèn một dòng phân cách mỗi khi máy khởi động lại, giúp bạn tách thông tin theo từng phiên:

. . .

-- Reboot --

. . .

Truy cập nhật ký từ các lần khởi động trước

Một số bản phân phối cho phép lưu thông tin khởi động trước đó theo mặc định, số khác thì tắt. Để bật lưu trữ liên tục, tạo thư mục chứa nhật ký:

sudo mkdir -p /var/log/journal

Hoặc chỉnh sửa tệp cấu hình /etc/systemd/journald.conf, trong phần [Journal] đặt Storage=persistent:

. . .
[Journal]
Storage=persistent

Khi tính năng đã bật, xem danh sách các lần khởi động mà journald biết bằng tùy chọn --list-boots:

journalctl --list-boots

-2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

Mỗi dòng tương ứng một lần khởi động: cột đầu là độ lệch (offset) dùng để tham chiếu nhanh, cột hai là ID khởi động nếu cần tham chiếu tuyệt đối, và hai giá trị thời gian ở cuối cho biết phạm vi phiên. Ví dụ, xem nhật ký từ lần khởi động trước bằng offset -1:

journalctl -b -1

Hoặc gọi lại dữ liệu bằng ID khởi động:

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

Lọc theo khoảng ngày và giờ tùy chỉnh

Khi máy chủ hoạt động liên tục với uptime dài, bạn sẽ cần xem nhật ký trong các khoảng thời gian không trùng với lần khởi động. Dùng --since và --until, với giá trị thời gian tuyệt đối theo định dạng YYYY-MM-DD HH:MM:SS. Ví dụ, xem mọi mục kể từ 17:15 ngày 10/01/2015:

journalctl --since "2015-01-10 17:15:00"

Nếu bỏ trống một số thành phần, giá trị mặc định sẽ được áp dụng: bỏ ngày thì lấy ngày hiện tại, thiếu giờ thì thay bằng “00:00:00” (nửa đêm), bỏ trường giây thì mặc định “00”:

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

journalctl cũng hiểu các giá trị tương đối như “yesterday”, “today”, “tomorrow”, “now”, hoặc dùng dấu “-” / “+” với giá trị số và từ “ago”. Lấy dữ liệu từ hôm qua:

journalctl --since yesterday

Nếu nhận thông báo gián đoạn dịch vụ bắt đầu từ 9:00 sáng và kéo dài đến một giờ trước, nhập:

journalctl --since 09:00 --until "1 hour ago"

Lọc nhật ký theo dịch vụ, PID, người dùng và mức độ ưu tiên

Ngoài ràng buộc thời gian, journal của systemd cung cấp nhiều cách lọc nhật ký dựa trên dịch vụ hoặc thành phần mà bạn quan tâm.

Xem nhật ký theo unit dịch vụ systemd

Lọc theo unit là cách hữu ích nhất, dùng tùy chọn -u. Ví dụ, xem toàn bộ nhật ký của Nginx:

journalctl -u nginx.service

Thường bạn sẽ kết hợp thêm bộ lọc thời gian, chẳng hạn kiểm tra tình trạng dịch vụ hôm nay:

journalctl -u nginx.service --since today

Kiểu tập trung này phát huy tác dụng khi xen kẽ bản ghi từ nhiều unit. Nếu Nginx kết nối với unit PHP-FPM để xử lý nội dung động, hợp nhất các mục của cả hai theo thứ tự thời gian bằng cách chỉ định cả hai:

journalctl -u nginx.service -u php-fpm.service --since today

Cách này giúp dễ phát hiện tương tác giữa các chương trình và gỡ lỗi cả hệ thống thay vì từng tiến trình riêng lẻ.

Lọc theo PID, UID hoặc GID

Nhiều dịch vụ tạo ra nhiều tiến trình con; nếu đã xác định PID cần theo dõi, lọc bằng trường _PID, ví dụ PID 8088:

journalctl _PID=8088

Để hiển thị tất cả mục nhật ký của một người dùng hoặc nhóm cụ thể, dùng bộ lọc _UID hoặc _GID. Nếu máy chủ web chạy dưới user www-data, tìm ID người dùng trước:

id -u www-data

33

Sau đó dùng ID trả về để lọc:

journalctl _UID=33 --since today

Journal có nhiều trường để lọc: một số được truyền từ tiến trình đang được ghi log, số khác do journald tự áp dụng từ thông tin thu thập được. Dấu gạch dưới phía trước (như _PID) cho biết trường thuộc loại thứ hai — journald tự ghi lại và lập chỉ mục PID để lọc sau này. Xem danh sách tất cả các trường bằng lệnh:

man systemd.journal-fields

Tùy chọn -F hiển thị tất cả giá trị có sẵn của một trường nhất định, giúp bạn xây dựng bộ lọc. Ví dụ, xem các ID nhóm mà journal có mục nhập:

journalctl -F _GID

32
99
102
133
81
84
100
0
124
87

Xem nhật ký theo đường dẫn tệp thực thi

Bạn cũng có thể lọc bằng cách cung cấp đường dẫn. Nếu đường dẫn trỏ tới tệp thực thi, journalctl hiển thị tất cả mục liên quan đến tệp đó, ví dụ với bash:

journalctl /usr/bin/bash

Thông thường, nếu tệp thực thi có unit tương ứng, lọc theo unit sẽ gọn gàng hơn và cung cấp thông tin tốt hơn (bao gồm cả các tiến trình con liên quan), nhưng đôi khi cách này không khả dụng.

Xem nhật ký kernel với journalctl -k

Các thông báo kernel, thường thấy trong đầu ra dmesg, cũng có thể truy xuất từ journal. Thêm cờ -k hoặc --dmesg:

journalctl -k

Mặc định lệnh hiển thị thông báo kernel từ lần khởi động hiện tại; bạn có thể chỉ định lần khởi động khác bằng cờ chọn khởi động đã giới thiệu, ví dụ lấy thông báo từ năm lần khởi động trước:

journalctl -k -b -5

Lọc theo mức độ nghiêm trọng với journalctl -p

Ghi nhật ký chi tiết thường hữu ích, nhưng khi xem xét, các mục ưu tiên thấp có thể gây xao nhãng. Dùng tùy chọn -p để chỉ hiển thị thông báo ở mức ưu tiên chỉ định trở lên. Ví dụ, chỉ xem mục ghi ở mức lỗi trở lên:

journalctl -p err -b

Lệnh này hiển thị mọi thông báo được đánh dấu là lỗi, chí mạng, cảnh báo hoặc khẩn cấp. Journal sử dụng các cấp độ thông báo syslog tiêu chuẩn, bạn có thể dùng tên hoặc giá trị số tương ứng, từ ưu tiên cao nhất đến thấp nhất:

Giá trị	Tên mức độ
0	khẩn cấp (emergency)
1	cảnh báo nghiêm trọng (alert)
2	chí mạng (critical)
3	lỗi (error)
4	cảnh báo (warning)
5	thông báo (notice)
6	thông tin (info)
7	gỡ lỗi (debug)

Số hoặc tên có thể dùng thay thế cho nhau với tùy chọn -p; khi chọn một mức, các thông báo ở mức đó và tất cả mức cao hơn sẽ được hiển thị.

Tùy chỉnh hiển thị đầu ra nhật ký

Ngoài việc chọn mục nhập bằng bộ lọc, journalctl còn cho phép điều chỉnh cách hiển thị dữ liệu để phù hợp nhiều nhu cầu khác nhau.

Kiểm soát độ dài và ký tự hiển thị

Theo mặc định, toàn bộ mục nhập được hiển thị trong trình xem trang, cho phép nội dung tràn sang bên phải và bạn dùng phím mũi tên phải để xem phần bị ẩn. Nếu muốn rút gọn đầu ra, chèn dấu ba chấm vào chỗ thông tin đã bị cắt, dùng tùy chọn --no-full:

journalctl --no-full

. . .
Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

Ngược lại, nếu muốn hiển thị toàn bộ thông tin kể cả ký tự không thể in được, dùng cờ -a:

journalctl -a

Tắt trình phân trang

Nếu dự định xử lý dữ liệu bằng các công cụ thao tác văn bản, bạn sẽ muốn xuất kết quả ra đầu ra chuẩn thay vì hiển thị trong trình xem trang. Dùng tùy chọn --no-pager:

journalctl --no-pager

Dữ liệu sau đó có thể được chuyển thẳng vào tiện ích xử lý hoặc ghi vào tệp trên ổ đĩa tùy nhu cầu.

Xuất nhật ký ở các định dạng khác nhau

Khi phân tích dữ liệu nhật ký, định dạng dễ sử dụng sẽ thuận lợi hơn nhiều. Dùng tùy chọn -o kèm bộ chỉ định định dạng, ví dụ xuất mục nhật ký dưới dạng JSON:

journalctl -b -u nginx -o json

{ "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

Định dạng này hữu ích cho việc phân tích bằng các tiện ích. Nếu muốn hiểu cấu trúc dữ liệu trước khi chuyển cho trình tiêu thụ JSON, dùng json-pretty:

journalctl -b -u nginx -o json-pretty

Việc xử lý khối lượng JSON lớn đòi hỏi hiệu năng đọc ghi ổn định, nên nếu thường xuyên phân tích log theo cách này, một máy chủ VPS sử dụng SSD NVMe sẽ giúp trải nghiệm mượt hơn đáng kể. Các định dạng có thể sử dụng bao gồm:

Định dạng	Mô tả
cat	Chỉ hiển thị chính trường thông điệp.
export	Định dạng nhị phân thích hợp để truyền tải hoặc sao lưu.
json	JSON chuẩn, mỗi dòng chứa một mục dữ liệu.
json-pretty	JSON dễ đọc hơn đối với con người.
json-sse	JSON đóng gói tương thích với sự kiện được gửi từ máy chủ (server-sent events).
short	Kiểu xuất syslog mặc định.
short-iso	Kiểu mặc định bổ sung dấu thời gian ISO 8601.
short-monotonic	Kiểu mặc định với dấu thời gian đơn điệu.
short-precise	Kiểu mặc định với độ chính xác đến micro giây.
verbose	Hiển thị mọi trường nhật ký có sẵn, kể cả những trường thường bị ẩn.

Theo dõi nhật ký systemd theo thời gian thực

Journalctl mô phỏng cách nhiều quản trị viên dùng lệnh tail để giám sát hoạt động hiện tại hoặc gần đây, và chức năng này được tích hợp sẵn nên bạn không cần chuyển tiếp dữ liệu sang công cụ khác.

Để hiển thị một số lượng bản ghi nhất định, dùng tùy chọn -n, hoạt động giống hệt tail -n. Mặc định nó hiển thị 10 mục gần đây nhất:

journalctl -n

Chỉ định số lượng mục muốn xem bằng cách nhập số ngay sau tùy chọn:

journalctl -n 20

Để chủ động theo dõi nhật ký khi chúng đang được ghi, dùng cờ -f, hành xử giống như tail -f:

journalctl -f

Để thoát khỏi chế độ theo dõi, nhấn CTRL+C.

Quản lý và dọn dẹp dung lượng nhật ký

Sau khi lưu trữ nhật ký liên tục, bạn cần quan tâm đến chi phí dung lượng cũng như cách dọn dẹp nhật ký cũ để giải phóng không gian. Đây là bước đặc biệt quan trọng khi chạy trên gói VPS có dung lượng ổ đĩa hạn chế, vì journal phình to có thể chiếm mất không gian dành cho ứng dụng.

Kiểm tra dung lượng ổ đĩa mà journal chiếm dụng

Dùng cờ --disk-usage:

journalctl --disk-usage

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

Xóa nhật ký cũ bằng –vacuum-size và –vacuum-time

Có hai cách thu nhỏ journal (khả dụng từ systemd phiên bản 218 trở lên). Với --vacuum-size, hệ thống xóa các mục cũ cho đến khi tổng dung lượng chiếm dụng đạt đến kích thước yêu cầu:

sudo journalctl --vacuum-size=1G

Cách còn lại là thiết lập thời gian giới hạn bằng --vacuum-time; mọi mục cũ hơn thời điểm đó sẽ bị xóa. Ví dụ, chỉ giữ lại các mục từ năm qua:

sudo journalctl --vacuum-time=1years

Cấu hình giới hạn dung lượng cho journald

Bạn có thể đặt giới hạn dung lượng mà journal được phép chiếm dụng bằng cách chỉnh sửa tệp /etc/systemd/journald.conf. Các chỉ thị sau giúp kiểm soát sự tăng trưởng của journal:

Chỉ thị	Ý nghĩa
SystemMaxUse=	Dung lượng đĩa tối đa mà journal có thể dùng trong bộ nhớ lưu trữ lâu dài.
SystemKeepFree=	Dung lượng trống mà journal cần để lại khi thêm mục nhật ký vào bộ nhớ lâu dài.
SystemMaxFileSize=	Kích thước tối đa của từng tệp nhật ký trong bộ nhớ lâu dài trước khi xoay vòng.
RuntimeMaxUse=	Dung lượng tối đa trong bộ nhớ tạm thời (hệ thống tệp /run).
RuntimeKeepFree=	Dung lượng được dành riêng cho mục đích khác khi ghi vào bộ nhớ khả biến (/run).
RuntimeMaxFileSize=	Dung lượng mà một tệp nhật ký riêng lẻ có thể chiếm trong bộ nhớ khả biến (/run) trước khi xoay vòng.

Bằng cách thiết lập các giá trị này, bạn kiểm soát được cách journald tiêu thụ và bảo tồn dung lượng trên máy chủ. Lưu ý rằng SystemMaxFileSize và RuntimeMaxFileSize nhắm mục tiêu vào các tệp đã lưu trữ để đạt giới hạn, điều này quan trọng khi diễn giải số lượng tệp sau khi thực hiện dọn dẹp.

Khắc phục sự cố thường gặp với journalctl

1. Journalctl không hiển thị nhật ký?

Đôi khi bạn chạy journalctl nhưng chỉ nhận màn hình trống hoặc kết quả vô dụng, tình huống dễ gây bối rối khi đang khắc phục sự cố. Có một số nguyên nhân phổ biến:

Cơ sở dữ liệu journal trống hoặc thiếu thông tin. Điều này xảy ra trên hệ thống mới cài, môi trường container tối thiểu, hoặc khi hệ thống được cấu hình chỉ lưu nhật ký trong bộ nhớ khả biến (bị xóa khi khởi động lại). Kiểm tra xem ghi nhật ký liên tục có bật hay không bằng cách tìm thư mục journal:

ls /var/log/journal

Nếu thư mục không tồn tại hoặc trống, nhật ký của bạn không được lưu giữa các lần khởi động. Khắc phục bằng cách tạo thư mục và khởi động lại dịch vụ journald:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Dịch vụ ghi nhật ký không hoạt động. Nếu systemd-journald — dịch vụ chịu trách nhiệm thu thập và quản lý dữ liệu nhật ký — gặp lỗi hoặc không khởi động được, nhật ký sẽ trống rỗng. Kiểm tra trạng thái bằng lệnh:

systemctl status systemd-journald

Bộ lọc quá hẹp. Vấn đề có thể nằm ở cách bạn truy cập chứ không phải tệp nhật ký: tên unit không tồn tại hoặc phạm vi thời gian quá cụ thể đều có thể trả về kết quả rỗng. Nên chạy journalctl không kèm cờ nào để xác nhận nhật ký đang được thu thập, sau đó dần dần áp dụng bộ lọc.

Nhật ký đã bị xoay vòng hoặc xóa. Journal tuân theo chính sách lưu giữ dựa trên kích thước và thời gian; nếu nhật ký cũ đã bị công cụ dọn dẹp của systemd-journald xóa, chúng không còn truy cập được nữa. Kiểm tra dung lượng hiện tại bằng journalctl --disk-usage — nếu bạn cấu hình giới hạn kích thước nghiêm ngặt hoặc mới chạy lệnh vacuum thủ công, nhật ký có thể đã bị xóa khỏi cơ sở dữ liệu.

2. Quyền truy cập bị từ chối khi sử dụng journalctl

Theo mặc định, quyền truy cập nhật ký hệ thống bị hạn chế cho người dùng root và các thành viên nhóm systemd-journal, nhằm bảo vệ dữ liệu nhạy cảm về hoạt động người dùng, tiến trình hệ thống và lỗi dịch vụ.

Chạy với đặc quyền cao hơn. Giải pháp đơn giản nhất là thêm sudo trước lệnh để nâng quyền trong suốt lần thực thi:

sudo journalctl

Cấp quyền vĩnh viễn qua nhóm. Nếu thường xuyên kiểm tra nhật ký, việc gõ sudo mỗi lần có thể bất tiện; hãy thêm người dùng vào nhóm systemd-journal:

sudo usermod -aG systemd-journal yourusername

Nhớ thay yourusername bằng tên đăng nhập thực tế, sau đó đăng xuất và đăng nhập lại để thay đổi có hiệu lực. Từ đó bạn có thể chạy journalctl mà không cần quyền quản trị.

Xác minh quyền truy cập. Nếu vẫn bị từ chối, kiểm tra quyền tệp/thư mục: thư mục /var/log/journal phải thuộc sở hữu của root và nhóm systemd-journal, với quyền đọc của nhóm được thiết lập đúng:

sudo chown root:systemd-journal /var/log/journal
sudo chmod 2755 /var/log/journal

3. Nhật ký không được lưu giữ sau khi khởi động lại

Nếu nhật ký biến mất mỗi khi máy khởi động lại, rất có thể hệ thống được cấu hình chỉ lưu nhật ký trong bộ nhớ khả biến — cấu hình mặc định phổ biến trong nhiều bản phân phối Linux và môi trường container được tối ưu dung lượng. Để giữ lại nhật ký, cấu hình journald dùng bộ nhớ lâu dài bằng cách tạo thư mục thích hợp và khởi động lại trình nền ghi nhật ký:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Nếu thư mục tồn tại mà nhật ký vẫn không được lưu, kiểm tra tệp cấu hình /etc/systemd/journald.conf, tìm chỉ thị Storage= trong phần [Journal]; nếu đang là volatile, đổi thành persistent, lưu tệp và khởi động lại dịch vụ:

[Journal]
Storage=persistent

4. Gỡ lỗi dịch vụ systemd bị lỗi

Khi một dịch vụ do systemd quản lý không khởi động được hoặc lỗi đột ngột, journalctl trở nên thiết yếu để tìm nguyên nhân gốc rễ: thay vì lục lọi nhiều tệp, journal tổng hợp mọi thông báo liên quan ở một nơi, kèm siêu dữ liệu, dấu thời gian và mức độ ưu tiên.

Xem xét trạng thái dịch vụ trước tiên bằng lệnh systemctl status, vốn cung cấp ảnh chụp nhanh trạng thái hiện tại cùng các mục nhật ký gần nhất:

systemctl status nginx.service

Đầu ra thường chỉ ra ngay vấn đề như đường dẫn cấu hình sai, sự cố quyền truy cập hoặc mã lỗi thoát — thông tin mã thoát và tín hiệu đặc biệt hữu ích để xác định dịch vụ tự lỗi hay bị hệ thống tắt.

Xem toàn bộ lịch sử nhật ký của dịch vụ bằng cờ -u:

journalctl -u nginx.service

Nếu chẩn đoán lỗi xảy ra trong lần khởi động gần nhất, giới hạn đầu ra chỉ trong phiên đó:

journalctl -u nginx.service -b

Điều tra bối cảnh lỗi bằng cách đọc các mục nhật ký từ vài phút trước và sau khi sự cố xảy ra, dùng bộ lọc thời gian để thu hẹp phạm vi:

journalctl -u nginx.service --since "10 minutes ago"

Để phân tích sâu hơn, bật chế độ hiển thị chi tiết hoặc xem thông báo lỗi mở rộng bằng lệnh sau — nó làm nổi bật các thông báo ưu tiên và lỗi gần đây, hữu ích khi dịch vụ không để lại dấu hiệu rõ ràng trong đầu ra chuẩn:

journalctl -xe

5. Giám sát các lần đăng nhập SSH

SSH là phương thức truy cập chính của hầu hết máy chủ Linux, và cũng vì thế trở thành kênh tấn công vét cạn mật khẩu phổ biến. Khi vận hành dịch vụ VPS của Fast Byte hoặc bất kỳ máy chủ nào, việc giám sát hoạt động SSH bằng journalctl là bước bảo mật cơ bản bạn nên duy trì.

Xem nhật ký SSH: systemd theo dõi hoạt động SSH trong unit ssh hoặc sshd tùy bản phân phối:

journalctl -u ssh.service

hoặc trên một số hệ thống:

journalctl -u sshd.service

Các nhật ký này bao gồm lần đăng nhập, lỗi xác thực, đóng phiên và thông báo đàm phán khóa — bước đầu tiên tuyệt vời để xác minh ai đã truy cập máy chủ và vào thời điểm nào.

Theo dõi thời gian thực khi nghi ngờ xâm nhập hoặc muốn theo dõi đăng nhập đang diễn ra:

journalctl -f -u ssh.service

Mỗi sự kiện đăng nhập mới sẽ được in ra ngay khi diễn ra, giúp phát hiện đăng nhập thất bại hoặc các nỗ lực kết nối dồn dập có dấu hiệu độc hại.

Lọc theo sự kiện đăng nhập cụ thể như mật khẩu không chính xác hoặc kết nối được chấp nhận, bằng cách kết hợp grep:

journalctl -u ssh.service | grep "Failed password"
journalctl -u ssh.service | grep "Accepted password"

Kết hợp thêm bộ lọc thời gian để thu hẹp vào một khoảng cụ thể, cực kỳ hữu ích trong kiểm tra an ninh hoặc điều tra pháp y:

journalctl -u ssh.service --since "1 hour ago"

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

1. Tại sao journalctl cần quyền truy cập root?

Theo mặc định, journalctl yêu cầu quyền root vì nó có thể làm lộ thông tin nhạy cảm thu thập từ dịch vụ hệ thống, thông báo kernel, phiên người dùng và tiến trình nền — bao gồm tên người dùng, biến môi trường, dấu vết lỗi và các lần xác thực.

Người dùng không phải root vẫn có thể đọc nhật ký nếu thuộc nhóm systemd-journal; thêm người dùng bằng lệnh sudo usermod -aG systemd-journal yourusername, sau đó đăng xuất và đăng nhập lại, miễn là quyền truy cập thư mục nhật ký được cấu hình đúng.

2. Làm thế nào để lưu nhật ký hệ thống sau khi khởi động lại máy?

Cần cấu hình systemd-journald dùng bộ nhớ lưu trữ lâu dài thay vì bộ nhớ khả biến (một số bản phân phối mặc định lưu trong /run/log/journal — thư mục tạm bị xóa khi tắt máy). Thực hiện theo bốn bước:

sudo mkdir -p /var/log/journal
sudo systemd-tmpfiles --create --prefix /var/log/journal
sudo systemctl restart systemd-journald

Tùy chọn, mở /etc/systemd/journald.conf và đảm bảo dòng Storage=persistent được thiết lập. Cấu hình này giúp hệ thống giữ lại dữ liệu nhật ký sau khởi động lại, thuận tiện cho việc kiểm tra và gỡ lỗi sự cố trước đó.

3. Tôi có thể xóa nhật ký journalctl không?

Có, bạn xóa hoặc thu nhỏ nhật ký bằng các tùy chọn --vacuum-* do systemd-journald cung cấp:

sudo journalctl --vacuum-time=2weeks
sudo journalctl --vacuum-size=500M
sudo journalctl --vacuum-files=10

Các lệnh này không xóa nhật ký hiện tại hoặc gần đây trừ khi chúng vượt ngưỡng đã định. Để xóa hoàn toàn, có thể xóa thủ công các tệp trong /var/log/journal, nhưng cách này hiếm khi cần và thường không được khuyến nghị cho hệ thống sản xuất.

4. Làm thế nào để truy cập nhật ký systemd?

Dùng lệnh journalctl — công cụ giao tiếp trực tiếp với journal của systemd, nơi lưu mọi nhật ký liên quan đến dịch vụ do systemd quản lý như thông báo khởi động, lỗi unit và lỗi thời gian chạy.

Xem nhật ký một dịch vụ cụ thể, ví dụ Nginx, bằng journalctl -u nginx.service; có thể kết hợp bộ lọc phiên khởi động, mức độ ưu tiên, phạm vi thời gian hoặc nhiều dịch vụ. Không giống tệp nhật ký truyền thống, journalctl cung cấp cái nhìn thống nhất, được lập chỉ mục từ nhiều nguồn.

5. Lệnh nào được sử dụng để xem nhật ký systemd?

Lệnh chính là journalctl, tích hợp sẵn trong systemd và truy cập toàn bộ nhật ký do systemd-journald thu thập: thông báo kernel, nhật ký khởi động sớm, dịch vụ hệ thống và phiên người dùng.

Một số cách dùng phổ biến: journalctl -u ssh.service (theo dịch vụ), journalctl -p err (theo mức độ ưu tiên), journalctl -f (thời gian thực) — khiến journalctl trở thành công cụ đa năng và toàn diện nhất để xem nhật ký liên quan đến systemd.

6. Làm thế nào để xem nhật ký kernel thông qua journalctl?

Dùng cờ -k để lọc đầu ra chỉ gồm thông báo xuất phát từ nhân hệ điều hành:

journalctl -k

Lệnh này đặc biệt hữu ích để chẩn đoán sự cố phần cứng, vấn đề mô-đun nhân hoặc lỗi khởi động. Kết hợp -b để xem thông báo từ lần khởi động trước:

journalctl -k -b -1

Nhờ đó bạn truy cập nhất quán vào nhật ký nhân, tích hợp với nhật ký từ các dịch vụ khác để hiểu rõ ngữ cảnh.

7. Sự khác biệt giữa dmesg và journalctl là gì?

Cả hai đều hiển thị nhật ký nhân hệ điều hành nhưng phục vụ mục đích khác nhau và hoạt động theo cơ chế khác nhau:

Tiêu chí	dmesg	journalctl
Phạm vi	Chỉ bộ đệm vòng của nhân (kernel ring buffer)	Nhật ký nhân kết hợp toàn bộ nhật ký hệ thống
Nguồn dữ liệu	Chỉ thông báo kernel	Kernel, dịch vụ, initrd, phiên người dùng
Lọc và tra cứu	Hạn chế, chủ yếu xem tuần tự	Lọc theo thời gian, unit, PID, mức ưu tiên, lần khởi động
Sau khi khởi động lại	Bộ đệm bị ghi đè theo thời gian	Giữ được nhật ký các lần khởi động trước nếu bật lưu trữ liên tục

Nội dung bài viết chỉ mang tính chất tham khảo kỹ thuật. Các lệnh, tùy chọn và cấu hình liên quan đến journalctl, systemd-journald có thể thay đổi tùy theo bản phân phối Linux, phiên bản systemd và môi trường triển khai thực tế. Trước khi áp dụng bất kỳ lệnh xóa nhật ký (vacuum) hay chỉnh sửa cấu hình nào cho hệ thống sản xuất, bạn nên kiểm thử trên môi trường thử nghiệm, sao lưu dữ liệu quan trọng và tự đánh giá rủi ro liên quan.