Journalctlを使用したSystemdログの表示と操作

システムとプロセスロギングは、systemdの最も重要な利点の2つにすぎません。ログがシステム全体に分散し、複数のアプリケーションにまたがり、異なるプロセスやデーモンによって処理される場合、それらを解釈するのは困難な場合があります。systemdは、ジャーナルとして知られる収集媒体において、すべてのカーネルおよびユーザーランドのプロセスログを管理するための集中型ソリューションを提供します。systemdの詳細については、systemctlを使用してsystemdのサービスとユニットを管理する方法に関するチュートリアルを参照してください。ジャーナル内のサービス、initrd、カーネルなどによって生成されるすべてのメッセージは、journalデーモンによって処理されます。このガイドの目的は、journalctlを使用してジャーナルのデータにアクセスし、操作する方法を説明することです。

基本的な前提

メッセージの発生元がどこであるかにかかわらず、systemdの主な目的の1つは、それらの管理を集中化できるようにすることです。多くの起動プロセスやサービス管理の大部分がsystemdプロセスによって処理されるため、ログの収集方法やアクセス方法は標準化されるべきです。journaldは、利用可能なあらゆるソースからデータを1つの包括的なツールに収集し、バイナリ形式で保存します。これにより、データを動的かつ簡単に操作できるようになります。

このアプローチには、いくつかの重要な利点があります。すべてのデータを収集する中央の場所を持つことで、管理者は必要なデータだけを絞り込んで表示できます。例えば、3回前のシステム起動時の起動データを表示できます。また、関連するサービスからのエントリを順次ログに記録し、それらの間の通信問題をより効果的に追跡することも可能になります。

バイナリ保存のおかげで、その時のユーザーのニーズに応じて、さまざまな出力形式でデータを表示できます。例えば、日次のログは標準的なsyslog形式で表示できます。しかし、サービスの切断傾向をグラフの形式で追跡する必要がある場合は、エントリをJSONオブジェクトとして出力し、グラフ作成サービスで利用できるようにすることができます。状況に応じた要求に応じてフォーマットを変更する必要がある場合、データはバイナリであり、プレーンテキストでディスクに書き込まれないため、変換は必要ありません。

ニーズに応じて、既存のsyslogを使用してsystemdジャーナルを実装することも、その機能を置き換えることもできます。systemdは、既存のロギングメカニズムを補完することさえできます。例えば、単一システム上の複数のサービスについて、systemdジャーナルを使用して、コンパイルされたデータを単一システム上で織り交ぜることができます。

システム時刻の設定

systemdはデフォルトでローカル時刻で結果を表示します。これは、ログレコードの表示方法におけるバイナリジャーナルロギングの利点です。あるいは、UTCで表示することもできます。したがって、ジャーナルロギングを開始する前に、タイムゾーンが正しく設定されていることを確認することが重要です。これを行うために、systemdにはtimedatectlというツールが備わっています。まず、list-timezonesオプションを使用してリストを表示し、どのタイムゾーンが使用可能かを確認することから始めます：

サーバーの場所に対応するタイムゾーンが見つかったら、set-timezoneオプションを使用してタイムゾーンを設定できます：

タイムゾーンが適切に表示されていることをテストして確認するには、timedatectlコマンドを単独で実行するか、「status」を追加して実行します。

最初の行はローカル時刻を示しています。この行には、お住まいの地域の正しい時刻が表示されている必要があります。

一般的なログの表示

journalctlコマンドを使用すると、journaldデーモンが収集したログを表示できます。journalctlを使用すると、システムからのすべてのジャーナルエントリが画面ページ内に表示され、最も古いエントリが上部に表示されます。ただし、データの完全なリストは数万行の長さになります。

標準的なsyslogロギングを使用したことがある方なら、このフォーマットに見覚えがあるでしょう。しかし、syslog方式とは異なり、このデータの集約は多くのソースから行われている点に留意することが重要です。ログには、初期のブートプロセス、initrd、カーネル、およびアプリケーションの標準エラーが含まれます。

ローカル時刻が設定されたため、すべてのエントリはローカル時刻のタイムスタンプで始まり、システムに現在保存されているすべてのログで利用可能になります。この新しい情報を使用してすべてのロジックが表示されます。ただし、ローカル時刻に限定されるわけではありません。–utc フラグを使用すると、タイムスタンプをUTCで表示することもできます：

時間によるジャーナルのフィルタリング

非常に多くのデータを利用できるのは素晴らしいことですが、それを精査して理解すること、ましてや頭の中で処理することは、気の遠くなるような作業になり得ます。これを念頭に置いて、journalctl機能の最も重要な部分である「フィルタリング」に到達します。

現在の起動からのログ表示

最新の再起動からのジャーナルデータを検索する場合は、-bフラグを指定してjournalctl関数を使用できます。これにより、システムの最新の再起動からの関連するすべてのログ情報が表示されます。このコマンドを使用すると、現在の作業環境に最も関連する情報を見つけて管理できます：

個々のエントリを個別に評価しない場合、journalctlは1日以上の起動履歴を表示し、便利な「Reboot」セパレータで区切って表示します。これにより、レビューのために異なるブートセッションからの情報を論理的に分離するのに役立ちます：

過去の起動情報

現在の起動情報を表示するのが最も便利である傾向がありますが、過去の起動情報が役立つ状況もあります。Journalは過去の複数の起動情報を保存するため、journalctlを使用すれば任意の期間の情報を簡単に表示できます。

一部のディストリビューションでは過去の起動情報の保存が無効になっていますが、他のディストリビューションではデフォルトで有効になっています。永続的な起動情報を有効にするには、以下を入力してジャーナルを保存するためのディレクトリを作成します：

または、次のようにジャーナル設定ファイルを編集することもできます：

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

これが有効になると、journalctlはこれらの起動を分割単位として指定するのに役立つ特定のコマンドを利用可能にします。journaldに記録された起動を表示するには、journalctlを介して–list-bootsオプションを使用できます：

図のように、各起動は独自の行にリストされ、最初の列には古い順から最新の順に過去の起動が反映されます。より絶対的な参照が必要な場合は、2番目の列に起動IDが含まれています。その後、2つの時間仕様がリストされています。1番目または2番目の列の情報のいずれかを使用して、特定の起動からのジャーナル情報を表示できます。たとえば、相対的な起動ポインタ-1を指定して-bフラグを使用すると、最新から2番目の再起動の情報を表示できます：

同様に、2番目の列の起動IDも次のように使用できます：

時間枠

IDで起動を表示するのも一つの方法ですが、特定の起動に必ずしも一致しない過去の時間枠で以前の起動を参照できる方が便利な場合がよくあります。例えば、頻繁に再起動されない長期稼働サーバーを扱っている場合にこれが当てはまります。時間制限のフィルタリングは、任意の時間制限で行うことができます。これにより、特定の時間枠内に発生した再起動に関する情報のみが表示されます。この時間枠のパラメータは、–sinceおよび–untilオプションで指定します。時間オプションにはいくつかの形式があります。絶対時間の値の形式は次のとおりです。

したがって、2015年1月10日午後5時15分以降のすべての起動を表示したい場合は、次のコマンドを入力します。

いずれかのコンポーネントが省略された場合、組み込みのデフォルト値が使用されます。さらに、日付が省略された場合は、現在の日付がデフォルトになります。時間コンポーネントがない場合は、深夜（00:00:00）がデフォルトになります。時間コンポーネントから秒を省略した場合、その分の開始時点（00）がデフォルトになります。

ジャーナルは、「today」（今日）、「tomorrow」（明日）、「yesterday」（昨日）、「now」（現在）などの時間関連のショートカットを理解できます。「ago」（前）のような単語を、前に付加する修飾子「-」や「+」と組み合わせて使用することで、文章のようなコマンドを構築できます。

9:00に開始されたサービスの中断について通知を受け、1時間前までのジャーナルログを確認したい場合は、次のように行うことができます。

ご覧の通り、目的のエントリを表示するために柔軟な時間枠を定義することは非常に簡単です。

メッセージの関心によるフィルタリング

時間制限によるジャーナルのフィルタリングに加えて、関心のあるサービスコンポーネントに基づいてデータをフィルタリングすることもできます。Systemdはこれを行うためのいくつかの方法を提供しています。

ユニット別

ほぼ間違いなく最も便利なフィルタリングパラメータは、関心のあるユニットによるものです。ユニットでフィルタリングするには、-uオプションを利用できます。例えば、Nginxユニットに関するすべてのログを表示したい場合は、次のコマンドを入力します。

現実的には、関心のある行を表示するために、これを時間フィルタと組み合わせたいと思うでしょう。上記のサービスと、それが本日どのように動作したかを確認したい場合は、次のように行うことができます。

これは、複数のユニット、特に連携しているユニットからの記録をまとめるジャーナルの機能を利用する場合に特に便利です。動的コンテンツ処理のためにNginxプロセスがPHP-FPNユニットに接続されている場合、両方のユニットを指定することで、エントリを時系列順にマージできます。

これにより、プログラムの相互作用を把握することが非常に容易になり、個々のプロセスではなくシステム全体のデバッグが簡単になります。

グループID、プロセス、またはユーザー別

多くのサービスは、特定の作業を実行するために多数のサブプロセス（子プロセス）を起動します。特定のプロセスのIDがわかっている場合は、_PIDフィールドを指定してフィルタリングすることもできます。関心のあるPIDが8088である場合は、次のように行うことができます。

特定のグループまたは特定のユーザーからログに記録されたエントリを表示したい場合もあります。これは、_GIDおよび_UIDフィルタを使用することで実現できます。Webサーバーがユーザーwww-dataで実行されている場合、以下を実行して必要なIDを見つけることができます。

そのIDを使用して、条件に該当するジャーナルの結果を表示できます。

Systemdはフィルタリング目的で多くのフィールドを利用可能にしています。一部のフィールドはログ記録時にシステムから収集された情報に基づいてjournaldによって適用され、他のフィールドは現在ログに記録されているプロセスから渡されます。

_PIDというプレフィックスは、ログ記録時にシステムから情報が収集されたことを示します。ジャーナルは、後でフィルタリング機能を利用できるように、ログ記録プロセス中にPIDを自動的に記録し、インデックスを作成します。利用可能なジャーナルフィールドについて調べるには、次のように入力します。

これらの一部についてはこのガイドの後半で説明しますが、ここでは、これらのフィールドに関連する他の便利なオプションについて触れておきます。特定のジャーナルフィールドの利用可能なすべての値を表示したい場合は、-Fオプションを使用できます。systemdジャーナルにどのようなグループIDがあるかを確認したい場合は、次のように実行できます。

これにより、ジャーナルのグループIDフィールドに保存されている値の完全なリストが提供され、フィルターの構築に役立ちます。

コンポーネントパス別

パスの場所を指定してフィルタリングを実行することもできます。パスが実行可能ファイルへのものである場合、その実行可能ファイルに関連するjournalctlのエントリが表示されます。対象の実行可能ファイルが「bash」である場合は、次のように入力します。

不可能な場合もありますが、実行可能ファイルのユニットが利用可能な場合は、より明確で情報量の多いフィルタリング方法を生成できます。

カーネルメッセージの表示

通常はdmesgの出力にあるカーネルメッセージも、ジャーナルから取得できます。これらのメッセージのみを表示するには、コマンドの一部として-kまたは-dmesgフラグのいずれかを使用します。

デフォルトでは現在の起動時のメッセージが表示されますが、前述の選択フラグを使用して、それ以前の起動を指定することもできます。5回前の起動時のメッセージを探している場合は、次のように入力すると必要な結果が得られます。

優先度別

システム管理者は、優先度によるフィルタリングを好むことがよくあります。低優先度のログは、表示すると便利なことも多いですが、混乱を招き、多くの不要な情報が含まれているため、分析中に理解しにくくなる可能性があります。journalctlで-pオプションを使用すると、指定した優先度のメッセージのみが表示され、他の優先度は除外されます。エラーレベル以上のエントリを表示したい場合は、次のように入力します。

このコマンドは、標準のsyslogメッセージングレベルを使用するジャーナルで、error、alert、emergency、またはcriticalとして示されているすべてのメッセージを返します。優先度レベルは数値に従って定義され、最も高いものから最も低いものへとランク付けされます。

• 0: emerg
• 1: alert
• 2: crit
• 3: err
• 4: warning
• 5: notice
• 6: info
• 7: debug

上記のいずれも、-pオプションと互換的に使用できます。上記のように優先度のいずれかを選択すると、そのレベル以上のすべての優先度がフィルタリングされます。

ジャーナルでの表示の変更

エントリ選択にフィルタリングを使用する以外にも、出力を変更し、ニーズに合わせてjournalctlの表示を調整する他の方法があります。

出力の切り詰め/展開

journalctlがデータを縮小するか展開するかを調整することで、出力の表示を調整できます。journalctlのデフォルトでは、エントリ全体が表示され、長いエントリは画面の右側に流れて表示されます。右矢印キーでスクロールすることで、エントリ全体を表示できます。代わりに、画面からはみ出る行に省略記号を表示して出力を切り詰めたい場合もあります。これには、–no-fullオプションを使用できます。

あるいは、-aフラグを使用することで、長さや印刷不可能な文字が含まれているかどうかに関係なく、すべてを表示できるようにすることもできます。

標準出力への出力

Journalctlはデフォルトで出力をページャーに表示しますが、テキスト編集ツールでデータを操作したい場合は、標準出力オプションに出力させる必要があります。これは–no-pagerオプションで実現できます。

ユーザーのニーズに応じて、これをディスク上のファイルや処理ユーティリティにリダイレクトできます。

出力フォーマット

データは、より消費しやすい形式で提示された方が常に解析しやすくなります。ジャーナルは、-o修飾子の後に特定のフォーマットを指定することで、表示のための複数のオプションを提供します。

ジャーナルエントリをJSON形式で出力したい場合は、次のように行います。

この戦略は、解析ユーティリティを使用する場合に特に便利です。json-prettyフォーマットは、JSONコンシューマーに渡す前にデータ構造を表示するのに適しています。

表示に利用できるフォーマットはいくつかあります。

• cat: メッセージフィールド自体のみを表示します。
• export: 転送やバックアップに適したバイナリ形式。
• json: 1行に1エントリの標準JSON。
• json-pretty: 人間が読みやすいようにフォーマットされたJSON。
• json-sse: Server-Sent Events（SSE）に対応するようにラップされたJSON形式の出力。
• short: デフォルトのsyslogスタイルの出力。
• short-iso: ISO 8601形式のウォールクロックタイムスタンプを表示するように拡張されたデフォルトフォーマット。
• short-monotonic: モノトニックタイムスタンプ付きのデフォルトフォーマット。
• short-precise: マイクロ秒精度のデフォルトフォーマット。
• verbose: 通常は内部で非表示になっているものも含め、エントリで利用可能なすべてのジャーナルフィールドを表示します。

上記のオプションにより、ジャーナルを好みのフォーマットで表示できます。

アクティブなプロセスの監視

ジャーナルを使用すると、別のツールを使用することなく、アクティブなアクティビティや最近のアクティビティの監視機能にアクセスできます。これは、'tail'機能を持つjournalctlコマンドで行うことができます。

• 最近のログの表示

-nオプション（tail -nコマンドと同様に動作します）を表示すると、一定量のレコードを表示できます。

表示したいエントリ数は、-n修飾子の後に特定の数値を指定することで指定できます。

• ログの追跡

-fフラグを使用すると、システムに書き込まれているログをアクティブに追跡することもできます。これもtail -fコマンドと同じように動作します。

ジャーナルのメンテナンス

ログは容量を消費します。空き容量を増やすために、古いログの一部を削除することを検討する価値があります。

現在のディスク使用量の確認

–disk-usageフラグを使用すると、ログ記録が現在ディスク上で占有している容量を確認できます。

古いログの削除

systemdバージョン218（およびそれ以降のバージョン）では、2つの異なる方法でジャーナルを縮小できます。1つは–vacuum-sizeオプションです。これはサイズを指定してジャーナルを縮小できます。つまり、占有スペースが要求されたパラメータになるまで、古いエントリがログから削除されます。

–vacuum-timeオプションは、カットオフ時間を指定してジャーナルの占有スペースを縮小できます。その時間より前のエントリは削除され、指定された時間以降に作成されたエントリは保持されます。過去1年間だけのエントリを保持したい場合は、次のように使用できます。

ジャーナル拡張の制限

ジャーナルが占有する容量を制限することもできます。これは、/etc/systemd.journald.confファイルを編集することで行います。ジャーナルの増加は、次のいずれかの方法を使用して制限できます。

• SystemMaxUse=: ジャーナルが永続ストレージで使用することを許可される最大ディスク容量を示します。
• SystemKeepFree=: ジャーナルエンティティが永続ストレージに追加されるときに、空けておくべき容量を示します。
• SystemMaxFileSize=: 永続ストレージにおいて、ジャーナルファイルがローテーションされるまでに許容される最大サイズを指定します。
• RuntimeMaxUse=: 揮発性ストレージ（/run ファイルシステム内）で使用を許可するディスク容量を指定します。
• RuntimeKeepFree=: 揮発性ストレージにデータを書き込む際、他の用途のために確保しておく必要がある空き容量（/run ファイルシステム内）を指定します。
• RuntimeMaxFileSize=: 揮発性ストレージ（/run ファイルシステム内）において、個々のログジャーナルがローテーションされるまでに占有できる最大容量を指定します。

これらのオプションはすべて、ジャーナルによるストレージ消費を制御するのに役立ちます。注意すべき重要な点は、SystemMaxFileSize および RuntimeMaxFileSize オプションが、指定された制限に達するためにアーカイブされたファイルを対象とすることです。これは、バキューム処理後のファイル数を解釈する際に念頭に置いておくべき重要な事実です。

結論

systemd ジャーナルが活用すべき非常に有用なツールであることは明らかであり、そのメリットの大部分は、ログ’の集中管理された性質と、記録されるメタデータの膨大な量に起因しています。journalctl コマンドを利用することで、ジャーナルの豊富な機能を活用でき、アプリケーションコンポーネントの関連性デバッグや広範なシステム分析をより容易に行う方法が促進されます。

快適なコンピューティングを！