systemd ログをマスターする:Linux でのjournalctlの使用に関する完全ガイド

systemd ジャーナルとjournalctl ログの概要

systemd の最も魅力的な利点のいくつか プロセスとシステムのロギングに関係するものです。他のツールを使用する場合、ログは通常、システム全体に分散され、さまざまなデーモンやプロセスによって処理され、複数のアプリケーションにまたがる場合、解釈がかなり困難になる可能性があります。 systemd は、すべてのカーネルおよびユーザーランドのプロセスをログに記録するための集中管理ソリューションを提供することで、これらの問題に対処しようとしています。これらのログを収集および管理するシステムはジャーナルと呼ばれます。 .

ジャーナルは journald で実装されています カーネル、initrd、サービスなどによって生成されるすべてのメッセージを処理するデーモン。このガイドでは、journalctl の使用方法について説明します。 ユーティリティ。ジャーナル内に保持されているデータにアクセスして操作するために使用できます。

この記事では、journalctl の使用方法を学習します。 systemd ジャーナルのログ データにアクセスしてフィルタリングするためのコマンドライン ツール。特定のブートまたは時間範囲からのログを表示する方法、システム単位、ユーザー、または優先度レベルでフィルタリングする方法、および他のツールと統合するために JSON などの形式でログを出力する方法について説明します。また、リアルタイム イベントの監視、ディスク使用量の管理、永続的なログの構成、ログの欠落や権限エラーなどの一般的な問題の解決方法についても学習します。障害が発生したサービスをデバッグする場合でも、集中ログ収集を設定する場合でも、journalctl はワークフローを合理化するための柔軟性と精度を提供します。

重要なポイント

• systemd Journal は、カーネル、サービス、ユーザー アプリケーションからのメッセージを 1 つの集中化されたインデックス付きログにキャプチャする統合ロギング システムを提供します。
• journalctl コマンドを使用すると、ブート セッション、時間範囲、systemd ユニット、プロセス ID、ユーザー ID、グループ ID などでログをフィルタリングできるため、関連するイベントを簡単に特定できます。
• --since などのオプションを使用して、特定の時間枠からログを取得できます。 、--until 、または "1 hour ago" のような相対式 または "yesterday" .
• ログはプレーン テキスト、JSON、冗長モードなどのさまざまな形式で表示できるため、外部ツールとの統合や分析のための解析が容易になります。
• journalctl -f の使用 tail -f と同様に、ログ メッセージが書き込まれたときにライブで追跡できます。 これは、システム アクティビティやサービスの動作をリアルタイムで監視するのに役立ちます。
• デフォルトでは、ログはメモリに保存され、再起動時に失われる可能性があります。 /var/log/journal を作成することで永続的なログを有効にできます。 journald.conf の構成
• ジャーナルのストレージ フットプリントは、--disk-usage のようなコマンドで管理できます。 、--vacuum-size 、および --vacuum-time 、最大サイズと保存期間を制御する構成オプションも含まれます。
• journalctl ブートとユニット全体のログを集約することでサービスのデバッグを簡素化し、障害の特定、SSH アクセスの追跡、詳細なコンテキストによる問題の調査が容易になります。

systemd ジャーナルの仕組みとそれが重要な理由

systemd の背後にある推進力の 1 つ ジャーナルは、メッセージの発信元に関係なく、ログを一元管理することを目的としています。ブート プロセスとサービス管理の多くは systemd によって処理されるため、 プロセスを考慮すると、ログの収集方法とアクセス方法を標準化することは理にかなっています。 journald デーモンは、利用可能なすべてのソースからデータを収集し、簡単かつ動的に操作できるようにバイナリ形式で保存します。

これにより、多くの重要な利点が得られます。単一のユーティリティを使用してデータを操作することにより、管理者はニーズに応じてログ データを動的に表示できます。これは、3 回前のブートからのブート データを表示したり、2 つの関連サービスからのログ エントリを順番に組み合わせて通信の問題をデバッグしたりするのと同じくらい簡単です。

ログ データをバイナリ形式で保存するということは、その時点での必要に応じてデータを任意の出力形式で表示できることも意味します。たとえば、毎日のログ管理では、標準の syslog でログを表示することに慣れているかもしれません。 形式ですが、後でサービスの中断をグラフ化する場合は、各エントリを JSON オブジェクトとして出力して、グラフ化サービスで利用できるようにすることができます。データはプレーン テキストでディスクに書き込まれないため、別のオンデマンド形式が必要な場合に変換する必要はありません。

systemd ジャーナルは既存の syslog とともに使用できます。 実装することも、syslog を置き換えることもできます。 ニーズに応じて機能をカスタマイズできます。 systemd は ジャーナルは管理者のほとんどのログ記録ニーズをカバーし、既存のログ記録メカニズムを補完することもできます。たとえば、集中管理された syslog があるとします。 複数のサーバーからのデータをコンパイルするために使用するサーバーですが、単一システム上の複数のサービスからのログを systemd でインターリーブしたい場合もあります。 日記。これらのテクノロジーを組み合わせることで、両方を実現できます。

timedatectl を使用して正しいシステム時刻を設定する方法

ログ記録にバイナリ ジャーナルを使用する利点の 1 つは、ログ レコードを UTC または現地時間で自由に表示できることです。デフォルトでは、systemd 結果は現地時間で表示されます。

このため、ジャーナルを開始する前に、タイムゾーンが正しく設定されていることを確認します。 systemd このスイートには実際には timedatectl というツールが付属しています。 これはこれに役立ちます。

まず、list-timezones で利用可能なタイムゾーンを確認してください。 オプション:

これにより、システムで利用可能なタイムゾーンがリストされます。サーバーの場所に一致するものが見つかったら、set-timezone を使用して設定できます。 オプション:

マシンが現在正しい時刻を使用していることを確認するには、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

最初の行には正しい時間が表示されるはずです。

journalctl でログを表示する方法

journald のログを確認するには デーモンが収集したため、journalctl を使用してください コマンド。

単独で使用すると、システム内のすべての仕訳入力がポケットベル (通常は less) 内に表示されます。 ) を参照してください。最も古いエントリが一番上に表示されます。

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

おそらく、スクロールするデータが何ページもあり、systemd の場合、その長さは数万行から数十万行になる可能性があります。 長い間システム上に存在しています。これは、ジャーナル データベースで利用可能なデータの量を示します。

この形式は、標準の syslog に慣れている人には馴染みのあるものです。 ロギング。ただし、実際には従来の syslog よりも多くのソースからデータを収集します。 実装では可能です。これには、初期のブート プロセス、カーネル、initrd、アプリケーションの標準エラーおよび出力からのログが含まれます。これらはすべてジャーナルで入手できます。

表示されているタイムスタンプはすべて現地時間であることがわかります。システムで現地時間が正しく設定されているため、これはすべてのログ エントリで利用可能です。すべてのログは、この新しい情報を使用して表示されます。

タイムスタンプを UTC で表示したい場合は、--utc を使用できます。 フラグ:

journalctl を使用して systemd ログを時間でフィルタリングする方法

このような大量のデータ コレクションにアクセスできることは確かに便利ですが、このような大量の情報を手動で検査して処理するのは困難または不可能な場合があります。このため、journalctl の最も重要な機能の 1 つは、 フィルタリング オプションです。

journalctl を使用して現在のブート セッションからのログを表示する

日常的に使用する最も基本的なものは、-b です。 旗。これにより、最近の再起動以降に収集されたすべてのジャーナル エントリが表示されます。

これは、現在の環境に関連する情報を特定して管理するのに役立ちます。

この機能を使用せず、複数日のブートを表示している場合は、journalctl が表示されます。 システムがダウンするたびに、次のような行が挿入されています。

. . .
-- Reboot --
. . .

これは、情報をブート セッションに論理的に分離するのに役立ちます。

journalctl を使用して以前のブートのログにアクセスする方法

通常は現在のブートの情報を表示したいと考えますが、過去のブートも役立つ場合もあります。ジャーナルには、以前の多くのブートからの情報を保存できるため、journalctl 情報を簡単に表示させることができます。

一部のディストリビューションでは、デフォルトで以前のブート情報の保存が有効になっていますが、他のディストリビューションではこの機能が無効になっています。永続的なブート情報を有効にするには、次のように入力してジャーナルを保存するディレクトリを作成します。

または、ジャーナル設定ファイルを編集することもできます。

[Journal] の下 セクションで、Storage= を設定します。 オプションを「persistent」に設定すると、永続的なロギングが有効になります。

/etc/systemd/journald.conf

. . .
[Journal]
Storage=persistent

以前のブートの保存がサーバーで有効になっている場合、journalctl には、分割の単位としてブーツを操作するのに役立ついくつかのコマンドが用意されています。 journald のブーツを確認するには 知っている場合は、--list-boots を使用してください 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

これにより、ブートごとに 1 行が表示されます。最初の列はブートのオフセットで、journalctl でブートを簡単に参照するために使用できます。 。絶対参照が必要な場合は、ブート ID が 2 列目にあります。ブート セッションが参照する時刻は、最後のほうにリストされている 2 つの時刻指定でわかります。

これらのブーツからの情報を表示するには、最初の列または 2 番目の列の情報を使用できます。

たとえば、前回のブートのジャーナルを確認するには、-1 を使用します。 -b を使用した相対ポインタ フラグ:

ブート ID を使用して、ブートからデータをコールバックすることもできます。

カスタムの日付と時刻の範囲でjournalctlログをフィルタリングする

ブートごとにログ エントリを表示することは非常に便利ですが、システムのブートとうまく調整できない時間帯を要求したい場合もよくあります。これは、稼働時間が長いサーバーを長時間実行する場合に特に当てはまります。

--since を使用して、任意の時間制限でフィルタリングできます。 および --until オプション。表示されるエントリを、それぞれ指定された時間以降または以前のエントリに制限します。

時間値はさまざまな形式で指定できます。絶対時間値の場合は、次の形式を使用する必要があります:

たとえば、次のように入力すると、2015 年 1 月 10 日の午後 5 時 15 分以降のすべてのエントリを表示できます。

上記の形式のコンポーネントを省略した場合、いくつかのデフォルトが適用されます。たとえば、日付を省略した場合は、現在の日付が想定されます。時刻要素が欠落している場合は、「00:00:00」（午前 0 時）が代入されます。秒フィールドを省略してデフォルトの「00」にすることもできます。

ジャーナルは、いくつかの相対値と名前付きショートカットも理解します。たとえば、「昨日」、「今日」、「明日」、または「今」という単語を使用できます。数値の前に「-」または「+」を追加するか、文の構成で「ago」などの単語を使用することで、相対時間を指定できます。

昨日のデータを取得するには、次のように入力します。

サービス中断が午前 9 時に始まり 1 時間前まで続いたというレポートを受け取った場合は、次のように入力できます。

ご覧のとおり、柔軟な時間枠を定義して、表示したいエントリをフィルタリングするのは比較的簡単です。

systemd ジャーナル ログをサービス、PID、またはユーザーでフィルタリングする方法

上記では、時間制約を使用して仕訳データをフィルタリングできるいくつかの方法を学びました。このセクションでは、関心のあるサービスまたはコンポーネントに基づいてフィルタリングする方法について説明します。 systemd ジャーナルでは、これを行うためのさまざまな方法を提供しています。

Systemd サービス ユニットごとのログの表示

おそらく最も便利なフィルタリング方法は、関心のある単位によるものです。-u を使用できます。 この方法でフィルタリングするオプション。

たとえば、システム上の Nginx ユニットからのすべてのログを表示するには、次のように入力します。

通常は、関心のある行を表示するために、時間でフィルタリングすることもできます。たとえば、今日のサービスの実行状況を確認するには、次のように入力します。

このタイプの焦点は、さまざまな単位の記録をインターリーブするジャーナルの機能を利用する場合に非常に役立ちます。たとえば、Nginx プロセスが動的コンテンツを処理するために PHP-FPM ユニットに接続されている場合、両方のユニットを指定することで、両方のエントリを時系列でマージできます。

これにより、個々のプロセスではなく、さまざまなプログラム間の相互作用を特定し、システムをデバッグすることがはるかに簡単になります。

PID、UID、または GID で systemd ログをフィルタリングする

一部のサービスは、作業を行うためにさまざまな子プロセスを生成します。興味のあるプロセスの正確な PID を調べている場合は、それによってフィルタリングすることもできます。

これを行うには、_PID を指定してフィルタリングできます。 フィールド。たとえば、関心のある PID が 8088 の場合、次のように入力できます。

また、特定のユーザーまたはグループから記録されたすべてのエントリを表示したい場合もあります。これは _UID で実行できます。 または _GID フィルター。たとえば、Web サーバーが www-data で実行されている場合、 ユーザーの場合は、次のように入力してユーザー ID を見つけることができます。

33

その後、返された ID を使用してジャーナル結果をフィルタリングできます。

systemd ジャーナルには、フィルタリングに使用できるフィールドが多数あります。これらの一部はログに記録されているプロセスから渡され、一部は journald によって適用されます。 ログ作成時にシステムから収集した情報を使用します。

先頭のアンダースコアは、_PID であることを示します。 フィールドは後者のタイプです。ジャーナルは、後でフィルタリングできるように、ログを記録しているプロセスの PID を自動的に記録し、インデックスを作成します。次のように入力すると、利用可能なすべての仕訳フィールドを確認できます。

このガイドでは、これらのいくつかについて説明します。ただし、ここでは、これらのフィールドによるフィルタリングに関連するもう 1 つの便利なオプションについて説明します。 -F オプションを使用すると、特定の仕訳フィールドで使用可能な値をすべて表示できます。

たとえば、どのグループ ID を確認するには、systemd ジャーナルにエントリがある場合は、次のように入力できます。

32
99
102
133
81
84
100
0
124
87

これにより、ジャーナルに保存されているグループ ID フィールドの値がすべて表示されます。これは、フィルタの構築に役立ちます。

実行可能パスごとにログを表示する

パスの場所を指定してフィルタリングすることもできます。

パスが実行可能ファイルにつながる場合、journalctl 問題の実行可能ファイルに関連するすべてのエントリが表示されます。たとえば、bash に関連するエントリを見つけるには、 実行可能ファイルの場合は、次のように入力できます。

通常、実行可能ファイルに対してユニットが利用可能な場合、そのメソッドはよりクリーンで、より良い情報 (関連する子プロセスからのエントリなど) を提供します。ただし、これが不可能な場合もあります。

journalctl -k を使用してカーネル ログを表示する方法

カーネル メッセージ。通常は dmesg にあります。 出力はジャーナルから取得することもできます。

これらのメッセージのみを表示するには、-k を追加します。 または --dmesg コマンドにフラグを設定します:

デフォルトでは、現在のブートからのカーネル メッセージが表示されます。前述した通常のブート選択フラグを使用して、代替ブートを指定できます。たとえば、5 回前のブートからのメッセージを取得するには、次のように入力します。

journalctl -p を使用して重大度レベルでログをフィルタリングします

システム管理者がよく関心を持つフィルターの 1 つは、メッセージの優先順位です。非常に詳細なレベルで情報をログに記録すると便利なことがよくありますが、利用可能な情報を実際に消化する場合、優先度の低いログは気が散って混乱を招く可能性があります。

journalctl を使用できます。 -p を使用して、指定された優先度以上のメッセージのみを表示するには オプション。これにより、優先度の低いメッセージを除外できます。

たとえば、エラー レベル以上で記録されたエントリのみを表示するには、次のように入力します。

これにより、エラー、クリティカル、アラート、または緊急としてマークされたすべてのメッセージが表示されます。ジャーナルは標準の syslog を実装しています。 メッセージレベル。優先順位名またはそれに対応する数値のいずれかを使用できます。優先度の高いものから低いものの順に、次のとおりです。

• 0 :出現
• 1 :警告
• 2 :クリティカル
• 3 :えー
• 4 :警告
• 5 :注意
• 6 :情報
• 7 :デバッグ

上記の番号または名前は、-p と同じ意味で使用できます。 オプション。優先度を選択すると、指定したレベルとその上のレベルでマークされたメッセージが表示されます。

journalctl をカスタマイズします ログ出力表示

上記では、フィルタリングによるエントリの選択を示しました。ただし、出力を変更できる他の方法もあります。 journalctl を調整できます さまざまなニーズに合わせて表示します。

journalctl で出力の長さとフォーマットを制御する方法

journalctl の方法を調整できます。 出力を縮小または拡張するように指示してデータを表示します。

デフォルトでは、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

これで逆の方向に進み、journalctl に指示することもできます。 印刷できない文字が含まれているかどうかに関係なく、すべての情報を表示します。これは -a で行うことができます。 フラグ:

journalctl でポケットベルを無効にする方法 出力

デフォルトでは、journalctl 出力をポケットベルに表示して利用しやすくします。ただし、テキスト操作ツールを使用してデータを処理することを計画している場合は、標準出力に出力できるようにする必要があるでしょう。

--no-pager を使用してこれを行うことができます。 オプション:

これは、ニーズに応じて、処理ユーティリティに直ちにパイプすることも、ディスク上のファイルにリダイレクトすることもできます。

journalctl のさまざまな出力形式

前述のように、仕訳入力を処理する場合、データがより使いやすい形式であると、データの解析が容易になる可能性が高くなります。幸いなことに、ジャーナルは必要に応じてさまざまな形式で表示できます。 -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" }
. . .

これは、ユーティリティを使用して解析する場合に便利です。 json-pretty を使用できます。 データ構造を 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"
}
. . .

表示には次の形式を使用できます。

• 猫 :メッセージ フィールド自体のみを表示します。
• エクスポート :転送またはバックアップに適したバイナリ形式。
• json :1 行に 1 つのエントリを持つ標準 JSON。
• json-pretty :人間が読みやすいように JSON 形式でフォーマットされています
• json-sse :サーバー送信イベントの追加と互換性を持たせるためにラップされた JSON 形式の出力
• 短い :デフォルトの syslog スタイル出力
• ショート ISO :ISO 8601 ウォールクロック タイムスタンプを表示するためにデフォルトの形式が拡張されました。
• 短い単調 :単調タイムスタンプのデフォルト形式。
• 短精度 :マイクロ秒精度のデフォルト形式
• 冗長 :通常は内部的に非表示になっているものも含め、エントリで使用できるすべての仕訳フィールドを表示します。

これらのオプションを使用すると、現在のニーズに最も適した形式で仕訳入力を表示できます。

journalctl を使用してライブ systemd ログを監視する

journalctl コマンドは tail を使用する管理者の数を模倣します アクティブなアクティビティまたは最近のアクティビティを監視します。この機能は journalctl に組み込まれています により、別のツールにパイプすることなくこれらの機能にアクセスできるようになります。

journalctl -n で最近のログ エントリを表示

設定された量のレコードを表示するには、-n を使用できます。 オプション。これは tail -n とまったく同じように機能します。 .

デフォルトでは、最新の 10 件のエントリが表示されます。

-n の後の数字を使用して、表示するエントリの数を指定できます。 :

journalctl -f でリアルタイム ログを追跡する

書き込まれているログを積極的に追跡するには、-f を使用できます。 旗。 tail -f の使用経験がある場合、これも期待どおりに機能します。 :

このコマンドを終了するには、「CTRL+C」と入力します。 .

systemd ジャーナル ログを管理およびクリーンアップする方法

これまで見てきたすべてのデータを保存するコストについて疑問に思っているかもしれません。さらに、古いログをクリーンアップしてスペースを解放することも興味深いかもしれません。

journalctl --disk-usage を使用して systemd ログのディスク使用量を確認する

--disk-usage を使用すると、ジャーナルが現在ディスク上で占有しているスペースの量を確認できます。 フラグ:

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

journalctl --vacuum-size を使用して古いログを削除します および --vacuum-time

ジャーナルを縮小したい場合は、2 つの異なる方法で行うことができます (systemd で利用可能) バージョン 218 以降)。

--vacuum-size を使用する場合 オプションで、サイズを指定してジャーナルを縮小できます。これにより、ディスク上で占有される合計ジャーナル領域が要求されたサイズになるまで、古いエントリが削除されます。

ジャーナルを縮小するもう 1 つの方法は、--vacuum-time で締め切り時間を指定することです。 オプション。それを過ぎたエントリは削除されます。これにより、特定の時間が経過した後に作成されたエントリを保持できます。

たとえば、昨年のエントリを保持するには、次のように入力します。

ジャーナル ログのディスク容量制限を構成する

ジャーナルが占めることができるスペースの量に制限を設けるようにサーバーを構成できます。これは、/etc/systemd/journald.conf を編集することで実行できます。 ファイル。

次の項目を使用して、ジャーナルの増加を制限できます。

• SystemMaxUse= :永続ストレージ内のジャーナルが使用できる最大ディスク容量を指定します。
• SystemKeepFree= :永続ストレージにジャーナル エントリを追加するときにジャーナルが空けておく必要があるスペースの量を指定します。
• SystemMaxFileSize= :個々のジャーナル ファイルがローテーションされる前に永続ストレージ内でどれだけ大きくなるかを制御します。
• RuntimeMaxUse= :揮発性ストレージで使用できる最大ディスク容量を指定します (/run 内) ファイルシステム)。
• RuntimeKeepFree= :データを揮発性ストレージ (/run 内) に書き込むときに、他の用途のために確保するスペースの量を指定します。 ファイルシステム)。
• RuntimeMaxFileSize= :個々のジャーナル ファイルが揮発性ストレージ (/run 内) 内で占有できるスペースの量を指定します。 ファイルシステム) をローテーションする前に。

これらの値を設定することで、journald の動作を制御できます。 サーバー上のスペースを消費して保存します。 SystemMaxFileSize に注意してください。 と RuntimeMaxFileSize 指定された制限に達するようにアーカイブされたファイルをターゲットにします。これは、バキューム処理後のファイル数を解釈するときに覚えておくことが重要です。

一般的な journalctl のトラブルシューティング および systemd ジャーナルの問題

1.なぜ journalctl なのか ログが表示されない場合?

場合によっては、journalctl を実行することもできます。 このコマンドはログ出力の表示を期待していますが、空白の画面が表示されるか、意味のある結果が得られません。この状況は、特に問題のトラブルシューティングを行っている場合や、最近のシステム アクティビティを探している場合に混乱を招く可能性があります。幸いなことに、journalctl の理由をわかりやすく説明する一般的な説明がいくつかあります。 ログが表示されません。

ジャーナル データベースが空であるか、存在しません

出力が表示されない最も単純な理由の 1 つは、ジャーナルが空であることです。これは、新しくインストールされたシステム、最小限のコンテナ環境、またはシステム ログによってエントリがまだ生成されていないサーバーで発生する可能性があります。また、システムがメモリ (揮発性ストレージ) にのみログを保存するように構成されている可能性もあります。つまり、再起動時にすべてのログが消去されます。永続的なログが有効になっているかどうかを確認するには、journal の存在を探します。 ディレクトリ:

ls /var/log/journal

このディレクトリが存在しない場合、または空の場合は、起動と起動の間でログが保存されていないことを意味します。この問題は、ディレクトリを作成し、journald を再起動することで解決できます。 サービス:

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

永続的なログを有効にすると、今後のログはディスクに書き込まれ、再起動後も保持されます。

ログ サービスが実行されていない可能性があります

もう 1 つの可能性としては、ログ サービス自体にエラーが発生したか、開始に失敗したことが考えられます。 systemd-journald サービスはログ データの収集と管理を担当します。実行されていない場合、ジャーナルは当然空になります。次の方法でステータスを確認できます。

systemctl status systemd-journald

サービスが非アクティブであるか障害が発生している場合は、サービスを再起動するとログ収集機能が復元されます。

フィルタが狭すぎる可能性があります

場合によっては、ログ自体に問題があるのではなく、ログへのアクセス方法に問題がある場合があります。存在しないユニット名や過度に特定された時間範囲などの狭いフィルターを使用すると、関連するデータが存在する場合でも結果が返されないことがあります。多くの場合、journalctl を実行すると便利です。 ログが収集されていることを確認するためのフラグは使用せず、必要に応じてフィルタを段階的に適用します。

ログがローテーションまたは削除された可能性があります

最後に、ジャーナル ログはサイズと時間ベースの保存ポリシーの対象となることに注意してください。古いログが systemd-journald によってバキュームされた場合 、アクセスできなくなります。ジャーナルが現在使用しているスペースの量を調べるには、次のようにします。

journalctl --disk-usage

ジャーナル サイズを積極的に制限するようにシステムを構成している場合、または最近バキューム コマンドを手動で実行した場合は、ログがデータベースから削除されている可能性があります。

2. journalctl の使用時に権限が拒否されました

journalctl を実行しようとすると 通常のユーザーとして「アクセス許可が拒否されました」というメッセージを受け取ったとしても、あなたは一人ではありません。デフォルトでは、システム ログへのアクセスは root に制限されています。 systemd-journal のユーザーとメンバー グループ。この制限は、ユーザー アクティビティ、システム プロセス、サービス障害に関する情報が含まれる可能性のある機密性の高いログ データを保護するように設計されています。

journalctl を実行しています 昇格された特権付き

最も簡単で一般的な解決策は、sudo を使用してコマンドを実行することです。 。これにより、コマンドの実行中に権限が昇格され、すべてのシステム ログを表示できるようになります。

sudo journalctl

スクリプトを作成している場合、またはログを頻繁に検査している場合は、「sudo」と入力します。 毎回が面倒になる可能性があります。このような場合、ユーザーにジャーナルへのアクセスを永続的に許可する方が現実的かもしれません。

グループ メンバーシップによるユーザー アクセスの許可

sudo を必要としないようにするには 、ユーザーを systemd-journal に追加できます。 グループ。このグループは、root 以外のユーザーがジャーナル ログを読み取ることができるように特別に設計されています。次のコマンドを使用して、ユーザーをグループに追加できます。

sudo usermod -aG systemd-journal yourusername

yourusername を必ず置き換えてください。 実際のログイン名を使用します。ユーザーをグループに追加した後、ログアウトしてから再度ログインする必要があります。 変更が有効になるまで。それが完了すると、journalctl を実行できるようになります。 昇格された権限は必要ありません。

ジャーナルの権限を確認する

グループのメンバーシップによって問題が解決しない場合は、ファイルまたはディレクトリのアクセス許可に問題がある可能性があります。 /var/log/journal ディレクトリは root が所有する必要があります systemd-journal の下にグループ化されています 。グループの読み取り権限が正しく設定されている必要があります。設定されていない場合は、正しいグループに属している場合でもアクセスは拒否されます。これは次のように修正できます。

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

これらの権限と適切なグループ メンバーシップが設定されていると、root 以外のユーザーはログに安全にアクセスできます。

3.再起動後にログが保持されない

サーバーが再起動するたびにログが消える場合は、 システムが揮発性メモリのみにログを保存するように設定されている可能性があります。 、マシンの電源がオフになると失われます。これは、多くの Linux ディストリビューションとコンテナ環境、特にディスク使用率を低くするために最適化された環境で一般的なデフォルトです。

永続的なログの有効化

再起動後もログを保持するには、永続ストレージを使用するようにjournaldを構成する必要があります。これには、ジャーナルがログをディスクに書き込むことができる適切なディレクトリを作成する必要があります。パス /var/log/journal この目的に使用されます。存在しない場合は、作成してロギング デーモンを再起動します。

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

これが完了すると、今後のすべてのログはディスクに書き込まれ、システムの再起動後も存続します。

journald 構成の確認

ディレクトリは存在するがログが保持されない場合は、journald を調べる価値があります。 設定ファイル:

sudo nano /etc/systemd/journald.conf

このファイルで、Storage= を探します。 [Journal] に基づくディレクティブ セクション。 volatile に設定されている場合 、それを persistent に変更します。 :

[Journal]
Storage=persistent

ファイルを保存し、サービスを再起動して変更を適用します。これにより、システムは今後、RAM ではなくディスクにログを書き込むようになります。

4.失敗した systemd サービスのデバッグ

When a systemd-managed service fails to start or crashes unexpectedly, journalctl becomes an essential tool for identifying the root cause. 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. For example:

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.

よくある質問 (FAQ)

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 グループ。 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:

sudo mkdir -p /var/log/journal

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

sudo systemctl restart systemd-journald

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.

結論

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

この作品は、クリエイティブ コモンズ 表示 - 非営利 - 継承 4.0 国際ライセンスに基づいてライセンスされています。