官术网_书友最值得收藏!

Logging and diagnostics

As usual, you can obtain a reference to ILogger<T> from the DI framework and use it in your views, like this:

@inject ILogger<MyView> Logger

But there is also another built-in mechanism, the DiagnosticSource class, and property, which is declared in the RazorPage base class. By calling its Write method, you can write custom messages to a diagnostics framework. These messages can be any .NET object, even an anonymous one, and there is no need to worry about its serialization. Have a look at the following code snippet:

@{
DiagnosticSource.Write("MyDiagnostic", new { data = "A diagnostic" });
}

What happens with this diagnostic message is actually somewhat configurable. First, let's add the Microsoft.Extensions.DiagnosticAdapter NuGet package, and then create a custom listener for the events generated for this diagnostic source, like this:

public class DiagnosticListener
{
[DiagnosticName("MyDiagnostic")]
public virtual void OnDiagnostic(string data)
{
//do something with data
}
}

We can add as many listeners as we want, targeting different event names. The actual method name does not matter, as long as it has a [DiagnosticName] attribute applied to it that matches an event name. We need to register and hook it to the .NET Core framework, in the Configure method, by adding a reference to the DiagnosticListener service so that we can interact with it, like this:

public void Configure(IApplicationBuilder app, DiagnosticListener diagnosticListener)
{
var listener = new DiagnosticListener();
diagnosticListener.SubscribeWithAdapter(listener);

//rest goes here
}

Notice that the name in the [DiagnosticName] attribute and DiagnosticSource.Write call match, and also, the name, data, of the anonymous type in the Write call matches the parameter name (and type) of the OnDiagnostic method.

Built-in .NET Core classes produce diagnostics for the following:

  • Microsoft.AspNetCore.Diagnostics.HandledException
  • Microsoft.AspNetCore.Diagnostics.UnhandledException
  • Microsoft.AspNetCore.Hosting.BeginRequest
  • Microsoft.AspNetCore.Hosting.EndRequest
  • Microsoft.AspNetCore.Hosting.UnhandledException
  • Microsoft.AspNetCore.Mvc.AfterAction
  • Microsoft.AspNetCore.Mvc.AfterActionMethod
  • Microsoft.AspNetCore.Mvc.AfterActionResult
  • Microsoft.AspNetCore.Mvc.AfterView
  • Microsoft.AspNetCore.Mvc.AfterViewComponent
  • Microsoft.AspNetCore.Mvc.BeforeAction
  • Microsoft.AspNetCore.Mvc.BeforeActionMethod
  • Microsoft.AspNetCore.Mvc.BeforeActionResult
  • Microsoft.AspNetCore.Mvc.BeforeView
  • Microsoft.AspNetCore.Mvc.BeforeViewComponent
  • Microsoft.AspNetCore.Mvc.Razor.AfterViewPage
  • Microsoft.AspNetCore.Mvc.Razor.BeforeViewPage
  • Microsoft.AspNetCore.Mvc.Razor.BeginInstrumentationContext
  • Microsoft.AspNetCore.Mvc.Razor.EndInstrumentationContext
  • Microsoft.AspNetCore.Mvc.ViewComponentAfterViewExecute
  • Microsoft.AspNetCore.Mvc.ViewComponentBeforeViewExecute
  • Microsoft.AspNetCore.Mvc.ViewFound
  • Microsoft.AspNetCore.Mvc.ViewNotFound

Hopefully, the names should be self-explanatory. Why would you use this mechanism over the ILogger-based one? This one makes it very easy to add listeners to a diagnostic source, with strongly typed methods. I will talk more about the differences between the two in Chapter 12, Logging, Tracing, and Diagnostics.

主站蜘蛛池模板: 沈丘县| 壶关县| 喀什市| 昌黎县| 平利县| 益阳市| 大名县| 阿拉善右旗| 海兴县| 德江县| 本溪| 三门峡市| 无棣县| 宝山区| 辉南县| 青阳县| 确山县| 夏邑县| 嘉峪关市| 山阳县| 定州市| 古浪县| 游戏| 平凉市| 开化县| 乌鲁木齐县| 东辽县| 贡觉县| 宁德市| 井研县| 桃江县| 吉木萨尔县| 石阡县| 黎城县| 武强县| 新闻| 廊坊市| 保德县| 霍林郭勒市| 武乡县| 合作市|