Let’s say you’re looking at a glaring Red event in your event log that has an ominous ring to it or some monitoring program that screams loudly because some parameter it has defined isn´t being met by tests it is doing.
That’s bad, right?
The answer is of course, it depends on the context….everything is relative as Mr. Einstein would have said 🙂
I.e. events aren’t problems by themselves, they can be indicators of problems or they could be the result of the programmer simply not anticipating whatever condition has occurred on the system (remember the classic ‘An unexpected error has occurred’ message).
The event may also be misleading in itself if you´re not looking at the greater picture, a classic example of this is the Netlogon 5719 event (if no network connection is possible its an expected event and not the cause for the problem preventing the connection).
For starters, determine if:
Do you have a problem to go with the event or is this an event with no apparent negative effect?
It’s entirely possible that you’re looking at a false positive if you don’t have any problem even if the event is being logged.
Is the event being logged continuously or only under specific circumstances?
Some things like transient network conditions or access to files or databases will generate expected errors – depending on the programming behind the event this may or may not generate an initial false positive that is resolved by itself when the network becomes available.
Is the criteria being tested by the event or monitoring application valid?
Remember that the tests may be failing even if there is no problem present, the tests themselves might be faulty or generate false positives even.
In short; Events are not problems, always determine first if you have a problem before you start chasing away after events.