s6、runit、perp、nosh、daemontools-encoreなどを含むシステムこれがサービス管理がどのように機能するかです。各主要サービスには、独立して監視できる個別の関連ログファイルセットと分散ロギングメカニズムがあります。

しかし、systemdはこのようには機能しません。特定のサービスに対して別個の「関連ログファイル」はありません。監視するファイルがありません。

すべてのログ出力は単一の中央デーモンに入り、そのsystemd-journaldデーモンはそれを単一のストリームに書き込みます/{run,var}/log/journal/。

オプションは、関連するサービス名でタグ付けされたすべてのログエントリと一緒に単一の中央ログから印刷される内容をフィルタリングする後処理フィルタ-uです。journalctlすべてが扇形に広がっており、それをフィルタリングして（ほぼ）元の形に戻す必要があります。

システム的な方法は、適切なフィルタを追加するjournalctl -fか、システム固有のAPIを使用してログ用の独自のプログラムを直接作成することです。

追加読書

• https://unix.stackexchange.com/a/294206/5132

1.) Linuxディストリビューションがフルスコープjournaldを使用している場合、以下の読みやすい既存のログファイルはありません。@JdeBP話す。ログファイルは、既存のログファイルツールで解析するのが難しいバイナリ形式を使用します。

2.）journalctl -u {service}必要な情報がある場合は、journalctl -f -u {service}出力を使用してログを解析し、目的の反応をトリガーするプログラムにパイプすることができます。それ以上の内容は、選択したLinuxディストリビューションによって異なる場合があります。

たとえば、Debian 9（Stretch）はデフォルト設定で既存のjournaldsyslog入力ソケットを保持します。/dev/logただしrsyslogd、インストールされている場合は、受信側のjournaldsyslog メッセージを転送するように構成されます。

journald他のLinuxディストリビューションは、異なる構造化された既存のsyslogデーモンと関係がある可能性があります。