Làm chủ nhật ký systemd:Hướng dẫn đầy đủ về cách sử dụng tạp chí trên Linux

Giới thiệu về nhật ký systemd và ghi nhật ký tạp chí

Một số ưu điểm hấp dẫn nhất của systemd là những người liên quan đến việc ghi nhật ký quy trình và hệ thống. Khi sử dụng các công cụ khác, nhật ký thường được phân tán trên toàn hệ thống, được xử lý bởi các trình nền và quy trình khác nhau và có thể khá khó diễn giải khi chúng trải rộng trên nhiều ứng dụng. systemd cố gắng giải quyết những vấn đề này bằng cách cung cấp giải pháp quản lý tập trung để ghi nhật ký tất cả các quy trình hạt nhân và vùng người dùng. Hệ thống thu thập và quản lý các nhật ký này được gọi là tạp chí .

Tạp chí được triển khai với journald daemon, xử lý tất cả các thông báo được tạo bởi kernel, initrd, dịch vụ, v.v. Trong hướng dẫn này, chúng ta sẽ thảo luận cách sử dụng journalctl tiện ích có thể được sử dụng để truy cập và thao tác dữ liệu được lưu giữ trong tạp chí.

Trong bài viết này, bạn sẽ tìm hiểu cách sử dụng journalctl công cụ dòng lệnh để truy cập và lọc dữ liệu nhật ký từ nhật ký systemd. Chúng tôi sẽ đề cập đến cách xem nhật ký từ các lần khởi động hoặc phạm vi thời gian cụ thể, lọc theo đơn vị hệ thống, người dùng hoặc mức độ ưu tiên và xuất nhật ký ở các định dạng như JSON để tích hợp với các công cụ khác. Bạn cũng sẽ tìm hiểu cách giám sát các sự kiện trong thời gian thực, quản lý việc sử dụng ổ đĩa, định cấu hình ghi nhật ký liên tục và giải quyết các sự cố phổ biến như thiếu nhật ký hoặc lỗi cấp phép. Cho dù bạn đang gỡ lỗi một dịch vụ bị lỗi hay đang thiết lập bộ sưu tập nhật ký tập trung, thì tạp chí đều mang đến sự linh hoạt và chính xác để hợp lý hóa quy trình làm việc của bạn.

Bài học chính

• systemd tạp chí cung cấp một hệ thống ghi nhật ký hợp nhất để ghi lại các thông báo từ nhân, dịch vụ và ứng dụng người dùng trong một nhật ký được lập chỉ mục tập trung.
• journalctl lệnh cho phép bạn lọc nhật ký theo phiên khởi động, phạm vi thời gian, đơn vị hệ thống, ID tiến trình, ID người dùng, ID nhóm, v.v., giúp bạn dễ dàng xác định các sự kiện có liên quan.
• Bạn có thể truy xuất nhật ký từ các khoảng thời gian cụ thể bằng cách sử dụng các tùy chọn như --since , --until , hoặc các biểu thức tương đối như "1 hour ago" hoặc "yesterday" .
• Nhật ký có thể được hiển thị ở nhiều định dạng khác nhau như văn bản thuần túy, JSON và chế độ dài dòng, giúp tích hợp dễ dàng hơn với các công cụ bên ngoài hoặc phân tích cú pháp để phân tích.
• Sử dụng journalctl -f , bạn có thể theo dõi trực tiếp thông điệp tường trình khi chúng được viết, tương tự như tail -f , rất hữu ích cho việc giám sát hoạt động của hệ thống hoặc hành vi của dịch vụ trong thời gian thực.
• Theo mặc định, nhật ký có thể được lưu trong bộ nhớ và bị mất khi khởi động lại. Bạn có thể kích hoạt tính năng ghi nhật ký liên tục bằng cách tạo /var/log/journal và định cấu hình journald.conf tương ứng.
• Dấu chân lưu trữ của tạp chí có thể được quản lý bằng các lệnh như --disk-usage , --vacuum-size , và --vacuum-time , cũng như các tùy chọn cấu hình để kiểm soát kích thước và tỷ lệ giữ chân tối đa.
• journalctl đơn giản hóa việc gỡ lỗi dịch vụ bằng cách tổng hợp nhật ký trên các thiết bị và khởi động, giúp việc xác định lỗi, theo dõi quyền truy cập SSH và điều tra các vấn đề bằng ngữ cảnh chi tiết trở nên dễ dàng hơn.

Nhật ký hệ thống hoạt động như thế nào và tại sao nó quan trọng

Một trong những động lực đằng sau systemd tạp chí là tập trung việc quản lý nhật ký bất kể thư có nguồn gốc từ đâu. Do phần lớn quá trình khởi động và quản lý dịch vụ được xử lý bởi systemd quá trình này, việc tiêu chuẩn hóa cách thu thập và truy cập nhật ký là điều hợp lý. journald daemon thu thập dữ liệu từ tất cả các nguồn có sẵn và lưu trữ dữ liệu ở định dạng nhị phân để thao tác dễ dàng và linh hoạt.

Điều này mang lại cho chúng tôi một số lợi thế đáng kể. Bằng cách tương tác với dữ liệu bằng một tiện ích duy nhất, quản trị viên có thể tự động hiển thị dữ liệu nhật ký theo nhu cầu của họ. Việc này có thể đơn giản như xem dữ liệu khởi động từ ba lần khởi động trước hoặc kết hợp các mục nhật ký tuần tự từ hai dịch vụ liên quan để gỡ lỗi sự cố giao tiếp.

Lưu trữ dữ liệu nhật ký ở định dạng nhị phân cũng có nghĩa là dữ liệu có thể được hiển thị ở định dạng đầu ra tùy ý tùy thuộc vào những gì bạn cần vào lúc này. Ví dụ:để quản lý nhật ký hàng ngày, bạn có thể quen với việc xem nhật ký ở syslog tiêu chuẩn định dạng, nhưng nếu sau này bạn quyết định vẽ đồ thị các gián đoạn dịch vụ, bạn có thể xuất từng mục nhập dưới dạng đối tượng JSON để làm cho mục đó có thể sử dụng được cho dịch vụ vẽ đồ thị của bạn. Vì dữ liệu không được ghi vào đĩa ở dạng văn bản thuần túy nên không cần chuyển đổi khi bạn cần định dạng theo yêu cầu khác.

systemd tạp chí có thể được sử dụng với syslog hiện có triển khai hoặc có thể thay thế syslog chức năng, tùy thuộc vào nhu cầu của bạn. Trong khi systemd tạp chí sẽ đáp ứng hầu hết các nhu cầu ghi nhật ký của quản trị viên, nó cũng có thể bổ sung cho các cơ chế ghi nhật ký hiện có. Ví dụ:bạn có thể có syslog tập trung máy chủ mà bạn sử dụng để biên dịch dữ liệu từ nhiều máy chủ, nhưng bạn cũng có thể muốn xen kẽ nhật ký từ nhiều dịch vụ trên một hệ thống bằng systemd tạp chí. Bạn có thể thực hiện cả hai điều này bằng cách kết hợp các công nghệ này.

Cách đặt thời gian hệ thống chính xác với timedatectl

Một trong những lợi ích của việc sử dụng nhật ký nhị phân để ghi nhật ký là khả năng xem bản ghi nhật ký theo giờ UTC hoặc giờ địa phương theo ý muốn. Theo mặc định, systemd sẽ hiển thị kết quả theo giờ địa phương.

Vì điều này, trước khi bắt đầu viết nhật ký, chúng tôi sẽ đảm bảo múi giờ được thiết lập chính xác. systemd bộ thực sự đi kèm với một công cụ có tên là timedatectl có thể giúp giải quyết vấn đề này.

Trước tiên, hãy xem những múi giờ nào có sẵn với list-timezones tùy chọn:

Điều này sẽ liệt kê các múi giờ có sẵn trên hệ thống của bạn. Khi bạn tìm thấy cái phù hợp với vị trí máy chủ của mình, bạn có thể đặt nó bằng cách sử dụng set-timezone tùy chọn:

Để đảm bảo rằng máy của bạn hiện đang sử dụng đúng thời gian, hãy sử dụng timedatectl chỉ lệnh hoặc với status tùy chọn. Màn hình sẽ giống nhau:

 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 sẽ hiển thị thời gian chính xác.

Cách xem nhật ký với journalctl

Để xem nhật ký của journald daemon đã được thu thập, hãy sử dụng journalctl lệnh.

Khi được sử dụng một mình, mọi mục nhật ký trong hệ thống sẽ được hiển thị trong một máy nhắn tin (thường là less ) để bạn duyệt. Các mục cũ nhất sẽ được đưa lên trên cùng:

-- 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 có thể sẽ có nhiều trang và trang dữ liệu để cuộn qua, có thể dài hàng chục hoặc hàng trăm nghìn dòng nếu systemd đã có trên hệ thống của bạn trong một thời gian dài. Điều này cho thấy có bao nhiêu dữ liệu có sẵn trong cơ sở dữ liệu tạp chí.

Định dạng này sẽ quen thuộc với những người đã quen với syslog tiêu chuẩn khai thác gỗ. Tuy nhiên, điều này thực sự thu thập dữ liệu từ nhiều nguồn hơn syslog truyền thống khả năng triển khai có thể thực hiện được. Nó bao gồm các nhật ký từ quá trình khởi động ban đầu, kernel, initrd và lỗi tiêu chuẩn ứng dụng và lỗi. Tất cả đều có trên tạp chí.

Bạn có thể nhận thấy rằng tất cả các dấu thời gian được hiển thị đều là giờ địa phương. Tính năng này hiện có sẵn cho mọi mục nhập nhật ký vì chúng tôi đã đặt giờ địa phương chính xác trên hệ thống của mình. Tất cả nhật ký được hiển thị bằng thông tin mới này.

Nếu bạn muốn hiển thị dấu thời gian trong UTC, bạn có thể sử dụng --utc cờ:

Cách lọc nhật ký hệ thống theo thời gian với journalctl

Mặc dù việc có quyền truy cập vào bộ sưu tập dữ liệu lớn như vậy chắc chắn là hữu ích nhưng lượng thông tin lớn như vậy có thể khó hoặc không thể kiểm tra và xử lý theo cách thủ công. Vì lý do này, một trong những tính năng quan trọng nhất của journalctl là các tùy chọn lọc của nó.

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

Cơ bản nhất mà bạn có thể sử dụng hàng ngày là -b cờ. Thao tác này sẽ hiển thị cho bạn tất cả các mục nhật ký đã được thu thập kể từ lần khởi động lại gần đây nhất.

Điều này sẽ giúp bạn xác định và quản lý thông tin phù hợp với môi trường hiện tại của bạn.

Trong trường hợp bạn không sử dụng tính năng này và hiển thị số lần khởi động hơn một ngày, bạn sẽ thấy journalctl đó đã chèn một dòng trông như thế này mỗi khi hệ thống gặp sự cố:

. . .
-- Reboot --
. . .

Điều này có thể được sử dụng để giúp bạn phân tách thông tin thành các phiên khởi động một cách hợp lý.

Cách truy cập nhật ký từ lần khởi động trước bằng journalctl

Mặc dù bạn thường muốn hiển thị thông tin từ lần khởi động hiện tại, nhưng chắc chắn đôi khi những lần khởi động trước đây cũng sẽ hữu ích. Nhật ký có thể lưu thông tin từ nhiều lần khởi động trước đó, vì vậy journalctl có thể được thực hiện để hiển thị thông tin một cách dễ dàng.

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, trong khi một số khác lại tắt tính năng này. Để kích hoạt thông tin khởi động liên tục, bạn có thể tạo thư mục để lưu nhật ký bằng cách nhập:

Hoặc bạn có thể chỉnh sửa tệp cấu hình tạp chí:

Theo [Journal] phần, đặt Storage= tùy chọn “liên tục” để bật ghi nhật ký liên tục:

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

Khi tính năng lưu các lần khởi động trước đó được bật trên máy chủ của bạn, journalctl cung cấp một số lệnh giúp bạn làm việc với bốt như một đơn vị chia. Để xem đôi bốt journald biết về điều đó, hãy sử dụng --list-boots tùy chọn với journalctl :

-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

Điều này sẽ hiển thị một dòng cho mỗi lần khởi động. Cột đầu tiên là phần bù cho phần khởi động có thể được sử dụng để dễ dàng tham chiếu phần khởi động bằng journalctl . Nếu bạn cần một tham chiếu tuyệt đối, ID khởi động nằm ở cột thứ hai. Bạn có thể biết thời gian mà phiên khởi động đề cập đến bằng hai thông số thời gian được liệt kê ở cuối.

Để hiển thị thông tin từ những đôi giày này, bạn có thể sử dụng thông tin từ cột đầu tiên hoặc cột thứ hai.

Ví dụ:để xem nhật ký từ lần khởi động trước, hãy sử dụng -1 con trỏ tương đối với -b cờ:

Bạn cũng có thể sử dụng ID khởi động để gọi lại dữ liệu từ quá trình khởi động:

Lọc nhật ký tạp chí theo phạm vi ngày và giờ tùy chỉnh

Mặc dù việc xem các mục nhật ký khi khởi động là vô cùng hữu ích, nhưng bạn thường có thể muốn yêu cầu khoảng thời gian không phù hợp với quá trình khởi động hệ thống. Điều này có thể đặc biệt đúng khi xử lý các máy chủ hoạt động lâu dài với thời gian hoạt động đáng kể.

Bạn có thể lọc theo giới hạn thời gian tùy ý bằng cách sử dụng --since và --until các tùy chọn hạn chế các mục được hiển thị tương ứng với các mục sau hoặc trước thời gian nhất định.

Các giá trị thời gian có thể có nhiều định dạng khác nhau. Đối với giá trị thời gian tuyệt đối, bạn nên sử dụng định dạng sau:

Ví dụ:chúng ta có thể xem tất cả các mục kể từ ngày 10 tháng 1 năm 2015 lúc 5:15 chiều bằng cách nhập:

Nếu các thành phần có định dạng trên bị bỏ đi, một số giá trị mặc định sẽ được áp dụng. Ví dụ:nếu ngày bị bỏ qua, ngày hiện tại sẽ được coi là ngày hiện tại. Nếu thành phần thời gian bị thiếu, “00:00:00” (nửa đêm) sẽ được thay thế. Trường giây cũng có thể được tắt để mặc định là “00”:

Tạp chí cũng hiểu một số giá trị tương đối và các phím tắt được đặt tên. Ví dụ:bạn có thể sử dụng các từ “hôm qua”, “hôm nay”, “ngày mai” hoặc “bây giờ”. Bạn có thể tính thời gian tương đối bằng cách thêm “-” hoặc “+” vào trước một giá trị được đánh số hoặc sử dụng các từ như “trước” trong cấu trúc câu.

Để lấy dữ liệu từ ngày hôm qua, bạn có thể gõ:

Nếu bạn nhận được báo cáo về việc dịch vụ bị gián đoạn bắt đầu lúc 9 giờ sáng và tiếp tục cho đến một giờ trước, bạn có thể nhập:

Như bạn có thể thấy, việc xác định khoảng thời gian linh hoạt để lọc các mục bạn muốn xem là tương đối đơn giản.

Cách lọc nhật ký nhật ký hệ thống theo dịch vụ, PID hoặc người dùng

Ở trên, chúng tôi đã tìm hiểu một số cách để bạn có thể lọc dữ liệu nhật ký bằng cách sử dụng các giới hạn về thời gian. Trong phần này, chúng ta sẽ thảo luậ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 tạp chí cung cấp nhiều cách khác nhau để thực hiện việc này.

Xem nhật ký theo đơn vị dịch vụ Systemd

Có lẽ cách lọc hữu ích nhất là theo đơn vị bạn quan tâm. Chúng ta có thể sử dụng -u tùy chọn để lọc theo cách này.

Ví dụ:để xem tất cả nhật ký từ thiết bị Nginx trên hệ thống của chúng tôi, chúng tôi có thể nhập:

Thông thường, bạn có thể muốn lọc theo thời gian để hiển thị các dòng bạn quan tâm. Ví dụ:để kiểm tra xem dịch vụ hiện đang chạy như thế nào, bạn có thể nhập:

Kiểu tập trung này trở nên cực kỳ hữu ích khi bạn tận dụng khả năng của nhật ký để xen kẽ các bản ghi từ nhiều đơn vị khác nhau. Ví dụ:nếu quy trình Nginx của bạn được kết nối với đơn vị PHP-FPM để xử lý nội dung động, bạn có thể hợp nhất các mục từ cả hai theo thứ tự thời gian bằng cách chỉ định cả hai đơn vị:

Điều này có thể giúp việc phát hiện sự tương tác giữa các chương trình và hệ thống gỡ lỗi khác nhau dễ dàng hơn nhiều thay vì các quy trình riêng lẻ.

Lọc nhật ký hệ thống theo PID, UID hoặc GID

Một số dịch vụ sinh ra nhiều quy trình con khác nhau để thực hiện công việc. Nếu bạn đã tìm ra PID chính xác của quy trình mà bạn quan tâm, bạn cũng có thể lọc theo đó.

Để làm điều này, chúng ta có thể lọc bằng cách chỉ định _PID lĩnh vực. Ví dụ:nếu PID mà chúng tôi quan tâm là 8088, chúng tôi có thể nhập:

Vào những lúc khác, bạn có thể muốn hiển thị tất cả các mục được ghi lại từ một người dùng hoặc nhóm cụ thể. Điều này có thể được thực hiện với _UID hoặc _GID bộ lọc. Ví dụ:nếu máy chủ web của bạn chạy dưới www-data người dùng, bạn có thể tìm ID người dùng bằng cách nhập:

33

Sau đó, bạn có thể sử dụng ID được trả về để lọc kết quả tạp chí:

systemd tạp chí có nhiều trường có thể được sử dụng để lọc. Một số trong số đó được chuyển từ quá trình được ghi lại và một số được áp dụng bởi journald sử dụng thông tin thu thập được từ hệ thống tại thời điểm ghi nhật ký.

Dấu gạch dưới ở đầu cho biết rằng _PID trường thuộc loại sau. Nhật ký tự động ghi lại và lập chỉ mục PID của quá trình đang ghi nhật ký để lọc sau này. Bạn có thể tìm hiểu về tất cả các trường tạp chí có sẵn bằng cách nhập:

Chúng ta sẽ thảo luận về một số điều này trong hướng dẫn này. Tuy nhiên, hiện tại, chúng ta sẽ xem xét một tùy chọn hữu ích khác liên quan đến việc lọc theo các trường này. -F tùy chọn có thể được sử dụng để hiển thị tất cả các giá trị có sẵn cho một trường tạp chí nhất định.

Ví dụ:để xem ID nhóm nào systemd tạp chí có các mục, bạn có thể gõ:

32
99
102
133
81
84
100
0
124
87

Điều này sẽ hiển thị cho bạn tất cả các giá trị mà tạp chí đã lưu trữ cho trường ID nhóm. Điều này có thể giúp bạn xây dựng bộ lọc của mình.

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

Chúng tôi cũng có thể lọc bằng cách cung cấp vị trí đường dẫn.

Nếu đường dẫn dẫn đến tệp thực thi, journalctl sẽ hiển thị tất cả các mục liên quan đến tệp thực thi được đề cập. Ví dụ:để tìm những mục liên quan đến bash thực thi được, bạn có thể gõ:

Thông thường, nếu có sẵn một đơn vị để thực thi thì phương pháp đó sẽ sạch hơn và cung cấp thông tin tốt hơn (các mục từ các tiến trình con liên quan, v.v.). Tuy nhiên, đôi khi điều này là không thể.

Cách xem nhật ký hạt nhân bằng journalctl -k

Thông báo hạt nhân, những thông báo thường được tìm thấy trong dmesg đầu ra, cũng có thể được lấy từ tạp chí.

Để chỉ hiển thị những thông báo này, chúng ta có thể thêm -k hoặc --dmesg gắn cờ theo lệnh của chúng tôi:

Theo mặc định, điều này sẽ hiển thị các thông báo kernel từ lần khởi động hiện tại. Bạn có thể chỉ định một khởi động thay thế bằng cách sử dụng các cờ lựa chọn khởi động thông thường đã thảo luận trước đó. Ví dụ:để nhận tin nhắn từ năm lần khởi động trước, bạn có thể nhập:

Lọc nhật ký theo mức độ nghiêm trọng với journalctl -p

Một bộ lọc mà quản trị viên hệ thống thường quan tâm đó là mức độ ưu tiên của tin nhắn. Mặc dù việc ghi nhật ký thông tin ở mức độ chi tiết thường hữu ích nhưng khi thực sự xử lý thông tin có sẵn, nhật ký có mức độ ưu tiên thấp có thể gây mất tập trung và khó hiểu.

Bạn có thể sử dụng journalctl để chỉ hiển thị các tin nhắn có mức độ ưu tiên được chỉ định trở lên bằng cách sử dụng -p tùy chọn. Điều này cho phép bạn lọc ra những tin nhắn có mức độ ưu tiên thấp hơn.

Ví dụ:để chỉ hiển thị các mục được ghi ở mức lỗi trở lên, bạn có thể nhập:

Thao tác này sẽ hiển thị cho bạn tất cả các thông báo được đánh dấu là lỗi, quan trọng, cảnh báo hoặc khẩn cấp. Tạp chí thực hiện tiêu chuẩn syslog mức độ tin nhắn. Bạn có thể sử dụng tên ưu tiên hoặc giá trị số tương ứng của nó. Theo thứ tự ưu tiên cao nhất đến thấp nhất, đó là:

• 0 :nổi lên
• 1 :cảnh báo
• 2 :chí mạng
• 3 :ờ
• 4 :cảnh báo
• 5 :thông báo
• 6 :thông tin
• 7 :gỡ lỗi

Các số hoặc tên trên có thể được sử dụng thay thế cho nhau bằng -p tùy chọn. Việc chọn mức độ ưu tiên sẽ hiển thị các thông báo được đánh dấu ở cấp độ được chỉ định và các cấp độ cao hơn mức đó.

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

Ở trên, chúng tôi đã trình bày lựa chọn mục nhập thông qua lọc. Tuy nhiên, có nhiều cách khác để chúng ta có thể sửa đổi đầu ra. Chúng ta có thể điều chỉnh journalctl hiển thị để phù hợp với nhiều nhu cầu khác nhau.

Cách kiểm soát độ dài và định dạng đầu ra trong journalctl

Chúng ta 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 nhỏ hoặc mở rộng đầu ra.

Theo mặc định, journalctl sẽ hiển thị toàn bộ mục nhập trong máy nhắn tin, cho phép các mục nhập ở bên phải màn hình. Thông tin này có thể được truy cập bằng cách nhấn phím mũi tên phải.

Nếu bạn muốn cắt ngắn đầu ra, chèn dấu chấm lửng vào nơi thông tin đã bị xóa, bạn có thể sử dụng --no-full tùy chọn:

. . .
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

Bạn cũng có thể đi theo hướng ngược lại với điều này và nói với journalctl để hiển thị tất cả thông tin của nó, bất kể nó có bao gồm các ký tự không thể in được hay không. Chúng ta có thể làm điều này với -a cờ:

Cách tắt Trình nhắn tin trong journalctl Đầu ra

Theo mặc định, journalctl hiển thị đầu ra trong một máy nhắn tin để sử dụng dễ dàng hơn. Tuy nhiên, nếu bạn dự định xử lý dữ liệu bằng các công cụ thao tác văn bản, bạn có thể muốn xuất ra thành đầu ra tiêu chuẩn.

Bạn có thể làm điều này với --no-pager tùy chọn:

Điều này có thể được chuyển ngay vào tiện ích xử lý hoặc được chuyển hướng thành một tệp trên đĩa, tùy thuộc vào nhu cầu của bạn.

Các định dạng đầu ra khác nhau trong journalctl

Nếu bạn đang xử lý các mục nhật ký, như đã đề cập ở trên, rất có thể bạn sẽ phân tích cú pháp dữ liệu dễ dàng hơn nếu nó ở định dạng dễ sử dụng hơn. May mắn thay, tạp chí có thể được hiển thị ở nhiều định dạng khác nhau nếu cần. Bạn có thể thực hiện việc này bằng cách sử dụng -o tùy chọn có bộ xác định định dạng.

Ví dụ:bạn có thể xuất các mục nhật ký dưới dạng JSON bằng cách nhập:

{ "__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 cho việc phân tích cú pháp bằng các tiện ích. Bạn có thể sử dụng json-pretty định dạng để xử lý cấu trúc dữ liệu tốt hơn trước khi chuyển nó cho người dùng 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"
}
. . .

Các định dạng sau có thể được sử dụng để hiển thị:

• mèo :Chỉ hiển thị chính trường thông báo.
• xuất :Định dạng nhị phân phù hợp để truyền hoặc sao lưu.
• json :JSON tiêu chuẩn với một mục nhập trên mỗi dòng.
• json-đẹp :JSON được định dạng để con người dễ đọc hơn
• json-sse :Đầu ra được định dạng JSON được bao bọc để làm cho sự kiện thêm do máy chủ gửi trở nên tương thích
• ngắn :syslog mặc định đầu ra kiểu
• iso ngắn :Định dạng mặc định được tăng cường để hiển thị dấu thời gian của đồng hồ treo tường ISO 8601.
• ngắn gọn :Định dạng mặc định có dấu thời gian đơn điệu.
• ngắn gọn chính xác :Định dạng mặc định với độ chính xác đến micro giây
• dài dòng :Hiển thị mọi trường tạp chí có sẵn cho mục nhập, bao gồm cả những trường thường bị ẩn nội bộ.

Các tùy chọn này cho phép bạn hiển thị các mục nhật ký ở bất kỳ định dạng nào phù hợp nhất với nhu cầu hiện tại của bạn.

Theo dõi nhật ký hệ thống trực tiếp với journalctl

journalctl lệnh bắt chước số lượng quản trị viên sử dụng tail để theo dõi hoạt động đang hoạt động hoặc gần đây. Chức năng này được tích hợp vào journalctl , cho phép bạn truy cập các tính năng này mà không cần phải chuyển sang công cụ khác.

Hiển thị các mục nhật ký gần đây với journalctl -n

Để hiển thị số lượng bản ghi đã đặt, bạn có thể sử dụng -n tùy chọn hoạt động chính xác như tail -n .

Theo mặc định, nó sẽ hiển thị 10 mục gần đây nhất:

Bạn có thể chỉ định số lượng mục bạn muốn xem bằng một số sau -n :

Theo dõi nhật ký thời gian thực với journalctl -f

Để chủ động theo dõi nhật ký khi chúng được viết, bạn có thể sử dụng -f cờ. Một lần nữa, điều này hoạt động như bạn mong đợi nếu bạn có kinh nghiệm sử dụng tail -f :

Để thoát lệnh này, gõ CTRL+C .

Cách quản lý và dọn dẹp nhật ký nhật ký hệ thống

Bạn có thể thắc mắc về chi phí lưu trữ tất cả dữ liệu mà chúng tôi đã thấy cho đến nay. Hơn nữa, bạn có thể thấy thú vị khi dọn dẹp một số nhật ký cũ hơn và giải phóng dung lượng.

Kiểm tra mức sử dụng đĩa của nhật ký systemd bằng journalctl --disk-usage

Bạn có thể tìm hiểu dung lượng mà tạp chí hiện đang chiếm trên đĩa bằng cách sử dụng --disk-usage cờ:

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

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

Nếu bạn muốn thu nhỏ nhật ký của mình, bạn có thể thực hiện điều đó theo hai cách khác nhau (có sẵn với systemd phiên bản 218 trở lên).

Nếu bạn sử dụng --vacuum-size tùy chọn, bạn có thể thu nhỏ nhật ký của mình bằng cách chỉ ra kích thước. Thao tác này sẽ xóa các mục nhập cũ cho đến khi tổng dung lượng nhật ký chiếm trên đĩa đạt kích thước được yêu cầu:

Một cách khác mà bạn có thể thu nhỏ nhật ký là cung cấp thời gian giới hạn với --vacuum-time tùy chọn. Bất kỳ mục nào vượt quá thời gian đó sẽ bị xóa. Điều này cho phép bạn giữ lại các mục đã được tạo sau một thời gian cụ thể.

Ví dụ:để giữ các mục từ năm ngoái, bạn có thể nhập:

Định cấu hình giới hạn dung lượng ổ đĩa cho nhật ký nhật ký

Bạn có thể định cấu hình máy chủ của mình để đặt giới hạn về dung lượng mà nhật ký có thể chiếm. Điều này có thể được thực hiện bằng cách chỉnh sửa /etc/systemd/journald.conf tập tin.

Các mục sau đây có thể được sử dụng để hạn chế sự phát triển của tạp chí:

• SystemMaxUse= :Chỉ định dung lượng ổ đĩa tối đa mà tạp chí có thể sử dụng trong bộ lưu trữ liên tục.
• SystemKeepFree= :Chỉ định lượng không gian mà nhật ký sẽ để trống khi thêm các mục nhật ký vào bộ lưu trữ liên tục.
• SystemMaxFileSize= :Kiểm soát mức độ lớn mà các tệp nhật ký riêng lẻ có thể tăng lên trong bộ lưu trữ liên tục trước khi được xoay.
• RuntimeMaxUse= :Chỉ định dung lượng ổ đĩa tối đa có thể được sử dụng trong bộ lưu trữ dễ thay đổi (trong /run hệ thống tập tin).
• RuntimeKeepFree= :Chỉ định lượng không gian được dành cho các mục đích sử dụng khác khi ghi dữ liệu vào bộ lưu trữ dễ thay đổi (trong /run hệ thống tập tin).
• RuntimeMaxFileSize= :Chỉ định dung lượng mà một tệp nhật ký riêng lẻ có thể chiếm trong bộ nhớ dễ thay đổi (trong /run hệ thống tập tin) trước khi được xoay.

Bằng cách đặt các giá trị này, bạn có thể kiểm soát cách thức journald tiêu thụ và bảo toàn không gian trên máy chủ của bạn. Hãy nhớ rằng SystemMaxFileSize và RuntimeMaxFileSize sẽ nhắm mục tiêu các tập tin lưu trữ để đạt đến giới hạn đã nêu. Điều quan trọng cần nhớ là khi diễn giải số lượng tệp sau thao tác hút bụi.

Khắc phục sự cố thường gặp journalctl và các tạp chí systemd

1. Tại sao là journalctl Không hiển thị nhật ký?

Trong một số trường hợp, bạn có thể chạy journalctl lệnh mong đợi để xem đầu ra nhật ký nhưng lại gặp phải một màn hình trống hoặc không có kết quả có ý nghĩa. Tình huống này có thể gây nhầm lẫn, đặc biệt nếu bạn đang khắc phục sự cố hoặc đang tìm kiếm hoạt động gần đây của hệ thống. May mắn thay, có một số cách giải thích phổ biến giúp làm sáng tỏ lý do tại sao journalctl không hiển thị nhật ký.

Cơ sở dữ liệu tạp chí trống hoặc bị thiếu

Một trong những lý do đơn giản nhất khiến không thấy kết quả đầu ra là nhật ký trống. Điều này có thể xảy ra trên các hệ thống mới được cài đặt, môi trường vùng chứa tối thiểu hoặc máy chủ mà việc ghi nhật ký hệ thống chưa tạo ra bất kỳ mục nhập nào. Cũng có thể hệ thống của bạn được định cấu hình để chỉ lưu trữ nhật ký trong bộ nhớ (bộ lưu trữ khả biến), nghĩa là tất cả nhật ký sẽ bị xóa khi khởi động lại. Để kiểm tra xem tính năng ghi nhật ký liên tục có được bật hay không, bạn có thể tìm kiếm sự hiện diện của journal thư mục:

ls /var/log/journal

Nếu thư mục này không tồn tại hoặc nếu nó trống, điều đó có nghĩa là nhật ký của bạn không được lưu giữa các lần khởi động. Bạn có thể giải quyết vấn đề này bằng cách tạo thư mục và khởi động lại journald dịch vụ:

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

Sau khi bật tính năng ghi nhật ký liên tục, nhật ký trong tương lai sẽ được ghi vào đĩa và được giữ lại trong suốt quá trình khởi động lại.

Dịch vụ ghi nhật ký có thể không chạy

Một khả năng khác là bản thân dịch vụ ghi nhật ký đã gặp lỗi hoặc không khởi động được. systemd-journald service chịu trách nhiệm thu thập và quản lý dữ liệu nhật ký. Nếu nó không chạy, nhật ký đương nhiên sẽ trống. Bạn có thể kiểm tra trạng thái của nó bằng:

systemctl status systemd-journald

Nếu dịch vụ không hoạt động hoặc bị lỗi thì việc khởi động lại dịch vụ sẽ khôi phục chức năng thu thập nhật ký.

Bộ lọc có thể quá hẹp

Đôi khi, vấn đề không nằm ở bản thân nhật ký mà nằm ở cách bạn đang cố truy cập chúng. Việc sử dụng các bộ lọc hẹp, chẳng hạn như tên đơn vị không tồn tại hoặc phạm vi thời gian quá cụ thể, có thể không trả về kết quả nào ngay cả khi có dữ liệu liên quan. Việc chạy journalctl thường rất hữu ích không có bất kỳ cờ nào để xác nhận rằng nhật ký đang được thu thập và sau đó áp dụng dần dần các bộ lọc nếu cần.

Nhật ký có thể đã bị xoay hoặc xóa

Cuối cùng, hãy nhớ rằng nhật ký nhật ký phải tuân theo các chính sách lưu giữ dựa trên thời gian và kích thước. Nếu nhật ký cũ đã được hút bụi trước systemd-journald , chúng sẽ không thể truy cập được nữa. Bạn có thể kiểm tra xem tạp chí hiện đang sử dụng bao nhiêu dung lượng với:

journalctl --disk-usage

Nếu bạn đã định cấu hình hệ thống của mình để hạn chế mạnh mẽ kích thước tạp chí hoặc nếu gần đây bạn chạy lệnh chân không theo cách thủ công thì nhật ký có thể đã bị xóa khỏi cơ sở dữ liệu.

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

Nếu bạn cố chạy journalctl với tư cách là người dùng thông thường và nhận được thông báo “quyền bị từ chối”, bạn không đơn độc. Theo mặc định, quyền truy cập vào nhật ký hệ thống bị hạn chế ở root người dùng và thành viên của systemd-journal nhóm. Hạn chế này được thiết kế để bảo vệ dữ liệu nhật ký có khả năng nhạy cảm, có thể chứa thông tin về hoạt động của người dùng, quy trình hệ thống và lỗi dịch vụ.

Đang chạy journalctl với đặc quyền nâng cao

Giải pháp đơn giản và phổ biến nhất là chạy lệnh với sudo . Điều này nâng cao đặc quyền của bạn trong suốt thời gian thực hiện lệnh và cho phép bạn xem tất cả nhật ký hệ thống:

sudo journalctl

Nếu bạn đang viết kịch bản hoặc thường xuyên kiểm tra nhật ký, hãy nhập sudo lúc nào cũng có thể trở nên tẻ nhạt. Trong những trường hợp như vậy, việc cấp quyền truy cập vĩnh viễn cho người dùng của bạn vào tạp chí có thể sẽ thực tế hơn.

Cấp quyền truy cập cho người dùng của bạn thông qua tư cách thành viên nhóm

Để tránh cần sudo , bạn có thể thêm người dùng của mình vào systemd-journal nhóm. Nhóm này được thiết kế đặc biệt để cho phép người dùng không phải root có thể đọc nhật ký tạp chí. Bạn có thể thêm người dùng của mình vào nhóm bằng lệnh sau:

sudo usermod -aG systemd-journal yourusername

Đảm bảo thay thế yourusername với tên đăng nhập thực tế của bạn. Sau khi thêm người dùng vào nhóm, bạn phải đăng xuất và đăng nhập lại để thay đổi có hiệu lực. Khi đã xong, bạn sẽ có thể chạy journalctl mà không cần đặc quyền nâng cao.

Xác minh quyền của tạp chí

Nếu tư cách thành viên nhóm không giải quyết được vấn đề thì có thể có vấn đề với quyền truy cập tệp hoặc thư mục. /var/log/journal thư mục phải thuộc quyền sở hữu của root và được nhóm theo systemd-journal . Quyền đọc nhóm phải được đặt chính xác, nếu không quyền truy cập sẽ vẫn bị từ chối ngay cả khi bạn thuộc đúng nhóm. Bạn có thể khắc phục điều này bằng:

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

Với các quyền này và tư cách thành viên nhóm phù hợp, người dùng không phải root có thể truy cập nhật ký một cách an toàn.

3. Nhật ký không tồn tại sau khi khởi động lại

Nếu bạn nhận thấy nhật ký biến mất mỗi khi máy chủ khởi động lại thì hệ thống của bạn có thể được định cấu hình để lưu trữ nhật ký trong chỉ bộ nhớ dễ thay đổi , bị mất khi máy tắt nguồn. Đây là một mặc định phổ biến trong nhiều bản phân phối và môi trường vùng chứa Linux, đặc biệt là những môi trường được tối ưu hóa để sử dụng ít ổ đĩa.

Bật tính năng ghi nhật ký liên tục

Để giữ lại nhật ký trong các lần khởi động lại, bạn cần định cấu hình tạp chí để sử dụng bộ nhớ liên tục. Điều này đòi hỏi phải tạo thư mục thích hợp để tạp chí có thể ghi nhật ký vào đĩa. Con đường /var/log/journal được sử dụng cho mục đích này. Nếu nó không tồn tại, hãy tạo nó 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

Sau khi hoàn tất, tất cả nhật ký trong tương lai sẽ được ghi vào đĩa và tồn tại khi khởi động lại hệ thống.

Xác minh cấu hình nhật ký

Nếu thư mục tồn tại nhưng nhật ký vẫn không tồn tại thì bạn nên kiểm tra journald tập tin cấu hình:

sudo nano /etc/systemd/journald.conf

Trong tệp này, hãy tìm Storage= chỉ thị theo [Journal] phần. Nếu nó được đặt thành volatile , đổi thành persistent :

[Journal]
Storage=persistent

Lưu tệp và khởi động lại dịch vụ để áp dụng các thay đổi. Điều này đảm bảo kể từ bây giờ hệ thống sẽ ghi nhật ký vào đĩa thay vì RAM.

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

Khi dịch vụ do systemd quản lý không khởi động được hoặc gặp sự cố bất ngờ, journalctl trở thành một công cụ thiết yếu để xác định nguyên nhân gốc rễ. Instead of searching through multiple log files, the journal collects all messages related to a service in one place, complete with metadata, timestamps, and priority levels.

Reviewing the Service Status

The first step when troubleshooting is to examine the service status. The systemctl status command provides a snapshot of the service’s current state, including the most recent log entries. Ví dụ:

systemctl status nginx.service

This output often reveals immediate issues such as misconfigured paths, permission problems, or exit codes. The exit code and signal information, if present, can be especially helpful for determining whether the service failed on its own or was killed by the system.

Viewing the Full Log History

To see all logs related to the failed service, use journalctl with the -u flag:

journalctl -u nginx.service

This provides a chronological view of messages generated by the service. If you’re trying to diagnose a failure that happened during the last system boot, it’s helpful to limit the output to just that session:

journalctl -u nginx.service -b

Investigating Failure Context

You can often get to the heart of the issue by reading the log entries from a few minutes before and after the failure. Use time-based filters to narrow your focus:

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

This can help identify whether the problem was isolated or part of a larger system issue.

For deeper analysis, you can enable verbose output or view extended error messages using:

journalctl -xe

This command highlights priority messages and recent failures, which can be useful when a service doesn’t leave obvious clues in the standard output.

5. Monitoring SSH Login Attempts

SSH is a primary access method for most Linux servers, which also makes it a common vector for brute-force attacks, unauthorized access attempts, or general auditing. Fortunately, journalctl allows you to monitor all SSH-related activity with ease.

Viewing SSH Logs

Systemd tracks SSH activity under the sshd or ssh unit, depending on your distribution. To see all entries related to SSH:

journalctl -u ssh.service

or, on some systems:

journalctl -u sshd.service

These logs include login attempts, authentication failures, session closures, and key negotiation messages. It’s an excellent first step when verifying who accessed the server and when.

Following SSH Activity in Real Time

For real-time monitoring, you can use journalctl in follow mode. This is especially useful if you suspect an intrusion or want to keep an eye on active login attempts:

journalctl -f -u ssh.service

Each new login event will be printed live as it happens, making it easier to spot failed logins or rapid connection attempts that may indicate malicious behavior.

Filtering by Login Events

If you’re looking for specific login messages, such as failed passwords or accepted connections, you can filter the journal output using keyword matches:

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

These messages indicate whether a login was successful and which user attempted it. You can combine these with time filters to narrow the search to a specific window:

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

This can be extremely helpful during security audits or forensic investigations.

Frequently Asked Questions (FAQs)

1. Why does journalctl require root access?

By default, journalctl requires root access because it can expose sensitive information collected from system services, kernel messages, user sessions, and background daemons. These logs may include usernames, environment variables, error traces, authentication attempts, and other details that could pose a security risk if accessed by unauthorized users.

To safeguard this data, systemd restricts access to the system journal. However, you don’t always need to use sudo . Non-root users can read logs if they are part of the systemd-journal group. You can add your user to this group with:

sudo usermod -aG systemd-journal yourusername

After logging out and back in, you should be able to access logs without elevated privileges, as long as file permissions on the journal directories are properly configured.

2. How do I make logs persistent across reboots?

To preserve logs after a reboot, you need to configure systemd-journald to use persistent storage rather than volatile memory. By default, some distributions store logs in /run/log/journal , a temporary directory cleared at shutdown. To enable persistent logging:

1. Create the persistent journal directory:

   sudo mkdir -p /var/log/journal
   

2. Set permissions if needed:

   sudo systemd-tmpfiles --create --prefix /var/log/journal
   

3. Restart the journal daemon:

   sudo systemctl restart systemd-journald
   

4. Optional:Verify or edit configuration:

   Open /etc/systemd/journald.conf and ensure the following line is set:

   Storage=persistent
   

This configuration ensures your system retains log data across reboots, making it easier to audit and debug historical issues.

3. Can I clear journalctl logs?

Yes, journalctl allows you to clear logs using the --vacuum-* options provided by systemd-journald . These commands help reduce disk usage by deleting old or excess log data.

Here are common methods to clear or shrink journal logs:

• Remove logs older than a specific time:

  sudo journalctl --vacuum-time=2weeks
  

• Limit total disk usage for all logs:

  sudo journalctl --vacuum-size=500M
  

• Restrict the number of journal files kept:

  sudo journalctl --vacuum-files=10
  

These commands do not erase current or recent logs unless they exceed the defined threshold. To fully remove all logs, you can manually delete the journal files from /var/log/journal , but this is rarely necessary and not generally recommended for production systems.

4. How do I access systemd logs?

You can access systemd logs using the journalctl command, which interfaces directly with the systemd journal. All logs related to services managed by systemd, such as boot messages, unit failures, and runtime errors, are stored in the journal.

For general access:

journalctl

To see logs for a specific systemd service, such as nginx , use:

journalctl -u nginx.service

You can also filter by boot session, priority level, time range, or combine multiple services to gain deeper insight. Unlike traditional log files, journalctl provides a unified, indexed view of log messages from multiple sources.

5. Which command is used to view systemd logs?

The primary command used to view systemd logs is:

journalctl

This tool is included with systemd and provides access to all logs collected by the systemd-journald service, including kernel messages, early boot logs, system services, and user sessions.

You can tailor the command with various options:

• View logs for a specific service:

  journalctl -u ssh.service
  

• Filter logs by priority:

  journalctl -p err
  

• Display logs in real time:

  journalctl -f
  

This makes journalctl the most versatile and comprehensive utility for viewing systemd-related logs.

6. How to see kernel logs through journalctl ?

Kernel messages, such as those traditionally viewed using dmesg , are also available through the systemd journal. To display only kernel messages using journalctl , use the -k flag:

journalctl -k

This command filters the output to include only messages originating from the kernel. It is especially useful for diagnosing hardware issues, kernel module problems, or boot-time errors. You can also use the -b option to show messages from the current or previous boot:

journalctl -k -b -1

This gives you consistent access to kernel logs, integrated with logs from other services for better contextual understanding.

7. What is the difference between dmesg and journalctl ?

While both dmesg and journalctl can show kernel logs, they serve different purposes and operate under different mechanisms.

In short, dmesg is limited to low-level kernel logs in real time, while journalctl offers a more complete, structured, and persistent logging interface that encompasses the entire system.

Kết luận

As you can see, the systemd journal is incredibly useful for collecting and managing your system and application data. Most of the flexibility comes from the extensive metadata automatically recorded and the centralized nature of the log.

In this guide, we covered basic log viewing, time-based and field-based filtering, monitoring kernel and service logs, output formatting, and real-time log tracking. We also discussed journal maintenance, storage limits, and troubleshooting common issues like missing logs or permission errors.

The journalctl command makes it easy to take advantage of the advanced features of the journal and to do extensive analysis and relational debugging of different application components. By mastering journalctl, you gain a versatile, unified logging interface for debugging, monitoring, and auditing across your entire system.

For more detailed insight into logging and troubleshooting on Linux systems, explore the following related tutorials:

• How To Troubleshoot Common Apache Errors
• How To Centralize Logs With Journald on Debian 10
• How To Centralize Logs With Journald on Ubuntu 20.04

Tác phẩm này được cấp phép theo Giấy phép quốc tế Creative Commons Ghi công-NonCommercial-ShareAlike 4.0.