Geekly Articles each Day

journaldでのリモートロギングまたはそれでも「必要ない」ですか？


免責事項


すべての実験は、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を学習する絶好の機会だと思いました！


ツールがタスクに依存していることは明らかです。 そこで、今回は簡単な要件の収集が行われました。


  1. ロギングの単一ポイントを整理する必要があります
  2. 事前に不明な数のクライアントを単一のロギングポイントに接続する（およびそれぞれ切断する）可能性を整理する必要があります。
  3. ログをオンラインで表示する機能を整理し、新しいエントリを自動的に受信することをお勧めします
  4. 前の段落を実行するとき、中央ポイントでのログストレージはN時間（偶数日でもない）に制限できます。
  5. メッセージ形式は複数行まで一貫していません
  6. 対象となる主要なソフトウェアはstdoutに書き込まれます（はい、動作またはナプロスチルを変更できますが、販売するものを購入します）。コンソールは閉じません。

そして一般的な技術紹介：


  1. データはパブリックネットワークを介して送信されます
  2. 専用ホストマシン：Centos7.2（最新）
  3. 接続されたマシン：Ubuntu 16.04

Systemdとjournaldは良い選択のようですよね？ 結局のところ、すべてのポイントはすでに実装されています！ テストベンチを上げます！


ホストホスト


さあ、始めましょう。
3つのコンポーネントに関心があります。


  1. systemd-journal-gatewaydジャーナルエントリを表示（またはダウンロード）するためにポートを開くhttp-daemon
  2. systemd-journal-remote中央サーバーでジャーナルエントリをダウンロードまたは受信するデーモン
  3. 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インターフェースを注意深く調べます。



Nda。 たぶん、設定できなかったのはいいですね、m？


合計


journaldはPythonのネイティブライブラリを提供するため、概念実証のために、 ペットプロジェクトが数日で作成されました。 機能の：


  1. SSEライブビュー
  2. 構成レベルで管理者が表示されたユニットをフィルタリングする機能
  3. Webアプリケーションレベルでユーザーごとにホスト/優先度/ユニットをフィルタリングする機能
  4. まあ、少しブートストラップ

同じプロジェクトが友人に公開され、既存の問題の説明、免責事項、雑誌の強制清掃が行われました。


しかし、個人的には、大規模なプロジェクトでは、長い間、ログの中央リポジトリとしてjournaldを使用しないでしょう。 上記のバグが削除されるまで、私の選択は間違いなくsyslogを優先します。


記事の著者： Stepan Karamyshev



Source: https://habr.com/ru/post/J317182/

More articles:


All Articles