ソフトウェア製品が複雑になるほど、サードパーティのシステムとのやり取りが多くなり（多くの場合、それほど複雑ではありません）、誤動作の可能性が高くなります。 テストはリリースを公開する前にほとんどのバグを見つけるのに役立ちますが、時には何かがすり抜けることがあります 。 また、障害の事実と関連する状態に関する詳細な情報を迅速に受け取るために、当社の製品ではレポートシステムが広く使用されています。 今日はそのデバイスについてお話したいと思います。
通常、アプリケーションは、バグまたは予測不可能なユーザー操作によりクラッシュします。 クラッシュの原因を理解するには、さまざまな情報を収集する必要があります。アプリケーションが動作する環境、ユーザーがしたこと。 一般に、問題の解決に役立つデータ。 このために、システムを使用して、アプリケーションの動作と障害の事実に関するレポートを送信します。
障害の原因の調査に加えて、レポートを使用してユーザーの行動を分析します。 これを行うために、およそ3か月ごとに、アプリケーションの使用に関する統計の匿名収集を開始します。 どの機能が最も頻繁に使用され、どのような状況で、ユーザーに問題があるかを調べます。 これは、製品開発計画の調整に役立ちます。 たとえば、 Parallels Desktopをご覧ください。 1台の仮想マシン、2台、4台などを実行するユーザーの数に関心があります。 それらのほとんどに1つのVMがある場合、複数の仮想マシンを使用するためにインターフェースを大幅に最適化するなどの意味がないことは明らかです。
実装の詳細
レポートは、アプリケーションがクラッシュしたとき、およびユーザー主導で自動的に送信されます。 これには、アプリケーションログ、クラッシュダンプ、メモリダンプ、マシン構成情報、およびその他のサービス情報が含まれる場合があります。 これらはすべてtar.gzファイルにパックされ、そのサイズは単位から数百メガバイトの範囲であり、サーバーに送信されます。 ここで、ファイルは1次処理の対象となり、サービス情報（送信者のIPアドレスとタイムスタンプ）が追加されてから、ファイルがMongoDBにアップロードされます。
次に、2つのシナリオがあります。
•開発者は、XMLファイル、ログ、および構成を手動で分析して、アプリケーションが実行されている環境とユーザーが何をしていたかを理解できます。
•レポートは自動的に分類され、一般的な統計に含まれます。
分類は次のとおりです。Pythonで記述されたパーサーは、 RabbitMQからMongoDBにアップロードされたレポートの IDを受け取り、それらから状態トレースを抽出し、特定のルールに従ってテキストラベル-署名を割り当てます。 パーサーは、XMLファイルから必要なデータを抽出し、それらをインデックス付きフィールドを持つ個別のドキュメントとして追加します。
また、特別なパーサーもあり、それぞれが特定の種類のクラッシュレポートを処理します。 各レポートを調べて、関心のあるファイルがあるかどうかを確認します。 たとえば、あるパーサーはMacレポートのみを検索し、別のパーサーはWindowsのみを検索します。 次に、まったく同じ方法で署名を作成します。 レポートコンポーネントはChefを使用してデプロイされます。
リアルタイムレポートの一般的な統計は、署名と個々のフィールドでデータを並べ替えることができる特別なWebページに表示されます。 たとえば、Mac OS、ゲストOSおよび製品バージョンに応じて。 これにより、たとえば次の更新後にいくつかの署名の数が急激に増加し始めた場合に、最初に解決する必要がある問題をすばやく理解できます。
サーバーパーク
1か月あたり平均100ギガバイトの約40万件のレポートを処理しています。 10年以上にわたり、5000万を超えるさまざまなレポートを蓄積してきました。 ほとんどのユーザーは米国にいるため、レポートを受信するサーバーは米国にあります。 しかし、データの保存、処理、分析はロシアで行われています。 時には、海を渡って処理して送信する時間よりも早くレポートが届くことがありました。 これで、すでにキューとマイクロサービスを使用して解析するシステムのテストと実装が開始されました。 マイクロサービスの数は現在の負荷に応じて変更できるため、唯一の帯域幅が唯一の制限になる可能性があります。
レポートシステムに対応するサーバーの数：
必要に応じて、サブシステムのいずれかを拡大する負荷に合わせてスケーリングできます。
レポートは、障害に関する詳細情報のソースであるだけでなく、「早期警告」システムでもあります。 多くの場合、ユーザーはすぐにサポートに連絡せず、数回問題に遭遇しただけです。 しかし、自動レポートのおかげで、障害の数がすぐに増加し、すぐに問題の解決が開始されます。 多くの場合、呼び出しの波がサポートに入る前であってもバグを修正します。