In my team there is discussion about web application exception logging, regarding whether we should log to a text file or the event log.
Can anyone please tell me which is the better way of exception logging occuring in the application? Either one of the two I've already mentioned or is there a better option?
Don't reinvent the wheel - use an already existing logging library/tool such as log4net or ELMAH instead of writing your own logging library. Both give you multiple choices for where you log exceptions to, it's up to you which you prefer.
Two things to consider:
1 - Where do you log to if you're logging to the database, but the database is unavailable / under heavy load?
2 - Windows Event Logging is very light-weight and event log forwarding means you can automagically aggregate logs from multiple machines without writing any code.
Another great and easy to use Logging-Library is NLOG
From the site:
"Supported targets include:
Files – single file or multiple, with
automatic file naming and archival
Event Log – local or remote
Database
– store your logs in databases
supported by .NET
Network – using
TCP, UDP, SOAP, MSMQ protocols
Command-line console – including
color coding of messages
E-mail – you
can receive emails whenever
application errors occur
ASP.NET trace
… and many more
Other key features:
very easy to configure, both through configuration file and programmatically
easy-to-use logger pattern known from log4xxx
advanced routing using buffering, asynchronous logging, load balancing, failover, and more
cross-platform support: .NET Framework, .NET Compact Framework and Mono (on Windows and Unix)"
I prefer a text file because it allows for more flexibility and easier navigation. I suppose it's a matter of preference, but the navigation between errors in the Windows event log seems very cumbersome. In addition to the cumbersome navigation it includes errors that you don't care about. If you can define the format and the content then it's much more efficient.
At the app I work, we are used to log every exception at the database, so this way is easier to link the exceptions details to the "user error report" they are requested to fill (which is at our the default error page). It helps us on statistics and as already said, linking exception details to the user description of the error (like, which steps he took to get that error, etc...)
Disclaimer: i am the developer of KissLog.net logging application.
log4Net and Elmah are very good, but they have limited capabilities.
Elmah doesn't support trace / log messages, and logs only the exceptions, and log4Net doesn't provide a user interface to navigate through the logs.
You can try to use KissLog.net, it is an application where i tried to aggregate all the necessary logging features (capture errors, log / trace messages, easy to use user-interface)
Related
I'm working with few applications, Two Dot Net (Standalone Windows Thick client) and SSIS (SQL Server ETL Engine) and right now all of them use their own logging implementations. Dot Net uses Log4Net and SSIS writes to a text file.
I want to redesign this whole thing where all the applications right to one Logging interface. There are few options which I'm considering: Windows Event Logging, ELK(Elastic/LogStash) or Custom Log provider
Details:
It's a file processing system where we do a bunch of operations using DotNet Apps and then load the files, using SSIS, into a SQL server DB.
I recommend going for log4net in the other application. It is very popular, has lots of features, is maintained, well documented and you can find tons of help on it on different forums (including stackoverflow). It can do much more than just logging into a file. It supports remote logging, SMTP, .NET Trace, DB and even Windows Event Log. Allows for extremely flexible configuration.
It is always good to have separate logging for separate apps but you can have both log into a single logging target as well.
What is the best way to 'log' Windows Service activity, should I use Windows Log Event Viewer, or just use plain txt file. If I use event log, I think there is a chance of being the event log full.
My new favourite logging framework is Serilog. We make use of ELK for log aggregation and so Serilog is setup to write logs JSON format, e.g.
{"Level":"Information","MessageTemplate":"Service Started","Timestamp":"2017-07-27T11:29:54.3948669+01:00"}
{"Level":"Information","MessageTemplate":"Service Stopped","Timestamp":"2017-07-27T11:31:14.8305763+01:00"}
These logs are then sent for aggregation and are visible and searchable via a web interface - we don't bother logging to the event log because nobody logs onto these boxes.
If you only have a couple of services then log aggregation might be overkill - its easy enough to have Serilog write to other formats instead (e.g. to the event log, or non-json formatted files which are easier for humans to read).
Definitely use a logging framework (log4net is also good, I've also heard good things about NLog but never used it myself). Any good logging framework will let you selectively log important messages to the event log.
I would use the NLog library.
link
Then you are free to choose File or EventViewer depending on the customer expectations.
From the support people point of view I would use the event viewer because it is easy to reach. (but do not flood it with info messages, just error)
I'm trying to create a simplified API for both logging (errors, warnings, info) and tracing (debug, analytics) to the Windows Event Log so I can use Windows Event Viewer to work with the logs. I found the EventLog class and started coding against it, and it works for logging to the Application log. I can't find any documentation on specifying the log subcategory with this class, though. I need to push trace info to the Analytic and Debug logs, and I'd like to let the application choose whether logged events go to the Admin or Operational logs.
I then learned about the EventSource class, and various blogs on MSDN indicate that it does allow you to specify the logging "channel", but I don't know whether the channel is another word for the log subcategory.
This is the only thread I could find comparing the two classes, and it didn't seem to answer what I need to know:
Can I use either EventLog or EventSource for logging to a specific to WEL subcategory?
Is one of them recommended over the other in the .NET 4.5 framework? i.e. is EventLog considered to be deprecated, or is it meant only for non-trace use?
Yes you can use EventLog as shown here or EventSource as shown here and here. I know of no official recommendation, but in my opinion it is easier to write a strong typed log message with EventSource. It also has more features and with this you can even use it with .Net 3.5 if you want.
Looks like I misinterpreted the Help/TechNet info on these logs. There are the Windows Logs -- Application Security, Setup, System, ForwardedEvents -- and then there are custom Applications and Services Logs. Only the latter may have a subtype: Admin, Operational, Analytic, Debug. The Windows Logs don't have subtypes, and they're intended only for logging (not tracing), so they don't accept a logging level that equates to "Debug" or "Trace".
That being said, the EventLog class suits my needs for logging, but it doesn't seem to provide enough features to interface with ETW for tracing. If I want to write to trace-worthy logs, I'll have to use ETW and the EventSource class is better equipped for that.
You don't need an API - it's built in to .Net. Consider TraceSource and the EventLogTraceListener. You can apply filters to message types to send only those messages which are 'event log worthy' to the event log, and use ETW and custom trace listeners to capture transient debug data. Reconfiguration can be done at runtime to help with debugging. Also an upside - there are a ton of TraceSources built in to the .net framework.
See this SO answer, and this blog post for more on why TraceSource is a good option
Can somebody please compare these two logging mechanism?
This has been written about quite a bit. Here are some things to read:
http://james.newtonking.com/archive/2007/06/05/enterprise-library-logging-vs-log4net.aspx
http://theiterator.com/2009/01/log4net-vs-enterprise-library-logging-application-block/
https://stackoverflow.com/questions/118047/log4net-vs-enterprise-library-which-is-better-faster
My thoughts:
The general consensus seems to be that log4net performs faster. Whether this is meaningful in a typical application is up for debate.
log4net also supports hierarchical loggers out of the box which is nice. EL can perform something similar but you have to roll your own.
log4net's configuration is a bit arcane and not well documented (IMO). However, EL's is also cumbersome to configure (and painful without the config tool). Also EL gives you so much choice that you may want to spend some time on design (e.g. do you want categories to be related to the logging level or layers, or functional area, or all of the previous, or something else?)
If you are already using EL, you may want to just stick with EL Logging (it also integrates with the Exception Handling Block) for consistency. If I'm using EL for an application, then I tend to use EL for logging. If not then I usually favor log4net for smaller applications since the setup time is usually shorter. (Not to impugn anyone's favorite logger! :) )
I've used both and found that they both work well.
I've given some descriptions below all directly from the tool's website. I prefer ELMAH which is at the bottom, but have not spent much time on Log4Net or the Logging Application Block.
Log4Net
Support for multiple frameworks
Output to multiple logging targets
Hierarchical logging architecture
XML Configuration
Dynamic Configuration
Logging Context
Proven architecture
Modular and extensible design
High performance with flexibility
Logging Application Block
The event log
An e-mail message
A database
A message queue
A text file
A WMI event
Custom locations using application block extension points
ELMAH
Logging of nearly all unhandled exceptions.
A web page to remotely view the entire log of recoded exceptions.
A web page to remotely view the full details of any one logged exception.
In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrors mode turned off.
An e-mail notification of each error at the time it occurs.
An RSS feed of the last 15 errors from the log.
This might be of interest: http://www.dotnetlogging.com/comparison/
I'm building a C#/Asp.Net (FW 2.0) web application and I was wondering where I should store my error logs entry.
I could write it on a file on the server, but that doesn't seems right to me. It would be insconsistent with the idea of a database.
The other obivous answer is on the database, but what happened if I do not have any connection with the database. If the client get a connection error to the database what do I do(because the server and the database aren't on the same machine obviously)?
Your suggestions are appreciated.
Than you
Edit : I'm talking about basic error logging here, please do not refer such things as big frameworks like log4net.
System Event log with appropriate event source (logging channel)
http://support.microsoft.com/kb/307024
Compared to logging to a DB log4net or nlog are not "big frameworks". Keep it simple and these two provide exactly what you need, with very little ramp up period.
Having a fallback mechanism is a very valid scenario. Logging to the windows event log is often not practical, because it isn't easy to analyze to logs, as is with relational databases. But allowing events to be logged to the event log when your database fails is not a luxury option IMO.
This scenario is one of the reasons I built a logging framework (I won't reference it, just as you requested). It supports a concept called 'fallbackProvider' that allow the event to be logged to an alternative logger in case the main logger fails. When you write your own logging mechanism, you could embrace such a concept.
Good luck.
Store it in the event log; it is designed for this purpose after all! Its the place most people would look for errors, messages and warning regardless of what they know about the application.
The enterprise library provides a framework for logging which you can use Enterprise Library. This allows you to change how/where events are logged based on a configuration file so you don't have to make a decision where events are logged.
In addition to this, if you use the exception handling block you can also log errors to the eventlog with minimal effort
I guess you really have three options:
Use a small database to store all the error logs on the local machine using something light-weight like SQLlite or SQLServer Compact.
Save it to a flat file (xml, or what have you) where you can view it.
Send it straight to the Event Log. (I'd probably do this).
log to the database and xml as a fallback, asp.net account will need perms to log errors to eventviewer which may not be such a good idea on the web server unless it is absolutely neccessasy.
If you're willing to consider a simple commercial product, take a look at Gibraltar. It stores logs locally then uploads them to a web service when a connection is available. The logs are then indexed in an embedded database and an analysis tool lets you review errors and other information at whatever level of detail you require.
I see that you're a student, Frank. Email me directly to discuss the possibility of us offering you a free license.
-System Event Viewer
-you may cache your error to local & lightweight db file (can be SqLite/Sql Compact), then when connection is available, you send it to server