そのため、開発マシンのコンソール アプリケーションでホストしている WCF サービスがあります。同じマシンでPerfViewを実行して、ETW (Event Tracing for Windows) イベントを収集しています。WCF サービスは TPL (Task Parallel Library) を利用しており、WCF 要求の存続期間全体にわたって、すべてのスレッドで ETW イベントを関連付けようとしています。私はクライアントとサーバーの間ではなく、サーバー上で厳密に話しています。ただし、PerfViewでイベントを見て、カスタムからのイベントのみにビューをフィルター処理すると、EventSource一部のスレッドのイベントのみにActivityId. 任意のスレッドについて、すべてのイベントに があるか、どのイベントにもないかのいずれかActivityIdです。また、どのイベントにもRelatedActivityId.
このリンクはセマンティック ロギング アプリケーション ブロック (SLAB) に関連していますが、その中で次のことが言及されています。
TPL タスクを使用する場合、各スレッドは独自のアクティビティ ID を取得し、TPL スケジューリング コードは、ActivityId 値と RelatedActivityId 値を含む転送イベントを自動的に発行します。これらを使用して、関連するイベントを関連付けることができます。
それは私にはまったく当てはまらないようです。アクティビティ ID を関連付ける転送イベントが表示されないだけでなく、多くの場合、前述のように、アクティビティ ID が完全に欠落しています。
この SO の回答によると: https://stackoverflow.com/a/27620321/1937249 :
アウト プロセス リスナーを使用する場合、名前による TPL 構成が機能せず、代わりに GID が使用されるというバグがあります: https://slab.codeplex.com/workitem/62
そこで、イベント ソースの GUID を次のように名前の代わりにPerfView の「追加プロバイダー」に追加してみました。
しかし、違いはありませんでした。私のイベントは公開されましたが、それらの多くはまだそれらがなくActivityId、すべてのイベントでそれらがありませんでしたRelatedActivityId.
関連する可能性のある最後の 1 つのことは、フレームワークに組み込まれているものではなくMicrosoft.Diagnostics.Tracing、NuGet パッケージの名前空間を使用していることです。Microsoft.Diagnostics.Tracing.EventSourceSystem.Diagnostics.Tracing
編集
TplEventSource からキャプチャされたすべてのイベント タイプを示す画像を次に示します。TplEventSource が有効になっていることを意味すると思います。リストに「移籍イベント」が表示されるべきなのか、それともイベントの 1 つに移籍であることを示すキーワードやその他のフィールドが必要なのか、はっきりしません。実際の「転送イベント」があると思われる場合、リストにそのようなものは表示されません。
PerfView の出力
EventSourceこれは、単一の WCF 要求に対するカスタムのイベント リストの図です。リクエストがスレッド ID 10,724 で開始されていることがわかります。そのスレッドのすべてのイベントにはActivityId. 「Asi-Geoservices/StartAuthenticateRequest/Start」は非同期データベース呼び出しを行い、アプリケーションはスレッド 8,268 で再開します。スレッド 8,268 のイベントにはActivityId. 「Asi-Geoservices/StartServiceProviderRequest/Start」は非同期 HTTP リクエストを作成し、アプリケーションはスレッド 11,764 で再開します。ここでも、このスレッドの各イベントにはActivityId. 「Asi-Geoservices/StartServiceProviderRequest/Stop」の後、別の非同期データベース呼び出しが行われ、アプリケーションがスレッド 8,268 で再び再開され、そこでリクエストが最終的に完了します。ActivityId.
