MonitorWare concepts - WinSyslog
Article created 2004-05-27 by Tamsila-Q-Siddique.
Filter Conditions
Filter conditions are used inside the rule
engine. They help to decide when a rule is to be carried out.
Filter conditions are considered to match of the outcome if the
configured comparison operation is "TRUE". Available filter conditions are listed down below:
- Global Conditions
- General Conditions
- Date / Time
- InformationUnit Type
- Syslog
- SNMP Traps
- Custom Property
Global Conditions
Global Conditions apply to the rule as whole. They are automatically combined with a logical "AND"
with the conditions in the filter tree. These are:
Minimum Wait Time - This filter condition can be
used to prevent rules from firing to often. For example, a rule might be
created to check the status of a port probe event. The port probe probes
an SMTP server. If the event is fired and the rule detects
it, it will spawn a process that tries to restart the service. This process will
take some time. Maybe the SMTP gateway need some more time
to fully start up so that the port probe might fail again while the problem is
already taken care of. The port probe as such will generate an
additional event. Setting a minimum wait time will prevent this second
port probe event to fire again if it is – let us say – within 5
minutes from the original one. In this case, the minimum wait time is
not yet reached and as such, the rule will not match. If, however, the
same event is generated 5 hours later (with the mail gateway failing
again), the rule will once again fire and corrective action taken.
Fire only if Event occurs - This is kind of the opposite
of the "Minimum Wait Time". Here, multiple events must come in
before a rule fires. For example Ping is not a very reliable protocol, so a single ping
might be lost. Thus, it may not be the best idea to restart some
processes just because a single ping failed. It would be much better to
wait for repetitive pings to fail before doing so.
Exactly this the "Fire only if Event occurs" filter condition is made for. It waits until
a configured amount of the same events occurs within a period. Only if the
count is reached, the filter condition matches and the rule can fire.
General Filter Conditions
This set includes filters which are related to Non-Event Log specific settings. These are:
Source System -This is the system a message
originated from. It can be used to check for authorized systems to pass
messages to the MonitorWare Agent.
Message Content - The message content filter condition is very powerful. It evaluates
to true if the specified content is found anywhere within the message. As there is implicit
wildcarding, there is no need for extra wildcards to be specified.
CustomerID - CustomerID is provided for customer ease. For example if someone
monitors his customer's server, he can put in different CustomerIDs into each of the agents. This is
user configurable.
SystemID - SystemID is of type integer and is to be used by our customer. In addition, it is
user configurable.
Status Name and Value - These filter type corresponds to "Set Status Action".
Date / Time
This filter condition is used to check the time frame and / or day of week in which an event
occurred.
Time - This filter condition is used
to check the period in which an event occurred. For example, a syslog
message from a Cisco router saying that it dialed up is normal if it
occurs during office hours. If it occurs at night, so, it is an alerting
signal and an administrator might receive notification of this event
(while he might otherwise decide to discard it). This can be done with
the time setting.
Weekdays - This is closely equivalent to the time filter condition, except that it is applied
on a per-day basis. So it can be used to detect for example events occurring on weekends and act
differently on them.
Information Unit Type
This is based on the type of service that generated the information unit. So with this setting
rules can be created that act only on e.g. syslog messages.
Syslog
Syslog related filters are grouped here:
Syslog Priority - For syslog information units,
this is the actual syslog priority. If that filter condition is used on
non-syslog originated information units, it will be a value mapped on a
best effort basis to a syslog priority.
Syslog Facility - For syslog information units,
this is the actual syslog facility. If that filter condition is used on
non-syslog originated information units, it will be a value mapped on a
best effort basis to a syslog facility.
Syslog Tag - The syslog tag value, is a short string. For non-syslog messages, this is provided
based on configuration. In most cases, this is used for filtering.
SNMP Traps
Using SNMP Traps MonitorWare Agent can be used to manage and monitor all sorts of equipment
including computers, routers, wiring hubs etc. A trap is generated when the device feels it should do
so and it contains the information that the device feels should be transmitted. Related filters are grouped here:
Community - It corresponds to the respective SNMP entity.
Enterprise - It corresponds to the respective SNMP entity.
Generic name - It corresponds to the respective SNMP entity.
Version - It corresponds to the respective SNMP entity.
Uptime - It corresponds to the respective SNMP entity.
Custom Property
As the name suggests it is a "Custom Property". Internally in MonitorWare Agent all values are
stored in properties. For example the main message is stored in a property called "msg". By using this
dialog you can access properties which are dynamic (Like those from SNMP Trap Monitor when using v2
protocol).
|
