Event Configuration How-To
From OpenNMS
Originally written by Tarus Balog tarus@opennms.org. This page based on v1.0 from November 2002.
Contents |
Introduction
Purpose
This How-To is one in a series designed to serve as a reference for getting started with OpenNMS. Eventually, these documents will cover everything necessary to get OpenNMS installed and running in your environment.
Copyright
Content is available under a Creative Commons Attribution-NonCommercial-ShareAlike2.5 License.
Corrections and Omissions
Please submit any corrections and omissions to the author.
Overview
OpenNMS has three main functional areas:
- Determining Availability of Network Services (discussed in part 3 of this series)
- Gathering Performance Data via SNMP (discussed in part 4 of this series)
- Event Management and Notifications
The last area: Events, is the subject of this How-To. Notifications will be handled in the next part.
Events are a staple of any network management system (NMS). In fact, the main function of an NMS can be described as detecting changes within the network, and every change can be thought of as an event.
OpenNMS manages events through a process called eventd. There are two main types of events: those generated internally by the OpenNMS software and those generated via external SNMP traps. Processes can generate events, such as when the discovery process generates a newSuspect event when an interface responds to a ping, and processes can "subscribe" to events, as when the capsd process asks to be notified whenever a newSuspect event occurs so it can begin its capabilities scan.
When an event is generated, various parameters can be set, such as its description, a log message and a severity. In addition, automatic actions can be launched to send event parameters to an external script. This is controlled through the eventconf.xml file.
OpenNMS also comes with a feature rich Notification system. Particular events can be chosen to cause a notification to be sent, such as a page or e-mail.
The following sections will discuss Events in detail. Since this functionality changed between 1.0 (the current production release at the time this document was written) and 1.1 (the current development release), notes will be made as to what is available in which release.
Events
The eventconf.xml file, found by default in /opt/OpenNMS/etc, is the configuration file that controls how events are handled. Let's look for a moment at the top of that file:
<events xmlns="http://xmlns.opennms.org/xsd/eventconf">
<global>
<security>
<doNotOverride>logmsg</doNotOverride>
<doNotOverride>operaction</doNotOverride>
<doNotOverride>autoaction</doNotOverride>
<doNotOverride>tticket</doNotOverride>
</security>
</global>
Every file that contains events starts with an <events> tag and ends with an </events> tag.
The eventd process listens on port 5817, so other processes, even those external to OpenNMS, can send events to the system. The <security> tag is there so that these events cannot override the actions defined in the eventconf.xml file. This way, no one with access to the OpenNMS machine could send in an "autoaction" to open, say, a root window on their machine.
Internal Events
Now, after the global settings section of the eventconf.xml file come the events. Each event must be defined in order to be properly treated by the OpenNMS system. Let's look at a common event: nodeLostService:
<event>
<uei>http://uei.opennms.org/nodes/nodeLostService</uei>
<event-label>OpenNMS-defined node event: nodeLostService</event-label>
<descr>
&lt;p&gt;A %service% outage was identified on interface
%interface%.&lt;/p&gt; &lt;p&gt;A new Outage record has been
created and service level availability calculations will be
impacted until this outage is resolved.&lt;/p&gt;
</descr>
<logmsg dest='logndisplay'>
%service% outage identified on interface %interface%.
</logmsg>
<severity>Major</severity>
</event>
Every event is bracketed by an <event> tag. Within those tags are various other definitions:
- The UEI
- The "Universal Event Identifier" is simply a label to uniquely identify the event. The original intent was that this would be some sort of XML namespace, hence the "http://", but it really is just a label. In version 1.1 and beyond, the "http://" has been removed. Note: for internal OpenNMS events, the UEI is generated directly by the code and cannot be changed without modifying the source.
- The
event-label - This is a plain text label for the event, sometimes used in the web user interface.
-
descr - is the description of the event. You can embed HTML entities should you wish to format the description more fully. Note that there are elements such as
%interface%that you can place in the event description and log message (which will be described later in this document). -
logmsg - Is a short description or summary of the event. The "
dest" attribute can take on a number of values:
logndisplay- Both log the event in the database and display it in the Web UI.
logonly- Log the event in the database, but do not display it.
suppress- Neither log the event in the database or display it.
donotpersist- Do not log the event in the database, but still send it to OpenNMS daemons that are listening for this type of event (e.g.: this can be used to generate notifications).
discardtraps- This only applies to traps coming in via trapd. This will cause trapd to discard the trap without creating an event. Other OpenNMS daemons that are listening for this type of event will not receive this event. This feature was first available in OpenNMS 1.3.0.
-
severity - This indicates the severity of the event.
Severities
When setting severities for events, I often think back to a scene from the movie Spinal Tap. This movie is a "documentary" about an aging hard rock band. In one scene the interviewer is asking a band member to what he attributes the band's popularity. He points to the amplifiers and says "while most amplifiers go to 10, ours go to 11". The interviewer asks why not make them go to 10, but just make 10 louder, to which the band member replies "but ours go to 11".
I have seen this when people set out to set severities for the events in their NMS. Events are either "Critical" (something's wrong with my network!) or "Normal". The severities between the two tend to be ignored. Unfortunately, it makes it real hard to highlight really important events when everything is either green or red. So rather than put everything "at 11", I suggest setting normal network outages as Minor or Major (but treat them just the same as you normally would), and reserving Critical for those events that really matter.
Another way to look at this is to assign actions to severities. Thus a "Critical" event means you wake up the president of your company on Christmas morning and ruin his holiday. So if Helmut's backup ISDN circuit goes down, it is doubtful you would want the severity to be Critical. However, if the entire network backbone is down, it might warrant that phone call.
The following is a list of severities that come with OpenNMS, and my personal description of what they mean. Currently, the default events in OpenNMS don't exactly conform to this list, but they will in the future:
- Critical (dark red)
- This event means numerous devices on the network are affected by the event. Everyone who can should stop what they are doing and focus on fixing the problem.
- Major (light red)
- A device is completely down or in danger of going down. Attention needs to be paid to this problem immediately.
- Minor (orange)
- A part of a device (a service, and interface, a power supply, etc.) has stopped functioning. The device needs attention.
- Warning (yellow)
- An event has occurred that may require action. This severity can also be used to indicate a condition that should be noted (logged) but does not require direct action.
- Normal (green)
- Informational message. No action required.
- Cleared (light grey)
- This event indicates that a prior error condition has been corrected and service is restored.
- Indeterminate (yellow-green)
- The severity of the event cannot be determined.
Additional Parameters
A number of additional parameters can occur between the <event> tags (note that there are others defined in the code but not yet implemented):
-
<operinstruct> - This is a set of instructions for the NMS operator when the event occurs.
-
<mouseovertext> - This can be text to be displayed when the mouse is placed over the event in the event browser of the Web UI.
-
<autoaction> - The text following this tag must be the complete path to an executable program. The program will be executed every time the event occurs.
Note that each tag must be closed with its corresponding "/" tag.
Elements
Various elements can be included in the description, log message, operator instruction and automatic actions for each event. Not all events will have values for all elements, and some refer to SNMP traps, which will be discussed in the next section.
-
%uei% - The Universal Event Identifier for the event.
-
%source% - The source of the event (what process).
-
%time% - The time of the event.
-
%nodeid% - The node ID of the device that caused the event.
-
%interface% - The interface associated with the event.
-
%service% - The service associated with the event.
-
%severity% - The severity of the event.
-
%snmphost% - The host of the SNMP agent that generated the event.
-
%snmp% - The SNMP information associated with the event.
-
%id% - The SNMP Enterprise OID for the event.
-
%generic% - The Generic trap number for the event.
-
%specific% - The Specific trap number for the event.
-
%community% - The community string for the trap.
-
%version% - The SNMP version of the trap.
-
%operinstruct% - The operator instructions for the event.
-
%mouseovertext% - The mouse over text for the event.
In version 1.1 and beyond, there are two more parameters available:
-
%nodelabel% - Returns the node label for the node given in
%nodeid%if available. -
%interfaceresolv% - Does a reverse lookup on the
%interface%and returns its name if available.
There is also a parm element that will be discussed later.
SNMP Traps
Outside of internally generated events, OpenNMS can also receive SNMP traps via the trapd process. These are controlled in eventconf.xml using the <mask> tag. For example:
<event>
<mask>
<maskelement>
<mename>id</mename>
<mevalue>.1.3.6.1.4.1.9.9.70.2</mevalue>
</maskelement>
<maskelement>
<mename>generic</mename>
<mevalue>6</mevalue>
</maskelement>
<maskelement>
<mename>specific</mename>
<mevalue>17</mevalue>
</maskelement>
</mask>
<uei>http://uei.opennms.org/vendor/Cisco/traps/ciscoC3800SysAggregateStatusChange</uei>
<event-label>CISCO-C3800-MIB defined trap event: ciscoC3800SysAggregateStatusChange</event-label>
<descr>&lt;p&gt;Notification that the aggregate status of a node
has changed.&lt;/p&gt;&lt;table&gt;
&lt;tr&gt;&lt;td&gt;&lt;b&gt;
c3800SysNextTrapSeqNum&lt;/b&gt;</td&gt;&lt;td&gt;%parm[#1]%
&lt;/td&gt;&lt;td&gt;&lt;p;&gt;</p&gt;&lt;/td;&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;&lt;b&gt;
sysName&lt;/b&gt;&lt;/td&gt;&lt;td&gt;%parm[#2]%
&lt;/td&gt;&lt;td&gt;&lt;p;&gt;&lt;/p&gt;&lt;/td;&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;&lt;b&gt;
c3800SysTrapSeverity&lt;/b&gt;&lt;/td&gt;&lt;td&gt;%parm[#3]%
&lt;/td&gt;&lt;td&gt;&lt;p;&gt;
clear(1) minor(2) major(3)&lt;/p&gt;
&lt;/td;&gt;&lt;/tr&gt;&lt;tr&gt;&lt;td&gt;&lt;b&gt;
c3800SysAggregateStatus&lt;/b&gt;&lt;/td&gt;&lt;td&gt;%parm[#4]%
&lt;/td&gt;&lt;td&gt;&lt;p;&gt;
clear(1) minor(2) major(3)</p>
&lt;/td;&gt;&lt;/tr&gt;&lt;/table&gt;
</descr>
<logmsg dest='logndisplay'><p>Cisco Event: C3900: Node Status has changed.</p></logmsg>
<severity>Indeterminate</severity>
</event>
This is a Cisco Systems event for their C3800 device. Parts of it looks similar to the internally generated events, with the main difference being the <mask> block. This block consists of <maskelement> tags, and the event will only match if all the defined tags are met.
This particular event will match an SNMP trap whose enterprise OID (id) is equal to ".1.3.6.1.4.1.9.9.70.2", its generic trap value is enterprise specific (6) and its specific trap value is 17.
The possible <mename> values are:
- uei
- source
- host
- snmphost
- nodeid
- interface
- service
- id
- specific
- generic
- community
It is possible to use the "%" symbol to indicate a wildcard in the mask values. For example, to match all Cisco events, I could use:
<mask>
<maskelement>
<mename>id</mename>
<mevalue>.1.3.6.1.4.1.9.%</mevalue>
</maskelement>
</mask>
Note: The order in which events are listed in the eventconf.xml file is extremely important. The search will stop with the first event definition that matches the given event. Thus if the above code with the wildcard was listed before the more specific ciscoC3800SysAggregateStatusChange event, the latter event would never be generated. Also note that the wildcard is simply a substring match. If an event was generated from a Cisco device with the Enterprise OID of ".1.3.6.1.4.1.9" it would not match this event, as there is no trailing ".". If the trailing "." is left off, care must be taken so that a trap with an OID of ".1.3.6.1.4.1.99" is listed before the ".1.3.6.1.4.1.9%" event or else it will match the more generic event.
The parm Element
Some events, especially SNMP traps, have additional information sent with them called "variable bindings" or "varbinds" for short. In the ciscoC3800SysAggregateStatusChange event listed above, there are four of them, and they can be accessed using the parm element. Each parameter consists of a name and a value.
-
%parm[all]% - Will return a space-separated list of all parameter values in the form
parmName1="parmValue1" parmName2="parmValue2"etc. -
%parm[values-all]% - Will return a space-separated list of all parameter values associated with the event.
-
%parm[names-all]% - Will return a space-separated list of all parameter names associated with the event.
-
%parm[<name>]% - Will return the value of the parameter named <name> if it exists.
-
%parm[##]% - Will return the total number of parameters.
-
%parm[#<num>]% - Will return the value of parameter number <num>.
-
%parm[name-#<num>]% - Will return the name of parameter number <num>.
For example, the ciscoC3800SysAggregateStatusChange event description lists out each of the parameters. Thus the second paramater, the sysName is printed out using %parm[#2]%.
Filtering on varbinds (OpenNMS 1.1 and beyond)
Let's take a look at the example ciscoC3800SysAggregateStatusChange event once more. What should its severity be? Since the event is generated whenever the status changes, you don't know if the change is "bad" (from operational to non-operational) or "good" (the non-operational status is cleared). That information is contained within the parameters that are passed with the event, particularly parameter #3, the trap severity.
With 1.1, the ability to filter on variable bindings was added. This is done in the <mask> block. To re-write the above event:
<mask>
<maskelement>
<mename>id</mename>
<mevalue>.1.3.6.1.4.1.9.9.70.2</mevalue>
</maskelement>
<maskelement>
<mename>generic</mename>
<mevalue>6</mevalue>
</maskelement>
<maskelement>
<mename>specific</mename>
<mevalue>17</mevalue>
</maskelement>
<varbind>
<vbnumber>3</vbnumber>
<vbvalue>3</vbvalue>
</varbind>
</mask>
Copying the event and changing the <mask> block to the above will match on the same id, generic and specific values, but also will require that the third parameter is equal to "3" (indicating a Cisco determined trap severity of "major"). Thus you could change the description and/or severity to match the event.
It is also possible to match more than one varbind, and more than one value per varbind:
<varbind> <vbnumber>3</vbnumber> <vbvalue>2</vbvalue> <vbvalue>3</vbvalue> </varbind> <varbind> <vbnumber>4</vbnumber> <vbvalue>2</vbvalue> <vbvalue>3</vbvalue> </varbind>
The above code snippet will match if the third parameter has a value of "2" or "3" and the fourth parameter has a value of "2" or "3".
This feature was updated long before the 1.6.0 release to allow a regular expression match on the varbind value. Just specify the expression prefixed with a with a "~".
<varbind> <vbnumber>1</vbnumber> <vbvalue>~[Dd]own</vbvalue> </varbind>This will match a varbind 1 containing the word "Down" or "down" anywhere within its value.
You can also do quick prefix matches with the '%' in a varbind value:
<varbind> <vbnumber>1</vbnumber> <vbvalue>Error:%</vbvalue> </varbind>this will match varbind 1 with any string beginning with "Error:"
Again, note that the order in which events are listed is very important. Put the most specific events first.
Decoding varbinds (OpenNMS 1.7.0 and beyond)
A lot of MIBs define specific variables to code the value of some OID. As an example the snmp agent returns a numerical value for the ifAdminStatus and ifOperStatus: 1 means Up and 2 means Down.
Becouse of the fact that OpenNMS has not a MibParser we usually put this map (between numerical encoded value and their meaning) into the event Description.
Configuring the Event properly now are able to decode the numerical value sent into trap varbinds to the corresponding string value into the <logmsg>.
Let consider a Cisco HSRP status changes trap ( OID .1.3.6.1.4.1.9.9.106.2 generic 6 and specific 1), this trap correspond to uei.opennms.org/vendor/Cisco/traps/cHsrpStateChange event.
The trap contains the following varbind: cHsrpGrpStandbyState whose possible values are from 1 to 6 and whose meaning is:
initial(1) learn(2) listen(3) speak(4) standby(5) active(6).
I want to display in logmsg the literal meaning of the HSRP status.
Here is the original event definition:
<event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.9.9.106.2</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>1</mevalue> </maskelement> </mask> <uei>uei.opennms.org/vendor/Cisco/traps/cHsrpStateChange</uei> <event-label>CISCO-HSRP-MIB defined trap event: cHsrpStateChange</event-label> <descr><p>A cHsrpStateChange notification is sent when a cHsrpGrpStandbyState transitions to either active or standby state, or leaves active or standby state. There will be only one notification issued when the state change is from standby to active and vice versa.</p><table> <tr><td><b> cHsrpGrpStandbyState</b></td><td>%parm[#1]% </td><td><p;> initial(1) learn(2) listen(3) speak(4) standby(5) active(6)</p> </td;></tr></table> </descr> <logmsg dest='logndisplay'><p>Cisco Event: HSRP State Change.</p></logmsg> <severity>Minor</severity> </event>
An here follows the new event definition in which the status is decoded in the logmsg:
<event> <mask> <maskelement> <mename>id</mename> <mevalue>.1.3.6.1.4.1.9.9.106.2</mevalue> </maskelement> <maskelement> <mename>generic</mename> <mevalue>6</mevalue> </maskelement> <maskelement> <mename>specific</mename> <mevalue>1</mevalue> </maskelement> </mask> <uei>uei.opennms.org/vendor/Cisco/traps/cHsrpStateChange</uei> <event-label>CISCO-HSRP-MIB defined trap event: cHsrpStateChange</event-label> <descr><p>A cHsrpStateChange notification is sent when a cHsrpGrpStandbyState transitions to either active or standby state, or leaves active or standby state. There will be only one notification issued when the state change is from standby to active and vice versa.</p><table> <tr><td><b> cHsrpGrpStandbyState</b></td><td>%parm[#1]% </td><td><p;> initial(1) learn(2) listen(3) speak(4) standby(5) active(6)</p> </td;></tr></table> </descr> <logmsg dest='logndisplay'><p>Cisco Event: HSRP State Change to %parm[#1]%.</p></logmsg> <severity>Minor</severity> <varbindsdecode> <parmid>parm[#1]</parmid> <decode varbindvalue="1" varbinddecodedstring="initial"/> <decode varbindvalue="2" varbinddecodedstring="learn"/> <decode varbindvalue="3" varbinddecodedstring="listen"/> <decode varbindvalue="4" varbinddecodedstring="speak"/> <decode varbindvalue="5" varbinddecodedstring="standby"/> <decode varbindvalue="6" varbinddecodedstring="active"/> </varbindsdecode> </event>
Here the parm[#1] (So the first varbind into the trap is translated using the decode map. If the value of the first OID in this trap is 6 the the log message will be:
<p>Cisco Event: HSRP State Change to active.</p>
Creating event definitions from trap definition in mibs
There is a program named mib2opennms available to convert trap definitions from mib files to opennms event definitions, see Converting MIBs Using mib2opennms
The eventconf.xml File
As mentioned above, the eventconf.xml file controls the definition of both internal and external events in OpenNMS. The order in which the events are listed is very important as it is possible to have numerous event definitions for a given event if you start to filter on variable bindings.
All this has caused the file to grow very large. In 1.0.2, eventconf.xml was over 3.1 MB of text. In order to make this file easier to manage, a new tag was introduced in 1.1.0 called <event-file>. This allows files to be "included" as part of eventconf.xml. The new file now looks like:
<event-file>/opt/OpenNMS/etc/events/3Com.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/APC.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Brocade.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/CIM.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Cisco.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Fore.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/HP.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Intel.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Microsoft.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Novell.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Oracle.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/SonicWall.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Xerox.events.xml</event-file> <event-file>/opt/OpenNMS/etc/events/Standard.events.xml</event-file>
The included files must start with a <events> tag and end with an </events> tag. In between will be <event> definitions just like in the original eventconf.xml file.
All of the events have been broken out by vendor. When OpenNMS starts, each file will be loaded in order, so again the order in which the files are listed is important. There are also still some events in eventconf.xml. These will be loaded before any included files, and best practice states to only list the internal OpenNMS events in that file directly.
At the very bottom of the file is <event-file>/opt/OpenNMS/etc/events/default.events.xml</event-file>. This contains the generic default events and should always be listed last.
A few tips:
- Since the system has to scan through all of the events to find a match, it is best to remove event files you are not using.
- If you customize a file, such as Cisco events, you may want to simply copy it to "my.Cisco.events.xml" and list your file first. This way you will have less work should the default file be changed in a future release.
Sample: Discard rtc login events
To avoid getting the rtc login events displayed and persisted in the database add the following definition in eventconf.xml above the existing event for uei uei.opennms.org/internal/authentication/successfulLogin:
<event>
<mask>
<maskelement>
<mename>uei</mename>
<mevalue>uei.opennms.org/internal/authentication/successfulLogin</mevalue>
</maskelement>
<varbind>
<vbnumber>1</vbnumber>
<vbvalue>rtc</vbvalue>
</varbind>
</mask>
<uei>uei.opennms.org/internal/authentication/successfulLogin</uei>
<event-label>OpenNMS-defined internal event: a user has successfully authentication to the WebUI</event-label>
<descr>
This event is sent by the WebUI when user rtc has successfully authenticated
</descr>
<logmsg dest='donotpersist'>
OpenNMS user %parm[user]% has logged in from %parm[ip]%.
</logmsg>
<severity>Normal</severity>
</event>
Activate changes in event configurations
After changing the event configurations use
$OPENNMS_HOME/bin/send-event.pl uei.opennms.org/internal/eventsConfigChange
to inform opennms that the event configuration has been changed and needs to be reloaded. See also Configuration Files for more details about reloading changes.
Test event configuration
There are two very useful tools to test event configurations:
$OPENNMS_HOME/bin/send-event.pl
and
$OPENNMS_HOME/bin/send-trap.pl
Just start the scripts without parameters to get an explanation how to use them
The Database
Each event that occurs in OpenNMS is written to the database in the events table. To see them, simply access the database with "psql -U opennms opennms" and then browse the events with "SELECT * FROM events;".
One great troubleshooting tool is to look at the eventparms that get sent with the event. For example:
SELECT eventparms FROM events WHERE eventid=204;
eventparms
---------------------------------------------------------------------------------------------------------------------------
ds=http(string,text);value=11.75(string,text);threshold=100.0(string,text);trigger=3(string,text);rearm=50.0(string,text)
(1 row)
Here are all of the parameters sent during a highThresholdRearmed event, and they can be used in event filters if needed.
Finally, it is worth noting that the database can get very full, and it may be necessary to delete events from the events table that are no longer needed. If you know SQL, this is pretty simple, but since OpenNMS events are sometimes referenced in the outages table and in notifications, you may not want to delete those (the outage table is required for availability calculation). Here is a sample SQL to delete non-referenced events:
DELETE FROM events WHERE eventid NOT IN (SELECT svclosteventid FROM outages) AND eventid NOT IN (SELECT svcregainedeventid FROM outages);
Debugging
Edit $OPENNMS_HOME/etc/log4j.properties and set the logging level for the eventd to DEBUG. Then check the </code>eventd.log</code> and you will see the parameters and their values for each incoming event like the following lines (date and time cut off for readability):
353 DEBUG [Event TCP Receiver[5817][127.0.0.1:14115]] TcpStreamHandler: Event record converted
353 DEBUG [Event TCP Receiver[5817][127.0.0.1:14115]] TcpStreamHandler: handling event, uei = uei.opennms.org/internal/rtc/subscribe
404 DEBUG [Event TCP Server[5817]] TcpServer: New connection accepted from 127.0.0.1:14117
404 DEBUG [Event TCP Receiver[5817][127.0.0.1:14115]] RunnableConsumerThreadPool$SizingFifoQueue: adjust: started fiber EventHandlerPool-fiber0 ratio = 1.0, alive = 0
404 DEBUG [Event TCP Receiver[5817][127.0.0.1:14115]] TcpStreamHandler: stopping record handler
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: Event {
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: uuid = <not-set>
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: uei = uei.opennms.org/internal/rtc/subscribe
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: src = RTCPostSubscriber
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: iface = null
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: time = Monday, February 22, 2010 4:26:29 PM GMT
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: parms {
404 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: (url, http://localhost:8980/opennms/rtc/post/Infrastructure+CentralSide)
405 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: (user, rtc)
405 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: (passwd, rtc)
405 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: (catlabel, Infrastructure CentralSide)
405 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: }
405 DEBUG [EventHandlerPool-fiber0] DefaultEventHandlerImpl: }
405 DEBUG [EventHandlerPool-fiber0] EventConfData: Match found using key: EventKey
Conclusion
The Event management system is pretty straightforward once it is understood. While time consuming to set up, once configured it is pretty automatic.
It is hoped that this How-To has proved useful. Please direct corrections and comments to the author.
New Pages