Article created 2003-05-14 by Rainer
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
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