Linux 系統中 journalctl 指令的完整教學

如果你每天都管理 GNU/Linux 系統，遲早你會遇到以下問題： 系統日誌、服務和內核以前，你需要在文件之間來回跳轉。 /var/log但隨著…的到來 systemd 使用 systemd 管理服務 ——遊戲規則改變了：現在幾乎所有事情都是透過報紙發生的。 日誌而控制它的關鍵在於命令。 journalctl.

本指南將透過詳盡的講解和實際範例，向您展示如何使用journalctl 查詢、過濾、即時監控和清理日誌，如何限制日誌佔用的磁碟空間，以及如何利用其高級過濾器（按服務、PID、使用者、優先順序、時間、核心等篩選）。我們的目標是讓您最終獲得全面的概覽，而無需在無數不同的地方搜尋資訊。

journalctl是什麼？它在systemd中扮演什麼角色？

journalctl 是線路實用程序 命令 這允許您查看 systemd 日誌它是生態系統的一部分 systemd它是目前 Ubuntu、Debian、Fedora、CentOS/RHEL 7+、Arch 等發行版所使用的初始化系統和服務管理器。 Linux 和許多其他人。

負責收集事件的元件是守護程式 systemd-journald，它收集來自 核心、initrd、服務、systemd 單元、使用者程序和經典 syslog 訊息所有這些都儲存在一個 二進位格式 （不是純文字），這便於進行快速搜尋、進階篩選和多種輸出格式。

與傳統的分散式日誌檔案方法不同，日誌系統可作為集中式系統日誌。這使得我們可以在同一時間線上查看 Nginx 和 PHP-FPM 訊息，或將核心訊息與特定服務的訊息合併，從而排查影響應用程式的硬體問題。

二進位格式的另一個優點是，相同的資料可以根據需要匯出為不同的格式：經典的 syslog 格式、用於外部工具的 JSON 格式、備份匯出格式，或具有更精確時間戳記的格式。無需轉換文件，因為日誌內部會以結構化元資料的形式儲存事件。

systemd 日誌可以與傳統的 syslog 伺服器（例如 rsyslog、syslog-ng 等）共存，甚至可以取代它。您可以繼續透過 syslog 將日誌傳送到中央伺服器，同時使用journalctl 在本機進行偵錯，並充分利用 systemd 提供的過濾器和元資料功能。

初步檢查：時區和系統時間

由於該期刊允許顯示時間戳 當地時間或UTC正確配置時區非常重要，這樣在關聯事件時就不會出錯。這可以透過以下工具完成… timedatectl它也是 systemd 的一部分。

要列出系統上所有可用的時區，您可以執行以下命令 timedatectl list-timezones從而找到與您所在位置對應的那個。找到後，您可以使用以下命令定義它。 sudo timedatectl set-timezone ZONA/HORARIA例如 Europe/Madrid 西班牙首都。

如果您想檢查一切是否正常運行，只需運行 timedatectl status您可以在這裡看到諸如此類的數據。 本地時間、世界協調時 (UTC)、活動時區和 NTP 同步狀態. 從那裡， journalctl 預設情況下，日期將以您的本地時間顯示，這樣更容易閱讀。

首次接觸：查看所有日誌條目

最基本的使用方法是啟動 journalctl 沒有論證這樣，該命令將使用分頁器（通常為 12345）顯示期刊中所有可用的條目，從最早到最新。 less這樣你就可以繞著出口走。

在這個清單中，你會看到來自啟動過程、核心、服務、應用程式錯誤、使用者會話等等的各種訊息。如果系統已經運行了數週或數月，那麼出現數萬甚至數十萬行的消息是完全正常的，因此你首先會明白需要對它們進行過濾。

預設格式與經典的syslog非常相似：日期、主機名稱、進程、PID 和訊息。主要區別在於，雖然您看到的是文本，但其內部所有內容都使用字段和元資料進行結構化處理，您可以使用不同的過濾器稍後訪問這些資訊。

如果您希望在任何時候以 UTC 時間而不是本地時間查看日期，您可以將參數新增到命令中。 --utc所有時間戳都會相應調整，而不會影響原始內容。

按開始時間和時段篩選

journalctl最實用的功能之一是讓您可以按啟動會話或特定時間範圍篩選日誌。這對於高運行時間的伺服器，或者當您想要詳細查看特定重新啟動過程中發生的情況時，尤其有用。

僅顯示目前啟動狀態

要重點關注自上次系統重新啟動以來發生的情況，您可以使用指示器。 -b此參數表示 journalctl 這表明 僅收集從目前啟動過程中收集的條目:

命令： journalctl -b

當您不按啟動項目進行篩選，且日誌中出現多次重新啟動記錄時，日誌會插入類似如下的行： -- Reboot -- 用於標記課程之間的間隔。它們對於方向調整非常有用，但在日常實踐中，通常會將自己限制在以下範圍內： 創業進行中 調試當前問題。

查看先前的啟動記錄並啟用持久性日誌記錄

如果您想調查在以下情況下發生的問題： 之前的靴子您需要啟用系統日誌持久化功能。某些發行版預設啟用此功能；而其他發行版則需要手動啟用。 建立目錄 /var/log/journal 或點選設定。

啟用的最簡單方法 存儲 persistent 正在建立所述目錄 sudo mkdir -p /var/log/journal 或編輯 /etc/systemd/journald.conf 並在本節中確立 選項 Storage=persistent從那時起，記錄將在重啟後保留。

要列出期刊記錄的所有開局，您可以使用 journalctl --list-boots你會看到一張表格，上面 相對索引（0 代表目前會話，-1 代表上一個會話，依此類推）、唯一啟動 ID 以及每次會話的日期範圍.

如果要存取上一次啟動，可以使用相對索引，例如 journalctl -b -1或直接傳遞完整的啟動 ID，這在您需要在文件或工單中共享確切的參考資訊時非常有用： journalctl -b ID_DE_BOOT.

定義自訂時間視窗

除了情緒爆發之外， journalctl 允許以任意時間範圍進行過濾。對於頻繁重啟的伺服器來說，這一點至關重要。以下選項用於此目的： --since y --until表示開始時間，也可以選擇表示結束時間。

標準日期和時間格式為 YYYY-MM-DD HH:MM:SS不過，它的彈性很高：如果省略日期，則預設為當前日期；如果省略時間，則使用當前時間。 午夜（00:00:00）你也可以省略秒數。

典型例子如下： journalctl --since "2015-01-10 17:15:00" 顯示自該日期和時間以來發生的所有事情，或者 journalctl --since "2015-01-10" --until "2015-01-11 03:00" 精確定義一個可能與你所報告的事件相符的特定時間段。

該期刊也理解這一點。 相關關鍵字 如 yesterday, today, tomorrow o now此外，它也接受如下表達式： "1 hour ago"這樣你就可以查詢諸如以下內容： journalctl --since 09:00 --until "1 hour ago" 無需計算確切日期即可查看動態時間視窗。

按服務、流程、使用者和其他欄位篩選

掌握了時間濾波器之後，下一步是… 將日誌重點放在特定服務或元件上. 這是哪裡 journalctl 與直接查看文字檔案相比，它的功能尤其強大。

按 systemd 單元篩選

您可能最常使用單位過濾器，使用參數 -u這讓你能夠看到 僅與特定服務相關的事件例如，要查看 Nginx 的運行情況，您可以執行：

例如： journalctl -u nginx.service

通常會將其與時間濾波器結合使用，例如 journalctl -u nginx.service --since today 只查看今天發生的事情。這樣可以避免前幾天的干擾，並專注於服務最近的運作狀況。

寫日記的一大好處是你可以… 將來自多個單元的記錄交錯排列 在一個時間軸上。如果你的 Nginx 與 PHP-FPM 通信，你可以這樣做： journalctl -u nginx.service -u php-fpm.service --since today 你將擁有 兩個服務的日誌按時間順序排列這對於檢測它們之間的通訊問題非常有用。

按PID、UID和GID篩選

在產生大量子進程的服務中，或當您想要調查特定進程的行為時，按進程進行篩選非常實用。 進程 ID (PID)這是透過字段完成的。 _PID期刊會自動將其新增為元資料：

過濾器： journalctl _PID=8088

同樣地，如果你想看 由特定使用者或群組產生的所有條目您可以使用這些字段 _UID y _GID例如，如果你的 Web 伺服器運作方式為 www-data首先，使用以下命令取得其 UID： id -u www-data 然後你可以用類似這樣的方式來篩選 journalctl _UID=33 --since today.

下劃線前綴表示這些欄位是由 journald 使用系統資訊添加的，而不僅僅是進程寫入的資料。這使得無需應用程式正確格式化訊息即可進行非常精確的搜尋。

如果您對有哪些欄位有任何疑問，可以查閱手冊頁面。 systemd.journal-fields如果您想查看日誌中某個欄位的不同值，可以使用下列方法： journalctl -F NOMBRE_CAMPO例如 journalctl -F _GID 列出日誌中出現的所有 GID。

按可執行路徑篩選

另一個有趣的選項是按以下條件篩選 可執行檔的路徑如果你繼續 journalctl 以路徑作為參數，將顯示與該二進位相關的所有條目，例如：

按路線： journalctl /usr/bin/bash

通常情況下，如果存在 systemd 單元，最好使用它們，因為這樣還可以獲得子進程事件和額外的元數據，但對於沒有自己單元的程序，這種方法非常有用。

僅查看內核訊息

我們傳統上透過以下方式獲取的信息 dmesg 它們也儲存在日誌中。要篩選它們，無需進一步說明，您可以使用相關選項。 -k o --dmesg:

內核： journalctl -k

預設情況下，內核訊息會顯示出來。 目前啟動但您可以像以前一樣使用相同的啟動選擇選項，例如 journalctl -k -b -5 查看五次啟動之前的核心訊息。

按優先順序或嚴重等級篩選

當日誌中包含大量資訊時，你往往只對查看哪些內容感興趣。 錯誤、警報或嚴重故障. journalctl 允許使用選項按優先順序進行篩選 -p接受符號名稱和數值。

該期刊所採用的等級遵循標準的syslog等級劃分，從最重要到最不重要： 0：緊急，1：警報，2：嚴重，3：錯誤，4：警告，5：通知，6：訊息，7：調試如果你運行類似這樣的程序 journalctl -p err -b，你會看到 所有錯誤等級事件或更嚴重 當前開始。

你可以使用號碼或名稱，例如 journalctl -p 4 o journalctl -p warning這樣一來，該等級及所有更高優先順序的訊息將始終顯示，省去了您組合多個篩選器的麻煩。

調整記錄的顯示方式

除了篩選你想查看的條目之外， journalctl 還允許你隨時修改輸出的格式和呈現方式，以適應你的需要，無論是互動閱讀還是腳本自動處理。

縮短或顯示完整條目

預設情況下，分頁器會顯示所有日誌行，即使它們溢出到右側；您可以水平移動遊標來查看全部內容。如果您喜歡這樣 線條被截斷，末端顯示為省略號。您可以使用該選項 --no-full.

另一方面，如果你想 journalctl 顯示所有數據，不隱藏不可列印字符您可以新增參數 -a這在處理轉義字元或格式特殊的訊息時非常有用。

繞過分頁器並將資料轉儲到標準輸出

當意圖是 將日誌傳遞給其他工具（grep、awk、jq 等）。 或將它們重定向到一個檔案；預設的分頁器很煩人。要停用它，只需使用該選項即可。 --no-pager所有內容將直接透過標準輸出列印出來。

正因如此，您可以輕鬆地將命令串聯起來，例如 journalctl -u nginx --since today --no-pager | grep 500 或將日誌的特定部分轉儲到檔案中 journalctl > mensajes.log 稍後冷靜分析。

選擇輸出格式：syslog、JSON、匯出、詳細輸出…

選項 -o 允許選擇 多種輸出格式 這取決於你打算如何處理這些資訊。一些最常用的格式包括：

• 五分褲預設格式，經典的syslog風格。
• 短等離子弧與前一個相同，但帶有可讀的 ISO 8601 時間戳記。
• 短單調：新增單調時間戳，可用於查看從開始到結束的相對時間。
• 短而精確與標準版相同，但有 微秒精度.
• 貓：僅顯示訊息字段，不顯示元資料。
• JSON每行一個 JSON 輸入，非常適合與…一起使用 jq 或其他工具。
• json-pretty：JSON 格式已調整為縮進，以便於人類閱讀。
• json-sse：旨在用於伺服器發送事件（Server-Sent Events）。
• 出口：適合的二進位格式 匯出或備份日誌.
• 冗長的： 樣本 每個事件關聯的所有欄位和元數據包括囚犯。

例如，要從目前啟動過程中提取可供解析的 JSON 格式的 Nginx 日誌，您可以使用類似這樣的命令： journalctl -b -u nginx -o json或者，如果您想在將它們傳遞給另一個工具之前，先給它們一個清晰的預覽， journalctl -b -u nginx -o json-pretty.

即時查看日誌並了解最新條目

在日常行政工作中，常常會遇到這樣的情況： 密切注意那一刻發生的事情例如，在重新啟動服務、重現錯誤或啟動部署時。 journalctl 它包含與以下類似的標準功能： tail.

僅顯示最新條目

選項 -n 工作原理與 tail -n：顯示日誌中的最後 N 筆記錄。如果未指定數字，則預設顯示以下內容： 最後 10 行:

最新的： journalctl -n

如果您想更改金額，只需添加下面的數字即可，例如 journalctl -n 20 查看最新 20 筆記錄。結合其他篩選條件（依服務、優先順序等），可以快速了解特定事項的狀態。

以 tail-f 風格關注期刊的即時動態

要監控日誌 實時，就像它們正在被書寫時一樣。您可以使用該選項 -f，簡稱 遵循與……完全相同 tail -f:

監控： journalctl -f

有趣的是，你可以將它與按服務、優先順序或時間篩選的條件結合。例如，你可以只追蹤 特定服務中的錯誤 使用以下類型的命令 journalctl -u apache2 -p err -f你會看到新條目在生成時顯示出來。

磁碟空間管理：日誌大小和舊日誌的刪除

寫日記很方便，但如果放任不管，很容易就會變成… 佔用大量空間尤其是在高流量伺服器上。幸運的是， journalctl y systemd-journald 它們提供了多種控制尺寸的方法。

檢查原木佔用了多少空間

若要快速查看日誌檔案目前所佔用的磁碟空間，您可以執行：

光碟報告： journalctl --disk-usage

出口處會顯示類似這樣的資訊。 “日誌佔用磁碟空間 8.0M”清晰地顯示目前消耗量。該數字考慮了儲存和儲存兩個因素。 持續 /var/log/journal 就像揮發性物質一樣 /run 當沒有堅持性時。

按大小或時間刪除舊記錄

如果您認為日誌佔用空間過多，可以使用vacuum 參數（從 systemd 218 開始可用）以兩種主要方式減少它：按總大小或按年齡。

有選項 --vacuum-size 你建立了一個 日誌檔案集的最大大小限制. journald 它會刪除較舊的條目，直到總數達到您指定的限制，例如：

限制尺寸： sudo journalctl --vacuum-size=1G

另一種方法是使用 --vacuum-time它會刪除特定時間閾值之前的所有條目。例如，如果您只想保留 去年的日誌你可以運行：

年齡限制： sudo journalctl --vacuum-time=1years

這兩種方法可以結合使用於以下配置中： journald 因此，該系統 預防性自我管理 無需在磁碟空間不足時執行程式。

在 journald.conf 中配置永久限制

要微調期刊的成長方式，您需要編輯該文件。 /etc/systemd/journald.conf在那裡，您會找到幾個影響持久性儲存和揮發性儲存的關鍵選項。 /run:

• SystemMaxUse=限制日誌在持久性儲存中可以使用的最大磁碟空間。
• SystemKeepFree=：指示日誌在寫入持久性儲存時應為其他用途預留多少空間。
• SystemMaxFileSize=：定義持久性日誌中每個單獨檔案在輪換之前的最大大小。
• RuntimeMaxUse=：類似 SystemMaxUse 但對於易揮發性儲存而言 /run.
• RuntimeKeepFree=：等價於 SystemKeepFree 但對於波動區域而言。
• RuntimeMaxFileSize=：易失性儲存中單一日誌檔案在輪換前的最大大小。

值接受以下的後綴： K、M、G 或 T （千字節、兆字節、吉字節、太字節），所以你可以輸入類似這樣的內容： SystemMaxUse=500M 沒問題。更改設定後，請記住 重新啟動服務 類似 sudo systemctl restart systemd-journald 使更改生效。

請記住 SystemMaxFileSize y RuntimeMaxFileSize 這些是指示性數值：系統會嘗試將檔案大小調整到這些限制，但它們並不總是完全匹配，因此在解釋清理後的檔案數量時，如果某些檔案與預期數量略有不同，請不要感到驚訝。

journalctl 的其他實用用途和最佳實踐

除了上述所有之外， journalctl 提供了一些值得掌握的額外選項。 對於日常系統管理，無論是普通用戶級別還是高級用戶級別， 根 或特權群體（wheel, adm, systemd-journal).

例如，有可能 依特定使用者篩選期刊 運用 _UID正如我們所見，將時間篩選器與服務和優先順序結合起來，甚至使用選項 --grep 內建了搜尋文字字串的功能，無需借助其他工具。 grep 外部。

您也可以 直接將日誌輸出重定向到文件 就像這樣簡單的事情 journalctl > mensajes.log這對於與同事共享日誌摘錄或將其附加到報告中而無需授予伺服器存取權限非常有用。

對於管理多用戶系統的人來說，需要記住的是，預設情況下每個用戶都可以看到自己的日誌，但對系統日誌和其他用戶日誌的全域存取權限僅限於管理員，正是為了防止敏感資訊外洩。

最後，要記住的是： systemd y journalctl 它們與其他生態系統設施高度集成，例如 systemctl 列出和管理服務 o timedatectl 調整時間。利用這種整合方式，比混用新舊系統簡單得多。

憑藉這些選項、過濾器和配置，journalctl 成為監控、調試和維護任何基於 systemd 的 Linux 系統健康狀況的中心工具，使您能夠從追蹤分散的日誌轉變為對機器上發生的一切進行結構化和可管理的檢視。