Journalctlを使用してシステムログを表示および操作する方法

毎日使用する可能性のあるこれらの中で最も基本的なものは、-bフラグです。 これにより、最新の再起動以降に収集されたすべてのジャーナルエントリが表示されます。

これは、現在の環境に関連する情報を識別および管理するのに役立ちます。

この機能を使用しておらず、1日以上の起動を表示している場合は、システムがダウンするたびにjournalctlが次のような行を挿入していることがわかります。

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

通常、現在のブートからの情報を表示する必要がありますが、確かに過去のブートも役立つ場合があります。 ジャーナルは以前の多くの起動からの情報を保存できるため、journalctlで情報を簡単に表示できます。

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

または、ジャーナル構成ファイルを編集できます。

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

/etc/systemd/journald.conf

サーバーで以前のブートの保存が有効になっている場合、journalctlは、分割の単位としてブートを操作するのに役立ついくつかのコマンドを提供します。 journaldが認識しているブーツを確認するには、journalctlで--list-bootsオプションを使用します。

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

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

たとえば、前回の起動時のジャーナルを表示するには、-bフラグを指定した-1相対ポインターを使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これにより、個々のプロセスではなく、異なるプログラムとデバッグシステム間の相互作用を簡単に見つけることができます。

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

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

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

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

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

先頭の下線は、_PIDフィールドが後者のタイプであることを示します。 ジャーナルは、後でフィルタリングするためにログを記録しているプロセスのPIDを自動的に記録およびインデックス付けします。 次のように入力して、利用可能なすべての仕訳フィールドについて調べることができます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

出力を縮小または拡大するように指示することで、journalctlがデータを表示する方法を調整できます。

デフォルトでは、journalctlはページャーにエントリ全体を表示し、エントリが画面の右側に続くようにします。 この情報にアクセスするには、右矢印キーを押します。

情報が削除された場所に省略記号を挿入して出力を切り捨てたい場合は、--no-fullオプションを使用できます。

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

デフォルトでは、journalctlは、消費しやすいように出力をページャーに表示します。 ただし、テキスト操作ツールを使用してデータの処理を計画している場合は、おそらく標準出力に出力できるようにする必要があります。

これは、--no-pagerオプションを使用して実行できます。

これは、必要に応じて、すぐに処理ユーティリティにパイプするか、ディスク上のファイルにリダイレクトできます。

前述のように、仕訳入力を処理している場合、データがより使いやすい形式であれば、データを解析する時間がより簡単になる可能性が高くなります。 幸いなことに、ジャーナルは必要に応じてさまざまな形式で表示できます。 これは、フォーマット指定子を指定した-oオプションを使用して実行できます。

たとえば、次のように入力して、JSONでジャーナルエントリを出力できます。

これは、ユーティリティを使用した解析に役立ちます。 json-pretty形式を使用して、データ構造をJSONコンシューマーに渡す前に、より適切に処理することができます。

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

これらのオプションを使用すると、現在のニーズに最適な形式でジャーナルエントリを表示できます。

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

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

表示するエントリの数は、-nの後に数字を付けて指定できます。

書き込まれているログを積極的に追跡するには、-fフラグを使用できます。 繰り返しますが、これは、tail -fの使用経験がある場合に期待できるように機能します。

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

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

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

ジャーナルを縮小できるもう1つの方法は、--vacuum-timeオプションでカットオフ時間を提供することです。 それ以降のエントリはすべて削除されます。 これにより、特定の時間後に作成されたエントリを保持できます。

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

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

以下の項目を使用して、ジャーナルの成長を制限できます。

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