Logging to files or to event viewer?_问答_开发者

I was wondering what is the 'correct' way to log information messages; to files, or to a special log in the event viewer?

I like logging to files since I can use rolling flat file listener and see fresh new log from each day, plus in the event viewer I can only see one message at a time - where in a file I can scan through the day much easily. My colleague argues that files just take up space and he likes having his warnings, errors and information messages all in one place. What do you think? Is there a preferred way? If so, why?

Also, are there any concurrency issues in any of the meth开发者_JAVA技巧ods? I have read that entlib is thread-safe and generates a Monitor.Enter behind if the listener is not thread safe, but I want to make sure (we're just using Logger.Write). We are using entlib 3.1.

Thank you in advance.

Here's the rule of thumb that I use when logging messages.

EventLog (if you have access of course) - We always log Unhandled Exceptions - In most cases we log Errors or Fatals - In some cases we log Warnings - In some very rare cases we log Information - We will never log useless general messages like: "I'm here, blah, blah, blah"

Log File - General rule, we log everthing but can chose the type of level or filter to use to turn down the volume of messages being logged

The EventLog is always a good option because its bound to WMI. This way products like Open View and alike, can monitor and alert ops if something went haywire. However, keep the messages to a minimum because its slow, its size limited on a per messaeg basis and it, entry limit as you can easily fill up the EventLog quite quickly and you application has to handle the dreaded "EventLog is Full" exception :)

Hope this helps...

There is no 'correct' way. It depends on your requirements.

You 'like' looking at flat files but how many (thousands) of lines can you really read every day?

What you seem to need is a plan (policy) and that ought to involve some tooling. Ask yourself how quickly will you notice an anomaly in the logs? And the absence of something normal?

The eventlog is a bit more work/overhead but it can be easily monitored remotely (multiples servers) by some tool. If you are using (only) manual inspection, don't bother.

In enterprise applications there are different types of logs such as -

Activity logs - Technical logs which instrument a process and are useful in debugging
Audit logs - logs used for auditing purpose. Availability of such logs is a legal requirements in some cases.

What to store where: -

As far as the Audit logs or any logs with sensitive information are concerned they should go to database where they can be stored safely.
For Activity logs my preference is to files. But we should also have different log levels such as Error, Info, Verbose etc which should be configurable. This will make it possible to save space and time required for logging when it is not needed.
You should write to event log only when you are not able to write to a file.

Consider asking your customer admins or technical support people where they want the logs to be placed.

As to being thread-safe, yes, EntLib is thread-safe.

I would recommend Event-viewer but in cases where you don't have admin rights or particular access to Event-viewer, Logging to normal files would be better option.

I prefer logging to a database, that way I can profile my logs and generate statistics and trends on errors occurring and fix the most frequent ones.

For external customers I use a web service called async to report the error. (I swallow any expections in it so any logging error's wouldn't affect the client - not that I've had any, using log4net and L4NDash).