谈谈Nancy中让人又爱又恨的Diagnostics【上篇】

前言

在Nancy中有个十分不错的功能-Diagnostics，可以说这个功能让人又爱又恨。

或许我们都做过下面这样的一些尝试：

• 记录某一个功能用到的相关技术信息

• 记录下网站的访问记录

• 全局配置某些框架内部功能的开关

• .....

当然，对于上面提到的这些东西，现在都有非常成熟的解决方案可以用。

不过，Nancy在内部也实现了这样的一个机制，可以让我们比较方便的处理这些问题。

下面我们先来看看具体是如何使用的！本文也是着重于如何使用。

如何使用

由于在Nancy1.x与2.x中的差别，在使用Diagnostics的用法上也有了略微较大的差别。

截至在本文编写之前(2017-06-26)，Nancy在GITHUB上面的相关介绍还是基于1.x的。而本文是用2.0作为例子演示的，当然也有与1.x的简单对比。

在2.0中，Diagnostics的启用是通过在Bootstrapper中的Configure方法启用，而在1.x中是通过重写一个DiagnosticsConfiguration类型的属性来启用。

下面是两个大版本之间的使用方法：

2.0的使用如下：

public override void Configure(INancyEnvironment environment)
{
    environment.Diagnostics(password: "123");
    base.Configure(environment);
}

1.x的使用如下：

protected override DiagnosticsConfiguration DiagnosticsConfiguration
{
    get { return new DiagnosticsConfiguration { Password = "123"}; }
}

其中，2.0中的写法是通过INancyEnvironment的一个扩展方法来实现的。

当我们只指定密码的时候，就表示我们要开启这个功能了。其本质就是在当前的environment中添加Diagnostics的相关配置。

需要注意的是，我们指定的密码不能为空！如果为空就会提示Diagnostics的配置不正确。

相比1.x，个人觉得2.0的写法应该是更推荐的写法，因为 Diagnostics在Nancy中是一个功能模块，并且是由用户去决定是否去启用的，所以在Bootstrapper这样一个启动器中为一个功能模块单独设计一个属性来标识是否启用，感觉有那么一点累赘，如果这样的属性一多，就会造成Bootstrapper比较臃肿，而在配置方法中去统一管理这些配置项会简洁许多。这样的做法就有点类似ASP.NET Core中Startup类的Configure方法。比较符合按需加载的特性。

在启用这个功能之后，我们可以通过访问默认地址 http://yourdomain.com/_Nancy 去访问相关的功能。当第一次打开的时候会进入一个登录页面。

在文本框中输入我们设置的密码后就可以进入到Diagnostics的主面板了。

通过主面板上面的信息，我们可以看到有下面4个主要内容：Information、Interactive Diagnostics、Request Tracing和Settings

下面分别来看看这些内容：

Information

Information主要是记录了当前站点使用Nancy的相关配置信息：

这里主要包含两个部分的信息，第一部分是Nancy的相关信息，第二部分是配置的相关信息。

在第一部分中，可以看到当前用的Nancy版本是2.0，根路径、视图引擎等信息。我们这里用的Hosting是Kestrel

这里没有正确的加载出来，里面应该是有些问题细节还没有处理好的。

在第二部分中，就是当前站点使用的一些配置信息，由于并没有重写相关的配置，所以可以看到清一色的Default.

Interactive Diagnostics

这里在默认的情况下也是有两个模块，一个是缓存的路由信息，一个是测试相关的Provider。

这里主要看一下路由的信息。

如果看过我下面这篇博客，对怎么取到这些路由信息的，就会比较清楚。

浅析如何在Nancy中生成API文档

下面还有Finalize和MemberwiseClone这两个方法，可以按照字面上的意思去理解，不过似乎并没有发现什么实际性的作用，所以这里就不深入说明了。

Request Tracing

默认情况下，Request Tracing 是没有开启的，所以这个时候打开这个部分只能看到No Sessions found。

想要开启Tracing，同样是在Bootstrapper的Configure方法中开启。

public override void Configure(INancyEnvironment environment)
{
    environment.Diagnostics(password:"123");            

    environment.Tracing(enabled: true, displayErrorTraces: true);

    base.Configure(environment);       
}

当开启之后，再打开这个页面时，

就可以看到Trace了一个会话

点进去可以看到这个session更多详细的信息：

左边列出了每一个请求的精简信息，右边是详细的信息。

注：对于Request Tracing，Nancy限制了最多只能存储500个会话，每个会话只能存储50个请求。内部是通过维护一个线程安全的队列来处理的，每当其超过上限时，就会进行出队操作，将最先记录的移出队列。所以在这里，我们能看到的永远是最新的会话和最新的请求。

Settings

Setting这里读取的是StaticConfiguration的内容。就2.0来说，个人暂时没有发现 这一个板块的内容有太大的作用。

在2.0中，默认情况下我们能看到的东西就一个!原因很简单，2.0中的大部分配置项已经没有使用StaticConfiguration这个静态类来设置了。

同时也回顾对比一下1.x中的setting页面，对比一下两者的默认配置项：

可以看到1.x配置项比2.0多了不少！在1.x中设置可以直接影响站点的相关配置。例如：选中Disable Error Traces，那么站点就会禁用掉Error Traces。

这里可以说是功能开关。

自定义配置

上面的示例中，我们是通过默认地址 http://yourdomain.com/_Nancy 去访问的，

如果说，我们开启了这个功能，但是什么配置都没有改，就会有可能让其他人看到我们站点的大部分信息。所以正常情况下，都是不会用这个默认地址的，毕竟这是在Nancy内部设置的一个默认地址。我们通过上面提到的Diagnostics这个扩展方法来替换我们的默认路径。

public override void Configure(INancyEnvironment environment)
{
    environment.Diagnostics(
        password:"123",
        path:"_dash"//设置为http://yourdomain.com/_dash                
        );            

    environment.Tracing(enabled: true, displayErrorTraces: true);

    base.Configure(environment);       
}

此时再一次访问 http://yourdomain.com/_Nancy 就会提示404了(前提是没有其他的请求指向这个地址)。

只有输入我们设置的地址才能正常访问！后续的操作就和上面介绍的一样了。

另外，我们能配置的除了密码，和访问地址外，还可以设置控制面板的过期时间以及相关的加密配置。

更多使用方法可以参考下面的链接：

https://github.com/NancyFx/Nancy/wiki/Diagnostics

总结

本文简单的介绍了如何使用Nancy的Diagnostics功能，如果真的使用这个功能，可能下面的2个情况需要注意一下：

• 密码尽可能要设置的复杂一点
• 最好能修改默认的访问路径

为什么说这个Diagnostics让人又爱又恨呢？这个功能可以说是十分强大，也可以说是并没有什么作用。当然这也主要是取决于怎么用。

对于一个Web框架来说，考虑到的东西比较齐全、比较深入，对我们开发者来说是十分值得借鉴的。在此同时，给我们的日常维护也带来了便利之处。

这里的一系列功能是没有持久化的，我们可以在这里的基础上对他进行持久化，这样就可以强化这一个功能。

如果说一个公司有强大的服务器团队，那么这个功能就可能会变得没有太大的展示空间。毕竟人家会有一套更专业的东西去管理，监控网站的相关信息，而且记录的内容，信息也会比Diagnostics多上N个等级。

在下一篇将会详细介绍这个功能的实现。

本文已经同步到Nancy之大杂烩