Aspnetcore: EventSource？ DiagnosticSource？ どちらも？

@ rynowak-共有できるこれに関するガイダンスはありますか？

私は内部で何度も繰り返したいくつかの簡単な考えですが、外部についてはよくわかりません...

EventSource

EventSourceの使用は、LTTNGやETWなどのアウトプロセスロギングメカニズムの使用も意味すると想定します。 EventSourceは、忠実度の低い情報を含むいくつかのデータポイントを起動して後で確認し、ある種の統計または要約にコンパイルする場合に最適です。 EventSourceの一般的な使用法は、イベントをファイル（ETW）にパイプし、それらを使用して事後分析を行うことであるため、忠実度が低いと言います。 PerfViewのようなEventSourceからのデータを見るツールは、いくつかのイベント（JIT、GC）に関する特別な知識を持っていますが、作成するイベントについては、一般的なビューを表示します。 データの一般的なビューまたは要約/表を表示することは、すべて単純なタイプであるため機能します。 もちろん、専用のツールを作成することもできますが、一般的なケースは、PerfViewのようなものを使用することです。

次の声明は明白に思えますが、それについて言及する理由はすぐに明らかになることを願っています。 EventSourceを使用すると、発生するイベントの解釈が事前に決定されます。 記録するすべてのデータはコンポーネントの作成者によって指定され、通常はイベント名に関連付けられた固定の意味を持ちます。 EventSourceを使用すると、「4096バイトのデータを読み取る」や「5.6msでファイルをロードする」などとよく言われます。 これらの小さな事実の記述は、「ファイルI / Oの実行に費やされた150ミリ秒」のような要約にまとめたり、外れ値の場合は具体的に掘り下げたりすることができます。

DiagnosticSource

DiagnosticSourceの使用は、データを意味のあるナゲットに抽出する「プラグイン」または別のロギングシステムによってインプロセスで行われていると想定します。 DiagnosticSourceは、アプリケーションの状態の完全なコンテキストをリスナーに渡し、そのリスナーがアプリケーションの状態へのアクセスに基づいて独自の解釈を追加する場合に最適です。 DiagnosticSourceには、ネイティブのログ形式もありません。また、データポイントの一般的な理解もありません（通常は単純なタイプではないため）。ユーザーが見たいものを作成するには、追加のシステムが必要です。

DiagnosticSourceイベントは分厚い傾向があり、「リクエストを処理しようとしています」や「ミドルウェアによってスローされた例外をキャッチしました」などと表示されます。 これらはまだ事実の表明ですが、範囲ははるかに大きいです。 ツールは豊富なコンテキストにアクセスできるため、コンテキストに応じて意味のある情報を自由にキャプチャできます。 最終的に、Application Insightsなどのツールによってキャプチャされる一連の情報は、ASP.NETチームによって定義されません。 私たちは彼らに私たちが持っているすべてのコンテキストを提供し、彼らが重要だと思うものをキャプチャします。

ブリッジを介してDiagnosticSourceデータをEventSourceにパイプすることもできます。 私は個人的にこれを行っていませんが、場所によっては必要な診断コードの量が2倍になるのを避けるつもりのようです。 https://github.com/dotnet/corefx/blob/master/src/System.Diagnostics.DiagnosticSource/src/System/Diagnostics/DiagnosticSourceEventSource.cs#L22すべてのでDiagnosticSourceを使用するとは思いませんEventSourceと同じ場所。 これを活用した戦略がどのように機能するかはわかりませんが、試したことはありません。

私たちにとって、この領域は数回変更されました。 ここでは、Glimpseとの提携から始め、最終的にApplicationInsightsとの提携を開始しました。 その過程で、診断ソースの上に他のいくつかのものが構築されましたが、それらの他のツールの現在のステータスはわかりません。

私たちの計画

EventSourceやDiagnosticSourceに関するより大きな戦略について話すことはできませんが、私がそれらをどのように考えているか、そしてチームのほとんどが私たちのアプローチをどのように見ているかについては答えることができます。 EventSourceの代わりとしてDiagnosticSourceを作成しませんでした。 私の考えでは、それは異なる消費者と一連のシナリオに役立ちます。

診断ソースイベントを追加して、多くの価値が追加されると考えます。 これらのいくつかは、他の誰かが診断を構築するための拡張性のようなものであるため、非常に長い道のりを進みます。 ホスティングにはおそらく3〜5の診断ソースポイントがあり、MVCには10に近いと思います。現在追跡している場所が他にあるかどうかはわかりません。 誰かが真のニーズを持っているなら、私たちはそれを検討します。

イベントソースの構築を行っています。 これは、フィールドサポートエンジニアが精通していることであり、通常、マイクロソフトのチームのパフォーマンス分析の重要な部分です。 パフォーマンスカウンターがないために残された空白を解決しようとしています。 .NETチームは、適切な代替としてEventCounters（EventSourceの上に構築）を作成するために取り組んでいます。 ASP.NETチームがEventSourceにさらに投資するのが遅れた主な理由は、しばらくの間、Windows以外の戦略がどうなるかが明確でなかったためです。 EventSourceが* nixプラットフォームで使用されない場合は、将来、別のものを作成することを避けたかったのです。 それは片付けられました。

ここに良いドキュメントがあります： https ：

あなたのために

まあ、それはあなたが両方またはどちらかを行うことができるように聞こえます。 私はあなたが取り組んでいることにあまり精通していないので、以下はいくつかの一般的なアドバイスです。

まず、あなたの消費者が誰であるかを考えてください。 これはあなたのためですか？ （perf）これはアプリケーション開発者向けですか？ （デバッグとトラブルシューティング）これはツールの作成者向けですか？ ツールは事後分析ですか、それともアプリ内で実行されていますか？

次に、計測する予定の場所の数と、意味があると思うデータの種類について考えます。 消費者はこのデータをどのように理解し、解釈しますか？ 個々のデータポイントは意味がありますか、それともデータを集約する必要がありますか？

長期間更新されていない「ディスカッション」の問題は定期的にクローズします。

ご不便をおかけして申し訳ございません。 それでも問題が発生する場合は、更新された情報を使用して新しい問題をログに記録してください。調査いたします。