为了减少由于单个请求挂掉而拖垮整站的情况发生,给所有请求做统计是一个不错的解决方法,通过观察哪些请求的耗时比较长,我们就可以找到对应的接口、代码、数据表,做有针对性的优化可以提高效率。在 asp.net web api 中我们可以通过注册一个 DelegatingHandler 来实现该功能。那在 asp.net core 中该如何实现呢?

一:比较 asp.net web api 和 asp.net core 的请求管道

使用NLog给Asp.Net Core做请求监控的方法 

使用NLog给Asp.Net Core做请求监控的方法

观察这两张图,可以发现他们非常的相似,都是管道式的设计,在 asp.net web api 中,我们可以注册一系列的 DelegatingHandler 来处理请求上下文 HttpRequestMessage,在 asp.net core 中,我们可以注册一系列中间件来处理请求上下文,他们两者从功能和意义上是非常相似的,我这里这里不会详细介绍各自的管道是如何的(这样的文章非常多,博客园随处可见),他们都完成了类似中间件的功能,只是在代码设计上有一点区别。

我们先看一段代码,新建一个 asp.net web api 项目,添加几个 DelegatinHandler

然后在 Global 中注册

public class DelegatingHandler1 : DelegatingHandler
  {
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
      Trace.WriteLine("DelegatingHandler1 HashCode: " + this.GetHashCode());
      Trace.WriteLine("DelegatingHandler1 base InnerHandler HashCode: " + base.InnerHandler.GetHashCode());
      Trace.WriteLine("DelegatingHandler1 start");
      var response = await base.SendAsync(request, cancellationToken);
      Trace.WriteLine("DelegatingHandler1 end");
      return response;
    }
  }
  public class DelegatingHandler2 : DelegatingHandler
  {
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
      Trace.WriteLine("DelegatingHandler2 HashCode: " + this.GetHashCode());
      Trace.WriteLine("DelegatingHandler2 base InnerHandler HashCode: " + base.InnerHandler.GetHashCode());
      Trace.WriteLine("DelegatingHandler2 start");
      var response = await base.SendAsync(request, cancellationToken);
      Trace.WriteLine("DelegatingHandler2 end");
      return response;
    }
  }
  public class DelegatingHandler3 : DelegatingHandler
  {
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
      Trace.WriteLine("DelegatingHandler3 HashCode: " + this.GetHashCode());
      Trace.WriteLine("DelegatingHandler3 base InnerHandler HashCode: " + base.InnerHandler.GetHashCode());
      Trace.WriteLine("DelegatingHandler3 start");
      var response = await base.SendAsync(request, cancellationToken);
      Trace.WriteLine("DelegatingHandler3 end");
      return response;
    }
  }

修改一下 ValuesController

public class WebApiApplication : System.Web.HttpApplication
  {
    protected void Application_Start()
    {
      AreaRegistration.RegisterAllAreas();
      GlobalConfiguration.Configure(WebApiConfig.Register);
      FilterConfig.RegisterGlobalFilters(GlobalFilters.Filters);
      RouteConfig.RegisterRoutes(RouteTable.Routes);
      BundleConfig.RegisterBundles(BundleTable.Bundles);

      GlobalConfiguration.Configuration.MessageHandlers.Add(new DelegatingHandler1());
      GlobalConfiguration.Configuration.MessageHandlers.Add(new DelegatingHandler2());
      GlobalConfiguration.Configuration.MessageHandlers.Add(new DelegatingHandler3());
    }
  }

启动后输入路径 /api/values,我们可以在VS 的输出栏看到下面这些内容

public class ValuesController : ApiController
  {
    // GET api/values
    public IEnumerable<string> Get()
    {
      Trace.WriteLine("/api/values");
      var handlers = this.RequestContext.Configuration.MessageHandlers;
      return new string[] { "value1", "value2" };
    }
  }

启动后输入路径 /api/values,我们可以在VS 的输出栏看到下面这些内容

DelegatingHandler1 HashCode: 58154627
DelegatingHandler1 base InnerHandler HashCode: 35529478
DelegatingHandler1 start
DelegatingHandler2 HashCode: 35529478
DelegatingHandler2 base InnerHandler HashCode: 47422476
DelegatingHandler2 start
DelegatingHandler3 HashCode: 47422476
DelegatingHandler3 base InnerHandler HashCode: 65273341
DelegatingHandler3 start
/api/values
DelegatingHandler3 end
DelegatingHandler2 end
DelegatingHandler1 end

输出中我们可以看到 DelegatingHandler1 的 InnerHandler 是 DelegatingHandler2,以此类推,在 DelegatingHandler3 的 InnerHandler 处理请求的时候就转发到了相关控制器,这里和 .net core 中的中间件非常相似,在.net core 中间件顺序是 RequestServicesContainerMiddleware(给请求上下文绑定容器)-> AuthenticationMiddleware(认证)-> RouterMiddleware (路由以及MVC)

如果我们在 ValuesController 中观察表达式 this.RequestContext.Configuration.MessageHandlers 还可以看到最终处理请求的是一个 HttpRoutingDispatcher,最也是是分配到路由以及控制器来处理的,按照如此方式我们可以很容易在 asp.net web api 中对请求统计。这里是比较简陋的,对此我们可以记录客户端和服务器更详细的信息,包括 IP 地址,http状态码,是否是认证用户等等,但是这篇主要是以 asp.net core 为主的,所以这里就不详细写下去了。

public class ApplicationInsight : DelegatingHandler
  {
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
    {
      var stopWatch = new Stopwatch();
      stopWatch.Start();

      var response = await base.SendAsync(request, cancellationToken);

      stopWatch.Stop();
      //停止计时器,并记录
    }
  }
  public partial class Startup
  {
    public void Configuration(IAppBuilder app)
    {
      GlobalConfiguration.Configuration.MessageHandlers.Add(new ApplicationInsight());
    }
  }

二:asp.net core 中间件 + NLog 实现请求监控

先看统计结果,start 开始时间,time 是请求消耗时间(毫秒),authenicate 是认证通过的 schema,使用 NLog 自定义字段也是非常方便的

使用NLog给Asp.Net Core做请求监控的方法

先说一说遇到的问题

(1)NLog 记录一张以上的表如何实现,应为首先会有一个一般性的日志表(称他为 log),并且这些统计不对写到 log 表

(2)使用 NLog 自定义字段 LayoutRenderer 没有类似 .net framework 中的 System.Web.Current

(3)使用 UseMiddleware 无法在让我们的中间件成为第一个中间件

(4)实现忽略记录的方法,肯定有一些接口是不希望记录的,所以这个也要实现

NLog 配置

这里只列出了部分内容,github 地址在最后,数据库是 mysql ,apiinsight 表示请求统计,log 是一般性的日志,debughelper 可以加快我们调试时日志的检索速度

<targets>
  <!--黑洞 忽略的日志-->
  <target xsi:type="Null"
      name="blackhole" />
  <!--文件日志-->
  <target xsi:type="File"
    name="debughelper"
    fileName="${var:root}\Logs\debug_helper.log"
    layout="${longdate}|${event-properties:item=EventId.Id}|${logger}|${uppercase:${level}}|${message} ${exception}" />
  <!--apiinsight api 统计-->
  <target name="apiinsight" xsi:type="Database"
       dbProvider="MySql.Data.MySqlClient.MySqlConnection, MySql.Data"
       connectionString="${var:connectionString}"
       >
  </target>
  <!--日志-->
  <target name="log" xsi:type="Database"
     dbProvider="MySql.Data.MySqlClient.MySqlConnection, MySql.Data"
     connectionString="${var:connectionString}"
       >
  </target>
 </targets>

在 Startup 中

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
  //省略了其他配置

  //全局的 HttpContext
  app.UseGlobalHttpContext();

  //省略了其他配置

  LogManager.Configuration = new XmlLoggingConfiguration(Path.Combine(env.ContentRootPath, "nlog.config"));
  LogManager.Configuration.Variables["root"] = env.ContentRootPath;
  LogManager.Configuration.Variables["connectionString"] = Configuration.GetConnectionString("DefaultConnection");
}

自定义字段都是通过 LayoutRenderer 实现,由于自定义字段有很多,这里只列出了一个开始时间是如何查询的,这个时间是在我们注册的第一个中间件执行 Invoke 方法的时候写进 HttpContext.Items 的

[LayoutRenderer("apiinsight-start")]
  public class StartApiInsightRenderer : LayoutRenderer
  {
    protected override void Append(StringBuilder builder, LogEventInfo logEvent)
    {
      var httpContext = HttpContextProvider.Current;
      if (httpContext == null)
      {
        return;
      }
      var _apiInsightsKeys = httpContext.RequestServices.GetService<IApiInsightsKeys>();

      if (httpContext != null)
      {
        if (httpContext.Items.TryGetValue(_apiInsightsKeys.StartTimeName, out var start) == true)
        {
          builder.Append(start.ToString());
        }
      }
    }
  }

NLog 规则,很容易理解日志统计只记录 Cheers 命名空间下的日志

<rules>
  <!--需要记录的日志-->
  <logger name="Cheers.*" minlevel="Trace" writeTo="apiinsight" />
  <logger name="WebApp.*" minlevel="Info" writeTo="log" />
  <logger name="*" minlevel="Trace" maxlevel="Debug" writeTo="debughelper" />

  <!--忽略的日志-->
  <logger name="Microsoft.*" minlevel="Trace" writeTo="blackhole" final="true" />
 </rules>

核心 ApiInsightMiddleware 中间件

public class ApiInsightMiddleware
  {
    private readonly RequestDelegate _next;
    private readonly IServiceProvider _serverProvider;
    private readonly IApiInsightsKeys _apiInsightsKeys;
    private readonly ILogger<ApiInsightMiddleware> _logger;
    private HttpContext _httpContext;

    public ApiInsightMiddleware(RequestDelegate next, IServiceProvider serviceProvider, ILogger<ApiInsightMiddleware> logger)
    {
      _next = next;
      _serverProvider = serviceProvider;
      _apiInsightsKeys = _serverProvider.GetService<IApiInsightsKeys>();
      _logger = logger;
    }

    public async Task Invoke(HttpContext httpContext)
    {
      _httpContext = httpContext;
      var flag = SetValues();

      await _next(httpContext);

      if (flag == true)
      {
        ApiInsight();
      }
    }
    //省略了其他的代码
  }

很好理解,在执行下一个中间件之前调用 SetValues 开始计时,下一个中间件执行成功开始统计并写入日志(或者忽略不写)。现在他是 asp.net core mvc 的第一个中间件了,好处就是更符合这个中间件本身的所做的事情了,但是带来的问题就是 httpContext.RequestService 是 null ,因为 RequestService 是在 RequestServicesContainerMiddleware 这个中间件写进去的,在者其实很多地方我们都需要 HttpContext ,并且目前微软还没有给我们定义一个静态的 HttpContext。

静态的 HttpContext

HttpContext 是通过单例 IHttpContextAccessor 提供的,当 HttpContext 创建的时候就会赋值给他,当请求到达中间件这个管道的时候,HttpContext 就已经存在于 IHttpContextAccessor 了,并且和 Invoke 参数列表中的 HttpContext 是一致的(同一个请求中),问题在于 RequestServicesContainerMiddleware 这个中间件没有执行就没有容器,并且很多时候我们都要用到容器,所以就模仿源码在这里都加进去了。

public static class HttpContextProvider
  {
    private static IHttpContextAccessor _accessor;
    private static IServiceScopeFactory _serviceScopeFactory;

    public static Microsoft.AspNetCore.Http.HttpContext Current
    {
      get
      {
        var context = _accessor"color: #ff0000">第一个中间件

在 Startup 的 Configure 方法中目前还没发现如何注册第一个中间件,因为 Configure 方法始终是在 IStartupFilter 这个接口之后执行的,这也提供了我们让自己的中间件成为第一个中间件的可能。可能这样做并不是特别有必要,甚至是没有意义的,但是实现的过程确实很有意思的。这里在 Startup 中的 方法 ConfigureService 注册我们的中间件。

  public void ConfigureServices(IServiceCollection services)
  {
    services.AddApiInsights();
    services.AddMvc();
  }

具体的

public static class ApiInsightsServiceCollectionExtensions
  {
    static readonly string stopWatchName = "__stopwatch__";
    static readonly string startTimeName = "__start__";

    /// <summary>
    ///   注册和 API 监控相关的服务,中间件
    /// </summary>
    /// <param name="services"></param>
    public static void AddApiInsights(this IServiceCollection services)
    {
      services.AddSingleton<IApiInsightsKeys>(
          new ApiInsightsKeys(stopWatchName, startTimeName)
        );
      services.FirstRegister<IStartupFilter, RequestApiInsightBeginStartupFilter>(ServiceCollectionServiceExtensions.AddTransient<IStartupFilter, RequestApiInsightBeginStartupFilter>);
      services.AddSingleton<IRequestIsAuthenticate, DefaultRequestIsAuthenticate>();
    }
  }

这里注册了三个服务

IApiInsightsKeys

定义了存储在 HttpContext.Item 中的键值对的名称

  public interface IApiInsightsKeys
  {
    string StopWatchName { get; }
    string StartTimeName { get; }
  }

IRequestIsAuthenticate

/// <summary>
  ///   验证请求用户是否已经认证
  /// </summary>
  public interface IRequestIsAuthenticate
  {
    /// <summary>
    ///   返回已经认证的 scheme
    /// </summary>
    /// <returns></returns>
    Task<string> IsAuthenticateAsync();
    /// <summary>
    ///   返回已经认证的 用户名
    /// </summary>
    /// <returns></returns>
    Task<string> AuthenticatedUserName();
  }

就验证而言可能不同的开发者使用的是不一样的验证方式,可能是基于 Asp.Net Core Authentication 中间件的认证方式,也可能是其他的比如自定义的 token,或者有一个单点登录的服务器,又或者是 session,其实 Asp.Net Core 的 Authentication 中间件也可以帮我们实现基于 restful 的token 认证。所以就把它定义出来了,并且默认的实现就是基于 Authentication 这个中间件的。

IStartupFilter

看到他是一个非常特殊的方式来注册的,自定义的 FirstRegister 这个方法,实际上 Asp.Net Core 内置有多个 IStartup 这样的服务,并且都是在 Startup 的 Configure 之前执行的,所以这里一定要用这个服务来让我们的中间件成为第一个中间件。FirstRegister 代码也很容易理解,由于在宿主启动之前,内部注册了多个 IStartup,并且最后会按先后顺序配置 IApplicationBuilder,所以我们只能让第一个 StartupFilter 的 IApplicationBuilder 就注册我们的中间件,通过改动 ServiceCollection 中服务的顺序可以实现。虽然不是很有必要,但是可以从中观察的 Startup 的 Configure方法 以及 接口StartupFilter (还有 IHostingStartup )的执行顺序。

public class RequestApiInsightBeginStartupFilter : IStartupFilter
  {
    public Action<IApplicationBuilder> Configure(Action<IApplicationBuilder> next)
    {
      return builder =>
      {
        builder.UseMiddleware<RequestApiInsightBeginMiddleware>();
        next(builder);
      };
    }
  }

忽略的方法

  [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
  public class NoInsightAttribute : Attribute
  {
  }

在 ApiInsight 方法中会调用 IsIgnore 检测该方法是否打了标签 NoInsightAttribute,如果是那就忽略该方法,这里建议使用特性路由,原因有两点,第一特性路由不需要使用 IActionSelector 接口重新查找匹配的方法,第二,在 restful api 中,结合特性路由和 HttpMethodAttribute 标签可以使方法更简洁,相同的接口名称通过不同的请求方式达到不同的目的

private bool IsIgnore()
  {
    var actionDescriptor = GetSelectedActionDescriptor() as ControllerActionDescriptor;
    if (actionDescriptor == null)
    {
      return false;
    }
    else
    {
      var noInsight = actionDescriptor.MethodInfo.GetCustomAttribute<NoInsightAttribute>();
      return noInsight != null;
    }
  }

程序地址: https://github.com/cheesebar/ApiInsights

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。

标签:
Asp.Net,Core,NLog请求监控,Asp.Net,Core,NLog

免责声明:本站文章均来自网站采集或用户投稿,网站不提供任何软件下载或自行开发的软件! 如有用户或公司发现本站内容信息存在侵权行为,请邮件告知! 858582#qq.com
评论“使用NLog给Asp.Net Core做请求监控的方法”
暂无“使用NLog给Asp.Net Core做请求监控的方法”评论...

《魔兽世界》大逃杀!60人新游玩模式《强袭风暴》3月21日上线

暴雪近日发布了《魔兽世界》10.2.6 更新内容,新游玩模式《强袭风暴》即将于3月21 日在亚服上线,届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。

艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕,并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时,他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中,玩家将会进入一个全新的海盗主题大逃杀式限时活动,其中包含极高的风险和史诗级的奖励。

《强袭风暴》不是普通的战场,作为一个独立于主游戏之外的活动,玩家可以用大逃杀的风格来体验《魔兽世界》,不分职业、不分装备(除了你在赛局中捡到的),光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式,玩家在加入海盗主题的预赛大厅区域前,可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹,《巨龙崛起》和《魔兽世界:巫妖王之怒 经典版》的玩家都可以获得奖励。