.NET Core のログとトレース.NET Core logging and tracing

ログとトレースは、実際には同じ手法の 2 つの名前です。Logging and tracing are really two names for the same technique. コンピューターの初期の頃から、単純な手法が使用されています。The simple technique has been used since the early days of computers. アプリケーションをインストルメント化して、後で使用するために出力を書き込みます。It simply involves instrumenting an application to write output to be consumed later.

ログとトレースを使用する理由Reasons to use logging and tracing

この単純な手法は、驚くほど強力です。This simple technique is surprisingly powerful. これは、次のようなデバッガーでは対応できない場合に使用できます。It can be used in situations where a debugger fails:

  • 長期間にわたって発生する問題は、従来のデバッガーでデバッグするのが困難な場合があります。Issues occurring over long periods of time, can be difficult to debug with a traditional debugger. ログを使用すると、長期間にわたる詳細な事後分析を行うことができます。Logs allow for detailed post-mortem review spanning long periods of time. これに対し、デバッガーはリアルタイム分析に制約されます。In contrast, debuggers are constrained to real-time analysis.
  • 多くの場合、マルチスレッド アプリケーションと分散アプリケーションはデバッグが困難です。Multi-threaded applications and distributed applications are often difficult to debug. デバッガーをアタッチすると、動作が変更される傾向があります。Attaching a debugger tends to modify behaviors. 必要に応じて詳細ログを分析することで、複雑なシステムを理解できます。Detailed logs can be analyzed as needed to understand complex systems.
  • 分散アプリケーションの問題は、多くのコンポーネント間の複雑な相互作用によって生じる可能性があり、デバッガーをシステムのすべての部分に接続するのは合理的でない場合があります。Issues in distributed applications may arise from a complex interaction between many components and it may not be reasonable to connect a debugger to every part of the system.
  • 多くのサービスは停止することができません。Many services shouldn't be stalled. デバッガーをアタッチすると、多くの場合、タイムアウト エラーが発生します。Attaching a debugger often causes timeout failures.
  • 問題は常に予測できるとは限りません。Issues aren't always foreseen. ログとトレースは、問題が発生した場合に備えてプログラムで常に記録できるように、オーバーヘッドが低くなるように設計されています。Logging and tracing are designed for low overhead so that programs can always be recording in case an issue occurs.

.NET Core API.NET Core APIs

System.ConsoleSystem.Diagnostics.Trace、および System.Diagnostics.Debug クラスはそれぞれ、ログ記録に便利な出力スタイルの API を備えています。The System.Console, System.Diagnostics.Trace, and System.Diagnostics.Debug classes each provide similar print style APIs convenient for logging.

どの出力スタイル API を使用するかは、ユーザーが決定します。The choice of which print style API to use is up to you. 主な違いを次に示します。The key differences are:

  • System.Console
    • 常に有効であり、常にコンソールに書き込みます。Always enabled and always writes to the console.
    • 顧客がリリースで参照する必要のある情報の場合に便利です。Useful for information that your customer may need to see in the release.
    • 最も簡単な方法であるため、アドホックな一時デバッグによく使用されます。Because it's the simplest approach, it's often used for ad-hoc temporary debugging. このデバッグ コードは、多くの場合、ソース管理にチェックインされません。This debug code is often never checked in to source control.
  • System.Diagnostics.Trace
    • TRACE が定義されている場合にのみ有効になります。Only enabled when TRACE is defined.
    • アタッチされている Listeners (既定では DefaultTraceListener) に書き込みます。Writes to attached Listeners, by default the DefaultTraceListener.
    • ほとんどのビルドで有効になるログを作成するときに、この API を使用します。Use this API when creating logs that will be enabled in most builds.
  • System.Diagnostics.Debug
    • DEBUG が定義されている場合にのみ有効になります。Only enabled when DEBUG is defined.
    • アタッチされたデバッガーに書き込みます。Writes to an attached debugger.
    • *nix では、COMPlus_DebugWriteToStdErr が設定されている場合は stderr に書き込みます。On *nix writes to stderr if COMPlus_DebugWriteToStdErr is set.
    • デバッグ ビルドでのみ有効になるログを作成するときに、この API を使用します。Use this API when creating logs that will be enabled only in debug builds.

イベントのログ記録Logging events

次の API は、よりイベント指向です。The following APIs are more event oriented. 単純な文字列をログに記録するのではなく、イベント オブジェクトをログに記録します。Rather than logging simple strings they log event objects.

  • System.Diagnostics.Tracing.EventSource

  • System.Diagnostics.DiagnosticSource

    • .NET Core に含まれており、.NET Framework の NuGet パッケージとして提供されています。Included in .NET Core and as a NuGet package for .NET Framework.
    • シリアル化できないオブジェクトのインプロセス トレースを可能にします。Allows in-process tracing of non-serializable objects.
    • ログ対象オブジェクトの選択したフィールドを EventSource に書き込むことができるようにするブリッジが含まれています。Includes a bridge to allow selected fields of logged objects to be written to an EventSource.
  • System.Diagnostics.Activity

    • 特定のアクティビティまたはトランザクションによって生成されたログ メッセージを明確に識別する方法を提供します。Provides a definitive way to identify log messages resulting from a specific activity or transaction. このオブジェクトを使用すると、さまざまなサービス間でログを相互に関連付けることができます。This object can be used to correlate logs across different services.
  • System.Diagnostics.EventLog

    • Windows のみ。Windows only.
    • Windows イベント ログにメッセージを書き込みます。Writes messages to the Windows Event Log.
    • システム管理者は、致命的なアプリケーション エラー メッセージが Windows イベントログに記録されることを想定しています。System administrators expect fatal application error messages to appear in the Windows Event Log.

ILogger とログ記録フレームワークILogger and logging frameworks

低レベルの API は、ログ記録のニーズに適しているとは限りません。The low-level APIs may not be the right choice for your logging needs. ログ記録フレームワークを検討することもできます。You may want to consider a logging framework.

ILogger インターフェイスは、依存関係の挿入を通じてロガーを挿入できる共通のログ インターフェイスを作成するために使用されています。The ILogger interface has been used to create a common logging interface where the loggers can be inserted through dependency injection.

たとえば、アプリケーションに最適な選択を可能にするために、ASP.NET では、組み込みおよびサードパーティのフレームワークを選択できるようにしています。For instance, to allow you to make the best choice for your application ASP.NET offers support for a selection of built-in and third-party frameworks:

パフォーマンスに関する考慮事項Performance considerations

文字列を書式設定すると、CPU 処理時間が著しく長くなる可能性があります。String formatting can take noticeable CPU processing time.

パフォーマンス クリティカルなアプリケーションでは、次のことをお勧めします。In performance critical applications, it's recommended that you:

  • リッスンしているものがない場合は、大量のログを記録しないようにします。Avoid lots of logging when no one is listening. 最初にログ記録が有効かどうかを確認することで、負荷の高いログ メッセージを作成しないようにします。Avoid constructing costly logging messages by checking if logging is enabled first.
  • 役に立つものだけをログに記録します。Only log what's useful.
  • 凝ったフォーマット設定は分析ステージで行います。Defer fancy formatting to the analysis stage.