Some information about dealing with Log messages
Logfile Tuning Strategies
You generally drop all messages and only alert on a per-case basis on the ones you know to be extremely troublesome
an example would be registry inconsistency messages, exchange database timeouts etc.
everything else gets dropped
The downside is you'll always only add monitoring after the fact and not get alerted on the first instance of an issue.
You turn off alerting for messages at first
Then you collect messages for some interval, i.e. 4 weeks
You spend 10 minutes a day. 5 go classifying the messages of the last day, and 5 minutes on the documentation of what you classified
Then you turn on the alerting
You'll have a perfectly tuned setup that alerts you if anything goes wrong, but doesn't bother you with boring stuff
Which to chose:
This is an administrative question.
Can your team dedicate a defined time slot at an interval and follow through with it for 1-2 months?
If yes, you can use the second strategy and you'll have much greater results.
If that isn't for you, don't try it. Trying to constantly catch up with messages you didn't flag yet will ensure your team being unhappy with the message spam.
Use the positive filter method if you're cramped and already feel totally overwhelmed!
How to change your log settings
Find a lot message you don't like
Open the logfile viewer
If you're in the logfile viewer it'll also show you contextual messages.
Each message has an icon that allows you to open the logfile analyzer. Please do that after reviewing your actual message.
You might now actually just get an empty screen BUT you also have a good thing right there:
On the next screen, just jump to the "create rule" button.
On the coming screen *please* enable the online help:
Save your rule
Then go back to the analyzer and check if it is showing a match on this rule
In pratice, we re-map those messages from CRITICAL to WARNING, and this is what it looks like: