It is probably not a good idea to create an Elmah event log provider if you intend to store error information in the event log and also use the ELMAH interface. A related question has an excellent answer from Matthew Dougherty on this topic:
ELMAH error log classes are not just for writing; they also read the data log so that it can be displayed in the ELMAH web interface. Additionally, ELMAH registers more than just exception Information. It also registers server variables, form collection, and information needed to reproduce the yellow screen of death. Even if you had to register all this information in the event log, it would be difficult to read as plain text, and very difficult to read in such a way that the ELMAH network interface could use it. If you are not going to use the ELMAH web interface then it is clear that this is not a problem.
To create your own logging provider, you can subclass ErrorLog and override GetError (gets a single error by id used by the Elmah interface), GetErrors (lists all errors on the page used by the Elmah interface) and Log (logs a new error) methods for creating your own storage mechanism . See this article for an example on how to implement a custom ErrorLog.
Then you register your new ErrorLog provider in config:
<elmah> <errorLog type="MyNamespace.MyErrorLog, MyAssemblyName"/> </elmah>
As for events, they are emitted by Elmah modules. There are two events in ErrorLogModule - Logged and Filtering. There are four events in the ErrorMailModule module: Filtering, Mailing List, Mailing List, and DisposingMail.
source share