Register in files or event viewer?

I was wondering what the “correct” way of recording informational messages is; to files or to a special log in the event viewer?

I like to write to files, as I can use a sliding flat file listener and view a new new log every day, as well as in the event viewer. I can only see one message at a time - where in the file I can scan during the day very easily. My colleague claims that the files just take up space and that he likes his warnings, errors and informational messages 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 methods? I read that entlib is thread safe and generates Monitor.Enter if the listener is not thread safe, but I want to make sure (we just use Logger.Write). We are using entlib 3.1.

Thanks in advance.

+7
c # thread-safety logging enterprise-library
source share
6 answers

Here's a rule of thumb that I use when posting 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 record useless general messages like: "I'm here, blah, blah, blah"

Log file - General rule, we log everthing, but we can choose the type of level or filter that will be used to reduce the amount of messages logged

EventLog is always a good option as it is associated with WMI. Thus, products such as Open View and similar can monitor and warn operating systems if something goes with haywire. However, keep messages to a minimum because it is slow, its size is limited based on each message and its input limit, as you can easily fill in EventLog quickly and the application should handle the scary exception "EventLog is Full" :)

Hope this helps ...

+5
source share

There is no “right” way. It depends on your requirements.

You like to "look at flat files, but how many (thousand) lines can you really read every day?"

What you think is necessary is a plan (policy), which should include some tools. Ask yourself how quickly you notice an anomaly in magazines. And the lack of something normal?

An event log is a bit more work / overhead, but it can be easily controlled remotely (multiple servers) using some kind of tool. If you use (only) manual validation, don't worry.

+3
source share

There are various types of magazines in enterprise applications, such as -

  • Activity Logs - Technical logs that process the process and are useful for debugging
  • Audit logs - logs used for audit purposes. The presence of such magazines is in some cases a legal requirement.

What to store where: -

  • As for audit logs or logs with confidential information, they should go to a database where they can be stored safely.

  • For activity logs, I prefer files. But we must also have different levels of logs, such as Error, Info, Verbose, etc. which should be customizable. This will save the space and time required for logging when it is not required.

  • You should write to the event log only when you cannot write the file.

+2
source share

Consider asking your administrators or technical support technicians where they want the logs to be posted.

As for thread safety, yes, EntLib is thread safe.

+1
source share

I would recommend an Event-viewer, but in cases where you do not have administrator rights or specific access to the Event-viewer, it would be better to log in regular files.

0
source share

I prefer to keep a log in the database, so I can profile my logs and generate statistics and trends when errors occur and correct the most frequent ones.

For external clients, I use the async web service to report an error. (I swallow any expectations in it, so any registration error will not affect the client - not what I had using log4net and L4NDash).

0
source share

All Articles