こんにちはLogify、またはインストールされたアプリケーションのエラーを監視

ご存知のように、エラーのないプログラムはありません。また、単体テストからコードアナライザーまで、リリースされたアプリケーションの品質を改善するために設計された多くのツールとアプローチがあります。 ただし、それらすべてを同時に使用しても、アプリケーションにエラーがないことを保証することはできません。 そして、開発およびテスト中に発生する問題がすぐに、まあ、またはほぼすぐに目に見えて、何が起こったのかという詳細な情報を取得してすぐに修正できる場合、ユーザー側で発生するリリース後のエラーはより潜行性があります。



最も重要なことは、ほとんどの場合、彼らは単にそれらについてあなたに通知しないことです。 これについて尋ねられたときに、マイクロソフトにエラーを送信した頻度はどのくらいですか? :)原則として、ユーザーは単にアプリケーションを再起動するか、 誓いを立ててそれをさらに使用し続けるか、完全に削除します。 運が良ければ、秋について通知されると、次のようになります。











そして、これは問題を理解する上で全く明確になりません。 その結果、ユーザーはあなたのプログラムを使用することでネガティブな体験を形成し、あなたはそれについて何かする方法がありません。



まあ、ユーザーには希望がないので、自分の手で問題を取り上げる必要があります。 そもそも、プログラムの例外的な状況をすべて処理できることを知っています。 たとえば、.NETでは、すべての実行に対してグローバルハンドラーをハングさせることができます。 次に実行できる最も簡単なことは、このハンドラーで実行されるすべてのアクションをログに書き込むことです。 これは少なくとも何かです。



ただし、ログだけでは送信されないため、ユーザーからのメッセージを待って問題を見つけ、このログを送信するように依頼する必要があります。これは時間の無駄です。実際、ユーザーはまったく書き込みを行わない場合があります。 または、ログを電子メールで送信することもできますが、十分な数の通知を受信した場合にメールボックスがどうなるか想像するのは怖いです。 そして、これは大規模なプロジェクトでは非常に現実的です。 とにかく、100,500行のテキストログファイルに書かれているものを整理するのは、あまり楽しい仕事ではありません。



その結果、最も適切なソリューションはクラウドでスピンし、発生したエラーに関する情報を受け取り、処理し、構造化し、便利な形式でWebインターフェイスを通じて表示するサービスであるという結論に達しました。 さて、なぜこのようなサービスを自分用に書いてみませんか?



最初に、これらのクラッシュに関するデータを受信するためにデモでクラッシュの最も単純なコレクターを作成し、それらに基づいてコンポーネントの問題を修正し、品質を改善しました。 これは単にカウントスタックとデモモジュールの名前でしたが、このデータでは不十分であることがすぐにわかり、拡張し始めました。 その結果、現在、エラーが発生した環境に関する非常に詳細な情報を収集しています。ロードされたライブラリのリストとスタジオおよびフレームワークのバージョンから始まり、OSのバージョンと現在インストールされているカルチャで終わります。 さらに、必要に応じて、CustomDataメカニズムを使用していつでも追加情報を追加できます。 たとえば、 テストレポートを見ることができます。



問題のある領域を見つけるのに十分な情報があったとき、私たちは時々多くのレポートがあるという事実に直面しました。 結局のところ、問題が十分に些細なものであれば、多くのユーザーが遭遇する可能性が高いでしょう。 そして、この状況では、それぞれからレポートを取得します。 結果として、同一ではないにしても、非常に類似したレポートがたくさんあります。







控えめに言っても、これらすべてを扱うのは難しいことは明らかです。さらに、これらすべての同一のレポートの中で、他の問題について警告するユニークなレポートも失われる可能性があります。 これを取り除くために、キーフィールドの特定のセットの重複検索を実装し、それらを1つのレポートにまとめます。







はい、それはすでにはるかに優れています。



ただし、重複に加えて、受信トレイにはかなり興味深いレポートがいくつかありました。たとえば、すでに修正された問題に関するレポートなどです。 これにより、特定の条件下で受信レポートを自動的に無視するタスクが必要になり、多くの条件が与えられました:バージョンに応じて無視することが可能であり、タイのキーワードにより、タイの特定の行で、ネクタイのコンポーネントが私たちなどに届かなかった、など その結果、無視ルールの4つの主要なタイプを特定し、これがすべてのタスクをカバーしました。 一般に、このトピックは別の記事にふさわしいので、ここでドキュメントへのリンクを提供して、このメカニズムについて一般的な印象を与えることができます: フィルターを無視する



このサービスを使用する過程で、彼にとって別の珍しいアプリケーションが見つかりました。彼はサポート部門を完全に助けることができます。 多くの場合、ユーザーは何らかの問題があると書きますが、それはユーザーのマシン上でのみ再現され、エラー自体に関する詳細な情報を提供または受信する方法はありません。 または、たとえば、権限が制限されているプログラムでエラーが発生し、ログファイルを書き込めません。 これらすべての状況において、Logifyが私たちをうまく助けてくれます。なぜなら、デプロイされたアプリケーションのクラッシュに関するデータを収集することが主なタスクだからです。



その結果、Logifyは多くの製品に統合され、具体的なメリットを提供しています。 開発の過程で、Logifyは明らかに内部使用のための単なるプロジェクトではなくなったため、別のサービスとしてリリースすることにしました。 最初にベータ版で再設計されたUIを使用して、一般に公開されましたが、現在はすでに実稼働で完全にリリースされています。 だから誰も気にしないで、試してみてください: Logify 。 顧客はGitHubで利用できます



All Articles