Filtering Strategies - TelAlert UMS Administrator Guide

10.4.1 Filtering and Default Logic

The simplest way to associate an existing [

Filter

] definition with a destination is to refer to the [

Filter

] definition in the [

Destinations

] definition. You can also specify a default [

Filter

] definition that will apply to all destinations except those that specify their own. Thus, in the following example—

[Destinations]

...

Filter=DefaultFilter ...

{DavidTextPager}

...

{JohnTextPager}

...

{RachelTextPager}

...

Filter=RachelFilter

—{

DavidTextPager

}and {

JohnTextPager

} are both associated with {

DefaultFilter

} while {

RachelTextPager

} is associated with its own [

Filter

] definition, {

RachelFilter

A [

Filter

] definition specified directly on the command line overrides all others. Thus, in the case of the following command—

telalertc -i RachelTextPager -m "this is a test" -tags router -filter DefaultFilter

—the [

Filter

] definition in play is {

DefaultFilter

} because its specification on the command line overrides the [

Filter

] definition directly associated with {

RachelTextPager

10.4.2 RequiresFullMatch and Exclusive Value Combinations

In the above scenario, David wants TelAlert to suppress all messages except those meeting either of two conditions. He achieves this by setting both

RequiresFullMatch

and

Exclusive

False

. Each of the four possible combinations of

RequiresFullMatch

and

Exclusive

provides a unique effect and thus serves a relatively specific purpose.

RequiresFullMatch=False, Exclusive=False

Generally speaking, this combination is useful when you want all of the messages directed to a destination to be filtered (and thus not sent) unless they meet specified criteria. It differs from the

True-False

combination, however, in that it allows you to specify a set of criteria and have the destination be considered valid if it matches in a single respect.

In the example provided, this combination is appropriate because David wants to filter all messages other than those specified. At the same time, he wants to be able to provide a fairly “loose”

specification: either messages tagged with

Router

or messages tagged with

Server

RequiresFullMatch=False, Exclusive=True

Generally speaking, this combination is useful when you want all of the messages directed to a destination to be sent unless they meet specified criteria (in which case you want TelAlert to discard them). It differs from the

True-True

combination, however, in that it allows you to specify a set of criteria and have the destination be excluded if it matches in any respect.

Under what circumstances might this be the appropriate combination? Perhaps you want a certain destination to receive any message directed to it unless the message falls into one of three classes:

those relating to Web servers, those relating to mail servers, and those relating to Internet gateways.

To accomplish this, you would:

use the

False-True

combination

include three tags in your [

Filter

] definition:

Web

Mail

, and

Internet

configure your monitoring software so that, each time it generates a TelAlert command, it provides the information necessary to create these tags on the command line (where appropriate)

RequiresFullMatch=True, Exclusive=False

Generally speaking, this combination is useful when you want all of the messages directed to a destination to be filtered (and thus not sent) unless they meet specified criteria. It differs from the

False-False

combination, however, in that it allows you to specify a set of criteria and have the destination be considered valid only if it matches in every respect.

Under what circumstances might this be the appropriate combination? Perhaps you want a certain destination to receive only a very narrow set of messages. For instance, your network monitoring application may be able to generate notifications about a number of different status changes and node types, but in this case you want to receive “node down” messages only, and only those pertaining to downed UNIX servers—not routers, and not Windows servers.

To accomplish this, you would:

use the

True-False

combination

include three tags in your [

Filter

] definition:

Down

Server

, and

UNIX

configure your monitoring software so that, each time it generates a TelAlert command, it provides the information necessary to create these tags on the command line (where appropriate)

RequiresFullMatch=True, Exclusive=True

False-True

combination, however, in that it allows you to specify a set of criteria and have the destination be excluded only if it matches in every respect.

Under what circumstances might this be the appropriate combination? Perhaps you want a certain destination to receive any message directed to it unless the message has all of three special

characteristics: it pertains to a (1) workstation (2) manufactured by Hewlett-Packard and (3) running UNIX. To accomplish this, you would:

use the

True-True

combination

include three tags in your [

Filter

] definition:

Workstation

HP

, and

UNIX

configure your monitoring software so that, each time it generates a TelAlert command, it provides the information necessary to create these tags on the command line (where appropriate)

Interaction Between

Exclusive

and

RequiresFullMatch

works in conjunction with the tags specified in the filter and on the command line to determine whether a destination is a “match.”

Exclusive

tells TelAlert what to do with matches and, implicitly, with non-matches.

With

Exclusive

set to

False

, matching destinations are used and non-matching destinations are discarded.

With

Exclusive

set to

True

, matching destinations are discarded and non-matching destinations are used.

10.4.3 RequiresClientMatch

The

RequiresClientMatch

keyword has roughly the opposite effect of

RequiresFullMatch

: When this keyword is set to

True

, the filtering condition is met only if all the tags passed on the command line are also listed in the [

Filter

] definition. (Additional, non-matching tags present in the definition do not prevent a match.) Use this keyword when you want to filter out messages with tags that do not match a specific list.

10.4.4 The MatchKeyword

The

Match

keyword allows you to exert greater control over what constitutes a match. Using the two possible values for

RequiresFullMatch

, you can specify that a match takes place whenever either one or all of the tags defined in the [

Filter

] definition are matched on the command line.

The

Match

keyword opens up the many possibilities lying between “one” and “all.”

Using

Match

, you can specify a subset of tags that must be matched, and you can do this using conjunctional and disjunctional statements, i.e., “and” and “or” assertions. For instance, the following

Match

value—

Match=(Tag1 | Tag2) & Tag3

—says that a match occurs whenever the message is accompanied by either

Tag1

^or

Tag2

and

Tag3

. In other words, two of the three are required, and one of the two must be

Tag3

. In this example—

Match=(Tag1 & Tag2) | (Tag3 & Tag4)

—a match is understood to occur whenever the message is accompanied by either

Tag1

and

Tag2

Tag3

and

Tag4

. In other words, two of the four are required, and not just any two: either 1 and 2 or 3 and 4.

Match Value Expression Building Blocks

In addition to the tag names, the building blocks of a

Match

value expression are the “or” symbol (|), the “and” symbol (&), and the pairs of parentheses you can use to group portions of the expression. Parentheses are useful because TelAlert, in evaluating an expression, assigns equal importance to both |and &; it simply reads the expression from left to right, with the outcome depending on the first decisive operator.

For instance:

Match=Tag1 | Tag2 & Tag3

Here, if

Tag1

is a match, TelAlert will recognize that the entire expression is matched as soon as it sees the |. If

Tag1

is not a match, it will read on, recognizing the entire expression as matched only if both

Tag2

and

Tag3

are matched. In both cases, it proceeds as if the expression were written like so:

Match=Tag1 | (Tag2 & Tag3)

Consider this example:

Match=Tag1 & Tag2 | Tag3

Here, if

Tag1

is a match, TelAlert reads on, driven by the & operator to see if either

Tag2

Tag3

is also a match, required for the entire expression to be a match. If

Tag1

is not a match, TelAlert recognizes the entire expression as a non-match as soon as it sees the &. In both cases, it is as if the expression were written like so:

Match=Tag1 & (Tag2 | Tag3)

Even though you do not always have to use parentheses to set a Match value expression, it is a good idea to do so anytime you are writing an expression that mixes

|

and

&

operators, since this will help you avoid errors and reduce the potential for confusion on the part of someone examining the expression.

Match and RequiresFullMatch

It is important to note that no value you assign to

RequiresFullMatch

will have any meaning if

Match

is assigned a value; only one of these keywords can be in play at a time.

Exclusive

works in conjunction with

Match

just as it does with

RequiresFullMatch

: if the conditions for a match are met, the destination is included or excluded, as appropriate.

10.4.5 Filtering and Groups

The following discussion concerns two points of intersection between filtering and groups. For information on setting up and using [

Group

] definitions, refer to Chapter 14: Broadcasting to Groups and Creating Escalations.

Choosing the Appropriate Destination from Within a Group

So far, this discussion of filtering has assumed that TelAlert is being asked to send a message to a single destination, and that you want to use filtering as a means of having TelAlert act on or disregard this request, according to specified rules. For instance, it may be that the easiest way to integrate a network monitoring application with TelAlert is to configure it to generate a TelAlert alert for every event that it detects. Because you do not want TelAlert to send all of these messages, you create a [

Filter

] definition and refer to it in all of your destinations, such that only “real” events generate alerts.

A far more common scenario involves messages directed to groups of destinations. Perhaps you have a group called {

Support

} that is comprised of four pager destinations, one for each support technician. Each technician is primarily responsible for one of four areas: servers, workstations, routers, and modems. Here you could use [

Filter

] definitions so that your help desk software does not have to know which destination (i.e., which support technician) to notify about a given problem; instead, it always sends to the entire {

Support

} group, along with a problem-specific tag that TelAlert uses to select the appropriate destination.

Consider the following [

Filter

] definitions, each associated with {

JohnTextPager

}, {

DavidTextPager

}, {

RachelTextPager

}, and {

CynthiaTextPager

}, respectively:

[Filter]

Now, recalling that {

Support

} is a group of destinations comprised of {

JohnTextPager

}, {

DavidTextPager

}, {

RachelTextPager

}, and {

CynthiaTextPager

}, consider this command:

telalertc -g Support -m "node down" -tags server

Upon receiving this command, TelAlert would evaluate the four destinations comprising {

Support

}, using the [

Filter

] definition associated with each and the

–tags

value from the command line to determine which it should notify. In this case, TelAlert would notify John by sending him a page. The advantage is that the application generating the command can follow a very simple process every time, always specifying the same group and simply inserting a tag derived from the nature of the problem. This is also a benefit when human users will be generating the command and are unlikely to know who to contact.

Associating a [Filter] Definition with a Group

You can associate a [

Filter

] definition with a formally defined group of destinations, either by referring to it specifically in the [

Group

] definition or by setting it as the default value for all groups.

A [

Filter

] definition specified directly in a [

Group

] definition overrides the default.

Note that a [

Filter

] definition assigned to a group is not in turn assigned to the destinations comprising it; the [

Filter

] definition determines only whether the group itself is valid, given the tags included on the command line.

A group can be associated with one [

Filter

] definition, a subgroup within that group with another, and each of the individual destinations with still others. If, after evaluating the group’s [

Filter

] definition, TelAlert finds that the group is valid, it evaluates the subgroup’s [

Filter

] definition. If this too is valid, it looks at the [

Filter

] definitions invoked at the destination level. In such a case, the message will be sent to a destination only if all three [

Filter

] definitions permit it.

10.4.6 Filtering and Schedules

A [

Filter

] definition is one way of qualifying a destination—i.e., of setting rules for determining whether the destination is valid for a given message. A schedule is another means of destination qualification. Whereas a [

Filter

] definition determines whether a destination is valid based on the tag or tags accompanying the message, a schedule determines whether a destination is valid based on the time the message is to be sent.

You do not have to do anything special to make [

Filter

] definitions and schedules work together. If a destination is associated with a [

Filter

]definition and a [

Schedule

] definition, TelAlert will send it a message that is accompanied by a

-tag

value only if it finds that the destination is both on duty and valid according to the terms of the [

Filter

] definition.

For information on setting up and using schedules, refer to Chapter 11: Setting Up and Applying Schedules.

10.4.7 Filtering and Users

[

User

] definitions offer another means of associating [

Filter

] definitions with destinations. You can create a [

User

] definition that refers to a [

Filter

] definition and then refer to this [

User

] definition in the destination. The [

Filter

] definition will operate as if it were specified there

directly. (However, if a [

Filter

] definition is specified directly in the destination, it will override the one specified at the user level.)

This is an especially effective way of linking a [

Filter

] definition with one or more destinations when several destinations “belong to” the same human user and you want the same [

Filter

] definition to apply in all cases. For example:

[Filter]

...

User=John ...

{JohnHomePhone}

...

User=John ...

Here, {

JohnFilter

} will apply whenever TelAlert is asked to send a message (accompanied by one or more tags) to a destination linked to {

John

Maintaining links between [

Filter

] definitions and destinations in this way is valuable in part because filtering is typically used to see that the right messages get to the right person; this method allows you to think in terms of people as you set up filtering. If you are using [

User

] definitions to link schedules to destinations, too, this method makes even more sense.

In document TelAlert UMS Administrator Guide (Page 170-178)