常在服务器端处理用户请求时.特别是针对Web应用程序.当出现异常是可以根据日志操作记录还原异常出现时操作步骤.而记录异常堆栈信息判断问题出现问题位置. 为了跟踪和记录服务器行为.特别是针对出现异常时构建简单、统一的异常处理模式就显得尤为重要.
如果有一个基础的架构用来记录服务器端中日志和事件.那么对于调试和在问题的解决就变得更加简单直接.针对日志记录.可能针对大部分开发人员.首先表现明显就是应用程序底层或是运行时中存在Bug或是特定情况下Crash掉等. 比较明显的行为.这时日志记录目的是为了跟踪应用程序的底层行为.了解出现异常时应用程序内部所执行的过程. 能够帮助开发人员和软件测试找到应用程序崩溃的原因. 快速解决问题.
而还有一些情况.是很难再开发阶段把问题暴露出来.类似性能问题.而此时如果有了日志记录服务端行为.则可以通过提供的详细执行时间记录可以很方便的找出应用的性能瓶颈.定位这些比较”隐性“问题.
所以花了点时间研究日志记录组件.说说个人看法.
在开源日志管理上当然不得不提到是LogStash .
它是一个应用程序日志、事件的传输、处理、管理和搜索的平台.基于HTML5、Jquery、Css3和SVG等技术.所以也是跨平台的、跨浏览器的.可应用任何的Asp.net开发.可以用它来统一对应用程序日志进行收集管理.最难得可贵的提供Web接口用户查询和统计. 所以特点是跨平台同时也是足够开放的.[这就是开源社区的力量.]推荐.
另外一个就是从Java移植过来的.Net版本Log4Net
这个可能给位已经很熟悉了.Log4net是从java平台下非常优秀的日志记录框架Log4J移植到.NEt下版本.它也是Apache基金资助的项目的一部分.Log4net可以帮助我们把日志信息输出到各种不同目标（文本文件、数据库、控制台等）的.net类库，它可以容易的加载到开发项目中,实现程序调试和运行的时候的日志信息输出,提供了比.net自己提供的debug类和trace类的功能更多，使用起来也是非常的简单.
在说道本篇即将提到的Elmah.
Elmah其实是[The Error Logging Modules and Handlers]缩写.它是专用于ASP.NET的完全可热插拔的错误日志记录工具。其特点就是无需ASP.NET程序重新编译，即可通过配置web.config（或machine.config）来实现整个应用程序甚至是IIS中所有ASP.NET应用程序的错误日志记录工作。它支持日志的多种存储方式（各种数据库、XML、内存存储），除了提供一个界面用于查询日志详细信息外，还可以通过E-MAIL、RSS订阅或Twitter发布方式通知错误信息给相关人员.
分别试用一下.
LogStash最大的特点是除了跨平台本身之外.它最强大的地方是其提供丰富的插件的.各种灵活自定义规则.输出各种各样的日志结果.可以在不同的服务器上对不同的数据来源做自定义的filter，然后输出到不同的目的插件上去.这样对于分布式是采集日志提供很好解决方案.类似要监控A B服务器上日志.可以再C服务器上接受日志记录数据并分析让后分发给D服务器做报警和容错处理. 自由开放.可以任意端采集日志数据.
Log4Net包含了主要有四种重要的组件，分别是Logge, Repository, Appender以及 Layout.功能强大.可以自定义日志输出级别.但我认为对于规模偏小的应用程序.在配置方式和灵活度显得不够Clean.
本篇来尝试Elmah在Asp.net MVC 4使用.
首先Build 空的Asp.net MVC 4 Project:
添加Elmah引用:
如果采用VS2012则如上关于Elmah组建已经配置成功.其实这个过程做了两件事:
A:将Elmah.dll复制到程序的根目录的Bin文件夹下.并当前项目的引用.
B:向项目根目录下Web.Config文件添加如下内容
在webConfig文件中添加如下内容:
1: <configSections>
2: <sectionGroup name="elmah">
3: <section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah" />
4: <section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
5: <section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
6: <section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah" />
7: </sectionGroup>
8: </configSections>
9:
10: <httpHandlers>
11: <add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
12: </httpHandlers>
13:
14: <httpModules>
15: <add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah" />
16: </httpModules>
关于Elmah项目引用配置基本完成.如果你不习惯NuGEt也可以采用如上手工的方式添加项目引用.
此时在homeController中throw 一个nullException ：
1: public class HomeController : Controller
2: {
3: public ActionResult Index()
4: {
5: //throw new null exception for test
6: throw new ArgumentNullException();
7: return View();
8: }
9: }
运行效果如下:
很明显.当我们throw一个异常后.,会出现报错的黄页.在来看看Elmah是否记录本次执行过程中出现ArgumentNullException.
可以看到Elmah已经如期的扑捉到当前应用程序的异常.ELMAH在后台记录了错误信息，并为我们提供了查询错误日志信息的界面，只需要简单的操作，就完成了基本的需求.
其实Elmah处理原理.当我们请求页面报错时.在返回黄页错误时首先被httpModules中名为ErrorLog模块进行拦截. 该模块将本次请求出错的信息保存起来.-默认是放置在内存中.便于即时调试.但用户输入elmah.axd要查看日志信息时. 首先httpHandlers捕获到该请求.并交给专门处理elmah.axd的处理程序.该模块把错误日志View返回给用户.可见Elmah核心技术还是基于HttpModules和HttpHandlers来实现的.
在添加完对Elmah引用可见在web.config同时添加Elmah节点 如下:
1: <elmah>
2: <!--
3: See http://code.google.com/p/elmah/wiki/SecuringErrorLogPages for
4: more information on remote access and securing ELMAH.
5: -->
6: <security allowRemoteAccess="false" />
7: </elmah>
Elmah通过该节点对外公开功能配置项.该配置选项功能丰富.开篇提到Elmah对存储方式支持包含：
- Microsoft SQL Server
- Oracle (OracleErrorLog)
- SQLite (version 3) database file
- VistaDB (VistaDBErrorLog); 在1.2版，不再推荐使用
- Microsoft Access (AccessErrorLog)
- SQL Server Compact Edition (1.2支持)
- MySQL (1.2支持)
- PostgreSQL (1.2支持)
首先如果你只是引用Elmah而没有配置采用什么存储形式.Elmah默认设置为内存存储的方式.虽然这种方式便于开发调试.但在部署生产环境后还是推荐对数据要进行持久化存储. Xml文件或是采用支持的数据库.
改成文件存储方式只需要在配置项添加如下代码即可：
1: <elmah>
2: <!--
3: See http://code.google.com/p/elmah/wiki/SecuringErrorLogPages for
4: more information on remote access and securing ELMAH.
5: -->
6: <security allowRemoteAccess="false" />
7: <errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/Static/Log/" />
8: </elmah>
该配置必需确认LogPath路径目录是完整存在的.测试会发现在本地文件中会出现一个XML文件:
这种方式虽然简单直观.但Elmah设计方式在每次运行如果应用程序出错一旦扑捉到.就独立生成一个独立的文件.这种方式会导致服务器端存在大量冗余文件.且对这些文件管理也是一个问题.
在数据可视化和管理上数据库依然是最理想的选择.这里采用SQlServer2008 版本测试.在构建Elmah支持SQLServer数据支持需要如下三个操作：
A: 需要告诉Elmah 需要连接什么类型的数据库
B: Elmah如何连接这些数据库.也就是连接字符串需要提供
C: 在指定数据库中已经存在对应存储Log日志表和视图存储过程.
实际操作首先需要Elmah节点添加如下内容：
1: <errorLog type="Elmah.SqlErrorLog, Elmah" connectionStringName="SQlServerConStr" />
在该数据执行如下SQL语句.请参考官方的连接.
Elmah SQL Server Script File:http://code.google.com/p/elmah/source/browse/src/Elmah/SQLServer.sql
执行sQL语句完成后会在当前数据库看到表：
当再次运行应用程序.在Throw ArgumentNullException时查询数据库：
可见简单实用.另外针对SQL语句执行全部以官方标准为主.不同数据库之间SQL Script脚本会存在一定的差异.
在使用Elmah过程发一下一些特点.这里需要说明一下.
Elmah是通过Http Modules 和Http Handler来记录和展示程序捕获的异常. 但是如果你在应用程序中添加异常处理模块.Try-Catch Elmah是无法记录到的.或是在Catch后在Throw出来. 在整个应用程序异常链上. 只有最终的异常抛给了Asp.net运行时Elmah组件才能捕获到并记录.
有很多人认为加入Elmah组件后能够处理应用异常.其实本质上Elmah本质上是一个日志记录工具.并没有处理异常的能力.所以如果异常发生.不会改变原来应用程序给用户体验.依然还会出现黄色页面.
在官方Note明确提到一个例外.:
ELMAH捕获异常是基于HttpApplication对象的Error事件。
如果软件项目中的一些处理导致了HttpApplication事件无法被触发（比如在发生异常后，还没来得及执行Application_Error，就执行了Server.ClearError()方法，
会阻止Error事件的触发，再比如，如果一个异常被try-catch捕获到，并且没有再次throw，那么异常也是不会最终触发Error事件）
日志记录工具还是不少的，比如著名的Log4net以及Enterprise Library中的Logging Application Block。可以说，这些工具相对ELMAH来说，太重量级了，他们可以记录各种日志信息，比如监视代码中变量的变化情况，周期性的记录到文件中供其他应用进行统计分析工作；跟踪代码运行时轨迹，作为日后审计的依据；担当集成开发环境中的调试器的作用，向文件或控制台打印代码的调试信息。因此，如果仅仅是记录ASP.NET的错误日志.而Elmah开源且足够Clean.首选.