How Filters Work

Glossary:  Filters

Configuring a Filter

Filtering is based on the following adjustable Conditions:

  • Number of monitoring Agent locations reporting an Error
  • Duration of a period during which an Error is reported
  • Number of failed Tasks
  • State of an Owner Device
  • Specific type of Error, or Error code

Each new response is verified through a Filter in the following sequence:

  1. Error Code Check – compares a received error code (ex. HTTP “404 NOT FOUND”) with a list of Ignored Errors that are specified in a Filter
  2. Task Number Check – verifies if the number of failed tasks is above, or equals, the number of tasks that are specified in a Filter
  3. Monitoring Agent Locations Number Check – verifies if the number of failed monitoring locations (aka “Agents”) is above, or equals, the number of monitoring locations specified in a Filter. When the number of monitoring Agent locations that report an error reach a number specified in the Filter, the Error Duration Timer starts
  4. Error Duration Timer Check – compares the duration of the reported error with a duration specified in a Filter
  5. Owner Device State Check – verifies if an Owner Device is DOWN. In the case when an Owner Device is down, alert messages will not be sent (This option only affects Filters for notifications)

<Default Filter>  When a new monitoring device is set-up a <Default Filter> is automatically assigned to it.  In order for the <Default Filter>  to send an Alert for an Error, the Error must be detected by two, or more, monitoring Agent locations.

The <Default Filter> is recommended, in most cases, as it is designed to suppress most “nuisance” Error Alerts (such as, inconsequential network “hiccups etc…).

However, if only one monitoring location is used with a <Default Filter>, then the Default Filter requirement, of two monitoring locations needed to confirm an error, will be ignored. In this situation, an error will be confirmed if the one monitoring location detects an error even if Default filter is enabled. In fact, if the number of monitoring locations used is ever less than the required locations set-up within a filter to detect an error for a device, then the filter will be ignored.

Examples:

  • Using “Error is not confirmed by at least XX monitoring locations”:A Device is set-up to monitor a company web portal from 15 worldwide monitoring locations. The owner of the Device doesn’t want to wake up at night due to alerts caused by temporary network issues occurring simultaneously at two  backbone providers. Therefore, the Filter is configured to ignore errors unless they are confirmed by at least three monitoring locations.
  • Using “Error is detected in less than XX tasks”:An organization has a wide sub-network with four routers, which are holding all incoming and outgoing traffic. The routers are configured to be interchangeable in case one of the routers is temporarily overloaded. The monitoring is configured to detect a situation when two, or more, routers are inaccessible from any geographic location. The best practice in this situation is to create a Device with four ICMP (ping) Tasks and assign a Filter. The Filter is configured to Ignore Errors unless the Error is detected in at least two ICMP Tasks.
  • <Default filter> assigned to a Device will bypass alerting unless the Error is confirmed by two, or more, monitoring locations;
  • <Default filter> applied to any Report will calculate responses, as long as the Error was confirmed by two, or more, monitoring Agent locations simultaneously, within the requested report period. (Also, keep in mind that using the <Default Filter> an error from only one monitoring location will not result in a DOWN state.)