ロギング · レッスン 1

システムロギング

Linux のログ発生元、collector、保存先、閲覧ツールが連携する仕組みを学びます。

ログは、カーネル、サービス、アプリケーション、セキュリティコンポーネントが発したイベントを記録します。トラブルシューティングや監査に役立ちますが、それは収集が機能し、時刻を正しく理解し、必要な情報源が含まれている場合に限ります。

ログメッセージの流れを追う

ロギングの経路には、いくつかの異なる部分があります。

発生元がイベントを出力する。
collector が受信し、情報を付加する。
routing と retention の規則が保存先または転送先を選ぶ。
viewer が保存済みレコードを問い合わせる。

systemd ホストでは、systemd-journald がサービスの標準出力、カーネルメッセージ、journal-native または syslog メッセージを収集するのが一般的です。rsyslog などの syslog daemon もメッセージを受け取り、従来のテキストファイルへ書いたり転送したりできます。アプリケーションが独自ファイルや外部 telemetry を管理する場合もあります。

受信したメッセージをどこへ保存または転送するか決めるものはどれですか？

利用可能なログを見つける

すべてのホストに同じファイルがあると想定せず、稼働中のロギングサービスとローカル設定を調べます。

$ systemctl --type=service --state=running | grep -E 'journal|syslog'
$ ls -la /var/log
$ journalctl --disk-usage

互換性のある routing を使う Debian 系では /var/log/syslog が一般的で、ほかの環境では /var/log/messages がよく使われます。journal-only ホストではどちらもない場合があります。アプリケーション文書と unit 設定から、追加の宛先を特定できます。

/var/log/syslog がない場合、必ず何を意味しますか？

Journal を問い合わせる

journal 全体を出力せず、範囲を限定した問い合わせから始めます。

$ journalctl -b -p warning
$ journalctl -u ssh.service --since '1 hour ago'

-b は現在の boot、-p は priority、-u は unit で絞り込みます。unit 名と保存済み boot はホストごとに異なります。journalctl --list-boots で利用可能な boot を確認し、問題を再現しながら journalctl -f で新しいレコードを追います。

journalctl の問い合わせを現在の boot に限定するオプションはどれですか？

文脈の中でレコードを読む

従来の syslog 形式の行は次のようになります。

Jan 27 07:41:32 icebox anacron[4650]: Job `cron.weekly' started

timestamp、host、program と PID、その後に message が続きます。message text はアプリケーション出力であり、保証された構造化事実として扱わないでください。timezone、時計同期、boot ID、PID の再利用、イベント直前直後のレコードを確認します。journal field は、表示テキストだけより強い識別情報を提供できる場合があります。

ログにはユーザー名、アドレス、パス、token などの機密データが含まれる可能性があります。最小権限でアクセスし、export は redact し、調査中は原本と timestamp を保持してください。

ログの抜粋を外部共有する前に何をすべきですか？