IBM Enterprise Console User Manual
IBM Tivoli Enterprise Console
A d apters Guid e
Ve r s i o n 3 . 8
GC32-0668-01
IBM Tivoli Enterprise Console
A d apters Guid e
Ve r s i o n 3 . 8
GC32-0668-01
Note
Before using this information and the product it supports, read the information in “Notices”on page 165.
First Edition (September 2002)
This edition applies to version 3, release 8, of IBM Tivoli Enterprise Console (product number 5698-TEC) and to all
subsequent releases and modifications until otherwise indicated in new editions.
© Copyright International Business Machines Corporation 2002. All rights reserved.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
Contents
Preface ..............vii
Who Should Read This Guide ........vii
What This Guide Contains .........vii
Publications ..............viii
IBM Tivoli Enterprise Console Library ....viii
Prerequisite Publications.........viii
Related Publications ..........viii
Accessing Publications Online .......ix
Providing Feedback about Publications ....ix
Contacting Customer Support ........ix
Conventions Used in this Guide .......ix
Typeface Conventions ..........ix
Operating System-dependent Variables and Paths x
Chapter 1. Understanding Adapters . . . 1
Adapter Overview ............1
How Events Get Sent to the Event Server....1
How Events Get to the Event Server From an
Endpoint .............1
How Events Get to the Event Server From a
Managed Node ...........3
How Events Get to the Event Server From a
Non-TME Adapter ..........3
Internationalization Support for Events .....3
Event Information ............4
Event Attributes ............4
Adapter Files ..............7
Cache File ..............8
Configuration File ...........9
File Location ............9
File Format .............9
Example ..............9
Keywords.............9
Event Filtering ...........14
Regular Expressions in Filters .....15
Event Filter Examples ........15
Event Buffer Filtering .........15
Event Buffer Filter Examples .....16
BAROC File .............16
Example .............16
Rule File ..............17
Example .............17
Format File .............17
Example .............17
Class Definition Statement File .......18
Example .............18
Error File ..............19
Initial Files ..............20
Troubleshooting Adapters .........21
Adapter Startup Errors .........21
All Adapters .............21
Managed Node Adapters .........21
Endpoint Adapters ...........21
Non-TME Adapters...........22
Chapter 2. AS/400 Alert Adapter ....23
Adapter Files ..............23
Configuration File ...........24
Class Definition Statement File .......25
SELECT Statement Example .......25
FETCH Statement Example .......25
Keywords.............25
Configuring the AS/400 Alert Filters ......26
Default Alert Filter ...........26
Integrating with an Existing Alert Filter ....27
Starting the Adapter ...........27
STRTECADP..............28
Stopping the Adapter ...........29
ENDTECADP .............30
Events Listing .............32
Event Class Structure ..........32
Troubleshooting the AS/400 Adapter ......34
Logging Events in Test Mode ........35
TCP/IP Considerations ..........35
Starting an AS/400 Adapter after an IPL ....35
Adding an Autostart Job to QSYSWRK ....35
Changing the AS/400 Startup Program ....36
Multiple AS/400 Alert Adapters .......36
Configuration File ...........37
POSTEMSG ..............38
Chapter 3. AS/400 Message Adapter . . 39
Adapter Files ..............39
Configuration File ...........40
Class Definition Statement File .......41
SELECT Statement Example .......41
FETCH Statement Example .......41
MAP Statement Example ........41
Keywords.............41
Starting the Adapter ...........45
STRTECADP..............46
Stopping the Adapter ...........47
ENDTECADP .............48
Events Listing .............50
Event Class Structure ..........50
Troubleshooting the AS/400 Adapter ......51
Logging Events in Test Mode ........51
TCP/IP Considerations ..........51
Starting an AS/400 Adapter after an IPL ....52
Adding an Autostart Job to QSYSWRK ....52
Changing the AS/400 Startup Program ....52
Multiple AS/400 Message Queues .......53
Configuration File ...........53
Using FTP to Execute AS/400 Commands ....53
Chapter 4. NetWare Log File Adapter 55
NetWare Log File Adapter Reference Information. . 55
Adapter Files ..............55
Error File ...............55
Prefiltering NetWare Events .........56
© Copyright IBM Corp. 2002 iii
Configuration File ............56
Format File ..............57
Events Listing .............58
Event Class Structure ..........58
TECADNW4.NLM ............61
tecadnw4.nlm ............62
Troubleshooting the NetWare Log File Adapter . . 63
Chapter 5. OpenView Adapter .....65
OpenView Driver ............65
Reception of OpenView Messages ......65
Determining the OpenView NNM Version . . . 65
Incoming Messages Format ........66
Event Correlation With NNM 6.......66
Determining the OVsnmpEventOpen Filter Value 67
Testing Tools .............68
Testing Event Correlation With NNM 6 ....68
Event Correlation Example .......69
Adapter Files ..............70
Configuration File ...........70
Class Definition Statement File .......71
OpenView Event Example .......71
Keywords.............72
Built-in Variables for $VARBIND ....72
Object Identifier File ..........72
Error File ..............73
LRF File ..............73
Starting and Stopping the Adapter ......73
Events Listing .............74
Event Class Structure ..........74
OpenView Traps.............76
SNMP Traps .............76
OpenView Traps............76
Troubleshooting the OpenView Adapter .....77
Chapter 6. OS/2 Adapter .......79
Adapter Files ..............79
Configuration File ...........79
Format File .............80
Starting the Adapter ...........80
Stopping the Adapter ...........81
Events Listing .............81
Event Class Structure ..........81
Troubleshooting the OS/2 Adapter ......82
Chapter 7. SNMP Adapter.......83
SNMP Driver..............83
Reception of SNMP Messages .......83
Incoming Messages Format ........83
Server Configuration ...........83
Adapter Files ..............83
Configuration File ...........84
Class Definition Statement File .......84
SNMP Event Example .........84
Keywords.............84
Built-in Variables for $VARBIND ....85
Object Identifier File ..........85
Error File ..............85
Starting and Stopping the Adapter ......85
Cold Start ..............86
Warm Start .............86
Stopping the Adapter ..........86
Events Listing .............86
Event Class Structure ..........86
Rules Listing ..............88
SNMP Traps ..............88
Generic Traps.............88
Enterprise-specific Traps .........88
Creating a New SNMP Trap Event ......89
BAROC File Changes ..........89
Agent-independent Data ........90
Class Definition Statement File Changes ....92
Object Identifier File Changes .......93
Troubleshooting the SNMP Adapter ......93
Chapter 8. IBM Tivoli Enterprise
Console Gateways..........95
Controlling Event Traffic at the Gateway ....95
Example ..............95
Worksheets and Calculations .......97
Configuration File ............97
Chapter 9. UNIX Log File Adapter. . . 101
Event Server Configuration.........101
Starting the Adapter ...........101
Stopping the Adapter...........102
Running Multiple UNIX Log File Adapters . . . 102
Adapter Files .............103
Configuration File ...........103
Format File .............104
Class Definition Statement File ......104
Error File..............104
Events Listing .............104
Event Class Structure..........104
Default Rules .............108
Troubleshooting the UNIX Log File Adapter . . . 109
Chapter 10. Windows Event Log
Adapter ..............111
Adapter Files .............111
Configuration File ...........112
Prefiltering Windows Log Events.....115
Format File .............116
Registry Variables ............117
Low Memory Registry Variables ......119
Adapter Administrator Roles for Windows . . . 120
Starting the Adapter ...........120
Stopping the Adapter...........120
Events Listing .............120
Event Class Structure..........121
tecad_win Command...........123
tecad_win .............124
Troubleshooting the Windows Event Log Adapter 125
Chapter 11. Windows NT Event Log
Adapter ..............127
Adapter Files .............127
Configuration File ...........128
Prefiltering Windows NT Log Events . . . 130
iv IBM Tivoli Enterprise Console: Adapters Guide
Format File .............131
Non-English Format Files .......132
Registry Variables ............132
Low Memory Registry Variables ......134
Adapter Administrator Roles for Windows NT . . 134
Starting the Adapter ...........135
Stopping the Adapter...........135
Events Listing .............135
Event Class Structure..........135
tecad_nt Command ...........137
tecad_nt ..............138
Troubleshooting the Windows NT Event Log
Adapter ...............139
Appendix A. Files Shipped with
Adapters .............141
Appendix B. Format File Reference 145
Format File Location ...........145
Format Specifications...........146
Log File Example ............147
Windows NT Example ..........149
Mappings ..............149
Additional Mapping Considerations.....151
Activating Changes Made with a Format File. . . 153
Generating a New Class Definition Statement
File for a TME Adapter .........153
Generating a New Class Definition Statement
File for a Non-TME Adapter .......153
Appendix C. Class Definition
Statement File Reference ......155
File Format ..............155
Operators ..............155
Class Definition Statement File Details .....156
SELECT Statement ..........157
FETCH Statement ...........158
MAP Statement............159
MAP_DEFAULT Statement ........159
Example ..............159
Object Identifier to Name Translation .....160
Class Definition Statement File Syntax Diagrams 161
Notices ..............165
Trademarks ..............167
Glossary .............169
Index ...............171
Contents v
vi IBM Tivoli Enterprise Console: Adapters Guide
Preface
The IBM®Tivoli Enterprise Console®Adapters Guide provides detailed descriptions
for the currently available IBM Tivoli®Enterprise Console adapters.
Who Should Read This Guide
This guide is for IBM Tivoli Enterprise Console administrators who configure event
adapters and IBM Tivoli Enterprise Console gateways.
You should have prior knowledge of the following:
®
v UNIX
v Microsoft
v Tivoli Management Framework
v Adapter operating system
For example, if you are using an OpenView adapter, you should be familiar with
Hewlett-Packard OpenView.
What This Guide Contains
The IBM Tivoli Enterprise Console Adapters Guide contains the following sections:
v Chapter 1, “Understanding Adapters”
Describes adapters, events, attributes, adapter architecture, and adapter files.
v The following chapters provide information about how to configure and use
each adapter:
– Chapter 2, “AS/400 Alert Adapter”
– Chapter 3, “AS/400 Message Adapter”
– Chapter 4, “NetWare Log File Adapter”
– Chapter 5, “OpenView Adapter”
– Chapter 6, “OS/2 Adapter”
– Chapter 7, “SNMP Adapter”
– Chapter 9, “UNIX Log File Adapter”
– Chapter 10, “Windows Event Log Adapter”
– Chapter 11, “Windows NT Event Log Adapter”
v Chapter 8, “IBM Tivoli Enterprise Console Gateways”
Provides information about how to configure the IBM Tivoli Enterprise Console
gateway.
v Appendix A, “Files Shipped with Adapters”
Lists significant files shipped with and used by each adapter.
v Appendix B, “Format File Reference”
Contains details about format files, including organization, syntax, and how to
modify them.
v Appendix C, “Class Definition Statement File Reference”
Contains details about class definition statement files, including organization,
syntax, and how to modify them.
operating system
®
Windows®2000 or Windows NT®operating systems
© Copyright IBM Corp. 2002 vii
Publications
IBM Tivoli Enterprise Console Library
This section lists publications in the IBM Tivoli Enterprise Console library and any
other related documents. It also describes how to access Tivoli publications online
and how to make comments on Tivoli publications.
The following documents are available in the IBM Tivoli Enterprise Console library:
v Tivoli Event Integration Facility User’s Guide, GC32-0691
Discusses how to develop your own event adapters that are tailored to your
network environment and your specific needs. Additionally, the guide describes
how to filter events at the source.
v IBM Tivoli Enterprise Console Installation Guide, GC32-0823
Discusses how to install, upgrade, and remove IBM Tivoli Enterprise Console
components.
v IBM Tivoli Enterprise Console Reference Manual, GC32-0666
Provides details about command-line commands applicable to using the IBM
Tivoli Enterprise Console product, the predefined tasks shipped in the task
library, and the environment variables available to tasks that execute with an
event.
v IBM Tivoli Enterprise Console Rule Builder’s Guide, GC32-0669
Discusses how to develop rules and integrate them for event correlation and
automated event management.
v IBM Tivoli Enterprise Console User’s Guide, GC32-0667
Discusses how to plan for and configure your event database environment and
describes components, roles, and other information for using the IBM Tivoli
Enterprise Console product.
Prerequisite Publications
To be able to use the information in this book effectively, you must have some
prerequisite knowledge, which you can get from the following books:
v Tivoli Management Framework Planning for Deployment Guide, GC32-0393
Introduces the Tivoli environment and provides detailed information about the
desktop, managed nodes, administrators, policy regions, profiles, notices, tasks,
and scheduling.
v Tivoli Management Framework User’s Guide, GC31-8433
Describes the concepts and procedures for using Tivoli Management Framework
services. It provides instructions for performing tasks from the Tivoli desktop
and from the command line.
v Tivoli Management Framework Reference Manual, SC31-8434
Provides information about the command line interface for Tivoli Management
Framework.
Related Publications
The Tivoli Glossary includes definitions for many of the technical terms related to
Tivoli software. The Tivoli Glossary is available, in English only, at the following
Web site:
http://www.tivoli.com/support/documents/glossary/termsm03.htm
viii IBM Tivoli Enterprise Console: Adapters Guide
Accessing Publications Online
Publications in the product libraries are included in PDF or HTML formats, or
both, on the product CD. To access publications using a Web browser, open the
infocenter.html file, which is located in the appropriate publications directory on
the product CD.
When IBM publishes an updated version of one or more online or hardcopy
publications, they are posted to the Tivoli Information Center. You can access
updated publications in the Tivoli Information Center from the following Customer
Support Web site:
http://www.tivoli.com/support/documents/
The Tivoli Information Center contains the most recent version of the books in the
product library in PDF or HTML formats, or both. Translated documents are also
available for some products.
Note: If you print PDF documents on other than letter-sized paper, select the Fit to
page check box in the Adobe Acrobat Print dialog (which is available when
you click File —> Print) to ensure that the full dimensions of a letter-sized
page are printed on the paper that you are using.
Providing Feedback about Publications
If you have comments or suggestions about Tivoli products and documentation,
send an e-mail to pubs@tivoli.com or complete the customer feedback survey at
the following Web site:
http://www.tivoli.com/support/survey/
Contacting Customer Support
If you have a problem with any Tivoli product, you can contact IBM Customer
Support for Tivoli products. See the Tivoli Customer Support Handbook at the
following Web site:
http://www.tivoli.com/support/handbook/
The handbook provides information about how to contact Customer Support,
depending on the severity of your problem, and the following information:
v Registration and eligibility
v Telephone numbers and e-mail addresses, depending on the country in which
you are located
v What information you should gather before contacting Customer Support
Conventions Used in this Guide
This book uses several conventions for special terms, actions, operating
system-dependent commands, and paths.
Typeface Conventions
The following typeface conventions are used in this book:
Bold Commands, keywords, file names, authorization roles, URLs, or
Preface ix
other information that you must use literally appear in bold.
Names of windows, dialogs, and other controls also appear in
bold.
Italics Variables and values that you must provide appear in italics. Words
and phrases that are emphasized also appear in italics.
Monospace Code examples, output, and system messages appear in a
monospace font.
Operating System-dependent Variables and Paths
This book uses the UNIX convention for specifying environment variables and for
directory notation.
When using the Windows command line, replace $variable with %variable% for
environment variables and replace each forward slash (/) with a backslash (\)in
directory paths.
Note: If you are using the bash shell on a Windows system, you can use the UNIX
conventions.
x IBM Tivoli Enterprise Console: Adapters Guide
Chapter 1. Understanding Adapters
Event adapters are software programs that collect information, perform local
filtering, and convert relevant events into a format that can be used by the IBM
Tivoli Enterprise Console product. Because adapters are located on or near their
event sources and can perform local filtering of events, the adapters create a
minimal amount of additional network traffic. Adapters use a minimal amount of
system resources to perform their functions.
Network management applications have become an important part of monitoring
the availability of resources in the enterprise. The IBM Tivoli Enterprise Console
product can seamlessly integrate alarms and events from all the major network
management platforms and can correlate them with other system, database, and
application events.
Adapters are passive collectors of all types of events from systems and
applications, including the network management applications. All of your existing
network management configuration and monitoring of events can be preserved;
these events can simply be forwarded to the event server for correlation with other
events, where automated responses can be triggered or Information Technology
(IT) staff can be notified.
Adapter Overview
An adapter is a process that monitors resources so that they can be managed. These
monitored resources are called sources. A source is an application (for example, a
database) or system resource (for example, an NFS server). When an adapter
detects an event generated from a source (generally called a raw event), it formats
the event and sends it to the event server. The event server then further processes
the event.
Adapters can monitor sources in the following ways:
v An adapter can receive events from any source that actively produces them. For
example, SNMP adapters can receive traps sent by the Simple Network
Management Protocol (SNMP).
v An adapter can check an ASCII log file for raw events at configurable intervals if
the source updates a log file with messages.
How Events Get Sent to the Event Server
Adapters can send events to the event server using a TME®interface or a
non-TME interface. Both types of interfaces send events using an ordinary TCP/IP
channel. The difference between the two interfaces is the method used to establish
the connection. A TME interface establishes a connection using the oserv services
provided by Tivoli Management Framework; therefore, adapters that use this
interface are referred to as TME adapters. A non-TME interface establishes
connections using standard interprocess communication mechanisms (for example,
opening an IP socket); therefore, adapters that use this interface are called
non-TME adapters.
How Events Get to the Event Server From an Endpoint
TME adapters installed on endpoints send their events to the lcfd process, which
then sends the events to an IBM Tivoli Enterprise Console gateway, which in turn
© Copyright IBM Corp. 2002 1
bundles them up and forwards them on to an event server. A TME interface is
used for communications. The IBM Tivoli Enterprise Console gateway uses a
connection-oriented service to the server by default. A connection-oriented service
means that a connection is established when the adapter is initialized and the
connection is maintained for all events to be sent. The IBM Tivoli Enterprise
Console gateway runs on the same managed node as the Tivoli Management
Framework gateway that is providing the endpoint gateway service. The IBM
Tivoli Enterprise Console gateway provides the following benefits:
v Greater scalability, meaning you can manage many sources easier, with less
software running on the endpoints.
v Greatly reduces the amount of communications tasks performed by the event
server or the Tivoli management region server, as the IBM Tivoli Enterprise
Console gateway bundles a number of events before sending them to the event
server. This improves event server performance.
v Easier deployment of adapters and updates to adapters using profiles in the
Adapter Configuration Facility (ACF).
The TME adapters currently supported for an endpoint are the following:
v UNIX log file
v OS/2
®
v SNMP
v Microsoft Windows event log
v Windows NT event log
You configure these adapters to send their events to specific primary, secondary or
both event servers, and the IBM Tivoli Enterprise Console gateway forwards them
appropriately. If the IBM Tivoli Enterprise Console gateway, Tivoli Management
Framework gateway, or lcfd process is down, events are buffered at the endpoint.
The events are re-sent when communication is restored and the next event is sent.
If an event server is down (but the IBM Tivoli Enterprise Console gateway, Tivoli
Management Framework gateway, and lcfd processes are still up), events are
buffered at the IBM Tivoli Enterprise Console gateway. They are re-sent when
communication with the server is restored and the next event is sent.
The IBM Tivoli Enterprise Console gateway has configuration options that can be
specified similarly to how configuration options are specified for an adapter; that
is, you can configure the IBM Tivoli Enterprise Console gateway with a
configuration file that you distribute to the gateway node endpoint. For details
about configuring an IBM Tivoli Enterprise Console gateway, see Chapter 8, “IBM
Tivoli Enterprise Console Gateways” on page 95.
2 IBM Tivoli Enterprise Console: Adapters Guide
The following figure shows an example of the IBM Tivoli Enterprise Console
product and Tivoli Management Framework component relationships in a network
with endpoints.
How Events Get to the Event Server From a Managed Node
For network management OpenView adapters, events are sent from the managed
node adapter directly to the event server using a TME interface. In other words,
the oserv of the managed node that the adapter runs on sends the event to the
oserv of the event server when these are separate nodes, which then forwards it on
to the event server process.
For the UNIX log file, OS/2, Windows, Windows NT, and SNMP TME adapters, a
managed node must also be configured as an endpoint to send events to the event
server.
How Events Get to the Event Server From a Non-TME Adapter
A non-TME adapter sends events directly to the event server using an IP socket.
Internationalization Support for Events
By default, the following log file adapters send their events to the event server in
UTF-8 encoding:
v UNIX log file adapter
v NetWare log file adapter
v OS/2 log file adapter
v Windows event log adapter
v Windows NT event log adapter
To change the default configuration of these adapters so they send events in the
encoding of the event server host instead of UTF-8, the Pre37Server and
Pre37ServerEncoding configuration file options are provided. See page 12 for
additional information about these options.
Chapter 1. Understanding Adapters 3
The event server can receive events in both UTF-8 encoding or the encoding of the
event server host. The event server automatically determines the type of encoding
(UTF-8 or non-UTF-8) of an event by evaluating a particular flag in the event data.
The adapter automatically reads the format file from the appropriate directory. If
the adapter is sending events to an event server running a version earlier than the
IBM Tivoli Enterprise Console 3.7 product, the format files in the localization
directories must remain in English. See “Format File” on page 17 and Appendix B,
“Format File Reference” on page 145 for additional information.
Tivoli Event Integration Facility provides support for creating new adapters (other
than those shipped by the IBM Tivoli Enterprise Console product) or modifying
existing adapters to send events to the latest version of the event server. Existing
adapters shipped in a previous release of the IBM Tivoli Enterprise Console
product do not require updating; the new event server recognizes events sent from
those adapters. See the Tivoli Event Integration Facility User’s Guide for additional
information.
When the adapter is installed, a new codesets directory appears with the bin and
etc directories under $TECADHOME.
Event Information
Event information is formatted as a set of attributes. Each attribute is predefined
and contains a name and value. Adapters separate information into event classes,
format this information into attributes, and send this information to the event
server. The event server then processes this information.
Event classes are a classification of events; do not confuse them with the term
classes in the traditional object-oriented sense. Event classes can be subclassed to
facilitate a further breakdown of information so that more detailed rules can be
applied to the information. In essence, event classes are an agreement between the
adapter and the event server about what information the adapter sends to the
event server for a given class.
After event information is separated into attributes and the event is categorized
into an event class, the adapter sends the information to the event server for
further processing. Adapters are configured to send only information that
administrators are interested in; that is, filters are established on the local system
that specify whether to discard an event or forward it to the event server. This
minimizes any network loading that is related to enterprise monitoring.
Event Attributes
An event class name is followed by attribute information.
An adapter supplies information in the form of attributes. An attribute has the
following format:
attribute_name=value
The following list describes base event attributes that can be contained in an event
sent to the event server. Base event attributes are standard for most event classes
and are defined in the highest superclass of a basic recorder of objects in C
(BAROC) file. An adapter can also contain adapter-specific or user-defined
attributes.
4 IBM Tivoli Enterprise Console: Adapters Guide
Attribute Name Contents
acl The list of authorization roles that enables an administrator to
modify the event.
adapter_host The host on which the adapter is running.
administrator The administrator who acknowledged or closed the event.
cause_date_
reception
The cause_date_reception attribute is used to link an effect event to
its cause event. This value is set to the value of the date_reception
attribute of the cause event.
cause_event_ handle The cause_event_handle attribute is used to link an effect event to
its cause event. This value is set to the value of the event_handle
attribute of the cause event.
credibility Indicates how the event was sent from the adapter. The value is 1 if
an event was sent using a communications channel provided by
Tivoli Management Framework services, as is the case for a TME
adapter. The value is zero (0) if an event was sent from a non-TME
adapter.
date The date and time the event was generated.
date_reception A time stamp indicating the time the event server received the
event. It is an integer representing the number of seconds since the
epoch, which is January 1, 1970. This value is also used as a
component to uniquely identify an event. An event is uniquely
identified by a combination of the values for the date_reception,
event_handle, and server_handle attributes.
duration For closed events, the age (in seconds) of the event from when it
was received by the event server until it was closed. For all
non-closed events, the value is zero (0).
Note: If an event was closed by calling the set_event_status
predicate from within a rule, this attribute is not modified to give
the age. The value remains at zero (0).
event_handle A number used to reference the event. An event is uniquely
identified by a combination of the values of the date_reception,
event_handle, and server_handle attributes. Events received within
the same second are assigned an incremental number for this
attribute starting at 1 and incremented by 1.
hostname The name of the system on which the event occurred.
msg A text summary of the event.
msg_catalog For future support of internationalized event messages; not
currently implemented.
msg_index The message ID used to obtain the internationalized message.
num_actions The number of actions (tasks or programs) currently being tracked
by the event server for this event.
origin The protocol address or host name of the source system.
repeat_count A counter for keeping track of the number of times a duplicate type
of event has been received.
server_handle A number identifying the event server that received this event. An
event is uniquely identified by a combination of the values for the
date_reception, event_handle, and server_handle attributes.
Chapter 1. Understanding Adapters 5
Attribute Name Contents
server_path Stores information describing the rule engines that an event has
passed through. server_path has the following definition:
server_path list_of_strings;
Each element in the list represents one rule engine that the event
has visited, and each element contains a rule engine identifier,
server number, reception ID, and event handle. The following is an
example of a list:
chair 1 12121212 3
where:
chair The rule engine identifier
1 The server number
12121212
The event reception ID in server 1
3 The event handle for the event in server 1
severity The severity of the event. The database stores the severity as a
number. This mapping is defined in the root.baroc rule base file
and is set for the event server default severities as follows:
10 UNKNOWN
20 HARMLESS
30 WARNING
40 MINOR
50 CRITICAL
60 FATAL
You can also customize the severity settings.
source The source of the event (for example, the OpenView adapter). The
source is defined by the adapter type.
6 IBM Tivoli Enterprise Console: Adapters Guide
Attribute Name Contents
status The status of an event. It is initially set to OPEN or to a default
value specified by the event class. Possible values during an event
lifetime are as follows:
ACK An administrator or rule has acknowledged the event.
CLOSED
An administrator or rule has fixed the problem that was
reported by the event. An event adapter can also send an
event with a status of CLOSED to indicate that a
previously received event of the specified class should
have its status changed to CLOSED; the previously
received event to be closed is the most recent duplicate of
the same event. The event being sent with a CLOSED
status is dropped and not stored in the event database.
custom_status
A status that has been added to the STATUS enumeration
for site-specific purposes. The STATUS enumeration is
defined in the root.baroc file. To add a new status, edit this
file, recompile the rule base, and restart the event server.
OPEN The event has been received by the event server, but no
administrator or rule has acknowledged it.
RESPONSE
A rule has automatically responded to the event. This
status is assigned a rule language predicate. It is not
available from an event console.
Adapter Files
The database stores the status as a number. This mapping is defined
in the root.baroc rule base file and is set for the event server default
status as follows: zero (0) for OPEN, 10 for RESPONSE, 20 for ACK,
30 for CLOSED.
sub_origin A further categorization of the origin. This attribute is optional.
sub_source A further categorization of the source. This attribute is optional.
The adapter uses the following attributes to uniquely identify an event:
v date_reception
v event_handle
v server_handle
An adapter uses various files for its operations. The following table provides a
brief description of the types of files that can be used. Subsequent sections discuss
some of the more common files you might need to view or modify for
configuration or troubleshooting purposes. See Appendix A, “Files Shipped with
Adapters” on page 141 for detailed information about which files are shipped with
particular adapters.
File Type Description
Basic recorder of objects in C
(BAROC)
Cache Stores buffered events.
Class definition statement (CDS) Defines event class definitions to the adapter.
Defines event classes to the event server; must be
part of the rule base.
Chapter 1. Understanding Adapters 7
File Type Description
Configuration Defines configuration options for adapters.
Error Defines error logging and tracing options for the
adapter.
Format Defines the format of messages and matches them to
event classes for the UNIX log file, NetWare log file,
OS/2, and Windows and Windows NT event log
adapters.
Installation script Configures the adapter to start when the operating
system starts.
Object identifier Defines object-identifier-to-name mappings for the
NetView
Registration The registration file generated by the installation
script for NetView/6000 and OpenView.
Rules Defines rules to the event server; must be part of the
rule base.
®
/6000, OpenView, and SNMP adapters.
An adapter uses the TIVOLI_COMM_DIR Tivoli Management Framework
environment variable, if set, to determine which directory to use for its lock and
pipe files. If the variable is not set, /tmp/.tivoli is used instead. For more
information about this environment variable, see the Tivoli Management Framework
Release Notes.
Cache File
Events are written to the cache file using a “circular” method; when the cache file
has reached the size limit set by BufEvtMaxSize, the next new event is written to
the beginning of the cache file (thus overwriting the existing data at that location).
Subsequent events continue being written in order until the end of the file is
reached again, and the process starts over from the beginning of the file. A small
header at the beginning of the file tracks where the next new event will be written
and where the next old event will be removed.
The format of the cache file is as follows:
Cache File Format:
----------------maxsz: XXXXXXXXXX
head : XXXXXXXXXX
tail : XXXXXXXXXX
........................event1 event2
event3 event4 event5.................
.....................................
.....................................
.....................................
The first three lines in the cache file all have a fixed size of 18 bytes and contain
the following data:
maxsz The maximum size of the cache file.
head The byte offset from the beginning of the file to the next event to send. A
value of zero (0) indicates an empty cache file.
tail The byte offset from the beginning of the file to the first byte of free space
in the file.
8 IBM Tivoli Enterprise Console: Adapters Guide
The boundaries between events in the cache file are indicated by a terminating ^A
character at the end of each event.
Configuration File
Most adapters come with a configuration file containing configuration options and
filters. This file is read by an adapter when it is started. By modifying this file, you
can reconfigure an adapter at anytime, without having to modify the adapter
source code. To have your configuration changes take effect, simply stop and
restart the adapter. A configuration file usually has an extension of .conf; see each
specific adapter chapter for exact file names.
File Location
By default, an adapter expects its configuration file (along with its format, CDS,
and error files) to be located as shown in the following table. For Windows and
Windows NT, the syntax shown is correct when running the bash interpreter.
Adapter Type Node Type Location
TME Managed node $BINDIR/TME/TEC/adapters/etc/ or /etc/Tivoli/tecad/etc
non-TME Not applicable path/etc where the adapter was manually installed or
(which is a link to the TME adapter directory)
Endpoint $LCFROOT/bin/$INTERP/TME/TEC/adapters/etc or
/etc/Tivoli/tecad/etc (which is a link to the TME adapter
directory)
/etc/Tivoli/tecad/etc (which is a link to the TME adapter
directory)
For information about directory structures and system variables (those beginning
with $), see the Tivoli Management Framework Planning for Deployment Guide.
File Format
Each non-blank line that does not begin with the comment sign (#) is of one of the
following forms:
v To specify configuration options:
keyword=value
v To specify event filters:
Filter:CLASS=class_name;attribute=value;
v To specify event buffer filters:
FilterCache:CLASS=class_name;attribute=value;
Example
#
# Communication Parameters
#
ServerLocation=ravel
ServerPort=5529
#
# Event Filters
#
Filter:Class=disk_event
Filter:Class=Su_Success;origin=126.32.2.14
Keywords
Keywords use the following format: keyword=value
Chapter 1. Understanding Adapters 9
Some adapters have additional keywords specific to them. See each specific
adapter chapter for descriptions of these keywords. Adapters do not issue error
messages for misspelled keywords or keywords set to a value that is not valid. Do
not use blank spaces in keyword statements unless enclosed in single quotation
marks (however, you cannot use quotation marks at all with the HPOVFilter
keyword in the HPOV adapter). Do not use class names not defined in a BAROC
file with configuration options.
A configuration file can contain the following keywords, which are common to
most adapters:
AdapterCdsFile=path
Specifies the full path name of the CDS file. This keyword is required if the
CDS file is not in the same directory as the configuration file.
AdapterErrorFile=path
Specifies the full path name of the error file. This keyword is required if
the error file is not in the same directory as the configuration file.
BufEvtMaxSize
Specifies the maximum size, in kilobytes, of the adapter cache file. The
default value is 64. The cache file stores events on disk when they cannot
be sent to the event server.
The BufEvtMaxSize keyword is optional.
BufEvtPath
Specifies the full path name of the adapter cache file. On endpoint
adapters, the BufEvtPath keyword uses the $TIVOLIHOME variable to
resolve file location and drive letter differences over different environments
by using a path relative to the endpoint installation. The ACF defines
$TIVOLIHOME on each endpoint; you cannot change its value.
Operating System Default Path $TIVOLIHOME Value
UNIX $TIVOLIHOME/tec/
Windows, WindowsNT$TIVOLIHOME\tec\
The AS/400®adapters do not use this keyword.
This keyword is required when the BufferEvents keyword is set to YES.
BufferEvents
Specifies whether or not event caching is enabled. If BufferEvents is set to
anything other than YES, events are not cached. The value is not
case-sensitive. The default value is YES.
The BufferEvents keyword is optional.
BufferFlushRate
Specifies the number of events sent per minute. Once the adapter has
recovered the lost connection, and there are events in the buffer, the events
are sent at this rate per minute. The default value is zero (0); all events are
sent in one burst.
The BufferFlushRate keyword is optional.
ConnectionMode
Specifies the connection mode to use to connect to the IBM Tivoli
Enterprise Console gateway or event server. Valid values are
tecad_adapter.cache
tecad_adapter.cache
/etc/Tivoli
%SystemRoot%\system32\
drivers\etc\Tivoli
10 IBM Tivoli Enterprise Console: Adapters Guide
connection_oriented (or its abbreviations CO and co) and connection_less.
The default value is connection_less, except for the AS/400 adapters and
the IBM Tivoli Enterprise Console gateway, which have
connection_oriented as the default value.
When connection_less is specified or used by default, a new connection is
established (and discarded) for each event or group of events that is sent.
When connection_oriented or one of its abbreviations is specified, a
connection is established at adapter initialization and is maintained for all
events sent. A new connection is established only if the initial connection is
lost. The connection is discarded when the adapter is stopped.
The ConnectionMode keyword is optional.
Filter Works with the FilterMode keyword to determine how events are filtered.
An event matches a Filter statement when each attribute=value pair in the
Filter statement is identical to the corresponding attribute=value pair in the
event.
A Filter statement must contain the event class, and optionally can include
any other attribute=value pair that is defined for the event class. The format
of a filtering statement is the following:
Filter:Class=class_name;[attribute=value;...;attribute=value]
Each statement must be on a single line. The attribute=value pair is case
sensitive.
This keyword is optional.
FilterCache
Works with the FilterMode and Filter keywords to determine which events
are stored in the cache when events cannot be sent successfully to the
event server. To store events in the cache, you must set BufferEvents=YES.
An event matches a FilterCache statement when each attribute=value pair
in the FilterCache statement is identical to the corresponding
attribute=value pair in the event.
A FilterCache statement must contain the event class (class_name) and can
include any attribute=value pair that is defined for that event class. The
format of a filtering statement is the following:
Filter:Class=class_name;[attribute=value;...;attribute=value]
Each statement must be on a single line. The attribute=value pair is case
sensitive. You must specify the Filter keyword, when you use the
FilterCache keyword. Additionally, the FilterCache statement must specify
the same class or subset of classes that the Filter statement specifies.
This keyword is optional.
Note: When using FilterCache with endpoint adapters and the IBM Tivoli
Enterprise Console gateway, you must set the filtering statements at
both locations to the same specifications.
FilterMode
Specifies whether events that match a Filter or FilterCache statement are
sent to the event server (FilterMode=IN) or discarded (FilterMode=OUT).
The default value is OUT. The valid values are IN or OUT, without regard for
case. If you set FilterMode=IN, you must have one or more Filter and
FilterCache statements defined.
Chapter 1. Understanding Adapters 11
For information about how to use filtering keywords to send, cache, and
discard events, see “Event Filtering” on page 14.
This keyword is optional.
getport_timeout_seconds
Specifies the number of seconds to wait before re-sending the UDP call for
a port, if no response is heard. It re-transmits until the RPC call times out.
The default value is zero (0) seconds.
getport_timeout_usec
Specifies the number of microseconds to add to the seconds specified with
the getport_timeout_seconds keyword. The default value is 50 000
microseconds.
getport_total_timeout_seconds
Specifies the number of seconds to wait on getting a port after making a
all to the portmapper. The default value is zero (0) seconds.
getport_total_timeout_usec
Specifies the number of microseconds to add to the seconds specified with
the getport_total_timeout_seconds keyword. The default value is 50 000
microseconds.
NO_UTF8_CONVERSION
Specifies whether to encode event data in UTF-8. When this options is set
to YES, the IBM Tivoli Enterprise Console product does not encode event
data in UTF-8. The data is assumed to already be in UTF-8 encoding when
passed to the IBM Tivoli Enterprise Console product. It does, however,
prepend the flag indicating that the data is in UTF-8 encoding if the flag
does not exist at the beginning of the event data.
The default value for this option is NO.
Pre37Server
Specifies whether the adapter is to send its events in the encoding of the
event server host or in UTF-8 encoding. Event server host versions earlier
than the IBM Tivoli Enterprise Console 3.7 product do not support UTF-8
encoding of events. When set to YES, this keyword disables UTF-8
encoding and allows the adapter to communicate with event server host
versions earlier than the IBM Tivoli Enterprise Console 3.7 product. When
this keyword is set to NO, the adapter sends events in UTF-8 encoding.
The values are not case-sensitive. The default is NO.
When this keyword is set to YES, you must also specify the
Pre37ServerEncoding keyword.
Pre37ServerEncoding
Determines which language to use when a non-TME adapter
communicates with a non-UTF-8 event server host (versions earlier than
the IBM Tivoli Enterprise Console 3.7 product). This keyword is active only
when Pre37Server is set to YES. This keyword only applies to the log file
adapters (UNIX, NetWare, OS/2, Windows, and Windows NT).
RetryInterval
When ConnectionMode=connection_oriented, and the connection to the
event server is lost, an adapter waits the specified number of seconds
before connecting to a secondary server or buffering the events. While the
adapter is waiting for the expiration of this interval, no new events are
processed by the adapter.
12 IBM Tivoli Enterprise Console: Adapters Guide
This option allows an adapter to send all events to the primary event
server even if the primary event server is stopped briefly, such as when
loading a new rule base.
If you use this option to wait for restarting an event server, set the value
for a period of time longer than necessary for the event server to be
stopped and then restarted.
The RetryInterval keyword is optional. The default is 120 seconds.
ServerLocation
Specifies the name of the host on which the event server is installed. The
value of this field must be one of the formats shown in the following table,
depending on whether the adapter is a TME adapter or a non-TME
adapter, and whether the event server is part of an interconnected Tivoli
management region:
Adapter Type Format
TME EventServer
TME in an interconnected
Tivoli management region
non-TME host_name or IP_address. Use the dotted format
Note: AS/400 adapters are non-TME adapters.
EventServer#region_name
for IP_address.
For TME adapters on managed nodes and non-TME adapters,
ServerLocation can contain up to eight values, separated by commas. The
first location is the primary event server, while others are secondary
servers to be used in the order specified when the primary server is down.
For endpoint adapters, secondary event servers, if any, are defined in the
IBM Tivoli Enterprise Console gateway configuration file. Only specify a
primary event server in an endpoint adapter configuration file.
The default is EventServer. To use a non-TME value for ServerLocation,
see “Configuration File” on page 97 for more information.
The ServerLocation keyword is required.
Note: ServerLocation defines the path and name of the file for logging
ServerPort
Specifies the port number on a non-TME adapter on which the event
server listens for events. Set this keyword value to zero (0), the default
value unless the portmapper is not available on the event server, which is
the case if the event server is running on Windows or the event server is a
Tivoli Availability Intermediate Manager (see the following note). If the
port number is specified as zero (0) or it is not specified, the port number
is retrieved using the portmapper.
events, instead of the event server, when used with the TestMode
keyword.
The ServerPort keyword can contain up to eight values, separated by
commas. For non-TME adapters that send events to a UNIX event server,
use the default value of zero (0) (only one value of zero, even if multiple
UNIX event servers are specified with the ServerLocation keyword). For
Chapter 1. Understanding Adapters 13
non-TME adapters that send events to a Windows event server or a Tivoli
Availability Intermediate Manager (AIM), specify one value for each event
server defined with the ServerLocation keyword.
The ServerPort keyword is optional when the event server is running on
UNIX, but mandatory when running on Windows.
Note: If the event server is running on Windows: There is no portmapper
TestMode
Specifies whether test mode is turned on or off. When TestMode=YES, the
ServerLocation keyword specifies the file to which events are logged,
instead of being sent to the event server. Valid values are YES and NO,
without regard to case. The default is NO.
The TestMode keyword is optional.
daemon on a Windows machine that allows the adapter to query the
reception port at runtime. The event server listens on a fixed
reception port (tec_recv_agent_port in .tec_config) for connection
and adapter input. Set ServerPort to the value of the
tec_recv_agent_port entry in the .tec_config file in the
$BINDIR/TME/TEC directory. The default is 5529. The Tivoli
Availability Intermediate Manager never uses the portmapper; the
Tivoli Availability Intermediate Manager server listens on a fixed
port set in the Tivoli Availability Intermediate Manager graphical
user interface.
Event Filtering
Normally, an adapter sends all events to the event server. You can optionally
specify events that can or cannot be sent to the event server. You can do this by
specifying the event class and such information as the origin, severity, or any other
attribute=value pair that is defined for the event class. The class name specified for
an event filter entry must match a defined class name; an adapter does not
necessarily have knowledge of the class hierarchy.
Depending on how you specify the Filter and FilterMode keywords, filtered
events are either sent to the event server or discarded.
v To send specific events to the event server:
1. Set FilterMode to IN.
2. Create Filter statements to match the specific events that you want sent.
v To discard specific events:
1. Set FilterMode to OUT (the default value).
2. Create Filter statements to match the specific events that you want
discarded.
v To send all events to the event server (the default behavior):
1. Set FilterMode to OUT.
2. Do not specify any Filter statements.
Note: All events are discarded when the configuration is as follows:
1. FilterMode is set to IN.
2. No Filter statements are specified.
To use non-English characters in a Filter statement, you must enter the non-English
characters in the local encodings.
14 IBM Tivoli Enterprise Console: Adapters Guide
Regular Expressions in Filters: You can also use Tcl regular expressions in
filtering statements. The format of a regular expression is re:’value_fragment’.
Note: Tivoli Event Integration Facility uses an exception to the Tcl regular
expression syntax. The backslash character (\) in Tivoli Event Integration
Facility indicates that the following literal character is the character to filter
for, not some special character such as a tab. For example, \t means the tab
character in Tcl, but means t in Tivoli Event Integration Facility.
The following example shows a Filter statement with a regular expression. This
filter statement matches all events with a class name that contains TEC_ somewhere
in its name:
Filter:Class=re:’TEC_.*’
The following example shows a FilterCache statement with a narrower range. This
filter statement matches all events with a class name that contains TEC_ somewhere
in its name and has a severity of critical:
FilterCache:Class=re:’TEC_.*’;severity=CRITICAL
For more information about Tcl regular expressions, see a Tcl user’s guide.
Event Filter Examples: The following table shows some event filter examples for
a few different adapters:
Adapter Example
AS/400 Alert The following entry matches all events of the
SNA_Equipment_Malfunction class from the origin 1.2.3.4:
Filter:Class=SNA_Equipment_Malfunction;origin=1.2.3.4
UNIX Log File The following entry matches all events of the Su_Success class from
the origin 126.32.2.14:
Filter:Class=Su_Success;origin=126.32.2.14
OpenView The following entry matches all events of the OV_Message class from
the origin 126.32.2.14:
Filter:Class=OV_Message;origin=126.32.2.14
Windows NT The following entry matches all events of the NT_Power_Failure
class from the origin 126.32.2.14:
Filter:Class=NT_Power_Failure;origin=126.32.2.14
Event Buffer Filtering
When an adapter is unable to connect to the event server or IBM Tivoli Enterprise
Console gateway, it sends the events to a file if the BufferEvents keyword is set to
YES. You can filter events sent to a cache file, similar to filtering events for the
event server by using the FilterCache keyword.
There are no default event cache filters in the configuration files shipped with
adapters.
The following procedures describe how to filter events with the FilterCache and
FilterMode keywords, when the event server is unavailable:
v To cache specific events:
1. Set FilterMode to IN.
2. Set BufferEvents to YES (the default value).
Chapter 1. Understanding Adapters 15
3. Create Filter and FilterCache statements to match the specific events that
you want cached.
v To discard specific events:
1. Set FilterMode to OUT.
2. Create Filter and FilterCache statements to match the specific events that
you want discarded.
v To cache all events (the default behavior):
1. Set FilterMode to OUT.
2. Set BufferEvents to YES.
3. Do not specify any FilterCache statements.
Note: All events are discarded when the configuration is as follows:
1. FilterMode is set to IN.
2. No FilterCache statements are specified.
Event Buffer Filter Examples: The following table shows some event buffer filter
examples for a few different adapters:
Adapter Example
AS/400 Alert The following entry matches all events of the
SNA_Equipment_Malfunction class from the origin 1.2.3.4:
FilterCache:Class=SNA_Equipment_Malfunction;origin=1.2.3.4
UNIX Log
File
OpenView The following entry matches all events of the OV_Message class from the
Windows NT The following entry matches all events of the NT_Power_Failure class from
The following entry matches all events of the Su_Success class from the
origin 126.32.2.14:
FilterCache:Class=Su_Success;origin=126.32.2.14
origin 126.32.2.14:
FilterCache:Class=OV_Message;origin=126.32.2.14
the origin 126.32.2.14:
FilterCache:Class=NT_Power_Failure;origin=126.32.2.14
BAROC File
Each adapter comes with a BAROC file describing the classes of events the adapter
supports. This file is not used by the adapter itself, but serves as a mandatory link
between the adapter and the event server. The event server must load this file
before it is able to understand events received from the adapter. A BAROC file has
an extension of .baroc; see each specific adapter chapter for exact file names. The
format of a BAROC file is described in the IBM Tivoli Enterprise Console Rule
Builder’s Guide.
Example
The following fragment shows how an event class for reporting SNMP
authentication problems could be defined in a BAROC file:
CLASS AUTHENTICATION_FAILURE ISA EVENT
DEFINES {
source:default="SNMP";
sub_source:default="NET";
auth_source:STRING;
};
END
16 IBM Tivoli Enterprise Console: Adapters Guide
Rule File
Some adapters come with a rule file describing the classes of events the adapter
supports. This file is not used by the adapter itself, but serves as a mandatory link
between the adapter and the event server. The event server must load this file
before it is able to understand events received from the adapter. A rule file has an
extension of .rls; see each specific adapter chapter for exact file names. The format
of a rule file is described in the IBM Tivoli Enterprise Console Rule Builder’s Guide.
Example
The following fragment shows how an event class for reporting SNMP
authentication problems could be defined in a BAROC file:
CLASS AUTHENTICATION_FAILURE ISA EVENT
DEFINES {
source:default="NET";
sub_source:default="SNMP";
auth_source:STRING;
};
END
Format File
The UNIX log file, NetWare log file, OS/2, Windows, and Windows NT event log
adapters can extract information from system log messages, whose format and
meaning can vary widely. This capability is necessary because similar sources can
produce messages in different formats. For example, different NFS (network file
system) implementations might report the file system full error in different
formats. As a result, you might need to match different messages to the same or
different event classes. This type of matching is done with a format file.
The purposes of a format file are as follows:
v Serves as the lookup file for matching messages to event classes. When the
format file is being used for this purpose, all format specifications in the file are
compared from top to bottom. In situations where there are multiple matching
classes for a message, the last matching format specification is used. If no match
is found, the event is discarded.
v Serves as the source from which a CDS file is generated. See “Class Definition
Statement File” on page 18 for additional information.
See Appendix B, “Format File Reference” on page 145 for details about format files.
Example
The following examples show sample entries from the format file used by the
Windows NT event log adapter.
Note: The format files for the log file-type adapters are examples only;
customization might be required. The message text must fit on one line and
be no longer than 1024 characters.
FORMAT NT_Base
%t %s %s %s %s %s %s %s*
hostname DEFAULT
origin DEFAULT
category $3
eventType $4
sid $5
sub_source $6
id $7
msg $8
Chapter 1. Understanding Adapters 17
-date1 $1
-date2 $2
date PRINTF("%s %s", date1, date2)
END
FORMAT NT_Share_Dir_Missing FOLLOWS NT_Base
%t %s %s %s %s %s %s The server service was unable to recreate
the share %s because the directory %s no longer exists.
sharename $8
directoryname $9
END
FORMAT NT_Service_Start FOLLOWS NT_Base
%t %s %s %s %s %s %s %s* started successfully.
service $8
END
FORMAT NT_Service_Started FOLLOWS NT_Base
%t %s %s %s %s %s %s The %s* service was started.
service $8
END
Class Definition Statement File
CDS files are used by an adapter to map incoming raw events to a particular class
and to define event attributes before forwarding the event to the event server.
No alterations to this file are necessary to use an adapter unless you alter the
corresponding .fmt file (if any). If any event definition is changed in a CDS file,
the corresponding event class definition in the BAROC file might need changing as
well. Event definition content and syntax are discussed in the IBM Tivoli Enterprise
Console Rule Builder’s Guide.
See Appendix C, “Class Definition Statement File Reference” on page 155 for details
about CDS files.
Example
The following example shows a CDS file:
#
# Default attribute values
#
MAP_DEFAULT
source = SNMP;
sub_source = NET;
# forwarding_agent = $SOURCE_ADDR;
origin = $AGENT_ADDR;
adapter_host = $ADAPTER_HOST;
END
CLASS Authentication_Failure_Cisco
SELECT
1: ATTR(=,$ENTERPRISE), VALUE(PREFIX, "1.3.6.1.4.1.9");
2: $TYPE = 4;
3: ATTR(=,"authAddr");
FETCH
1: IPNAME($SOURCE_ADDR);
MAP
hostname = $F1;
originating_address = $V3;
END
# For Cisco routers, because we know the interface generating the trap,
# we map ’linkUp’ traps to ’linkDown’ CLOSED events
CLASS Link_Down_Cisco
SELECT
1: ATTR(=,$ENTERPRISE), VALUE(PREFIX, "1.3.6.1.4.1.9");
2: $TYPE = 3;
3: ATTR(=,"ifIndex");
18 IBM Tivoli Enterprise Console: Adapters Guide
Loading...