Clever Geek Handbook

Logreplica：クラスター全体のログをリアルタイムで単一ポイントに収集する

さまざまなプロジェクトで使用する有用なユーティリティを引き続き共有しています。 今回は、 logreplicaについて説明します。これは、異なるクラスターサーバーから大規模な「リアルタイム」ドライブを備えた単一のマシンへのログの信頼性の高い転送を整理できるシンプルなツールです。 これは、クラスタ全体のログを単一のマシンに直接書き込まれているように集中的に監視または分析する場合に非常に便利です。



logreplicaは、syslog / syslog-ng設定を使用する方法よりも、中央の場所でログを収集するより便利で信頼性の高い方法として考えられていたと言えます。



logreplicaの利点は、設定が簡単なことです。ログファイルの名前の「マスク」を設定し、ソースマシンのアドレスを指定するだけで、将来、マスクに対応するログは自動的にオンザフライで中央マシンに追加されます（マシン上の場合を含む） -新しいログファイルが表示されます。logreplicaが起動した時点では不明です）。 新しいマシンを追加する場合、その上で何も設定する必要はありません。設定ファイルにその名前を含めるだけです。



設定例/etc/dklab_logreplica.conf 



 ＃ログを保存する現在のマシンのディレクトリ。
宛先= / var /ログ/クラスター

 ＃宛先ディレクトリへの保存中にこれらのログファイルのプレフィックスをスキップします。
 skip_destination_prefixes = / var / log：/ var / lib / pgsql / data / logs

 ＃内部状態ディレクトリへのパス（変更されない場合があります）。
スコアボード= /var/run/dklab_logreplica.scoreboard

 ＃ログ成長チェックの前にスリープする時間間隔。
遅延= 0.25

 ＃リモートホストに接続するデフォルトユーザー。
ユーザー=ルート

 ＃すべてのログソースマシンで監視するファイル。
 [ファイル]
 / var / log / {メッセージ、メールログ}
 / var / log / httpd / * _ log

 ＃ログを収集するために接続するホスト。
 [ホスト]
 first = machine1.example.com
 second=nobody@machine2.example.com


logreplicaをインストールおよび構成する方法



ソースマシンでは、何も設定する必要はありません。中央の設定ファイルに登録されるとすぐに動作可能になります。 そのため、数十台のサーバーを構成せずにlogreplicaに自由に接続できます。すべての設定は、単一ファイル/etc/dklab_logreplica.confにあります。

  1. すべてのログを追加するサーバーを選択します。 logreplicaディストリビューションを/ opt / dklab_logreplica /にコピーし ます 。
  2. dklab_logreplica.init intスクリプトを/etc/init.dにコピーし、マシンの起動時に自動起動するように構成します（ chkconfig 、 update-rc.dおよびその他のLinuxユーティリティを参照）。
  3. デフォルトの構成dklab_logreplica.conf.sampleを/etc/dklab_logreplica.confにコピーし、システムに応じて変更します。
    • ログが収集されるマシンを指定します。
    • 監視するログファイルの名前のマスクを指定します。
    • ログがリアルタイムでコピーされるディレクトリを指定します。
  4. ssh-keygen -t rsaを使用して秘密+公開鍵を作成します。 ログがダウンロードされるマシンに公開鍵を入れます： ssh-copy-id root @ machine-to-be-pulled 。 そのため、ログサーバーからすべてのソースマシンへのパスワードなしのアクセスを取得する必要があります。そうしないと、logreplicaが機能しなくなります。

  5. ここで/etc/init.d/dklab_logreplica startを実行すると、logreplicaがソースマシン上のログファイルの変更の追跡を開始し、データを宛先ディレクトリに保存します。
logreplicaデーモンは、ネットワークの問題により突然消えた場合、ソースマシンに再接続できます。 これにより、ダウンタイム中にログに蓄積されたすべてのデータが転送されるため、何も失われません。 Logreplicaは、ソースマシン上のログローテーションも監視し、正しく処理します。



logreplicaによって解決される問題



クラスターに、さまざまなタスク（SQLサーバー、Webフロントエンド、バランサー、メールサーバーなど）を実行する複数の物理マシンまたは仮想マシンがあるとします。 これらのすべてのマシンからのログを1か所に保存したい場合があります-たとえば、さまざまな統計情報を読んだり、システム全体で何が起こっているかを監視するために（tail -fを使用しても）便利な場合です。



もちろん、すべてのログをネットワーク経由で中央のログサーバーに送信するようにsyslogまたはsyslog-ngを構成できますが、そうすると多くの不都合が発生します。

  1. マシン間の通信が一時的に中断された場合（残念ながら、頻繁に発生します）、ログの一部が失われる可能性があるため、データが失われることがあります。
  2. 実際には、クラスタ内の実際の状態と同期したsyslogまたはsyslog-ng構成を維持するのはかなり困難です。新しいマシンを追加したり、ログファイルのセットを変更したりできます。
  3. すべてのサービスがログのsyslogへの転送をサポートしているわけではありません（たとえば、apacheとnginxは、遅延を最小限に抑えるためにファイルに直接書き込みます）。 したがって、名前付きパイプを使用してデータをsyslogに転送する必要があります。つまり、構成と依存関係はますます大きくなります。
  4. 多くの場合、ログファイルの名前をハードコーディングして指定するのではなく、マスクを使用してログファイルを中央マシンに複製します。 syslogおよびsyslog-ngはこれを行うことができません。
  5. 最後に、実際には、中央のマシンだけでなく、ログが作成されたマシンにもログを保存することが非常に便利であることがわかりました（ソースマシンでは、より狭い「回転ウィンドウ」を設定できます）。 だから、syslogとsyslog-ngの設定は再び成長しています...
これらすべての問題を解決するために、logreplicaユーティリティが作成されました。 一般に、ログは単に「魔法のように」リアルタイムで中央マシンに表示され、サービスやリモートマシンの設定は一切変更されません。



リンク： dklab.ruのlogreplica 、 GitHubのlogreplica 。 アナログを知っている場合、または説明されている問題に対して異なるビジョンを持っている場合は、コメントを書いてください。


More articles:


All Articles