SLE Microのシステムログの管理
- 概要
システムログファイルの分析は、システムを分析する際に最も重要なタスクの1つです。実際、システムを保守またはトラブルシューティングする際は、最初にシステムログファイルを確認する必要があります。SLE Microは、システムで発生するほぼすべての事象を自動的に詳しくログに記録します。
- 目的
この記事では、システムで発生した事象を、システムログを表示して調べる方法について説明します。
- 所要時間
この記事の理解には20分ほどを要します。
- 目標
ログファイルが存在する場所、およびログファイルを管理する方法の概要を把握します。
- 要件
root
特権。
1 システムログファイルはどこにあるか #
SLE Microは、カーネル、SELinux、またはその他のサービスなどからのさまざまなタイプのメッセージをログに記録します。
カーネルメッセージ、およびsystemd
に登録されているシステムサービスのメッセージは、systemd
ジャーナルに記録されます(4項 「systemd
ロギングシステム - ジャーナル」を参照)。その他のシステムログファイルは、/var/log
ディレクトリの下層にあります。SELinuxメッセージは、/var/log/audit/audit.log
に記録されます。詳細については、SELinux
troubleshootingを参照してください。
以下のリストは、デフォルトインストール後にSLE Microで確認できるすべてのシステムログファイルの概要を示しています。インストールのスコープによっては、ここに一覧にされていない他のサービスやアプリケーションからのログファイルも、/var/log
に含まれます。以下に説明する一部のファイルやディレクトリは「プレースホルダ」であり、対応するアプリケーションがインストールされている場合にのみ使用されます。ほとんどのログファイルは、root
ユーザにのみ表示されます。通常、これらのファイルは、プレーンテキストであるため、エディタを使用して表示できます。
utmp
、wtmp
、およびlastlog
はSLE 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
5 法的事項 #
Copyright © 2006–2024 SUSE LLC and contributors. All rights reserved.
この文書は、GNUフリー文書ライセンスのバージョン1.2または(オプションとして)バージョン1.3の条項に従って、複製、頒布、および/または改変が許可されています。ただし、この著作権表示およびライセンスは変更せずに記載すること。ライセンスバージョン1.2のコピーは、「GNUフリー文書ライセンス」セクションに含まれています。
SUSEの商標については、https://www.suse.com/company/legal/を参照してください。その他の第三者のすべての商標は、各社の所有に帰属します。商標記号(®、™など)は、SUSEおよび関連会社の商標を示します。アスタリスク(*)は、第三者の商標を示します。
本書のすべての情報は、細心の注意を払って編集されています。しかし、このことは正確性を完全に保証するものではありません。SUSE LLC、その関係者、著者、翻訳者のいずれも誤りまたはその結果に対して一切責任を負いかねます。