Event Trigger [Cisco Performance Engine]

Table Of Contents

Event Trigger

Event Trigger Configuration

XML Configuration Example

Event Trigger Notifier Creation

Event Trigger Notifier Association with Collectors

Specifying the Interval Limit for Collection

Trigger Definition file

Trigger Limits: MaxActions and Interval

Event Mapping file

Event Trigger Usage in MPLS Scenario

Event Trigger

Event Trigger allows Network Engineer/SE/Partner applications to develop rules which trigger collections (or any other XML command) based on a certain Event condition.

Event Trigger takes action based on event match. The user specifies an event-action rules pair in an event-action mapping file. One or more mapping files is specified in the Trigger Definition file. This file is loaded by the notifier and associated with a collector.

When a notification is raised/cleared from these collectors, the notification is matched against the rules defined in event-action mapping file. If a notification matches any of the defined rules, the action specified in the rules is invoked.

For example, suppose you have configured a MibCollector for thresholds of ifInErrors.1. The event-action mapping file that defines rule to match the raised threshold for ifInErrors.1 is associated with the MibCollector.

When a threshold is raised for ifInErrors.1, it matches the rule. This invokes the action corresponding to the matched rule. The action invocation may be starting a new collector to poll for attributes like ifInOctets.1 and ifOutOctets.1.

Event Trigger Configuration

This section describes the following:

•XML Configuration Example

•Trigger Definition file

•Event Mapping file

XML Configuration Example

This XML configuration example contains the following sections:

•Event Trigger Notifier Creation

•Event Trigger Notifier Association with Collectors

•Specifying the Interval Limit for Collection

Event Trigger Notifier Creation
<das>
	<create>
		<notifier name= "EventTriggerNotifier">
			<mappingUrl>
				file:///cnsperfe/config/TriggerDefinitions/triggerDefinition.txt
		 	</mappingUrl>
		</notifier>
	</create>
</das>
The triggerDefinition.txt contains the event-action mapping file which defines rules for trigger activation.

Event Trigger Notifier Association with Collectors

The EVENT Trigger notifier is associated with collector similar to any other notifier (CNS/Trap/Plugin).
<das>
   <create>
     <collector name="c">
      <MibCollector>
          <schedule name="s"/>
          <device name="d"/>
          <threshold name="t"/>
          <notifier name="n"/>
          <notifier name="EventTriggerNotifier"/>
          <dataHandler name="h"/>
          <snmpGet>
               <oid>sysName.0</oid>
          </snmpGet>
          <snmpGetMany>
               <oid>ifInOctets</oid>
          </snmpGetMany>
     </MibCollector>
   </collector>
  </create>
</das>
Specifying the Interval Limit for Collection
<das>
    <create>
	     <schedule name= "randomSchedule">
			<interval>PT15S</interval>
			<maxIntervals>3</maxIntervals>
	     </schedule>
	 </create>
</das>
The maxIntervals tag of the schedule component can be used to limit the number of times the collection is invoked. This provides the flexibility to specify limits and restrict the number of schedule intervals for a given collector.

Trigger Definition file

This section describes the trigger definition file format.

Version=1.0
ID,MappingFile,MaxActions,Interval
where

Version - indicates version number of the trigger definition file.

ID - uniquely identifies an EVENT. This ID can be used while logging messages related to EVENT.

MappingFile - the event-action mapping file which defines rules to match a EVENT and action to be invoked after a match.

MaxActions - maximum number of actions to be invoked.

Interval - time interval to determine invocation rate. The interval is specified in either of the following formats:

–PT10S - S implies interval specified is in seconds.

–PT10M - M implies interval specified is in minutes.

–PT10H - H implies interval specified is in hours.

Example
	Version=1.0
	 ID,MappingFile,MaxActions,Interval
	 1,/opt/cnsperfe/config/EventMappings/rules-raise.re,3,PT2M
	 2,/opt/cnsperfe/config/EventMappings/rules-clear.re,5,PT30S
Trigger Limits: MaxActions and Interval

Trigger limit parameters allows the user to control the action and invocation rate of the matched notifications. The following example explains how the trigger limits are used to control number of actions to be invoked.

If MaxActions=3 and Interval=PT2M

•Scenario 1: Suppose 100 TCAs are raised/cleared, out of which 20 TCAs match the rule defined in the event-mapping file. All the 20 TCAs are received within the 2M (Interval) time frame.

•Event Trigger Behavior: Action is invoked only for the first 3(MaxActions) of the 20 matched TCAs. Hence MaxActions controls the number of action invocations for the matched TCAs.

If MaxActions=15 and Interval=PT10S

•Scenario 2: Suppose 100 TCAs are raised/cleared, out of which 25 TCAs match the rule defined in the event-mapping file. Out of the 25 matched TCAs, only 10 TCAs come within the 10S (Interval) time frame.

•Event Trigger Behavior: Because only 10 TCAs of the 25 matched TCAs arrived with the 10 second Interval time frame, action is invoked only for those 10 TCAs matched. This way, the Interval controls the action invocation rate.

You should configure the Trigger Limit parameters to accommodate anticipated scenarios.

Event Mapping file

The Event Mapping file defines rules for Trigger activation. The file format is:

<EVENT_REGEXP>...............</EVENT_REGEXP>
<ACTION_REGEXP>...............</ACTION_REGEXP>
where

<EVENT_REGEXP></EVENT_REGEXP> - the regular expression that matches a threshold raised/cleared.

<ACTION_REGEXP></ACTION_REGEXP> - an action expression which is invoked as a result of a match. This can be a collector combination or any other XML command.

If you want to extract values from the notification and substitute in the action, then use sub-expressions in the event regular expressions. CNS PerfE takes the values of these sub-expressions and provides them as a name value pair with the name as VARx.

This event mapping file is also termed as event-action mapping file.

There are 3 types of CNS PerfE notifications:

1. Threshold notification
<event>
 <id>
  <type>threshold</type> 
  <sequence>1375</sequence> 
 </id>
 <source>
  <device>
   <ipaddress>1.1.1.1</ipaddress> 
   <time>2003-07-11T03:47:12.836Z</time> 
  </device>
   <server>
   <name>CNS-PerfE hostname</name> 
   <ipaddress>CNS-PerfE IP Address</ipaddress> 
   <entity>Cisco CNS-PerfE</entity> 
   <version>dev</version> 
   <time>2003-07-11T03:47:12.837Z</time> 
   </server>
 </source>
 <priority>
  <server>minor</server> 
 </priority>
 <threshold>
  <type>crossed</type> 
  <attribute>55.DT.queue3.cbQosPoliceConformedPkt</attribute> 
  <value>300</value> 
  <configuredOp>GTE</configuredOp> 
  <configuredValue>300</configuredValue> 
 </threshold>
 <specific>
  <das>
   <collector name="c">
    <type>com.cisco.das.CBQoSCollector.CBQoSCollector</type> 
   </collector>
   <device name="d" /> 
   <threshold name="t2" /> 
  </das>
 </specific>
</event>  
2. Information notification
<event>
 <id>
  <type>informational</type> 
  <sequence>0</sequence> 
 </id>
 <source>
  <server>
   <name>CNS-PerfE hostname</name> 
   <ipaddress>CNS-PerfE IP Address</ipaddress> 
   <entity>Cisco CNS-PerfE</entity> 
   <version>dev</version> 
   <time>2003-07-11T03:18:33.461Z</time> 
  </server>
 </source>
 <priority>
  <server>none</server> 
 </priority>
 <informational>
  <type>stop</type> 
  <description>Normal termination</description> 
 </informational>
 <specific>
  <das>
   <collector name="sys">
    <type>com.cisco.das.SystemCollector.SystemCollector</type> 
   </collector>
  </das>
 </specific>
</event>
3. Error notification
<event>
 <id>
  <type>error</type>
  <sequence>1</sequence>
 </id>
 <source>
  <server>
   <name>CNS-PerfE hostname</name>
   <ipaddress>CNS-PerfE IP Address</ipaddress>
   <entity>Cisco CNS-PerfE</entity>
   <version>dev</version>
   <time>2003-07-11T03:25:00.113Z</time>
  </server>
 </source>
 <priority>
  <server>minor</server>
 </priority>
 <error>
  <type>Threshold Processing</type>
  <description>Invalid threshold attribute sys.disk.d.usedPercentage configured for 
SystemCollector</description>
 </error>
 <specific>
  <das>
   <collector name="sys">
    <type>com.cisco.das.SystemCollector.SystemCollector</type>
   </collector>
  </das>
 </specific>
</event>
Refer to the <CNS-PerfE dir>/schema/event.xsd schema for the definition of each of these notifications.

This following example describes about <EVENT_REGEXP> and <ACTION_REGEXP>.
<EVENT_REGEXP><event><id><type>threshold</type><sequence>(\d+)</sequence></id><source><dev
ice><ipaddress>(\d+.\d+.\d+.\d+)</ipaddress><time>.*</time></device><server><name>\w+</nam
e><ipaddress>\d+.\d+.\d+.\d+</ipaddress><entity>.*</entity><version>.*</version><time>.*</
time></server></source><priority><server>critical</server></priority><threshold><type>\S+<
/type><attribute>.1.3.6.1.2.1.2.2.1.10. (.*) 
</attribute><value>\d+</value><configuredOp>GTE</configuredOp><configuredValue>\d+</config
uredValue></threshold><specific><das><collector name= 
".*"><type>com.cisco.das.MibCollector.MibCollector</type></collector><device 
name="(.*)"/><threshold name=".*"/></das></specific></event></EVENT_REGEXP>
<ACTION_REGEXP><das><create><schedule 
name="s-VAR1"><start>2001-08-31T00:00:00.000-08:00</start><interval>PT5M</interval><maxInt
ervals>2</maxIntervals></schedul
e><collector name="c-VAR1"><MibCollector><schedule name="s-VAR1"/><device 
name="VAR4"/><dataHandler 
name="h"/><snmpGet><oid>IfInErrors.VAR3</oid></snmpGet></MibCollector></collector></create
><start><collector name="c-VAR1"/></start></das></ACTION_REGEXP>
CNS PerfE is configured for MibCollector to collect ifInOctets and thresholds are configured for this attribute.

The <EVENT_REGEXP> defines the following rule:

•Match any raised threshold for ifInOctets (as specified in the configuredOP tag).

•The values in () will be extracted by the EVENT Trigger from the matched threshold for substitution in the ACTION_REGEXP.

The VARx values of <ACTION_REGEXP> are the extracted values from the matched threshold received by the EVENT Trigger. The VARx values correspond to the () values in the EVENT_REGEXP.

In the above example:

VAR1 = sequenceID

VAR2 = device IP Address

VAR3 = index of the attribute configured for threshold

VAR4 = device name

If VAR1=1, VAR2=10.0.1.2, VAR3=1, and VAR4=d the <ACTION_REGEXP> can be interpreted as:

•Create a collector by name c-1 and schedule s-1.

•The collector is configured for ifInErrors.1.

•The schedule interval is 2 Minutes and maxIntervals is 2. This implies that the collector c-1 created dynamically as a result of a threshold match will poll the configured attribute ifInErrors.1 two times.

Note The sequenceID value used while creating a schedule and a collector component is to keep the component names unique. If the component names in the <ACTION_REGEXP> specified are not unique, duplicate component exception is reported in cases where multiple thresholds match the same <EVENT_REGEXP>.

Event Trigger Usage in MPLS Scenario

The Event Trigger feature helps in MPLS troubleshooting using threshold crossing alerts (TCAs) for the identification of performance bottlenecks and proactive capacity planning. This feature can be used for example, for MPLS pings to identify reachability issues and then automatically trigger performance or troubleshooting policies; for example, using a MPLS ping TCA to automatically trigger an appropriate MPLS traceroute operation.

Cisco CNS PerfE supports MPLS ping and traceroute commands via IosCliOpsCollector. Take the following steps to configure Cisco CNS PerfE to support workflows for MPLS troubleshooting:

Step 1 Configure a collector to periodically execute MPLS LSP ping.

Step 2 Configure thresholds for ping failure for the configured collector.

Step 3 Configure the Event Trigger feature as follows:

If ping failed notification is generated from the LSP ping, then CNS PerfE automatically starts the trace for the same LSP/VRF.

With the preceding configuration, whenever a ping failure is detected, Cisco CNS PerfE automatically triggers the corresponding traceroute operation and sends the data to the performance- or fault-management application.

The following XML example executes the MPLS ping command on the specified device every 15 minutes. Thresholds are configured for ping.successRate attribute. If the ping successRate is below 30% then a notification is raised which triggers MPLS traceroute command for the same LSP.

A CNS dataHandler is also created which will be used by the collector triggered as a result of ping failure to send MPLS traceroute data.
<das>
    <create>
        <schedule name="FifteenMinSched">
            <interval>PT15M</interval>
        </schedule>
        <device name="mplsDevice">
            <ios>
                <ipaddress>40.1.1.3</ipaddress>
                <username>lab</username>
                <password>lab</password>
                <secret>lab</secret>
                <connectMode>direct</connectMode>
                <transportMode>telnet</transportMode>
            </ios>
        </device>
        <threshold name="pingThreshold">
            <attribute name="ping.successRate">
                <raiseOperation>LTE</raiseOperation>
                <raiseValue>30</raiseValue>
                <clearOperation>GTE</clearOperation>
                <clearValue>90</clearValue>
                <level>minor</level>
            </attribute>
        </threshold>
        <dataHandler name="pingDataHandler">
            <ftp>
                <urlPrefix>ftp://username:passwd@hostname/IOSCLIOPS_</urlPrefix>
            </ftp>
        </dataHandler>
        <dataHandler name="traceDataHandler">
            <cns>
                <subject>cisco.mgmt.das.cnsDatahandler</subject>
            </cns>
        </dataHandler>
        <notifier name="thresholdNotifier">
            <cns>
                <subject>cisco.mgmt.das.cnsnotifier</subject>
            </cns>
        </notifier>
        <notifier name="Trigger-Not">
            
<mappingUrl>file:///CSCOPerfE/config/EventTrigger/TriggerDefinition.txt</mappingUrl>
        </notifier>
<collector name="c">
            <IosCliOpsCollector>
                <schedule name="FifteenMinSched"/>
                <device name="mplsDevice">
                    <operation name="op1">
                        <command>ping mpls ipv4 10.131.159.252/32</command>
                    </operation>
                </device>
                <threshold name="pingThreshold"/>
                <notifier name="thresholdNotifier"/>
                <notifier name="Trigger-Not"/>
                <dataHandler name="pingDataHandler"/>
                <regexp-url>file:///CSCOPerfE/config/ioscli/LspPing.re</regexp-ur
l>
            </IosCliOpsCollector>
        </collector>
    </create>
    <add/>
    <stop/>
    <start>
        <collector name="c"/>
    </start>
</das>
The notifier component Trigger-Not is the Event Trigger associated with the collector. The notifier points to a TriggerDefinition.txt which will contain rules for TCAs.

TriggerDefinition example:
Version=1.0
ID,MappingFile,MaxActions,Interval
1,/CSCOPerfE/config/EventTrigger/rules-ping-raise.re,2,PT30S
2,/CSCOPerfE/config/EventTrigger/rules-ping-clear.re,2,PT30S
This Trigger Definition file has two entries rules-ping-raise.re and rules-ping-clear.re which defines rules for matching the event and action to be invoked after a match.

rules-ping-raise.re:

This rules suggests that if a notification raised as a result of ping failure matches with the EVENT_REGEXP, then a new collector is spawned which executes MPLS trace command for the same LSP and sends the collected statistics to a CNS datahandler.
<EVENT_REGEXP><event><id><type>threshold</type><sequence>\d+</sequence></id><source><devic
e><ipaddress>.*</ipaddress><time>.*</time></device><server><name>.*</name><ipaddress>.*</i
paddress><entity>.*</entity><version>.*</version><time>.*</time></server></source><priorit
y><server>minor</server></priority><threshold><type>crossed</type><attribute>ping.successR
ate</attribute><value>\d+</value><configuredOp>LTE</configuredOp><configuredValue>\d+</con
figuredValue></threshold><specific><das>< collector name="c"> 
<type>com.cisco.das.IosCliOpsCollector.IosCliOpsCollector
</type></collector><device name="mplsDevice"/><threshold 
name="pingThreshold"/></das></specific></event></EVENT_REGEXP>
<ACTION_REGEXP><das><create><schedule name="TwoMinSched"> 
<interval>PT2M</interval><maxIntervals>5</maxIntervals></schedule><collector 
name="c_mplsDevice"><IosCliOpsCollector><schedule name="TwoMinSched"/> <device 
name="mplsDevice"><operation name="traceOp"><command>trace mpls ipv4 
10.131.159.252/32</command></operation></device><dataHandler 
name="traceDataHandler"/><regexp-url>file:///CSCOPerfE/config/ioscli/LspTrace.re</regexp-u
rl> </IosCliOpsCollector></collector></create><start><collector 
name="c_mplsDevice"/></start></das></ACTION_REGEXP>
rules-ping-clear.re:

This rule conveys that when a clear notification matches the EVENT_REGEXP, then the collector created for MPLS traceroute command will be stopped and removed.
<EVENT_REGEXP><event><id><type>threshold</type><sequence>\d+</sequence></id><source><devic
e><ipaddress>.*</ipaddress><time>.*</time></device><server><name>.*</name><ipaddress>.*</i
paddress><entity>.*</entity><version>.*</version><time>.*</time></server></source><priorit
y><server>minor</server></priority><threshold><type>cleared</type><attribute>ping.successR
ate</attribute><value>\d+</value><configuredOp>GTE</configuredOp><configuredValue>\d+</con
figuredValue></threshold><specific><das><collector 
name="c"><type>com.cisco.das.IosCliOpsCollector.IosCliOpsCollector
</type></collector><device name="mplsDevice"/><threshold 
name="pingThreshold"/></das></specific></event></EVENT_REGEXP>
<ACTION_REGEXP><das><stop><collector name="c_mplsDevice"/></stop><remove><collector 
name="c_mplsDevice"/></remove></das></ACTION_REGEXP>



	Table Of Contents Event Trigger Event Trigger Configuration XML Configuration Example Event Trigger Notifier Creation Event Trigger Notifier Association with Collectors Specifying the Interval Limit for Collection Trigger Definition file Trigger Limits: MaxActions and Interval Event Mapping file Event Trigger Usage in MPLS Scenario Event Trigger Event Trigger allows Network Engineer/SE/Partner applications to develop rules which trigger collections (or any other XML command) based on a certain Event condition. Event Trigger takes action based on event match. The user specifies an event-action rules pair in an event-action mapping file. One or more mapping files is specified in the Trigger Definition file. This file is loaded by the notifier and associated with a collector. When a notification is raised/cleared from these collectors, the notification is matched against the rules defined in event-action mapping file. If a notification matches any of the defined rules, the action specified in the rules is invoked. For example, suppose you have configured a MibCollector for thresholds of ifInErrors.1. The event-action mapping file that defines rule to match the raised threshold for ifInErrors.1 is associated with the MibCollector. When a threshold is raised for ifInErrors.1, it matches the rule. This invokes the action corresponding to the matched rule. The action invocation may be starting a new collector to poll for attributes like ifInOctets.1 and ifOutOctets.1. Event Trigger Configuration This section describes the following: •XML Configuration Example •Trigger Definition file •Event Mapping file XML Configuration Example This XML configuration example contains the following sections: •Event Trigger Notifier Creation •Event Trigger Notifier Association with Collectors •Specifying the Interval Limit for Collection Event Trigger Notifier Creation <das> <create> <notifier name= "EventTriggerNotifier"> <mappingUrl> file:///cnsperfe/config/TriggerDefinitions/triggerDefinition.txt </mappingUrl> </notifier> </create> </das> The triggerDefinition.txt contains the event-action mapping file which defines rules for trigger activation. Event Trigger Notifier Association with Collectors The EVENT Trigger notifier is associated with collector similar to any other notifier (CNS/Trap/Plugin). <das> <create> <collector name="c"> <MibCollector> <schedule name="s"/> <device name="d"/> <threshold name="t"/> <notifier name="n"/> <notifier name="EventTriggerNotifier"/> <dataHandler name="h"/> <snmpGet> <oid>sysName.0</oid> </snmpGet> <snmpGetMany> <oid>ifInOctets</oid> </snmpGetMany> </MibCollector> </collector> </create> </das> Specifying the Interval Limit for Collection <das> <create> <schedule name= "randomSchedule"> <interval>PT15S</interval> <maxIntervals>3</maxIntervals> </schedule> </create> </das> The maxIntervals tag of the schedule component can be used to limit the number of times the collection is invoked. This provides the flexibility to specify limits and restrict the number of schedule intervals for a given collector. Trigger Definition file This section describes the trigger definition file format. Version=1.0 ID,MappingFile,MaxActions,Interval where Version - indicates version number of the trigger definition file. ID - uniquely identifies an EVENT. This ID can be used while logging messages related to EVENT. MappingFile - the event-action mapping file which defines rules to match a EVENT and action to be invoked after a match. MaxActions - maximum number of actions to be invoked. Interval - time interval to determine invocation rate. The interval is specified in either of the following formats: –PT10S - S implies interval specified is in seconds. –PT10M - M implies interval specified is in minutes. –PT10H - H implies interval specified is in hours. Example Version=1.0 ID,MappingFile,MaxActions,Interval 1,/opt/cnsperfe/config/EventMappings/rules-raise.re,3,PT2M 2,/opt/cnsperfe/config/EventMappings/rules-clear.re,5,PT30S Trigger Limits: MaxActions and Interval Trigger limit parameters allows the user to control the action and invocation rate of the matched notifications. The following example explains how the trigger limits are used to control number of actions to be invoked. If MaxActions=3 and Interval=PT2M •Scenario 1: Suppose 100 TCAs are raised/cleared, out of which 20 TCAs match the rule defined in the event-mapping file. All the 20 TCAs are received within the 2M (Interval) time frame. •Event Trigger Behavior: Action is invoked only for the first 3(MaxActions) of the 20 matched TCAs. Hence MaxActions controls the number of action invocations for the matched TCAs. If MaxActions=15 and Interval=PT10S •Scenario 2: Suppose 100 TCAs are raised/cleared, out of which 25 TCAs match the rule defined in the event-mapping file. Out of the 25 matched TCAs, only 10 TCAs come within the 10S (Interval) time frame. •Event Trigger Behavior: Because only 10 TCAs of the 25 matched TCAs arrived with the 10 second Interval time frame, action is invoked only for those 10 TCAs matched. This way, the Interval controls the action invocation rate. You should configure the Trigger Limit parameters to accommodate anticipated scenarios. Event Mapping file The Event Mapping file defines rules for Trigger activation. The file format is: <EVENT_REGEXP>...............</EVENT_REGEXP> <ACTION_REGEXP>...............</ACTION_REGEXP> where <EVENT_REGEXP></EVENT_REGEXP> - the regular expression that matches a threshold raised/cleared. <ACTION_REGEXP></ACTION_REGEXP> - an action expression which is invoked as a result of a match. This can be a collector combination or any other XML command. If you want to extract values from the notification and substitute in the action, then use sub-expressions in the event regular expressions. CNS PerfE takes the values of these sub-expressions and provides them as a name value pair with the name as VARx. This event mapping file is also termed as event-action mapping file. There are 3 types of CNS PerfE notifications: 1. Threshold notification <event> <id> <type>threshold</type> <sequence>1375</sequence> </id> <source> <device> <ipaddress>1.1.1.1</ipaddress> <time>2003-07-11T03:47:12.836Z</time> </device> <server> <name>CNS-PerfE hostname</name> <ipaddress>CNS-PerfE IP Address</ipaddress> <entity>Cisco CNS-PerfE</entity> <version>dev</version> <time>2003-07-11T03:47:12.837Z</time> </server> </source> <priority> <server>minor</server> </priority> <threshold> <type>crossed</type> <attribute>55.DT.queue3.cbQosPoliceConformedPkt</attribute> <value>300</value> <configuredOp>GTE</configuredOp> <configuredValue>300</configuredValue> </threshold> <specific> <das> <collector name="c"> <type>com.cisco.das.CBQoSCollector.CBQoSCollector</type> </collector> <device name="d" /> <threshold name="t2" /> </das> </specific> </event> 2. Information notification <event> <id> <type>informational</type> <sequence>0</sequence> </id> <source> <server> <name>CNS-PerfE hostname</name> <ipaddress>CNS-PerfE IP Address</ipaddress> <entity>Cisco CNS-PerfE</entity> <version>dev</version> <time>2003-07-11T03:18:33.461Z</time> </server> </source> <priority> <server>none</server> </priority> <informational> <type>stop</type> <description>Normal termination</description> </informational> <specific> <das> <collector name="sys"> <type>com.cisco.das.SystemCollector.SystemCollector</type> </collector> </das> </specific> </event> 3. Error notification <event> <id> <type>error</type> <sequence>1</sequence> </id> <source> <server> <name>CNS-PerfE hostname</name> <ipaddress>CNS-PerfE IP Address</ipaddress> <entity>Cisco CNS-PerfE</entity> <version>dev</version> <time>2003-07-11T03:25:00.113Z</time> </server> </source> <priority> <server>minor</server> </priority> <error> <type>Threshold Processing</type> <description>Invalid threshold attribute sys.disk.d.usedPercentage configured for SystemCollector</description> </error> <specific> <das> <collector name="sys"> <type>com.cisco.das.SystemCollector.SystemCollector</type> </collector> </das> </specific> </event> Refer to the <CNS-PerfE dir>/schema/event.xsd schema for the definition of each of these notifications. This following example describes about <EVENT_REGEXP> and <ACTION_REGEXP>. <EVENT_REGEXP><event><id><type>threshold</type><sequence>(\d+)</sequence></id><source><dev ice><ipaddress>(\d+.\d+.\d+.\d+)</ipaddress><time>.</time></device><server><name>\w+</nam e><ipaddress>\d+.\d+.\d+.\d+</ipaddress><entity>.</entity><version>.</version><time>.</ time></server></source><priority><server>critical</server></priority><threshold><type>\S+< /type><attribute>.1.3.6.1.2.1.2.2.1.10. (.) </attribute><value>\d+</value><configuredOp>GTE</configuredOp><configuredValue>\d+</config uredValue></threshold><specific><das><collector name= "."><type>com.cisco.das.MibCollector.MibCollector</type></collector><device name="(.)"/><threshold name="."/></das></specific></event></EVENT_REGEXP> <ACTION_REGEXP><das><create><schedule name="s-VAR1"><start>2001-08-31T00:00:00.000-08:00</start><interval>PT5M</interval><maxInt ervals>2</maxIntervals></schedul e><collector name="c-VAR1"><MibCollector><schedule name="s-VAR1"/><device name="VAR4"/><dataHandler name="h"/><snmpGet><oid>IfInErrors.VAR3</oid></snmpGet></MibCollector></collector></create ><start><collector name="c-VAR1"/></start></das></ACTION_REGEXP> CNS PerfE is configured for MibCollector to collect ifInOctets and thresholds are configured for this attribute. The <EVENT_REGEXP> defines the following rule: •Match any raised threshold for ifInOctets (as specified in the configuredOP tag). •The values in () will be extracted by the EVENT Trigger from the matched threshold for substitution in the ACTION_REGEXP. The VARx values of <ACTION_REGEXP> are the extracted values from the matched threshold received by the EVENT Trigger. The VARx values correspond to the () values in the EVENT_REGEXP. In the above example: VAR1 = sequenceID VAR2 = device IP Address VAR3 = index of the attribute configured for threshold VAR4 = device name If VAR1=1, VAR2=10.0.1.2, VAR3=1, and VAR4=d the <ACTION_REGEXP> can be interpreted as: •Create a collector by name c-1 and schedule s-1. •The collector is configured for ifInErrors.1. •The schedule interval is 2 Minutes and maxIntervals is 2. This implies that the collector c-1 created dynamically as a result of a threshold match will poll the configured attribute ifInErrors.1 two times. Note The sequenceID value used while creating a schedule and a collector component is to keep the component names unique. If the component names in the <ACTION_REGEXP> specified are not unique, duplicate component exception is reported in cases where multiple thresholds match the same <EVENT_REGEXP>. Event Trigger Usage in MPLS Scenario The Event Trigger feature helps in MPLS troubleshooting using threshold crossing alerts (TCAs) for the identification of performance bottlenecks and proactive capacity planning. This feature can be used for example, for MPLS pings to identify reachability issues and then automatically trigger performance or troubleshooting policies; for example, using a MPLS ping TCA to automatically trigger an appropriate MPLS traceroute operation. Cisco CNS PerfE supports MPLS ping and traceroute commands via IosCliOpsCollector. Take the following steps to configure Cisco CNS PerfE to support workflows for MPLS troubleshooting: Step 1 Configure a collector to periodically execute MPLS LSP ping. Step 2 Configure thresholds for ping failure for the configured collector. Step 3 Configure the Event Trigger feature as follows: If ping failed notification is generated from the LSP ping, then CNS PerfE automatically starts the trace for the same LSP/VRF. With the preceding configuration, whenever a ping failure is detected, Cisco CNS PerfE automatically triggers the corresponding traceroute operation and sends the data to the performance- or fault-management application. The following XML example executes the MPLS ping command on the specified device every 15 minutes. Thresholds are configured for ping.successRate attribute. If the ping successRate is below 30% then a notification is raised which triggers MPLS traceroute command for the same LSP. A CNS dataHandler is also created which will be used by the collector triggered as a result of ping failure to send MPLS traceroute data. <das> <create> <schedule name="FifteenMinSched"> <interval>PT15M</interval> </schedule> <device name="mplsDevice"> <ios> <ipaddress>40.1.1.3</ipaddress> <username>lab</username> <password>lab</password> <secret>lab</secret> <connectMode>direct</connectMode> <transportMode>telnet</transportMode> </ios> </device> <threshold name="pingThreshold"> <attribute name="ping.successRate"> <raiseOperation>LTE</raiseOperation> <raiseValue>30</raiseValue> <clearOperation>GTE</clearOperation> <clearValue>90</clearValue> <level>minor</level> </attribute> </threshold> <dataHandler name="pingDataHandler"> <ftp> <urlPrefix>ftp://username:passwd@hostname/IOSCLIOPS_</urlPrefix> </ftp> </dataHandler> <dataHandler name="traceDataHandler"> <cns> <subject>cisco.mgmt.das.cnsDatahandler</subject> </cns> </dataHandler> <notifier name="thresholdNotifier"> <cns> <subject>cisco.mgmt.das.cnsnotifier</subject> </cns> </notifier> <notifier name="Trigger-Not"> <mappingUrl>file:///CSCOPerfE/config/EventTrigger/TriggerDefinition.txt</mappingUrl> </notifier> <collector name="c"> <IosCliOpsCollector> <schedule name="FifteenMinSched"/> <device name="mplsDevice"> <operation name="op1"> <command>ping mpls ipv4 10.131.159.252/32</command> </operation> </device> <threshold name="pingThreshold"/> <notifier name="thresholdNotifier"/> <notifier name="Trigger-Not"/> <dataHandler name="pingDataHandler"/> <regexp-url>file:///CSCOPerfE/config/ioscli/LspPing.re</regexp-ur l> </IosCliOpsCollector> </collector> </create> <add/> <stop/> <start> <collector name="c"/> </start> </das> The notifier component Trigger-Not is the Event Trigger associated with the collector. The notifier points to a TriggerDefinition.txt which will contain rules for TCAs. TriggerDefinition example: Version=1.0 ID,MappingFile,MaxActions,Interval 1,/CSCOPerfE/config/EventTrigger/rules-ping-raise.re,2,PT30S 2,/CSCOPerfE/config/EventTrigger/rules-ping-clear.re,2,PT30S This Trigger Definition file has two entries rules-ping-raise.re and rules-ping-clear.re which defines rules for matching the event and action to be invoked after a match. rules-ping-raise.re: This rules suggests that if a notification raised as a result of ping failure matches with the EVENT_REGEXP, then a new collector is spawned which executes MPLS trace command for the same LSP and sends the collected statistics to a CNS datahandler. <EVENT_REGEXP><event><id><type>threshold</type><sequence>\d+</sequence></id><source><devic e><ipaddress>.</ipaddress><time>.</time></device><server><name>.</name><ipaddress>.</i paddress><entity>.</entity><version>.</version><time>.</time></server></source><priorit y><server>minor</server></priority><threshold><type>crossed</type><attribute>ping.successR ate</attribute><value>\d+</value><configuredOp>LTE</configuredOp><configuredValue>\d+</con figuredValue></threshold><specific><das>< collector name="c"> <type>com.cisco.das.IosCliOpsCollector.IosCliOpsCollector </type></collector><device name="mplsDevice"/><threshold name="pingThreshold"/></das></specific></event></EVENT_REGEXP>* <ACTION_REGEXP><das><create><schedule name="TwoMinSched"> <interval>PT2M</interval><maxIntervals>5</maxIntervals></schedule><collector name="c_mplsDevice"><IosCliOpsCollector><schedule name="TwoMinSched"/> <device name="mplsDevice"><operation name="traceOp"><command>trace mpls ipv4 10.131.159.252/32</command></operation></device><dataHandler name="traceDataHandler"/><regexp-url>file:///CSCOPerfE/config/ioscli/LspTrace.re</regexp-u rl> </IosCliOpsCollector></collector></create><start><collector name="c_mplsDevice"/></start></das></ACTION_REGEXP> rules-ping-clear.re: This rule conveys that when a clear notification matches the EVENT_REGEXP, then the collector created for MPLS traceroute command will be stopped and removed. <EVENT_REGEXP><event><id><type>threshold</type><sequence>\d+</sequence></id><source><devic e><ipaddress>.</ipaddress><time>.</time></device><server><name>.</name><ipaddress>.</i paddress><entity>.</entity><version>.</version><time>.</time></server></source><priorit y><server>minor</server></priority><threshold><type>cleared</type><attribute>ping.successR ate</attribute><value>\d+</value><configuredOp>GTE</configuredOp><configuredValue>\d+</con figuredValue></threshold><specific><das><collector name="c"><type>com.cisco.das.IosCliOpsCollector.IosCliOpsCollector </type></collector><device name="mplsDevice"/><threshold name="pingThreshold"/></das></specific></event></EVENT_REGEXP>* <ACTION_REGEXP><das><stop><collector name="c_mplsDevice"/></stop><remove><collector name="c_mplsDevice"/></remove></das></ACTION_REGEXP>
	Terms & Conditions \| Privacy Statement \| Cookie Policy \| Trademarks