免責事項
すべての実験は、CentOS Linuxリリース7.2.1511をメインシステムとして実施し、最新のものはストックカブsystemd（systemd-219-19.el7_2.13）から入手可能です。 記事の公開時点で、データの一部が無関係であることを願っています。
はじめに
Fedora 15リリースでLinuxディストリビューションを入手し始め、ついにsystemdが勝ちました。 Bisonとaksakalsは、ユニットとsystemctlに徐々に慣れています。 古き良きの最後の擁護者は歯を磨きます。 これらの現実では、システム化された子製品を回避することはできません。 そして今日は、例えば、journaldについて話しましょう。
Journald自体（およびそれぞれjournalctl）は素晴らしいツールです。 systemdとはやや異質なプロジェクトとして始まったJournaldは、システム管理者が紹介されるsystemdファミリの2番目のツールになりました。 永続ストレージ用にオプションでリセットするオプションのログストレージランタイムのアイデア、boot-id journalctl --boot
およびmachine-id（ journalctl --machine
）のjournalctl --machine
、登録されたすべてのjournalctl -u
アプリケーションから単一のインターフェースからログを呼び出す機能、 journalctl --vacuum-size
またはjournalctl --vacuum-time
を使用した「 journalctl --vacuum-size
および「時間による」「 journalctl --vacuum-size
」ログローテーションの存在 良いことに、時間と優先度によってイベントを「つかむ」ために使用できるsince
、 until
、 priority
パラメーター、そしてもちろん、マルチタイムゾーンのコマンドとプロジェクトでの大きな頭痛を取り除くutc
パラメーターについて言及するしかありません。 バイナリファイルストレージ形式は少し物議をかもすかもしれませんが、著者はjournaldの最初の発表（セキュリティとストレージの低コスト、systemdとの統合、強制シングルフォーマット、移植性）でこの選択を説明しました。
残念ながら、たとえばログメッセージの翻訳を整理したり、特定のエラーの問題を解決するためにエンドユーザーにURLを提供したりするジャーナルディレクトリメカニズムはあまり人気がありません。 しかし、全体として、systemd開発者でさえ、この機会を十分に活用していません。
すべて実装され、動作し、何百ものマニュアルに記載され、検証されています。 どうもありがとう、でももっと欲しい。
前文
少し前まで、友人がログを収集するためのサーバーを構成するように頼みました。 ハハ！ これは、中央ログサーバーとしての機能を考慮してjournaldを学習する絶好の機会だと思いました！
ツールがタスクに依存していることは明らかです。 そこで、今回は簡単な要件の収集が行われました。
- ロギングの単一ポイントを整理する必要があります
- 事前に不明な数のクライアントを単一のロギングポイントに接続する（およびそれぞれ切断する）可能性を整理する必要があります。
- ログをオンラインで表示する機能を整理し、新しいエントリを自動的に受信することをお勧めします
- 前の段落を実行するとき、中央ポイントでのログストレージはN時間（偶数日でもない）に制限できます。
- メッセージ形式は複数行まで一貫していません
- 対象となる主要なソフトウェアはstdoutに書き込まれます（はい、動作またはナプロスチルを変更できますが、販売するものを購入します）。コンソールは閉じません。
そして一般的な技術紹介：
- データはパブリックネットワークを介して送信されます
- 専用ホストマシン：Centos7.2（最新）
- 接続されたマシン：Ubuntu 16.04
Systemdとjournaldは良い選択のようですよね？ 結局のところ、すべてのポイントはすでに実装されています！ テストベンチを上げます！
ホストホスト
さあ、始めましょう。
3つのコンポーネントに関心があります。
-
systemd-journal-gatewayd
ジャーナルエントリを表示（またはダウンロード）するためにポートを開くhttp-daemon -
systemd-journal-remote
中央サーバーでジャーナルエントリをダウンロードまたは受信するデーモン -
systemd-journal-upload
ジャーナルエントリをリモートサーバーに複製するデーモン
これらのコンポーネントはすべて、centosパッケージsystemd-journal-gateway
に含まれているため、次のようにします。
yum -y update && yum -y install systemd-journal-gateway
systemd-journal-remote
デーモンは、ホストマシンのログを取得するために使用されます。 彼から始めます。
systemd-journal-remote
リモートには、アクティブ（リモートログに移動してログをダウンロードする-トラッキングモードを含む）の2つの操作モードがあります。このモードでは、すべてのリモートマシンにsystemd-journal-gatewayd
が必要です。彼らが彼のところに来るまで待っています）。 車の数が不明な場合-パッシブモードを選択します。 実際のセットアップ全体は、ディレクトリ/var/log/journal/remote
、それに希望するユーザーの権限を割り当てて、サービスを開始することです。
mkdir -p /var/log/journal/remote chown systemd-journal-remote:systemd-journal-remote /var/log/journal/remote systemctl start /var/log/journal/remote
デモスタンドを構築しているので、ファイルを受信するためのプロトコルをhttpsからhttpに切り替えましょう。 これを行うには、サービス開始ファイル/lib/systemd/system/systemd-journal-remote.service
を編集し、 listen-https
オプションをlisten-http
に置き換える必要がありlisten-http
。 /lib/systemd/system/systemd-journal-remote.socket
を修正して、デーモンのバインドに必要なアドレスのみを指定することも役立ちます。
デーモンが起動し、パッシブモードでハングし、httpで動作します。 やった！
悪魔の詳細
まず、 /var/log/journal
ディレクトリを作成すると、すべてのシステムログが/var/log/journal/<uuid>
ディレクトリに書き込まれ始め/var/log/journal/<uuid>
。 この動作を変更して元の状態に戻すには、構成ファイル/etc/systemd/journald.conf
（または/etc/systemd/journald.conf.d/< >.conf
を入力する必要があります。更新中）、つまり、行Storage=
。 デフォルトでは、このパラメーターの値はauto
です。つまり、「varにディレクトリがある場合、journaldはそこにログを書き込みます」。 私の場合、パラメーターをvolatile
に設定する必要がありました。
systemd-journal-upload
アップロードはさらに簡単です： /etc/systemd/journal-upload.d/< >.conf
作成し、そこに書きます：
[Upload] URL=http://<IP- remote>:< >
systemctl start systemd-journal-upload
を実行します
悪魔の詳細
次に、 Centosの非常に古いバグが原因でデーモンが起動しません。 usermod -a -G systemd-journal systemd-journal-upload
手で実行します。 その後、デーモンは正常に起動するはずです。
リモートクライアント
リモートクライアントでは、Ubuntu 16.04を思い出します。 そこで、 apt-get install systemd-journal-remote
置き、 /etc/systemd/journal-upload.d/< >.conf
apt-get install systemd-journal-remote
/etc/systemd/journal-upload.d/< >.conf
前の段落と同様に編集し/etc/systemd/journal-upload.d/< >.conf
（ usermod
を除く）。
systemd-journal-gatewayd
そして、実際、ここには説明するものは何もありません。 Centosで導入された現在のバージョンでは、指定されたデーモンに非標準のディレクトリを指定することはできません。 さらに、開発者のロジックによれば、他のマシンからのログの標準ディレクトリは、ログビューアーにとって標準ではありません。 systemdの新しいバージョンでは、これは修正されているようですが、非ネイティブバージョンはインストールしません...
さて、少なくともログを観察しましょう。
journalctl -D /var/log/journal/remote --follow
さて、何かがうまくいくようです...
悪魔の詳細
第三に、 systemdの古いバグのおかげで、ディレクトリ/var/log/journal/remote
が最も大きく膨らみ始めます。 そして、何もあなたを助けません...
最後まで行きましょう！
しかし、ここまで来たので、最後に行きましょう。 ホストマシンでsystemd-journal-gatewayd
デーモンをsystemd-journal-gatewayd
ます（ここでも、 systemd-journal-gatewayd
を修正してデーモンを制限することを忘れないでください）。そして、ブラウザのWebインターフェースを注意深く調べます。
- オンラインでのログのスワップは事実上ありません
-
on mouse over
とログのon mouse scroll
で激しい - ボンネットの下のmicrohttpd
- 申し訳ありませんが、恐ろしいインターフェイス
- systemd-unitでログをフィルタリングすることは可能ですが、（クラウンスクリプトなどの情報量の少ないセッションユニットの数のため）、フィルターを使用できない
- すべてのユニットは完全に記述されています-たとえば、クラウン文字列のデータベースへのパスワードを使用する場合、パスワードがあなたを待っています
Nda。 たぶん、設定できなかったのはいいですね、m？
合計
journaldはPythonのネイティブライブラリを提供するため、概念実証のために、 ペットプロジェクトが数日で作成されました。 機能の：
- SSEライブビュー
- 構成レベルで管理者が表示されたユニットをフィルタリングする機能
- Webアプリケーションレベルでユーザーごとにホスト/優先度/ユニットをフィルタリングする機能
- まあ、少しブートストラップ
同じプロジェクトが友人に公開され、既存の問題の説明、免責事項、雑誌の強制清掃が行われました。
しかし、個人的には、大規模なプロジェクトでは、長い間、ログの中央リポジトリとしてjournaldを使用しないでしょう。 上記のバグが削除されるまで、私の選択は間違いなくsyslogを優先します。
記事の著者： Stepan Karamyshev