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

前書き

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

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

一般的なアイデア

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

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

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

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

システム時刻の設定

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

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

最初に、 `+ list-timezones`オプションで利用可能なタイムゾーンを確認します:

timedatectl list-timezones

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

sudo timedatectl set-timezone

マシンが正しい時刻を使用していることを確認するには、 `+ timedatectl `コマンドを単独で使用するか、 ` status +`オプションを使用します。 表示は同じです:

timedatectl status
 Universal time: Thu 2015-02-05 19:08:06 UTC
       RTC time: Thu 2015-02-05 19:08:06
      Time zone: America/New_York (EST, -0500)
    NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
     DST active: n/a

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

基本的なログ表示

`+ journald `デーモンが収集したログを表示するには、 ` journalctl +`コマンドを使用します。

単独で使用する場合、システム内にあるすべてのジャーナルエントリは、ページャー(通常は「+ less +」)内に表示され、閲覧できます。 最も古いエントリが上になります:

journalctl
-- 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 --utc

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

このような大量のデータにアクセスできることは確かに有用ですが、そのような大量の情報は、精神的に検査および処理することが困難または不可能な場合があります。 このため、 `+ journalctl +`の最も重要な機能の1つはフィルタリングオプションです。

現在のブートからのログの表示

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

journalctl -b

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

この機能を使用せず、1日以上のブートを表示している場合、システムがダウンしたときに `+ journalctl +`が次のような行を挿入していることがわかります。

. . .

-- Reboot --

. . .

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

過去のブーツ

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

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

sudo mkdir -p /var/log/journal

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

sudo nano /etc/systemd/journald.conf

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

/etc/systemd/journald.conf

. . .
[Journal]
Storage=

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

journalctl --list-boots
-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番目の列の情報を使用できます。

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

journalctl -b -1

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

journalctl -b caf0524a1d394ce0bdbcff75b94444fe

時間枠

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

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

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

YYYY-MM-DD HH:MM:SS

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

journalctl --since "2015-01-10 17:15:00"

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

journalctl --since "2015-01-10" --until "2015-01-11 03:00"

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

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

journalctl --since yesterday

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

journalctl --since 09:00 --until "1 hour ago"

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

メッセージインタレストによるフィルタリング

上記で、時間の制約を使用してジャーナルデータをフィルタリングする方法をいくつか学びました。 このセクションでは、関心のあるサービスまたはコンポーネントに基づいてフィルタリングする方法について説明します。 `+ 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

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

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

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

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

journalctl _PID=8088

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

id -u www-data
33

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

journalctl _UID= --since today

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

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

man systemd.journal-fields

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

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

journalctl -F _GID
32
99
102
133
81
84
100
0
124
87

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

コンポーネントパス別

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

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

journalctl /usr/bin/bash

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

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

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

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

journalctl -k

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

journalctl -k -b -5

優先順

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

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

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

journalctl -p err -b

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

  • 0:出現

  • 1:アラート

  • 2:クリティカル

  • 3:エラー

  • 4:警告

  • 5:通知

  • 6:情報

  • 7:デバッグ

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

ジャーナル表示の変更

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

出力の切り捨てまたは展開

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

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

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

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

標準出力への出力

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

`+-no-pager +`オプションでこれを行うことができます:

journalctl --no-pager

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

出力フォーマット

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

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

journalctl -b -u nginx -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コンシューマーに渡す前にデータ構造をより適切に処理できます。

journalctl -b -u nginx -o json-pretty
{
   "__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"
}

. . .

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

  • * cat *:メッセージフィールド自体のみを表示します。

  • * export *:転送またはバックアップに適したバイナリ形式。

  • * json *:行ごとに1つのエントリを持つ標準JSON。

  • * json-pretty *:人間が読みやすいようにフォーマットされたJSON

  • * json-sse *:追加されたサーバー送信イベントに互換性を持たせるためにラップされたJSON形式の出力

  • * short *:デフォルトの `+ syslog +`スタイルの出力

  • * short-iso *:ISO 8601ウォールクロックタイムスタンプを表示するように拡張されたデフォルト形式。

  • * short-monotonic *:単調なタイムスタンプを持つデフォルトの形式。

  • * short-precise *:マイクロ秒精度のデフォルト形式

  • * verbose *:通常内部的に隠されているものも含めて、エントリに利用可能なすべてのジャーナルフィールドを表示します。

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

アクティブプロセス監視

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

最近のログを表示する

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

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

journalctl -n

表示するエントリの数は、「+-n +」の後に数字で指定できます。

journalctl -n 20

フォローログ

書き込まれているログを積極的に追跡するには、 `+ -f `フラグを使用できます。 繰り返しになりますが、これは、 ` tail -f +`の使用経験がある場合に予想されるとおりに機能します。

journalctl -f

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

これまでに見てきたすべてのデータを保存するのに費用がかかるのではないかと思われるかもしれません。 さらに、いくつかの古いログをクリーンアップしてスペースを解放することに興味があるかもしれません。

現在のディスク使用量を見つける

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

journalctl --disk-usage
Journals take up 8.0M on disk.

古いログの削除

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

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

sudo journalctl --vacuum-size=1G

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

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

sudo journalctl --vacuum-time=1years

ジャーナル拡張の制限

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

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

  • * + SystemMaxUse = + *:永続ストレージのジャーナルが使用できる最大ディスク容量を指定します。

  • * + SystemKeepFree = + *:ジャーナルエントリを永続ストレージに追加するときに、ジャーナルが解放する必要があるスペースの量を指定します。

  • * + SystemMaxFileSize = + *:個々のジャーナルファイルがローテーションされる前に永続ストレージでどれだけ大きくなるかを制御します。

  • * + RuntimeMaxUse = + *:( `+ / run +`ファイルシステム内の)揮発性ストレージで使用できる最大ディスク容量を指定します。

  • * + RuntimeKeepFree = + *:( `+ / run +`ファイルシステム内で)揮発性ストレージにデータを書き込むときに他の用途のために確保するスペースの量を指定します。

  • * + RuntimeMaxFileSize = + *:個々のジャーナルファイルがローテーションされる前に( `+ / run +`ファイルシステム内の)揮発性ストレージで占有できるスペースの量を指定します。

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

結論

ご覧のとおり、「+ systemd 」ジャーナルは、システムとアプリケーションのデータを収集および管理するのに非常に役立ちます。 柔軟性の大部分は、自動的に記録される広範なメタデータとログの集中化された性質に由来します。 ` journalctl +`コマンドを使用すると、ジャーナルの高度な機能を簡単に活用でき、さまざまなアプリケーションコンポーネントの広範な分析とリレーショナルデバッグを実行できます。