Overview
The Event ID monitoring test appears under the Operating System section for monitored servers.
Monitoring Benefit
The Event ID test reports the status of the warning and critical events found in the server's event logs. The ENow client queries the event logs periodically and surfaces what it finds as a monitored indicator, so events that would otherwise sit unread in Event Viewer become something you are told about.
The value is in the events you were not looking for. Most event log review happens after something has already gone wrong; this test brings warning and critical events forward while they are still just events.
How do we verify the monitoring test results?
1. Check the collected event data on the EMS web server. Open this folder in Explorer:
\Program Files (x86)\ENow\MailscapeWeb\MailscapeData\Database\EventsIt contains a set of text files holding the events logged for each day. Compare these against what the Event monitoring page shows — they are the same data, and a difference means the collection has not completed.
2. Check the agent log on the monitored server. The client collects event information using a periodic WMI query, and logs that activity here:
\Program Files (x86)\ENow\Mailscape Agent\LogFiles\EventAgent.logThis is the file to look at when the monitoring page shows nothing for a server — it will show whether the query is running and whether it is returning results.
3. Confirm the event exists on the server. Open Event Viewer on the monitored server and locate the reported event. The event text carries the detail the indicator cannot: the component that logged it, the failure, and often the remedy.
4. Establish whether it is recurring. A single warning event and the same event every few minutes are different problems. The daily files in the Events folder make this straightforward to check across several days.
Common warning or error results, and potential solutions
| Result | Potential solution |
| A warning event is reported | Locate the event in Event Viewer on that server. Warning events are frequently precursors — worth reading rather than clearing, particularly where they recur. |
| A critical event is reported | Treat as a live fault on that server. The event text identifies the component and the failure. |
| The same event repeats continuously | Recurrence is the signal. Check the daily files under the Events folder to establish when it started and whether the rate is increasing. |
| No events shown for a server that should have some | Check EventAgent.log on that server. If the WMI query is failing, the monitoring page will show nothing rather than reporting an error. |
| Monitoring page and the daily files disagree | The collection has not completed. Allow a cycle and compare again. |
| An expected, benign event keeps alerting | Where an event is known and accepted in your environment, use Alert Exclusions to suppress that specific event rather than disabling the test. |
Related monitoring tests
- On domain controllers, AD Events under AD Replication watches specifically for Active Directory replication event IDs.
- DFS Replication Events monitors SYSVOL and DFS replication events.
Comments
0 comments
Please sign in to leave a comment.