journalctl
là công cụ dòng lệnh mặc định trong hệ thống Linux sử dụng systemd, cho phép truy xuất và quản lý nhật ký hệ thống một cách chi tiết. Việc sử dụng journalctl
giúp bạn dễ dàng theo dõi trạng thái dịch vụ, phát hiện lỗi và xử lý sự cố hệ thống nhanh chóng. Trong bài viết này, mình sẽ hướng dẫn bạn cách dùng journalctl
Linux từ cơ bản đến nâng cao để khai thác hiệu quả toàn bộ khả năng của công cụ này.
Những điểm chính
- Tổng quan về
journalctl
và System Logs: Hiểu rõ vai trò củajournalctl
trong hệ thống Linux sử dụng systemd và cách nó hỗ trợ ghi nhận toàn bộ hoạt động hệ thống. - Vai trò của journalctl Linux trong việc xem và thao tác Systemd Logs: Biết được vì sao
journalctl
là công cụ mạnh mẽ, không thể thiếu trong việc quản trị và giám sát log hệ thống. - Thiết lập thời gian hệ thống: Nắm được cách cấu hình thời gian chính xác, đảm bảo log phản ánh đúng trình tự và thời điểm xảy ra sự kiện.
- Cách xem log cơ bản: Thành thạo các lệnh cơ bản để truy xuất nhật ký hệ thống nhanh chóng và hiệu quả.
- Lọc nhật ký theo thời gian: Biết cách truy vấn log theo từng mốc thời gian cụ thể để dễ dàng phân tích sự cố.
- Lọc theo sở thích tin nhắn: Làm chủ các bộ lọc nâng cao giúp tìm kiếm thông tin theo mức độ ưu tiên, unit hoặc PID.
- Sửa đổi hiển thị nhật ký: Tùy chỉnh cách trình bày log để phù hợp với nhu cầu theo dõi hoặc xuất báo cáo.
- Giám sát quy trình hoạt động: Theo dõi realtime các hoạt động của dịch vụ và hệ thống giúp phản ứng kịp thời với các sự cố.
- Bảo trì nhật ký hệ thống: Hiểu được cách quản lý dung lượng log, xóa tự động, cấu hình lưu trữ để hệ thống luôn ổn định.
- Biết thêm Vietnix – Nhà cung cấp dịch vụ lưu trữ tốc độ cao.
- Câu hỏi thường gặp: Giải đáp các thắc mắc phổ biến giúp bạn sử dụng
journalctl
hiệu quả hơn trong thực tế.
Tổng quan về journalctl Linux và System Logs
Trong hệ thống Linux sử dụng systemd, việc ghi nhận và quản lý log đã được đơn giản hóa và tập trung hơn rất nhiều so với các phương pháp truyền thống. Trước đây, log hệ thống thường bị phân tán ở nhiều tệp và được xử lý bởi các daemon riêng lẻ như rsyslog
, syslog-ng
, khiến việc theo dõi trở nên phức tạp khi liên quan đến nhiều tiến trình.

Systemd khắc phục nhược điểm này bằng cách cung cấp một giải pháp quản lý nhật ký tập trung, gọi là journal. Toàn bộ log từ kernel, initrd, các dịch vụ nền (daemons) và ứng dụng người dùng đều được thu thập và xử lý thông qua daemon systemd-journald
.
Công cụ dùng để truy cập và thao tác với dữ liệu trong journal chính là journalctl
. Với journalctl
, bạn có thể xem log theo thời gian, theo dịch vụ, theo mức độ ưu tiên, thậm chí theo tiến trình cụ thể. Đây là công cụ không thể thiếu cho các quản trị viên hệ thống trong việc giám sát, phân tích và xử lý sự cố nhanh chóng.
Vai trò của journalctl Linux trong việc xem và thao tác Systemd Logs
Trong hệ thống sử dụng systemd
, việc quản lý log trở nên tập trung hơn nhờ vào journald
daemon – thành phần chịu trách nhiệm thu thập toàn bộ thông điệp nhật ký từ các nguồn khác nhau và lưu trữ dưới định dạng nhị phân. Điều này mang lại nhiều lợi ích đáng kể cho quản trị viên hệ thống.
Thay vì phải dùng nhiều công cụ để xử lý log từ từng dịch vụ, journalctl
cho phép truy vấn, hiển thị và lọc log một cách linh hoạt chỉ với một lệnh duy nhất. Bạn có thể dễ dàng xem log từ các lần khởi động trước, gộp nhật ký của nhiều dịch vụ liên quan để phân tích lỗi giao tiếp, hoặc xuất log sang định dạng JSON để phục vụ mục đích thống kê và trực quan hóa.

Định dạng nhị phân không chỉ giúp truy xuất nhanh hơn mà còn hỗ trợ xuất log sang nhiều kiểu định dạng khác nhau mà không cần chuyển đổi thủ công. Ngoài ra, journalctl
có thể hoạt động song song với các hệ thống syslog truyền thống, hoặc hoàn toàn thay thế nếu bạn muốn một giải pháp log toàn diện, thống nhất. Với tính năng mạnh mẽ, khả năng tương thích linh hoạt và hiệu quả khi xử lý log thời gian thực, journalctl
là công cụ không thể thiếu để theo dõi, phân tích và tối ưu hoạt động hệ thống Linux hiện đại.
Thiết lập thời gian cho hệ thống
Một trong những lợi ích của việc sử dụng định dạng nhật ký nhị phân (binary journal) trong journalctl
là khả năng linh hoạt hiển thị log theo giờ UTC hoặc giờ địa phương. Theo mặc định, systemd
sẽ hiển thị nhật ký theo múi giờ địa phương.
Vì vậy, trước khi bắt đầu làm việc với journalctl
, bạn nên kiểm tra và thiết lập múi giờ cho hệ thống để đảm bảo log hiển thị chính xác. Bộ công cụ systemd
đi kèm sẵn một tiện ích hỗ trợ việc này có tên là timedatectl
. Đầu tiên, để xem danh sách các múi giờ có sẵn trên hệ thống, bạn sử dụng lệnh:
timedatectl list-timezones
Lệnh trên sẽ hiển thị toàn bộ các múi giờ mà hệ thống hỗ trợ. Khi đã xác định được múi giờ phù hợp với vị trí máy chủ của bạn, bạn có thể đặt múi giờ đó bằng lệnh sau:
sudo timedatectl set-timezone zone
Trong đó zone
là tên múi giờ bạn muốn thiết lập, ví dụ: Asia/Ho_Chi_Minh
. Sau khi thiết lập, để xác nhận rằng hệ thống đang sử dụng đúng thời gian, bạn có thể chạy lệnh timedatectl
không tham số, hoặc dùng thêm tùy chọn status
. Cả hai cách đều trả về kết quả giống nhau:
timedatectl status
Ví dụ kết quả đầu ra là:
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 Local time
phải hiển thị đúng thời gian hiện tại theo múi giờ bạn đã thiết lập. Đây là bước quan trọng giúp bạn theo dõi log một cách chính xác theo mốc thời gian thực tế của hệ thống.
Cách xem Systemd Logs cơ bản
Để xem các log mà dịch vụ journald
đã thu thập, bạn chỉ cần sử dụng lệnh:
journalctl
Khi chạy lệnh này mà không có tùy chọn nào kèm theo, journalctl
sẽ hiển thị toàn bộ nhật ký hệ thống hiện có, sử dụng một công cụ phân trang (thường là less
) để bạn có thể dễ dàng cuộn và duyệt nội dung. Các bản ghi nhật ký cũ nhất sẽ được hiển thị ở đầu:
-- 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.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 83 classes, 104131 rules
Bạn sẽ thấy rất nhiều dòng dữ liệu – có thể lên đến hàng chục hoặc hàng trăm nghìn dòng nếu hệ thống của bạn đã sử dụng systemd
trong một thời gian dài. Điều này cho thấy mức độ chi tiết của dữ liệu mà journalctl
lưu trữ trong cơ sở dữ liệu journal.
Định dạng của log khá quen thuộc nếu bạn từng làm việc với các hệ thống ghi log theo chuẩn syslog. Tuy nhiên, journalctl
cung cấp nhiều hơn thế – nó thu thập dữ liệu từ nhiều nguồn mà các trình syslog truyền thống không thể xử lý được, bao gồm:
- Các log từ giai đoạn khởi động sớm (early boot).
- Log từ kernel.
- Log từ initrd.
- Log từ stdout và stderr của ứng dụng.
Tất cả đều được lưu trữ trong journal và có thể truy xuất dễ dàng bằng journalctl
. Bạn cũng sẽ thấy rằng tất cả các timestamp được hiển thị theo giờ địa phương, nhờ việc hệ thống đã được cấu hình thời gian chính xác. Thông tin thời gian này có sẵn cho mọi bản ghi log. Nếu bạn muốn hiển thị timestamp theo múi giờ UTC, có thể thêm tùy chọn --utc
:
journalctl --utc
Điều này giúp bạn đồng bộ hóa log giữa các hệ thống có múi giờ khác nhau, đặc biệt hữu ích trong các môi trường server quốc tế hoặc đa vùng miền.
Lọc nhật ký theo thời gian
Mặc dù việc truy cập được vào toàn bộ dữ liệu nhật ký hệ thống là rất hữu ích, nhưng lượng thông tin lớn như vậy có thể khiến việc kiểm tra thủ công trở nên khó khăn hoặc không khả thi. Vì lý do đó, một trong những tính năng quan trọng nhất của journalctl
chính là khả năng lọc theo thời gian.
1. Hiển thị log từ lần khởi động hiện tại
Cách lọc đơn giản và phổ biến nhất là sử dụng tùy chọn -b
, giúp hiển thị tất cả các log được ghi nhận từ lần khởi động gần nhất:
journalctl -b
Lệnh này đặc biệt hữu ích khi bạn muốn xem những thông tin liên quan đến môi trường hiện tại của hệ thống. Trong trường hợp bạn không sử dụng tùy chọn này và hiển thị log kéo dài nhiều lần khởi động, journalctl
sẽ tự động chèn dòng phân cách khi hệ thống khởi động lại:
-- Reboot --
2. Xem log từ các lần khởi động trước
Mặc dù log từ lần khởi động hiện tại là thường dùng nhất, nhưng đôi khi việc truy cập log từ các lần khởi động trước cũng rất cần thiết. journalctl
cho phép lưu thông tin từ nhiều phiên khởi động trước (nếu được bật). Một số bản phân phối Linux kích hoạt tính năng này mặc định, nhưng cũng có một số thì không. Để bật lưu log phiên khởi động trước, bạn cần tạo thư mục lưu trữ:
sudo mkdir -p /var/log/journal
Hoặc bạn chỉnh sửa file cấu hình:
sudo nano /etc/systemd/journald.conf
Trong mục [Journal]
, bạn hãy đặt giá trị Storage=
thành persistent
:
[Journal]
Storage=persistent
Khi tính năng lưu log các phiên khởi động trước đã được kích hoạt, bạn có thể xem danh sách các phiên đó bằng lệnh:
journalctl --list-boots
Ví dụ kết quả:
-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
Cột đầu tiên là chỉ số tương đối có thể dùng với cờ -b
. Cột thứ hai là boot ID dùng để tham chiếu chính xác phiên khởi động. Hai mốc thời gian cuối thể hiện thời gian bắt đầu và kết thúc của phiên đó. Ví dụ để xem log của phiên khởi động trước đó, bạn dùng lệnh:
journalctl -b -1
Hoặc nếu muốn truy xuất log dựa trên boot ID cụ thể, bạn dùng lệnh:
journalctl -b caf0524a1d394ce0bdbcff75b94444fe
3. Lọc theo khung thời gian tùy chọn
Ngoài việc lọc theo phiên khởi động, journalctl
còn hỗ trợ lọc theo khoảng thời gian cụ thể bằng cách dùng các tùy chọn --since
và --until
. Cú pháp như sau:
journalctl --since "YYYY-MM-DD HH:MM:SS" --until "YYYY-MM-DD HH:MM:SS"
Ví dụ, để xem các log từ 17:15 ngày 10/01/2016, bạn dùng:
journalctl --since "2016-01-10 17:15:00"
Nếu bạn bỏ phần ngày, journalctl
sẽ mặc định là ngày hiện tại. Nếu bạn bỏ phần giờ, nó sẽ mặc định là "00:00:00"
. Ví dụ lọc từ 0h ngày 10/01 đến 3h ngày 11/01:
journalctl --since "2015-01-10" --until "2015-01-11 03:00"
Ngoài định dạng thời gian tuyệt đối, bạn còn có thể dùng các từ khóa thời gian như: yesterday
, today
, tomorrow
, now
. journalctl
cũng hỗ trợ thời gian tương đối như:
journalctl --since yesterday
Hoặc kết hợp cụ thể hơn, bạn nhận được thông báo hệ thống bị gián đoạn từ 9h sáng đến một giờ trước, có thể dùng:
journalctl --since 09:00 --until "1 hour ago"
Như bạn thấy, việc định nghĩa các khoảng thời gian linh hoạt để lọc log với journalctl
là rất trực quan và dễ áp dụng, đặc biệt hữu ích khi xử lý sự cố trên các máy chủ có thời gian uptime dài.
Lọc theo sở thích tin nhắn
Ở phần trước, bạn đã được giới thiệu cách lọc dữ liệu nhật ký dựa trên các giới hạn thời gian. Trong phần này, mình sẽ nói đến cách lọc dựa trên dịch vụ hoặc thành phần mà bạn quan tâm. Systemd journal cung cấp nhiều cách để làm việc này.
- Lọc theo Unit: Cách lọc hữu ích nhất có thể là dựa trên unit mà bạn muốn xem nhật ký. Bạn có thể dùng tùy chọn
-u
để lọc theo unit. Ví dụ, để xem toàn bộ nhật ký của unit Nginx trên hệ thống, bạn có thể gõ lệnh:
journalctl -u nginx.service
Thông thường, bạn sẽ muốn kết hợp lọc theo thời gian để hiển thị các dòng nhật ký bạn quan tâm. Ví dụ, để kiểm tra trạng thái dịch vụ trong ngày hôm nay, bạn dùng:
journalctl -u nginx.service --since today
Kiểu lọc tập trung này rất hữu ích khi bạn tận dụng khả năng xen kẽ các bản ghi từ nhiều unit khác nhau trong journal. Ví dụ, nếu quá trình Nginx của bạn liên kết với unit PHP-FPM để xử lý nội dung động, bạn có thể gộp các bản ghi của cả hai unit theo thứ tự thời gian bằng cách chỉ định cả hai:
journalctl -u nginx.service -u php-fpm.service --since today
Điều này giúp bạn dễ dàng phát hiện tương tác giữa các chương trình khác nhau và gỡ lỗi hệ thống thay vì chỉ xem từng tiến trình riêng lẻ.
- Lọc theo Process, User hoặc Group ID: Một số dịch vụ sinh ra nhiều tiến trình con để thực hiện công việc. Nếu bạn biết chính xác PID của tiến trình cần quan tâm, bạn cũng có thể lọc theo PID đó. Cách làm là sử dụng trường
_PID
. Ví dụ, nếu PID cần tìm là 8088, bạn gõ:
journalctl _PID=8088
Trong một số trường hợp khác, bạn có thể muốn xem tất cả các mục nhập do một người dùng hoặc nhóm cụ thể ghi lại. Điều này có thể thực hiện với bộ lọc _UID
hoặc _GID
. Ví dụ, nếu máy chủ web của bạn chạy dưới user www-data
, bạn có thể tìm ID người dùng bằng lệnh:
id -u www-data
Kết quả là:
33
Sau đó, bạn dùng ID đó để lọc nhật ký:
journalctl _UID=33 --since today
Systemd journal có nhiều trường dữ liệu để lọc, một số được truyền từ tiến trình ghi log, một số được journald áp dụng dựa trên thông tin thu thập từ hệ thống tại thời điểm ghi log. Dấu gạch dưới ở đầu trường (ví dụ _PID
) biểu thị đây là trường loại sau. Journal tự động ghi nhận và đánh chỉ mục PID của tiến trình ghi log để dễ dàng lọc về sau. Bạn có thể xem toàn bộ các trường có thể dùng để lọc bằng lệnh:
man systemd.journal-fields
Trong hướng dẫn này, mình sẽ đề cập một số trường quan trọng. Ngoài ra, có một tùy chọn rất hữu ích khác là -F
, dùng để hiển thị tất cả các giá trị có sẵn cho một trường nhật ký. Ví dụ, để xem các group ID mà journal đã lưu, bạn có thể dùng:
journalctl -F _GID
Kết quả là:
32
99
102
133
81
84
100
0
124
87
- Lọc theo Đường dẫn thành phần (Component Path): Bạn cũng có thể lọc bằng cách chỉ định đường dẫn đến một tập tin thực thi. Nếu đường dẫn đó trỏ tới một chương trình,
journalctl
sẽ hiển thị tất cả mục nhập liên quan tới chương trình đó. Ví dụ, để tìm các mục nhập liên quan đến bash, bạn gõ:
journalctl /usr/bin/bash
Thông thường nếu có unit tương ứng cho chương trình, cách lọc theo unit sẽ sạch sẽ và cung cấp nhiều thông tin hơn (bao gồm cả các tiến trình con liên quan). Tuy nhiên, đôi khi cách lọc theo đường dẫn là lựa chọn duy nhất.
- Hiển thị tin nhắn Kernel: Các tin nhắn kernel (thường xuất hiện trong kết quả
dmesg
) cũng có thể được truy xuất từ journal. Để chỉ hiển thị các tin nhắn kernel, bạn thêm tùy chọn-k
hoặc--dmesg
:
journalctl -k
Mặc định, lệnh này sẽ hiển thị các tin nhắn kernel từ lần khởi động hiện tại. Bạn cũng có thể chỉ định boot khác bằng các tùy chọn chọn boot đã đề cập trước đó. Ví dụ, để xem tin nhắn từ lần khởi động thứ 5 trước, bạn dùng:
journalctl -k -b -5
- Lọc theo mức độ ưu tiên (Priority): Một bộ lọc phổ biến mà quản trị viên hệ thống thường dùng là dựa trên mức độ ưu tiên của tin nhắn. Mặc dù ghi log ở mức độ chi tiết cao rất hữu ích, nhưng khi xem lại thông tin, các tin nhắn ưu tiên thấp có thể gây rối và khó theo dõi. Bạn có thể dùng tùy chọn
-p
để hiển thị chỉ các tin nhắn ở mức ưu tiên nhất định trở lên, giúp loại bỏ các tin nhắn có mức ưu tiên thấp hơn. Ví dụ, để xem các bản ghi ở mức lỗi (error) trở lên trong lần khởi động hiện tại, bạn dùng:
journalctl -p err -b
Lệnh trên sẽ hiển thị tất cả các tin nhắn có mức độ error
, critical
, alert
, hoặc emergency
. Journal sử dụng các mức độ chuẩn của syslog, bạn có thể dùng tên mức độ hoặc số tương ứng. Các mức độ từ cao đến thấp lần lượt là:
0: emerg
1: alert
2: crit
3: err
4: warning
5: notice
6: info
7: debug
Các số hoặc tên này có thể dùng thay thế cho nhau với tùy chọn -p
. Việc chọn một mức độ sẽ hiển thị tất cả các tin nhắn có mức độ bằng hoặc cao hơn mức đó.
Sửa đổi hiển thị nhật ký
Trên đây, mình đã hướng dẫn cách lựa chọn bản ghi thông qua việc lọc. Ngoài ra, còn rất nhiều cách khác để bạn có thể tùy chỉnh cách hiển thị của journalctl
sao cho phù hợp với nhu cầu sử dụng:
1. Thu gọn hoặc mở rộng đầu ra
Bạn có thể điều chỉnh cách journalctl
hiển thị dữ liệu bằng cách yêu cầu nó thu gọn hoặc mở rộng đầu ra. Theo mặc định, journalctl
sẽ hiển thị toàn bộ nội dung của một bản ghi trong trình xem trang (pager), cho phép các dòng log dài có thể kéo sang bên phải màn hình. Bạn có thể xem phần bị ẩn bằng cách nhấn phím mũi tên phải. Nếu bạn muốn kết quả đầu ra được thu gọn lại, chèn dấu ba chấm (…) tại vị trí thông tin bị cắt bớt, bạn có thể dùng tùy chọn --no-full
:
journalctl --no-full
Kết quả đầu ra sẽ có dạng như sau:
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 bạn muốn journalctl
hiển thị toàn bộ thông tin, kể cả những ký tự không thể in ra màn hình, bạn có thể dùng tùy chọn -a
:
journalctl -a
2. Đầu ra ra màn hình tiêu chuẩn
Theo mặc định, journalctl
sẽ hiển thị đầu ra trong một trình xem trang để dễ dàng quan sát. Tuy nhiên, nếu bạn muốn xử lý dữ liệu với các công cụ xử lý văn bản khác, bạn nên xuất trực tiếp ra màn hình tiêu chuẩn. Điều này thực hiện được bằng tùy chọn --no-pager
:
journalctl --no-pager
Đầu ra này có thể được chuyển tiếp ngay tới các công cụ xử lý hoặc ghi ra file trên đĩa tùy theo mục đích của bạn.
3. Định dạng đầu ra
Nếu bạn xử lý các bản ghi nhật ký một cách tự động, bạn sẽ dễ dàng hơn khi xuất dữ liệu ở các định dạng dễ phân tích. May mắn là journalctl
hỗ trợ xuất log dưới nhiều định dạng khác nhau bằng tùy chọn -o
kèm theo tham số định dạng. Ví dụ, để xuất nhật ký của boot hiện tại và dịch vụ nginx
ở định dạng JSON, bạn dùng lệnh:
journalctl -b -u nginx -o json
Kết quả sẽ có dạng:
{
"__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"
}
Điều này rất hữu ích khi bạn muốn phân tích bằng các tiện ích xử lý JSON. Nếu muốn xem dữ liệu đẹp hơn trước khi xử lý tiếp, bạn có thể dùng định dạng json-pretty
:
journalctl -b -u nginx -o json-pretty
Kết quả sẽ được trình bày rõ ràng, dễ đọc hơn:
{
"__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"
}
Ngoài ra, bạn có thể sử dụng các định dạng sau khi hiển thị nhật ký:
cat
: Chỉ hiển thị trường thông báo (message).export
: Định dạng nhị phân, phù hợp để chuyển hoặc sao lưu.json
: JSON tiêu chuẩn, mỗi bản ghi trên một dòng.json-pretty
: JSON được định dạng dễ đọc cho người dùng.json-sse
: JSON chuẩn bị cho server-sent events.short
: Định dạng mặc định kiểu syslog.short-iso
: Định dạng mặc định kèm theo dấu thời gian chuẩn ISO 8601.short-monotonic
: Định dạng mặc định với dấu thời gian monotonic.short-precise
: Định dạng mặc định với độ chính xác micro giây.verbose
: Hiển thị tất cả trường dữ liệu của bản ghi, bao gồm các trường thường bị ẩn.
Giám sát quy trình hoạt động
Lệnh journalctl
mô phỏng cách nhiều quản trị viên sử dụng lệnh tail
để theo dõi các hoạt động đang diễn ra hoặc các sự kiện gần đây. Tính năng này được tích hợp sẵn trong journalctl
, cho phép bạn truy cập mà không cần phải kết hợp với công cụ khác.
- Hiển thị các bản ghi gần đây: Để hiển thị một số lượng bản ghi nhất định, bạn có thể sử dụng tùy chọn
-n
, hoạt động tương tự nhưtail -n
. Theo mặc định, lệnh sẽ hiển thị 10 bản ghi gần nhất:
journalctl -n
Nếu muốn xem số lượng bản ghi cụ thể, bạn chỉ cần thêm số vào sau -n
:
journalctl -n 20
- Theo dõi nhật ký liên tục: Để theo dõi nhật ký khi chúng đang được ghi thêm, bạn dùng cờ
-f
. Tương tự nhưtail -f
, lệnh này sẽ liên tục cập nhật các dòng log mới nhất.
journalctl -f
Để thoát khỏi chế độ theo dõi này, bạn nhấn tổ hợp phím CTRL+C
.
Bảo trì nhật ký hệ thống
Bạn có thể đang thắc mắc chi phí lưu trữ toàn bộ dữ liệu nhật ký hiện tại là bao nhiêu. Thêm vào đó, bạn cũng có thể muốn dọn dẹp các bản ghi cũ để giải phóng dung lượng ổ đĩa:
- Xem dung lượng ổ đĩa đang sử dụng: Để biết dung lượng mà journal hiện đang chiếm trên ổ đĩa, bạn có thể dùng tùy chọn
--disk-usage
:
journalctl --disk-usage
Kết quả sẽ hiển thị như sau:
Archived and active journals take up 8.0M in the file system.
- Xóa các nhật ký cũ: Nếu bạn muốn thu nhỏ kích thước nhật ký, có hai cách để thực hiện (áp dụng với systemd phiên bản 218 trở lên).
Sử dụng tùy chọn --vacuum-size
để thu nhỏ nhật ký theo dung lượng cụ thể. Lệnh này sẽ xóa các bản ghi cũ cho đến khi tổng dung lượng nhật ký còn lại bằng kích thước bạn yêu cầu:
sudo journalctl --vacuum-size=1G
Cách thứ hai là sử dụng tùy chọn --vacuum-time
để xóa các bản ghi cũ hơn một khoảng thời gian nhất định, giữ lại những bản ghi được tạo ra sau thời điểm đó. Ví dụ, để giữ lại nhật ký từ 1 năm gần đây:
sudo journalctl --vacuum-time=1years
- Giới hạn sự mở rộng của nhật ký: Bạn có thể cấu hình máy chủ để giới hạn dung lượng tối đa mà journal được phép sử dụng. Điều này được thực hiện bằng cách chỉnh sửa file cấu hình
/etc/systemd/journald.conf
.
Các tùy chọn sau giúp bạn kiểm soát sự phát triển của nhật ký:
SystemMaxUse=
: Xác định dung lượng đĩa tối đa mà nhật ký có thể sử dụng trong bộ nhớ lưu trữ lâu dài (persistent storage).SystemKeepFree=
: Xác định dung lượng đĩa cần giữ trống khi thêm bản ghi mới vào bộ nhớ lưu trữ lâu dài.SystemMaxFileSize=
: Giới hạn kích thước tối đa của từng file nhật ký trong bộ nhớ lưu trữ lâu dài trước khi được xoay vòng (rotate).RuntimeMaxUse=
: Xác định dung lượng đĩa tối đa mà nhật ký có thể sử dụng trong bộ nhớ tạm thời (volatile storage, trong thư mục/run
).RuntimeKeepFree=
: Xác định dung lượng cần giữ trống cho mục đích khác khi ghi dữ liệu vào bộ nhớ tạm thời.RuntimeMaxFileSize=
: Giới hạn dung lượng tối đa của từng file nhật ký trong bộ nhớ tạm thời trước khi xoay vòng.
Bằng cách thiết lập các giá trị trên, bạn kiểm soát được việc journald
sử dụng và giữ lại dung lượng ổ đĩa trên máy chủ. Bạn cần lưu ý rằng các tùy chọn SystemMaxFileSize
và RuntimeMaxFileSize
áp dụng cho các file nhật ký đã được lưu trữ (archived files) để đảm bảo các file này không vượt quá giới hạn đã định. Điều này rất quan trọng khi bạn phân tích số lượng file sau các thao tác dọn dẹp (vacuuming).
Vietnix – Nhà cung cấp dịch vụ lưu trữ tốc độ cao
Vietnix là nhà cung cấp dịch vụ thuê VPS uy tín với hạ tầng máy chủ mạnh mẽ, sử dụng 100% ổ cứng SSD, mang đến tốc độ truy cập nhanh và ổn định. Đặc biệt, dịch vụ VPS Linux tại Vietnix cho phép khách hàng toàn quyền quản trị, dễ dàng tùy chỉnh cấu hình qua giao diện trực quan và đầy đủ tính năng. Hệ thống backup tự động hàng tuần đảm bảo an toàn dữ liệu và khả năng khôi phục nhanh chóng khi cần thiết. Với Vietnix, bạn sẽ có giải pháp VPS linh hoạt, bảo mật cao và tối ưu chi phí cho mọi nhu cầu lưu trữ và vận hành. Liên hệ ngay!
Thông tin liên hệ:
- Hotline: 18001093
- Email: sales@vietnix.com.vn
- Địa chỉ: 265 Hồng Lạc, Phường 10, Quận Tân Bình, Thành Phố Hồ Chí Minh.
- Website: https://vietnix.vn/
Câu hỏi thường gặp
Tại sao journalctl đôi khi hiển thị log không theo thứ tự thời gian chính xác?
journalctl
đôi khi hiển thị log không theo thứ tự thời gian chính xác do một số nguyên nhân chính sau:
– Đồng bộ thời gian chưa chính xác.
– Log từ nhiều nguồn hoặc đơn vị (unit) khác nhau.
– Cách journalctl xử lý bộ nhớ đệm và file nhật ký.
– Tính năng đồng bộ song song của systemd-journald.
Ảnh hưởng của việc cấu hình sai journald.conf đến hiệu suất và ổn định hệ thống?
Cấu hình sai journald.conf
có thể làm hệ thống tiêu tốn nhiều tài nguyên, gây đầy ổ đĩa, làm chậm hiệu suất và gián đoạn dịch vụ. Log có thể bị xoay vòng quá sớm, mất dữ liệu quan trọng hoặc khó quản lý. Ngoài ra, bảo mật log cũng bị ảnh hưởng nếu cấu hình không đúng. Vì vậy, việc thiết lập journald.conf
hợp lý rất quan trọng để đảm bảo cân bằng giữa lưu trữ log đầy đủ và duy trì hiệu suất, ổn định hệ thống.
Lời kết
Việc nắm vững các cú pháp và tùy chọn của journalctl
Linux không chỉ giúp bạn dễ dàng xử lý sự cố mà còn tối ưu hóa quá trình giám sát hệ thống. Bằng cách áp dụng các kỹ thuật lọc, sắp xếp và bảo trì nhật ký được hướng dẫn trong bài viết, bạn sẽ kiểm soát tốt hơn nguồn dữ liệu log, đồng thời đảm bảo hệ thống luôn hoạt động ổn định và an toàn. Cảm ơn bạn đã theo dõi!