目次にジャンプページナビゲーションにジャンプ: 前のページ[アクセスキーp]/次のページ[アクセスキーn]
documentation.suse.com / SUSE Linux Microのシステムログの管理

SUSE Linux Microのシステムログの管理

発行日: 18/06/2025
概要

システムログファイルの分析は、システムを分析する際に最も重要なタスクの1つです。実際、システムを保守またはトラブルシューティングする際は、最初にシステムログファイルを確認する必要があります。SUSE Linux Microは、システムで発生するほぼすべての事象を自動的に詳しくログに記録します。

目的

この記事では、システムで発生した事象を、システムログを表示して調べる方法について説明します。

所要時間

この記事の理解には20分ほどを要します。

目標

ログファイルが存在する場所、およびログファイルを管理する方法の概要を把握します。

要件

  • root特権。

1 システムログファイルはどこにあるか

 

SUSE Linux Microは、カーネル、SELinux、またはその他のサービスなどからのさまざまなタイプのメッセージをログに記録します。

カーネルメッセージ、およびsystemdに登録されているシステムサービスのメッセージは、systemdジャーナルに記録されます(4項 「systemdロギングシステム - ジャーナル」を参照)。その他のシステムログファイルは、/var/logディレクトリの下層にあります。SELinuxメッセージは、/var/log/audit/audit.logに記録されます。詳細については、SELinux troubleshootingを参照してください。

以下のリストは、デフォルトインストール後にSUSE Linux Microで確認できるすべてのシステムログファイルの概要を示しています。インストールのスコープによっては、ここに一覧にされていない他のサービスやアプリケーションからのログファイルも、/var/logに含まれます。以下に説明する一部のファイルやディレクトリは「プレースホルダ」であり、対応するアプリケーションがインストールされている場合にのみ使用されます。ほとんどのログファイルは、rootユーザにのみ表示されます。通常、これらのファイルは、プレーンテキストであるため、エディタを使用して表示できます。

重要
重要: サポートされていないログファイル

utmp、wtmp、およびlastlogはSUSE Linux Microから削除され、サポートされなくなりました。これらのログファイルに書き込むアプリケーションがある場合、ログファイルは不完全であることに留意してください。wtmpはwtmpdbに置き換えられ、lastlogはlastlog2に置き換えられました。

audit/

監査フレームワークからのログ。

ConsoleKit/

ConsoleKitデーモンのログ(このデーモンは、どのユーザがログインしているか、およびそのユーザがコンピュータをどのように操作しているかを追跡するデーモンです)。

cups/

共通Unix印刷システム(CUPS) (cups)のアクセスおよびエラーのログ。

firewalld

ファイアウォールのログ。

krb5/

Kerberosネットワーク認証システムからのログファイル。

chrony/

Network Time Protocolデーモン(chrony)からのログ。

YaST2/

YaSTのすべてのログファイル。

zypp/

libzyppログファイル。パッケージのインストール履歴については、これらのファイルを参照してください。

zypper.log

コマンドラインインストーラzypperからのログ。

2 /var/logファイルの表示と解析

 

以下に詳しく説明するように、/var/logのプレーンテキストログは、CLIコマンドを使用して表示および解析できます。

ログファイルを表示するには、コマンドlessまたはmoreを使用します。ログファイルの先頭または末尾を表示するには、headおよびtailを使用します。ログファイルに追加されるエントリをリアルタイムに表示するには、tail -fを使用します。これらのツールの使用方法については、マニュアルページを参照してください。

ログファイルで文字列または正規表現を検索するには、grepを使用します。awkは、ログファイルを解析および書き換えるのに役立ちます。

3 logrotateを使用したログファイルの管理

 

/var/logの下層にあるログファイルは毎日増加し、すぐに巨大化します。logrotateは、ログファイルとその増加を管理するのに役立つツールです。ログファイルの自動的なローテーション、削除、圧縮、およびメール送信が可能です。ログファイルは定期的に(毎日、毎週、または毎月)処理するか、特定のサイズを超えたときに処理できます。

logrotateは通常、systemdによって1日に1回実行されるため、ログファイルが変更されるのは通常は1日に1回だけです。ただし、ログファイルのサイズが原因でlogrotateが1日に複数回実行される場合や、--forceが有効化されている場合は、例外が発生します。特定のファイルが前回いつローテーションされたかを確認するには、/var/lib/misc/logrotate.statusファイルを表示します。

logrotateは、ニーズに合わせて設定できます。詳細については、3.1項 「logrotateの構成」を参照してください。

3.1 logrotateの構成

 

メインの設定ファイルlogrotate.confでは、ログのローテーション頻度や、データの圧縮に使用するツールなどを定義します。サービスごとにlogrotateの専用の設定を/etc/logrotate.d/に配置できます。

3.1.1 logrotate.confの調整

 

logrotate.confのデフォルトバージョンは、/usr/etc/ディレクトリにあります。デフォルトがニーズに合わない場合は、このファイルを/etc/logrotate.confにコピーして、そこで設定値を変更します。/usr/etc/のバージョンはシステム更新時に上書きされる可能性があるため、変更しないでください。次の値を置き換えることができます。

weekly

ログローテーションの頻度。hourly、daily、weekly、monthly、またはyearlyの任意の値を使用できます。

maxage

ログの保持日数を指定できます。

rotate 4

この数値により、ローテーションされたログを保持するためのログローテーションの量が決まります。rotate 0に設定すると、ログは直ちに削除されます。rotate -1に設定すると、ログはmaxageの値に達するまで削除されません。

dateext

このオプションが設定ファイルで指定されている場合、ローテーションされたログファイルの名前に、logname.YYYYMMDDという形式の日付の拡張子が付きます。指定されていない場合、デフォルトのファイル名スキームはlogname.1、logname.2です。

compress

コメントアウトすると、ログは圧縮されません。

compresscmdおよびuncompresscmd

ここでは、ツールに対応する絶対パスを設定することで、デフォルトの圧縮および圧縮解除ツールを変更できます。

include PATH

ログローテーションの情報を使用して、ファイルのデフォルトの場所を変更できます。デフォルトは/var/lib/misc/logrotate.statusです。

3.1.2 サービス固有のlogrotate設定

 

サービスおよびアプリケーションに固有のlogrotate設定を/etc/logrotate.dに配置できます。3.1.1項 「logrotate.confの調整」で説明されているオプションのほかに、次の設定も使用できます。

missingok

指定されたログファイルが見つからなくても、ログローテーション時にエラーを報告しません。

notifempty

空のログファイルをローテーションしません。

delaycompress

ローテーションされたログの圧縮を、次のログローテーションまで延期します。

sharedscripts

ローテーションするログの数にかかわらず、一度だけ実行するスクリプトを含むセクションを指定します。省略した場合、スクリプトはローテーションする各ログファイルに対して実行されます。

size

ログローテーションを開始するまでにログファイルが到達可能なサイズを定義します。このオプションにより、時間スケジュールを無視できます。値はメガバイト(M)、キロバイト(K)、またはバイト(B)単位で指定できます。

minsize

ログのサイズがこの値を超える場合、ログは指定された時間スケジュールに従ってローテーションされます。値はメガバイト(M)、キロバイト(K)、またはバイト(B)単位で指定できます。

maxsize

ログファイルの最大サイズを指定します。この制限に達すると、時間間隔に達していなくてもローテーションがトリガされます。値はメガバイト(M)、キロバイト(K)、またはバイト(B)単位で指定できます。

4 systemdロギングシステム - ジャーナル

 

systemdは、「ジャーナル」と呼ばれる独自のロギングシステムを備えています。ジャーナル自体は、systemd-journald.serviceによって管理されるシステムサービスであるsystemdです。

このサービスは、カーネル、ユーザプロセス、標準入力、およびシステムサービスエラーから受信したログ情報に基づいて、構造化されたインデックスジャーナルを維持することで、ログデータを収集して保存します。systemd-journaldサービスは、デフォルトで有効化および開始されます。

ジャーナルは、/var/log/journal/にログデータを保存します。

4.1 journalctlコマンドの使用

 

このセクションでは、デフォルトのjournalctlの動作を拡張する一般的な便利なオプションをいくつか紹介します。

journalctlコマンドの構文は次のとおりです。 

        journalctl [options…] [matches…]
ヒント
ヒント: 特定の実行可能ファイルに関連するメッセージ

特定の実行可能ファイルに関連するすべてのジャーナルメッセージを表示するには、実行可能ファイルのフルパスを指定します。 

> sudo journalctl /usr/lib/systemd/systemd

このコマンドには次のオプションを指定できます。

-f

最新のジャーナルメッセージのみを表示し、新しいログエントリがジャーナルに追加されるとそれらを出力します。

-e

メッセージを出力してジャーナルの最後に移動します。これにより、最新のエントリをページャ内に表示できます。

-r

ジャーナルのメッセージを逆順に出力します。これにより、最新のエントリが最初に一覧にされます。

-k

カーネルメッセージのみを表示します。これは、フィールド照合機能_TRANSPORT=kernelと同等です。

-u

指定したsystemdユニットのメッセージのみを表示します。これは、フィールド照合機能_SYSTEMD_UNIT=UNITと同等です。 

> sudo journalctl -u apache2
 [...]
 Jun 03 10:07:11 pinkiepie systemd[1]: Starting The Apache Webserver...
 Jun 03 10:07:12 pinkiepie systemd[1]: Started The Apache Webserver.

4.2 ジャーナルログのフィルタ

 

オプションを指定しないでjournalctlを呼び出すと、ジャーナルの内容全体が出力され、最も古いエントリが最初に一覧にされます。特定のオプションまたはジャーナルフィールドでこの出力をフィルタできます。

4.2.1 時間間隔に基づくフィルタ

 

開始日または終了日、あるいはその両方を指定して、journalctlの出力をフィルタできます。日付指定は、2014-06-30 9:17:16の形式にする必要があります。時間の部分を省略すると、夜中の12:00と想定されます。秒を省略すると、:00と想定されます。日付の部分を省略すると、当日と想定されます。数値式ではなく、キーワード「yesterday、」 「today」、または「tomorrow」を指定できます。これらは、当日の前日の夜中の12:00、当日の夜中の12:00、または当日の翌日の夜中の12:00を示します。「now」を指定すると、当日を示します。また、-または+をプレフィクスとして付けて、現在時刻の前後を示す相対時間を指定することもできます。

現在時刻以降の新しいメッセージのみを表示し、出力を継続的に更新します。 

> sudo journalctl --since "now" -f

午前0時から午前3時20分までのすべてのメッセージを表示します。 

> sudo journalctl --since "today" --until "3:20"

4.2.2 ブート番号に基づくフィルタ

 

journalctlは特定のシステムブートに基づいてメッセージをフィルタできます。利用可能なブートを一覧もするには、次を実行します。 

> sudo journalctl --list-boots
 -1 097ed2cd99124a2391d2cffab1b566f0 Mon 2014-05-26 08:36:56 EDT—Fri 2014-05-30 05:33:44 EDT
  0 156019a44a774a0bb0148a92df4af81b Fri 2014-05-30 05:34:09 EDT—Fri 2014-05-30 06:15:01 EDT

1番目の列にはブートオフセットが一覧にされます。現在のブートの場合は0、直前のブートの場合は-1、その1つ前のブートの場合は-2といった具合になります。2番目の列には、ブートIDが含まれ、特定のブートに限定するためのタイムスタンプが続きます。

現在のブートのすべてのメッセージを表示します。 

> sudo journalctl -b

直前のブートのジャーナルメッセージを表示する必要がある場合は、オフセットパラメータを追加します。次の例は、直前のブートメッセージを出力します。 

> sudo journalctl -b -1

もう1つの方法は、ブートIDに基づいてブートメッセージを一覧にする方法です。このためには、_BOOT_IDフィールドを使用します。 

> sudo journalctl _BOOT_ID=156019a44a774a0bb0148a92df4af81b

4.2.3 フィールドに基づくフィルタ

 

特定のフィールドによってジャーナルの出力をフィルタできます。照合するフィールドの構文は、FIELD_NAME=MATCHED_VALUEです(_SYSTEMD_UNIT=httpd.serviceなど)。1つのクエリに複数の照合を指定することで、出力メッセージをさらにフィルタすることができます。デフォルトフィールドのリストについては、man 7 systemd.journal-fieldsを参照してください。

特定のプロセスIDによって生成されたメッセージを表示します。 

> sudo journalctl _PID=1039

特定のユーザIDに属するメッセージを表示します。 

# journalctl _UID=1000

カーネルリングバッファのメッセージを表示します(dmesgが生成するものと同じ)。 

> sudo journalctl _TRANSPORT=kernel

サービスの標準出力またはエラー出力のメッセージを表示します。 

> sudo journalctl _TRANSPORT=stdout

指定されたサービスによって生成されたメッセージのみを表示します。 

> sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service

2つの異なるフィールドを指定すると、同時に両方の式に一致するエントリのみが表示されます。 

> sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=1488

2つの照合が同じフィールドを示している場合は、いずれかの式に一致するすべてのエントリが表示されます。 

> sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service _SYSTEMD_UNIT=dbus.service

+セパレータを使用して、2つの式を論理ORで組み合わせることができます。次の例は、プロセスIDが1480のAvahiサービスプロセスのすべてのメッセージと、D-Busサービスのすべてのメッセージを表示します。 

> sudo journalctl _SYSTEMD_UNIT=avahi-daemon.service _PID=1480 + _SYSTEMD_UNIT=dbus.service

4.3 Journaldの設定

 
> sudo systemctl restart systemd-journald

4.3.1 ジャーナルサイズ制限の変更

 

ジャーナルログデータは、/var/log/journalが存在するファイルシステムの最大10%を使用します。たとえば、/var/log/journalを30 GBの/varパーティションに配置すると、ジャーナルは最大3 GBのディスク容量を使用します。この制限を変更するには、SystemMaxUseオプションを変更(およびコメント解除)します。 

SystemMaxUse=50M

4.3.2 ジャーナルの/dev/ttyXへの転送

 

ジャーナルを端末デバイスに転送し、好みの端末画面(たとえば、/dev/tty12)でシステムメッセージに関する通知を受信できます。journaldオプションを次のように変更します。 

ForwardToConsole=yes
TTYPath=/dev/tty12