オープンソースのクラウドログアセンブリとログコレクターの進化

こんにちは、私はYuri Nasretdinovです。Badooのシニアエンジニアとして働いています。 過去1年半にわたって、私たちのクラウドがどのように機能するかについていくつかのプレゼンテーションを行いました。 スライドとビデオはこちらとこちらでご覧いただけます 。



今日は、このシステムの別の部分、つまりログコレクタについて説明するときです。ログコレクタについては、この記事とともに、オープンソースで投稿します。 クラウドのロジックの大部分はGoで記述されており、このサブシステムも例外ではありません。

システムソースコード： github.com/badoo/thunder

この記事では、クラウドでアプリケーションログを配信する方法について説明します。これを単に「スクリプトフレームワーク」と呼びます。

アプリケーションログ

クラウドで実行されるアプリケーションはPHPクラスであり、最も単純な実装ではrun（）メソッドを持ち、たとえば1〜Nの数のジョブデータを受け取ります。Nはこのクラスのインスタンスの最大数です。 各タスクには固有のIDがあり、最終的な目標は、特定の起動のログとクラスのすべてのログを一度に簡単に見つけることができる集中リポジトリにログを配信することです。

<?php class ExampleScript extends ScriptSimple { public function run() { $this->getLogger()->info("Hello, world!"); return true; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の実装：起動IDのファイルごと

クラウド内のタスクの各起動は個別のPHPプロセスの起動を表しているため、各起動のログを個別に収集する最も簡単で明白な方法は、各プロセスの出力を<id>。<Out | err> .logの形式の個別のファイルにリダイレクトすることでしたoutおよびerrは、それぞれ標準出力チャネルとエラーに使用されます。



そのため、ログコレクターのタスクは、定期的にディレクトリに変更のログを照会し、ファイルに現れた新しい行を送信することでした。 ログを中央サーバーに配信する手段としてスクライブを使用し、最後に送信されたオフセットをファイル名に直接保存しました（これは、開いているファイル記述子にログを書き続ける場合に機能します）。 オフセットは送信時のファイルサイズです。新しいログがファイルに書き込まれるとサイズが大きくなり、ファイル内の最後に配信された位置から新しい行を配信する必要があります。

 <?php //   while (true) { foreach (glob("*.log") as $filename) { $filesize = filesize($filename); // 200 $read_offset = parseOffset($filename); // "id.out.log.100" -> 100 if ($filesize > $read_offset) { sendToScribe($filename, $read_offset); //   scribe   $read_offset rename($filename, replaceOffset($filename, $filesize); // "id.out.log.100" -> "id.out.log.200" } else if (finishedExecution($filename)) { unlink($filename); } } sleep(1); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディレクトリ内に少数のファイルがあり、それぞれが多かれ少なかれ活発に書き込みを行っている限り、このアプローチはうまく機能します。 アプリケーションが行の先頭に起動識別子を追加する「ロガー」を使用する代わりに単純なエコーを作成する場合でも、個別のファイルへのリダイレクトにより、各起動の出力を個別に簡単に区別できます。 同じファイルへの書き込みと比較すると、この場合、アプリケーションの異なる「インスタンス」からの出力を混在させることはできません。 また、他の誰もファイルに書き込まないことを理解するのは簡単です。指定されたIDのプロセスが既に完了している場合、スクライブに完全に配信されたときに対応するログファイルを削除できます。



ただし、この方式には多くの欠点があります。 主なものは次のとおりです。

1. ファイル名にはクラス名に関する情報が含まれていません-この情報はクラウドベースから要求する必要があります。
2. スクライブでは、宛先サーバーが処理するよりもはるかに多くのデータを簡単に「移動」できます。 この状況では、スクライブはデータをファイルシステムにローカルにバッファリングし、すでにディスクにあるログを複製します。
3. ログコレクターが古いファイルを削除する時間がなくなると、多くのファイルが蓄積される可能性があります。 ホストごとに数百万のファイルを数回蓄積しましたが、必要なログがまだ関連するまでに配信する方法がありませんでした。
4. 多くのファイルを絶えず作成、名前変更、削除すると、ext3ファイルシステム（およびext4程度）の動作があまりよくありません。ファイルへの書き込み時および作成時に、D状態でプロセスが数百ミリ秒「スタック」することがよくあります。 ;
5. stat（）ファイルの絶え間ないポーリングを取り除き、inotifyの使用を開始したい場合は、不快な驚きもあります。 大量の空きメモリがあるマルチコアシステムで特に顕著な実装機能により、ファイルが定期的に作成および削除されるディレクトリでinotify_add_watch（）が呼び出されると、このディレクトリ内のファイルに書き込むすべてのプロセスの「固着」が発生する場合があります。そしてそれは数十秒間続くことができます。

パラグラフ（5）で説明されている条件下での「不正な」inotify動作の原因について詳しく知りたい場合は、以下のネタバレを読んでください。







クラス名をファイルに追加することで、クラウドベースにリクエストを行う必要があるという問題を解決できますが、それ以外はそれほどバラ色ではありません。 ユーザーにロガーの使用を強制せずに、同じアプリケーションの異なるインスタンスから出力を分離する機能を維持するために、アプリケーションの出力をファイルではなく「Unixパイプ」にリダイレクトすることは可能ですが、これは新しい問題を作成します-更新する必要がある場合プロキシコード（PHPクラスを実行）、「壊れたパイプ」（壊れたパイプ）に書き込もうとすると、現在のタスクの作業が中断される場合があります。







これは、デーモンが再起動されると、パイプの読み取り側に対応するすべての記述子が閉じられ、後で書き込みを試みると、プロセスがSIGPIPEを受信して​​終了するためです。 ちなみに、headユーティリティーなどを使用したunixコマンドのチェーンの操作は、このメカニズムに基づいています。コマンドcat some_file.txt | 必要な行数を読み取った後、headコマンドは単純に終了し、対応するパイプが中断し、最後まで書き込みを続けるcatプロセスがSIGPIPEシグナルを受信し、実行を単に終了するため、headはエラーメッセージを表示しません。 チェーンに複数のプロセスがある場合、チェーンの各要素で同じ状況が発生し、すべての中間アプリケーションはSIGPIPEシグナルで正常に終了します。



「通常の」UNIXパイプを「名前付き」名前付きパイプに置き換えることができます。つまり、ファイルへの書き込みを続けます。名前付きパイプは異なるタイプのみです。 ただし、クラッシュを簡単に乗り越えてプロキシを再起動できるようにするには、ファイル名と起動IDの対応に関する情報をどこかに置く必要があります。 そのようなオプションの1つはファイル名自体で、元の問題に戻ります。 他のオプションは、これを別のデータベース、たとえばsqliteやrocksdbに保存することですが、これはそのような一見単​​純なタスクには扱いにくいと思われ、同時に2フェーズコミットの問題を追加します（新しい開始IDがパイプに報告されたとき）また、この時点で読み取りプロセスが終了したため、データベース内のレコードは更新されず、読み取りプロセスの次のインカネーションでは、起動IDがまだ古いと想定されます）。

解決策

新しいソリューションにはどのような機能が必要ですか？

1. コンポーネント（プロキシ、ログコレクター、および宛先サーバー）の再起動とクラッシュに対する抵抗。
2. クラスの1つが処理する時間がないほど多くのログを書き込む場合、他のクラスのログは許容可能な時間内に配信され、開発者が表示できるようにする必要があります。
3. ログ配信の問題については、状況が制御不能になることはなく、手動で簡単に修正できる必要があります（たとえば、数百万のファイルを作成しないでください）。
4. 可能であれば、システムはリアルタイムであり、帯域幅が大量に供給されている必要があります。

上記のinotifyおよびdentryキャッシュの目詰まりの問題により、新しい回路は常に同じ名前のファイルに書き込む必要があります。 単純で論理的なソリューションとして、アプリケーションの出力をclass_name.out.logの形式のファイルに書き込み、定期的にローテーションして、たとえばclass_name.out.log.oldを呼び出します。 残念ながら、異なるインスタンスのログを同じファイルに書き込むにはアプリケーションの変更が必要です：以前に単純なエコーを実行することが許されていた場合、新しいスキームでは、各行に起動識別子を持つタグを追加するロガーを常に使用する必要があります。 同時に記録しながらflock（）を使用することもパフォーマンスを大幅に低下させ、1つの「スタックプロセス」が現在のサーバーでこのアプリケーションの他のすべてのインスタンスの実行をブロックする可能性があるため、望ましくありません。 flock（）を使用する代わりに、ファイルをO_APPENDモード（フラグa）で開き、各レコードがアトミックになるように4 KB以下（Linuxの場合）のブロックで書き込むことができます。



したがって、「ファイルから実行」ではなく「ファイルからクラス」に書き込むだけで、ポイント1と3を解決しました。

ログを収集する方法は？

そのため、inotify、多数のファイル、プロキシクラッシュへの抵抗に関する問題の解決策を見つけました。 これらのログを収集する方法を理解することは今でも残っています。 論理的な解決策は、単にsyslogを残すか、syslog-ngなどの類似物を使用することです。 ただし、実際には既にログをファイルに書き込んでいるので、代わりにこれらのファイルの内容の単純な「ストリーム」を中央サーバーに書き込むことができます。 ダイアグラムは次のようになります。







図からわかるように、2つの大きなサブシステムがあります。サーバーレシーバー（プロセッサ）と各マシンのログコレクター（コレクター）です。



レシーバーとコレクター間の通信は、常に確立されたTCP / IP接続を使用して実行され、Googleプロトコルバッファーはパケットのパッケージ化に使用されます。 inotifyを使用するコレクターは、ファイルの変更を追跡し、新しい行のパケットを受信者に送信します。 次に、ソースサーバー上のファイルで受信した（およびログファイルに正常に書き込まれた）オフセットを送り返します。



レシーバーは、定期的に（この実装では1秒間に1回）リスト[{Inode：...、Offset：...}、...]の形式で新しいオフセットを個別のJSONファイルにリセットします。 このスキームにより、ネットワーク障害に耐えることができますが、サーバーの電源障害やカーネルパニックから保護することはできません。 この問題は私たちにとって重要ではないため、レシーバーは、実際のデータがディスクにフラッシュされるのを待たずに、write（）の呼び出しが成功した後、記録されたデータに関する確認を送信します。 ネットワーク、レシーバー、コレクターに障害が発生した場合、最後の行を2回以上配信できます。 保証だけでなく、1回限りの配信も必要な場合は、Yandexが構築したはるかに複雑なシステムhabrahabr.ru/company/yandex/blog/239823について読むことができます。

個々のクラスの「スロットル」配信

既に述べたように、1つの非常に「大量の」スクリプトが帯域幅を完全にブロックし、他のすべてのログの処理を遅くする可能性があることに満足していませんでした。 これは、スクライブがレシーバーへの配信が発生するよりもはるかに速く書き込むことができ、少なくとも同じジョブ内でログ内の行のシーケンスに従う必要があるため、スクライブからのイベントの処理がシングルスレッドであったために発生しました。



この問題の解決策は非常に簡単です。「マルチタスク処理の混雑」に類似したものを作成する必要があります。 1つのパスで、ファイル内のN行以下を処理してから、次の行に進みます。 「通常の」ログ用に送信されたすべての断片がサーバーで受信されると、「太字ファイル」の送信に戻り、同じアルゴリズムで動作できます。 したがって、「大きなファイル」の配信はシステムに限定的な影響を及ぼします。残りのすべてのクラスのログは、最大パケットサイズNによって規制される一定の遅延で配信され続けます。できるだけ早く配信されます。

ファイルの回転

ログが時間の経過とともにサーバー上のすべてのスペースを占有しないようにするには、ログをローテーションする必要があります。 ログローテーションは、最も古いログファイルを削除し、より新しいファイルの名前を「古い」ファイルに変更するプロセスです。 この場合、ローテーションとは、古いログファイルを削除し、現在のログファイルの名前を変更することです（class_name.out.log-> class_name.out.log.old）。 ファイルの名前を変更するとき、このファイルを開いたままにするすべてのプロセスは、ファイルの処理を続行できます（この場合は書き込み）。 したがって、新しいログファイルと古いログファイルの両方で発生した変更を引き続き送信する必要があります。 ファイルの名前を変更すると、iノードも保存されるため、データベースには、ファイル名ではなくiノード専用の正常に送信されたオフセットがデータベースに保存されます。



ローテーションに関連するもう1つの小さな問題は、ファイルを削除する前に、他のユーザーがそのファイルに書き込まないことを何らかの方法で判断する必要があることです。 すべてのアプリケーションはflock（）を使用せずにO_APPENDフラグを使用してファイルに書き込むため、他の目的でflock（）を使用できます。 この場合、アプリケーションは、作業を開始する前に書き込むファイル記述子に対して共有ロック（LOCK_SH）を取得します。 ファイルが使用されなくなったことを確認するには、排他ロック（LOCK_EX）を取得する必要があります。 ロックを取得できた場合、ファイルは使用されなくなり、削除できます。 それ以外の場合は、ログファイルが解放されるまで待機し、一時的にローテーションを遅らせる必要があります。

パフォーマンス、結論

ログコレクターの以前のバージョンはシングルスレッドで動作し、PHPで記述されていたため、比較はあまり正直ではありません。 それでも、古いアーキテクチャと新しいアーキテクチャの両方の結果を提示したいと思います。



古いシステム（PHP、1つのストリーム）-サーバーあたり3 MiB / s-はPHPにとってまともな結果です。



新しいシステム（Go、完全非同期およびマルチスレッド）-サーバーあたり100 MiB / s-はネットワークカードとドライブ上にあります。



ログアセンブリシステムの変更の結果、システムにあったすべての問題を解決し、配信速度に大きなマージンをもたらしました。また、個々のクラスの「洪水」に対する耐性を獲得しました。 。 , , Go , .

参照資料

Open-source : github.com/badoo/thunder

open-source : tech.badoo.com/open-source



youROCK

Lead PHP developer