In this scenario, the primary concern is to receive alerts if specific events happen. Of course, alerting is often used together with other scenarios as alerting alone does not provide in-depth analysis or storage of the captured events.
Alerts can be generated by every running instance of MonitorWare Agent. As such, alerts can be generated both on each machine that is monitored as well as on a central machine. Also, alert generation can be combined.
There are advantages and disadvantages for each mode. The big plus of generating alerts on each monitored machine is that they will be triggered whenever they are detected. There is no interim system that events need to be passed to and as such no interim system that can fail. However, this implies that alerts need to be configured on each monitored machine, which can be inconvenient (but becomes less of a burden with the soon available central configuration service).
Central alert generation ultimately solves this issue, as alerts are only generated on a single machine or at least few machines. On the other hand, if the reporting system is not able to reach the central server for some reason or the central server fails, no alerts will occur at all. This, of course can be largely worked around by monitoring the central server’s health with another instance of the MonitorWare Agent running on another machine, but this adds complexity.
Fortunately, MonitorWare is flexible enough to allow all imaginable configurations. For example, it is possible to trigger for extremely urgent alerts on every monitored machine while less critical alerts are checked at a central server.
In any case, alerts are defined via rule sets. Inside the rule set, filters are defined for the alert conditions and action carry out the actual alert. Of course, alert actions are most often sending emails or starting a “net send” command to broadcast the message e.g. to a group of network administrators.
Alerts can be executed on a MonitorWare Agent who is also performing other functions.