問題タブ [etw-eventsource]

Microsoft は最近、新しいSemantic Logging Blockを含むEnterprise Library 6をリリースしました。セマンティック ログ ブロックで利用できるオプションの 1 つは、ログ メッセージをWindows Azure テーブル ストレージに書き込む機能です。これは、Azure ベースのアプリケーションにログを実装する優れた方法のように思えます。残念ながら、いったんログを取得したらどうすればよいかわかりません。Azure Table Storage からログ エントリを取得できるログ ビューアーはありますか? ファイルではなく Azure Table Storage を監視する "tail" ユーティリティを基本的に探していると思います。

.NET 4.5 に含まれていたEventSourceクラスを介して、.NET アプリケーションでEvent Tracing for Windows (ETW)を使用しようとしています。私は次のようにサブクラス化し、 （モック目的で）インターフェイスを実装しようとしています：EventSourceMyEventSourceIMyEventSource

PerfViewを実行してこのコードを実行すると、IndexOutOfRangeExceptionへの呼び出しで が発生しWriteEventます。コードを変更してインターフェイスを削除すると...

...その後、すべてが正常に機能します。

両方のケースでテストに使用したコードは次のとおりです。

EventSource単純にインターフェイスを実装しているのに、サブクラスが壊れるのはなぜですか?

関連記事はこちら。

EventSourceクラスを使用して ETW イベントを発行するように .NET 4.5 アプリケーションをインストルメント化しています。目標は、エラー ログ用にこれらのイベント (エラー レベル イベント) の一部をキャプチャできるようにすることです。

いくつかの読み取りとテストを行った後、エラーログへのこのアプローチの信頼性、特にイベントのドロップまたは欠落の可能性について懸念しています。エラー ログが機能しない場合は、アプリケーションをシャットダウンする必要があります (私の場合、報告されていないエラーで実行するのは安全ではありません)。ETW と を使用しEventSourceている場合、エラーが適切に記録されていることを確認するにはどうすればよいですか?

明らかに、答えの一部は、何がイベントをリッスンしているかによって異なります。私の場合、最新の MS Enterprise Library の「Semantic Logging Application Block」を使用する予定です。

以下は、Microsoft が見逃したイベントの考えられる原因について話しているソースの 1 つです。 イベント トレーシングについて

そこには、欠落イベントの考えられる原因がリストされています

• イベントの合計サイズが 64K を超えています。これには、ETW ヘッダーとデータまたはペイロードが含まれます。イベントのサイズはアプリケーションによって設定されるため、ユーザーはこれらの欠落したイベントを制御することはできません。

• ETW バッファー サイズが合計イベント サイズよりも小さい。イベントのサイズはイベントをログに記録するアプリケーションによって設定されるため、ユーザーはこれらの欠落したイベントを制御することはできません。

• リアルタイム ログの場合、リアルタイム コンシューマーがイベントを十分に高速に消費していないか、完全に存在しないため、バッキング ファイルがいっぱいになります。これは、イベントがログに記録されているときにイベント ログ サービスが停止され、開始された場合に発生する可能性があります。ユーザーは、これらの欠落したイベントを制御できません。

• ファイルにログを記録するとき、ディスクが遅すぎてログ速度に追いつけません。

これらの懸念が EventSource クラスを使用して何らかの方法で緩和されたかどうか (たとえば、大きなペイロードを何らかの方法で切り捨てるかどうか) を確認するために、いくつかのテストを行いました。長い文字列をログに記録しようとしましたが、30,000 から 35,000 文字の間で失敗しました (64KB の最大イベント ペイロードと一致しています)。大きすぎる文字列について私が知ることができることから、黙って何もしません。セマンティック ログのアプリケーション ブロック ログにイベントはまったくありません。前後の出来事はいつものように書かれています。

ペイロードに文字列があるときはいつでも、トランケータを介して渡す必要がありますか? 「速すぎる」イベントの生成を手動で回避する必要がありますか (また、それはどのように可能でしょうか)。

Microsoft のパターンとプラクティスは、私たちを適切なパターンとプラクティスに導くはずなので、ここで何かが欠けているだけかもしれません。

アップデート：

どうやら、「イベントが速すぎる」状態について、消費アプリケーションに何らかの通知があるようです。今日初めてこれを受け取りました：

レベル: 警告、メッセージ: トレース セッションでのバッファー オーバーランまたはスキーマ同期の遅延により、一部のイベントが失われます: Microsoft-SemanticLogging-Etw-svcRuntime

そして、セッションを閉じるとき：

レベル: 警告、メッセージ: トレース セッション 'Microsoft-SemanticLogging-Etw-svcRuntime' で 1 つのイベントの損失が検出されました。

アップデート2:

Enterprise Library Developers Guideでは、先ほど説明した動作について説明しています。

セマンティック ログ アプリケーション ブロックによって生成されたログ メッセージを監視して、バッファがオーバーフローしたことやメッセージが失われたことを示す兆候がないかどうかを確認する必要があります。たとえば、イベント ID 900 および 901 のログ メッセージは、シンクの内部バッファがオーバーフローしたことを示します。アウト プロセス シナリオでは、イベント ID 806 および 807 は、ETW バッファーがオーバーフローしたことを示します。シンクのバッファリング構成オプションを変更して、通常のワークロードでバッファがオーバーフローする可能性を減らすことができます。

エラーがドロップされた場合にアプリケーションが実行されないようにしながら、セマンティック ロギングを使用できますか? 通常のトレース イベントがドロップされる可能性があります ...

私の現在の考えでは、昔ながらのロギング手法を使用して別のクラスで「重大な」エラーをログに記録し、重大度の低いエラー (およびデバッグ タイプのイベント) は ETW パイプラインを通過するようにします。それはそれほど悪くはありません...より良い提案が見つからない場合は、解決策として投稿するかもしれません.

更新 3:

string私が受け取った「missing events」という警告は、バッファ オーバーランとは何の関係もありませんでした。これは、ペイロード値としてnull を渡した場合に表示されるメッセージであることがわかりました。

.net 4.5 で ETW を使用しようとしています。

WCF サービスとコンソール アプリがあり、EventSource を使用してメッセージを書き込む必要がありますが、ファイル (ローリング ファイル) にログを記録するための独自の ETW (EventSource と EventListener) を作成する方法を理解するのに苦労しています。

助言がありますか？

実行時に EventSource Name を設定できるかどうかを知りたいです。

異なる EventSource にログを記録したい複数のアプリケーションがあります。これを構成可能にすることができれば、EventViewer のコンポーネントを再利用できます。

EventSourceAttribute に関する追加情報

前もって感謝します。

ETW を使用して例外をログに記録する標準的な方法はありますか?

私が見た限り、これを行う唯一の方法は、例外タイプの厳密に型指定されたパラメーターがないため、メッセージとおそらく内部例外メッセージをログに記録することです。