iagent User Guide Document 5159

Transcription

1

2 Notice Copyright Notice Copyright 2004-present by Aprisma Management Technologies, Inc. All rights reserved worldwide. Use, duplication, or disclosure by the United States government is subject to the restrictions set forth in DFARS (c)(1)(ii) and FAR Liability Disclaimer Aprisma Management Technologies, Inc. ( Aprisma ) reserves the right to make changes in specifications and other information contained in this document without prior notice. In all cases, the reader should contact Aprisma to inquire if any changes have been made. The hardware, firmware, or software described in this manual is subject to change without notice. IN NO EVENT SHALL APRISMA, ITS EMPLOYEES, OFFICERS, DIRECTORS, AGENTS, OR AFFILIATES BE LIABLE FOR ANY INCIDENTAL, INDIRECT, SPECIAL, OR CONSEQUENTIAL DAMAGES WHATSOEVER (INCLUDING BUT NOT LIMITED TO LOST PROFITS) ARISING OUT OF OR RELATED TO THIS MANUAL OR THE INFORMATION CONTAINED IN IT, EVEN IF APRISMA HAS BEEN ADVISED OF, HAS KNOWN, OR SHOULD HAVE KNOWN, THE POSSIBILITY OF SUCH DAMAGES. Trademark, Service Mark, and Logo Information SPECTRUM, IMT, and the SPECTRUM IMT/VNM logo are registered trademarks of Aprisma Management Technologies, Inc., or its affiliates. APRISMA, APRISMA MANAGEMENT TECHNOLOGIES, the APRISMA MANAGEMENT TECHNOLOGIES logo, MANAGE WHAT MATTERS, DCM, VNM, SpectroGRAPH, SpectroSERVER, Inductive Modeling Technology, Device Communications Manager, SPECTRUM Security Manager, and Virtual Network Machine are unregistered trademarks of Aprisma Management Technologies, Inc., or its affiliates. For a complete list of Aprisma trademarks, service marks, and trade names, go to: All referenced trademarks, service marks, and trade names identified in this document, whether registered or unregistered, are the intellectual property of their respective owners. No rights are granted by Aprisma Management Technologies, Inc., to use such marks, whether by implication, estoppel, or otherwise. If you have comments or concerns about trademark or copyright references, please send an to spectrum-docs@aprisma.com; we will do our best to help. Restricted Rights Notice (Applicable to licenses to the United States government only.) This software and/or user documentation is/are provided with RESTRICTED AND LIMITED RIGHTS. Use, duplication, or disclosure by the government is subject to restrictions as set forth in FAR (June 1987) Alternate III(g)(3) (June 1987), FAR (June 1987), or DFARS (c)(1)(ii) (June 1988), and/or in similar or successor clauses in the FAR or DFARS, or in the DOD or NASA FAR Supplement, as applicable. Contractor/manufacturer is Aprisma Management Technologies, Inc. In the event the government seeks to obtain the software pursuant to standard commercial practice, this software agreement, instead of the noted regulatory clauses, shall control the terms of the government's license. Virus Disclaimer Aprisma makes no representations or warranties to the effect that the licensed software is virus-free. Aprisma has tested its software with current virus-checking technologies. However, because no antivirus system is 100-percent effective, we strongly recommend that you write protect the licensed software and verify (with an antivirus system with which you have confidence) that the licensed software, prior to installation, is virus-free. Contact Information Aprisma Management Technologies, Inc., 273 Corporate Drive, Portsmouth, NH USA Phone: U.S. toll-free: Web site: Page 2

3 Contents Notice... 2 Preface... 5 Intended Audience... 5 Text Conventions... 5 Document Feedback... 6 Online Documents... 6 SPECTRUM s Integration... 7 Overview... 7 SPECTRUM s Model Type... 8 Process Monitoring... 9 Log File Monitoring...11 Setting Up the Server and the SPECTRUM Environment Basic Steps Required to Configure the Server...13 Modeling the Server with SPECTRUM...16 Modeling Devices with SPECTRUM...16 Modeling Processes with SPECTRUM...16 Configuring the Software to Monitor Log Files Configuring the Log File Monitor...18 Log File Syntax...19 Creating a Log File Monitor Entry to Trigger a Trap...20 Editing a Log File Monitor Entry...23 Deleting a Log File Entry...23 Configuring SPECTRUM to Process the Trap Trap Processing Overview...24 Processing Traps that Contain an IP Address or Model Handle...24 Creating Parsemap Files...25 Page 3

4 Creating an Event Format File...26 Generating an Alarm Based on the Event...27 Apply the Changes to the SpectroSERVER...28 Processing Traps that Contain an Application Log File Name...28 The Flow of Events in SPECTRUM Scenario 1: Correct Configuration for Monitoring a Log File...31 Scenario 2: Correct Configuration for Monitoring an Application Log File...32 Scenario 3: Missing Model...32 Scenario 4: Missing Application Process Model Match...33 Scenario 5: Missing Parse Map File...33 Scenario 6: Invalid Parse Map...34 Scenario 7: Unknown Message Header Format...35 Scenario 8: Missing Device Model...35 Scenario 9: Missing Parse Map and Device Model...36 Troubleshooting MIB-II Data is Missing in the Windows Environment...38 Services are Missing or Do Not Run in the Windows Environment...38 Incomplete Information in the Solaris Environment...39 Case Study: Monitoring a Syslog File Error Scenario...40 Configuration Prerequisites...42 Configuring the Log File Monitor Entry...42 Creating the Parsemap File...43 Creating the Event Format File...45 Modifying the EventDisp file to Generate an Alarm...46 Apply the Changes to the SpectroSERVER...47 Index Page 4

5 Preface In This Section Intended Audience [page 5] Text Conventions [page 5] Document Feedback [page 6] Online Documents [page 6] Intended Audience This guide is intended for users of SPECTRUM s integration. Text Conventions The following text conventions are used in this document: Element Convention Used Example Variables (The user supplies a value for the variable.) The directory where you installed SPECTRUM (The user supplies a value for the variable.) Courier and Italic in angle brackets (<>) <$SPECROOT> Type the following: DISPLAY=<workstation name>:0.0 export display Navigate to: <$SPECROOT>/app-defaults Solaris and Windows directory paths Unless otherwise noted, directory paths are common to both operating systems, with the exception that slashes (/) should be used in Solaris paths, and backslashes (\) should be used in Windows paths. <$SPECROOT>/app-defaults on Solaris is equivalent to <$SPECROOT>\app-defaults on Windows. On-screen text Courier The following line displays: path= /audit User-typed text Courier Type the following path name: C:\ABC\lib\db Page 5

6 Element Convention Used Example Cross-references References to SPECTRUM documents (title and number) Underlined and hypertextblue Italic See Document Feedback [page 6]. SPECTRUM Installation Guide (0675) Document Feedback Please send feedback regarding SPECTRUM documents to the following address: Thank you for helping us improve our documentation. Online Documents SPECTRUM documents are available online at: Check this site for the latest updates and additions. Page 6

7 SPECTRUM s Integration The SPECTRUM integration allows you to monitor processes and log files on third-party servers. This section gives an overview of this functionality. In This Section Overview [page 7] SPECTRUM s Model Type [page 8] Process Monitoring [page 9] Log File Monitoring [page 11] Overview Aprisma Management Technologies is pleased to announce a technology partnership with SNMP Research International (SRI), a leading provider of SNMP agent technology. Aprisma is leveraging this technology partnership within SPECTRUM to provide an industry proven solution to system and application monitoring. The power of the solution combines SNMP Research International s agent technology with SPECTRUM s industry leading, patented, analytics engine. This combination provides a robust solution for customers looking to cost effectively monitor critical systems and applications. This solution is available as of SPECTRUM version 6.6 SP6. The intent of this user guide is to provide a detailed understanding of how to leverage SPECTRUM for system and application monitoring. The majority of the guide focuses on the configuration of the SPECTRUM integration. Additional information is provided regarding the configuration of the SNMP Agent component of solution. For more a detailed understanding of the SNMP Agent component, users should refer to the SNMP Research International documentation. SNMP Research International refers to the SNMP Agent as CIAgent. There are several guides available that address different aspects of the agent s configuration. The SNMP Research International documentation is part of the SNMP agent installation and can be found in the /Snmpri/C/Doc directory on the server where the SNMP agent has been installed. Page 7

8 SPECTRUM s Model Type SPECTRUM s model type (Figure 1) is used to model and manage servers that are running software as a part of SPECTRUM s integration. This guide refers to these servers as servers. The software is compatible with the following operating systems: FreeBSD, HP/UX, Linux, Solaris, Windows NT, Windows XP, and Windows The model type includes the standard functionality for managing host devices that is included in a SPECTRUM s Generic Host model type (see the SPECTRUM Generic Host (1570) guide for information on this functionality). SPECTRUM s integration gives the model type the following additional functionality: Process Monitoring The model type can monitor processes running on the server and can be configured to generate an alarm under certain circumstances. This functionality is documented in the Technology Applications (5065) guide. Log File Monitoring The model type, used in conjunction with the software on the server, can monitor log files including Syslog files and application log files. The software can be configured to send SNMP traps to the SpectroSERVER based on the content of a log file entry. You can configure event and alarm processing based on this trap generation. Figure 1: Model Type Page 8

9 Process Monitoring Process monitoring functionality is available if the server supports the RFC2790 MIB or if the software is installed on the server. If your device supports the RFC2790 MIB but does not have the software running on it, the device is modeled in SPECTRUM using the appropriate host model type. If you have installed the software on the device, it is modeled using SPECTRUM s model type. In both cases, the device model will have an application model of type rfc2790app. You can access the process monitoring functionality either directly from this application model or from the model. You can configure the process monitoring functionality to generate SPECTRUM alarms that alert you when the process starts, stops, exceeds a maximum number of instances, or goes below a minimum number of instances. Each time you configure a process to be monitored, the process appears in the process monitoring table in the Process Monitor view. Additionally, SPECTRUM creates a Process model to represent all instances of this process. You can specify that alarms generated for the process be sent to the application model. Process models have enhanced functionality that allows them to be moved from the application view of the device model and moved into a container model such as the Service_Owns container model available in the Org- Chart/Services view. This functionality can be used to group appropriate Process models together to monitor a service. Alarms on any of the Process models contribute to the roll up condition of the container model. For further information on using the Service_Owns container model, see How to Manage Your Network with SPECTRUM (1909). You can use the log file monitoring functionality, available to servers with the software installed, to further enhance process monitoring. The software can be configured to monitor application logs and send traps to SPECTRUM based on the content of the log. You can configure SPECTRUM to generate an event based on this trap on the Process model. Figure 2 illustrates the process monitoring architecture. Note: Process monitoring is fully documented in the Technology Applications (5065) guide. Page 9

10 Server Figure 2: Process Monitoring The server must support RFC2790 or must be running the software. The server should be modeled in SPECTRUM using the appropriate host model type. If the server is running the IAGENT software, the model type should be used. Spectro SERVER SPECTRUM creates a Process model for each application that is being monitored. These Process models can be copied from the Application view and pasted into container models to be managed as part of a service or other network group. RFC2790 s Process Monitor view shows all processes running on the server and allows you to add processes to be monitored. Page 10

11 Log File Monitoring In general, log files can be defined as text files that are updated periodically with status or error information about network devices or applications. The log file monitoring functionality monitors application log files, certain Syslog log files, and SPECTRUM-generated log files for userspecified strings. Syslog files conform to a known format and contain information from multiple network devices. Application logs generally have a proprietary format and contain information from one or more processes. Spectrum-generated log files usually contain a model handle referencing the device model that generated the information. When a matching string is found in a new log file entry, the software generates an SNMP trap. The trap contains the source IP address of the server, but the log file entry sent with the trap contains the log file name and original source IP address or model handle. The trap is sent to the SpectroSERVER, where the model that represents the server receives the trap. The trap is mapped to a SPECTRUM event, which is asserted on the model. SPECTRUM s built-in intelligence parses the log file entry information received in the trap and determines the source of the log file entry using the IP address, SPECTRUM model handle, or application log file name. If the log file entry contains a model handle or an IP address, SPECTRUM routes an event to the matching device model. If the source of the log file entry is an application, SPECTRUM can assert the event on a Process model. A user-defined mapping determines the appropriate Process model to assert the event on. If the log file entry found in the trap conforms to the supported Syslog format, SPECTRUM looks for a user-defined Parsemap file specific to the log file entry. The ParseMap file creates a customized event that is asserted on the appropriate model. The Parsemap file may also assign variable values to portions of the log file entry text. The variables can be exposed in the event message for this event. You can configure SPECTRUM to generate alarms based on the generated events and you can use the power of SPECTRUM s Event Rules to generate alarms based on the values of variable bindings sent with the traps. Event Rules can also be used to generate alarms based on frequency, sequence, and duration of the traps sent from the log file. Page 11

12 Figure 3 illustrates the log file monitoring architecture. Server Log file Software Figure 3: Log File Monitoring The software can be configured to monitor log files for certain text strings. When those text strings are found, a trap is generated and sent to the SpectroSERVER. Spectro SERVER The server should be modeled in SPECTRUM using the model type. The model receives the trap and an event is generated on the model. SPECTRUM s built-in intelligence extracts the information source from the log file text. The source can be an IP Address, SPECTRUM model handle, or application. If the log file entry found in the trap conforms to the supported Syslog format, SPECTRUM looks for a user-defined Parsemap file to create a customized event. Parsemap file If the source is an application, and you have matched a Process model to this application, SPECTRUM generates an event on the Process model. If the source is an IP Address or SPECTRUM model handle, SPECTRUM asserts an event on the appropriate device model. Page 12

13 Setting Up the Server and the SPECTRUM Environment This section provides instructions on how to setup the Server and the SPECTRUM environment before configuring Log File Monitoring. In This Section Basic Steps Required to Configure the Server [page 13] Modeling the Server with SPECTRUM [page 16] Modeling Devices with SPECTRUM [page 16] Modeling Processes with SPECTRUM [page 16] Basic Steps Required to Configure the Server Before configuring the software to monitor log files, you must configure the server to send traps to the SpectroSERVER. To do this, you must modify the s snmpd.cnf configuration file. The following steps instruct you on how to make these modifications. 1. If you are working in the Solaris environment, log on as root and navigate to the /etc/srconf/agt directory. If you are working in the Windows environment, navigate to the C:\etc\srconf\agt directory. 2. Locate the snmpd.cnf file. By default, there should be a backup of this file called snmpd.bak in this directory. If this backup copy does not exist, make a backup copy of snmpd.cnf in case you need to restore the original configuration. 3. Using a text editor, open the snmpd.cnf file. 4. Find the snmpnotifyentry section, which includes the following text: # The snmpnotifytable selects snmptargetaddrtable entries # to receive traps or informs. # #Entry type: snmpnotifyentry Page 13

14 #Format: snmpnotifyname (text) # snmpnotifytag (text) # snmpnotifytype (trap(1), inform(2)) # snmpnotifystoragetype (nonvolatile, permanent, readonly) snmpnotifyentry Traps TrapTag trap nonvolatile snmpnotifyentry Informs InformTag inform nonvolatile 5. Delete the line that reads: snmpnotifyentry Informs InformTag inform nonvolatile 6. Change the line that reads: snmpnotifyentry Traps TrapTag trap nonvolatile to: snmpnotifyentry Spectrum Spectrum trap nonvolatile 7. Find the snmptargetaddrentry section, which contains the following text: snmptargetaddrentry localhostv1 snmpudpdomain : TrapTag \ v1exampleparams nonvolatile : snmptargetaddrentry localhostv2c snmpudpdomain : InformTag \ v2cexampleparams nonvolatile : Modify the first snmptargetaddrentry entry to: snmptargetaddrentry Spectrum snmpudpdomain <IPAddress_of_SpectroSERVER>: Spectrum \ v1exampleparams nonvolatile :0 9. Find the snmpnotifyfilterprofileentry section, which contains the following text: #Entry type: snmpnotifyfilterprofileentry #Format: snmptargetparamsname (text) # snmpnotifyfilterprofilename (text) # snmpnotifyfilterprofilestoragetype (nonvolatile,permanent,readonly) snmpnotifyfilterprofileentry v1exampleparams wellknowntraps nonvolatile Page 14

15 10. Delete the line that reads: snmpnotifyfilterprofileentry v1exampleparams wellknowntraps nonvolatile 11. Find the snmpnotifyfilterentry section, which contains the following text: #Entry type: snmpnotifyfilterentry #Format: snmpnotifyfilterprofilename (text) # snmpnotifyfiltersubtree (OID) # snmpnotifyfiltermask (octetstring) # snmpnotifyfiltertype (included, excluded) # snmpnotifyfilterstoragetype (nonvolatile, permanent, readonly) snmpnotifyfilterentry wellknowntraps snmptraps - included nonvolatile 12. Delete the line that reads: snmpnotifyfilterentry wellknowntraps snmptraps - included nonvolatile 13. Save the changes you have made to this file. 14. From the command line stop and restart the master agent: #ciagent stop /usr/local/ciagent/ #ciagent start /usr/local/ciagent/ Page 15

16 Modeling the Server with SPECTRUM In order for SPECTRUM to receive and process the traps sent from the server, you must model the server in SPECTRUM using the model type. If you use SPECTRUM s AutoDiscovery, this model is created automatically during the discovery process. You can also model the server manually using SPECTRUM s Model by IP or New Model commands. These options are found in the Edit menu of the Topology view when you are in Edit mode. See How to Manage Your Network (1909) with SPECTRUM for instructions on creating models manually. Modeling Devices with SPECTRUM Once you have modeled the server, you should also model all devices that send data to the log file on the server. When a trap is sent from the server, an event is asserted on the device model that represents the source of the log file entry. You can model devices using AutoDiscovery or with SPECTRUM s New Model command. See How to Manage Your Network (1909) with SPECTRUM for instructions on creating models manually. Modeling Processes with SPECTRUM If you will be using the log file monitoring to monitor application logs, you must configure the model to monitor each of these applications as a process. For instructions on doing this, see the section that discusses Process Monitoring in the RFC2790 section of the Technology Applications (5065) guide. Once you have configured the model to monitor processes, SPECTRUM automatically creates Process models to represent each of the monitored processes. The models are displayed by default in the s application view as shown in Figure 4. These models can receive events based on traps sent by the server. Additionally, they can be copied and pasted into container models such as the Service_Owns container model used to represent a particular network service. Page 16

17 Figure 4: Process Monitor Models Process Models Page 17

18 Configuring the Software to Monitor Log Files This section provides instructions on configuring the software to generate traps based on text found in a log file. In This Section Configuring the Log File Monitor [page 18] Log File Syntax [page 19] Creating a Log File Monitor Entry to Trigger a Trap [page 20] Editing a Log File Monitor Entry [page 23] Deleting a Log File Entry [page 23] Configuring the Log File Monitor You may have various devices on your network that send data to a log file on the server, or you may have applications on the server that send data to a log file. In either case, the software can be configured to monitor the log files and generate an SNMP trap based on the content found in a log file entry. The log file that you are monitoring will have a syntax that is dependent on the type of log file and the data being sent to the log file. Because application logs files are matched directly to the application you are monitoring, no special log file syntax is required (see Processing Traps that Contain an Application Log File Name [page 28]). However, SPECTRUM processes log files that gather data from other devices differently. Therefore, these log file entries must follow certain syntax criteria outlined in the Log File Syntax [page 19] section. Once you have reviewed the log file syntax, you must decide which log file entries should trigger a trap. Log file entries that provide critical information about a device s ability to function on the network or about an application s ability to perform are usually good candidates. The Creating a Log File Monitor Entry to Trigger a Trap [page 20] section explains how to configure the to monitor log files for strings of information that will generate a trap. Page 18

19 Note: The software can only monitor log files that exist on the server. It cannot monitor log files on a mapped network drive. Log File Syntax You can use the software to monitor application logs or log files that receive data from other devices, such as Syslog files. No special syntax is required for log files that monitor application logs. However, in order for SPECTRUM to assert the trap information on the appropriate device model, log files that receive information from devices on the network must have the following format, which is generally based on the BSD Syslog and Cisco IOS format: <MessagePrefix>%<MessageHeader><Additional_Information> Where: <MessagePrefix> contains the date and time of the message and the IP address of the source of the information contained in the entry. There can be other information interspersed within the prefix, but it must contain these two pieces of information. <MessageHeader> must have the format <A>-<B>-<C> Where: <A> can contain any number of upper case alpha characters, underscores, or the string Aprisma. <B> can contain any number of upper case alpha characters, numeric characters, or underscores. <C> can contain any number of upper case alpha characters, underscores, or dashes. <Additional_Information> can contain any data In general this syntax can be found in the following types of log files: Solaris Syslog file entries from a Cisco or Riverstone device. Solaris Syslog file entries from another type of device that uses the <MessageHeader> format outlined above. Kiwi Syslog file entries from a Cisco or Riverstone device. Kiwi Syslog file entries from another type of device that uses the <MessageHeader> format outlined above. Page 19

20 Aprisma log files, for example those generated by SPECTRUM Report Gateway. Creating a Log File Monitor Entry to Trigger a Trap You can configure the Log File Monitor to send a trap to SPECTRUM based on a regular expression found in a log file entry. You can monitor one or more log files on the Server, however all files must exist locally on the server. Although it is possible to give server access to files on a network drive, the server is not able to monitor network drive based files. You configure the software to search for data within each line of the log file using regular expression syntax. A regular expression is a string of characters which tells the software how to identify the string or strings you are searching for within each line of the log file. The software uses Perl compatible regular expressions. For more information on using Perl regular expressions see Note: All of the Perl regular expression syntax is supported with the exception of the matching qualifiers { and }, and the POSIX character classes. The trap that is generated by the software is in standard SNMP format. The trap header will contain the IP address of the Server that contains the log file. The message portion of the trap will contain the entire line entry from the log file up to 255 characters (as defined by the SNMP protocol). The steps below give step-by-step instructions for configuring the software to monitor a log file for a specific regular expression. You must repeat these instructions for each regular expression in each log file that you want to monitor. 1. From your SPECTRUM interface, select the SPECTRUM model that represents the server that contains the log file. 2. From the model s Icon Subviews menu, choose the Configuration > LogFile Web Configuration command. SPECTRUM launches your browser and the Log File Monitor Main page shown in Figure 5 is displayed. Page 20

21 Figure 5: Log File Monitor Main Page 3. A log file monitor entry is necessary for each regular expression that you want to search for in a log file. To create a log file monitor entry, choose an integer value that is not already shown in the Index column of the Log File Monitor Table. Enter the integer value into the Create Row field and click on the Create Row button. The Log File Monitor New Entry screen shown in Figure 6 is displayed. The integer value you entered in the Create Row field is displayed as the index number in the Index field. You must now complete the rest of the new entry. 4. Set the polling interval. This is the interval which determines how often the reads any new additions to the log file to see if there is a match to the defined configuration. This polling interval is not known or used by SPECTRUM in any way. 5. Enter the full path to the log file you are monitoring in the Log File Location field. If you are working on an NT server, do not use the \ notation in your path, instead, you can use the \\ or / notation. 6. Enter a basic description of the log file in the Description field. 7. In the Regular Expression to match in Log File field, enter the Perl regular expression that will be used to identify the string that will trigger a trap. Page 21

22 8. The Character Position (within line) to Start Watching and Character Position (within line) to Stop Watching fields can be used to specify specific positions in the line to search for the regular expression entered in step 7. These entries are optional. 9. Leave the Command to run on match field empty. 10. Set the value of the Send Trap on Match field to true. 11. Leave the Max Logfile Size (bytes), Command (run after max log file size is reached), and Send Trap on Maximum Logfile Size at their default values. These entries are not supported by the integration. 12. You can fill in the Logfile Owner field with the name of the log file owner. This entry is optional. 13. Set the Operational Status field to Create and Go. 14. Click the Make Changes button to save this new log file monitor entry. Figure 6: Log File Monitor Configuration Page 22

23 Editing a Log File Monitor Entry Each log file monitor entry can be edited if changes to the configuration are necessary. 1. From your SPECTRUM interface, select the SPECTRUM model that represents the server that contains the log file. 2. From the model s Icon Subviews menu, choose the Configuration > LogFile Web Configuration command. 3. SPECTRUM launches your browser and the Log File Monitor Main Page shown in Figure 5 is displayed. 4. Double-click on the folder symbol next to the index number of the log file monitor entry you want to change. 5. The Log File Monitor Entry screen is displayed. 6. Make the appropriate changes. 7. Ensure that the Operational Status field is set to Active. 8. Click the Make Changes button to save the changes to this entry. Deleting a Log File Entry If you no longer want to monitor a log file for a certain regular expression, you can delete the log file monitor entry containing this regular expression. 1. From your SPECTRUM interface, select the SPECTRUM model that represents the server that contains the log file. 2. From the model s Icon Subviews menu, choose the Configuration > LogFile Web Configuration command. 3. SPECTRUM launches your browser and the Log File Monitor Main Page shown in Figure 5 is displayed. 4. Double-click on the folder symbol next to the index number of the log file monitor entry you want to delete. 5. The Log File Monitor Entry screen is displayed. 6. Make sure the Operational Status field is set to Destroy. 7. Click the Make Changes button to save and this entry is removed from the table in the Log File Monitor Main Page. Page 23

24 Configuring SPECTRUM to Process the Trap This section gives you instructions on how to configure SPECTRUM to process the trap information received from the server. In This Section Trap Processing Overview [page 24] Processing Traps that Contain an IP Address or Model Handle [page 24] Creating Parsemap Files [page 25] Processing Traps that Contain an Application Log File Name [page 28] Trap Processing Overview Each trap that the software generates based on the content of a log file entry has the same OID, This OID generates the SPECTRUM event 0x3e00009 based on the trap mapping in the AlertMap file. This event is asserted on the model. The content of each log file entry (up to 255 characters) and the log file name that generated the trap is sent as part of the trap information. SPECTRUM s built in intelligence parses the trap data to determine the original source of the log file entry. The source can be an IP Address, SPECTRUM model handle, or application log file name. Processing Traps that Contain an IP Address or Model Handle If an IP Address or a model handle has been extracted as the source of the log file entry, SPECTRUM can find the device model that matches the IP Address or model handle and assert the event on this model. If the log file entry conforms to the syntax discussed in Log File Syntax [page 19], to make the event asserted on the device model meaningful, you should create a Parsemap file to customize the event and its contents. Page 24

25 If no Parsemap file is created, the event routed to the device model is the same event asserted on the model. Creating Parsemap Files Parsemap files specify the event associated with the information in the incoming trap. In addition, Parsemap files allow you to specify that portions of the log file entry text be used as event variables. If desired, these variables can be used in conjunction with an Event Rule to process the event. See the Event Configuration Files Guide (5070) for instructions on event processing and Event Rules. As discussed in the section on Log File Syntax [page 19], a log file entry has the following parts: <MessagePrefix>%<MessageHeader><Additional Information> SPECTRUM identifies the Parsemap file that will process the trap by finding the Parsemap file whose name matches the text of the <MessageHeader> from the log file entry. For example, Figure 7 shows a sample log file entry: Figure 7: Log File Entry :19:14 Local7.Info Feb 19 09:14:50 %SNMP- I-SENT_TRAP, Sending notification linkup to The <MessageHeader> portion of the entry is SNMP-I-SENT_TRAP. Thus, SPECTRUM will look for a Parsemap file named SNMP-I-SENT_TRAP. Therefore, you must create a Parsemap file for each log entry with a unique <MessageHeader> that you configure to generate a trap. The following steps show you how to create a Parsemap file: 1. Use your favorite text editor to create a new text file. 2. In the first line of the text file, enter the new event file name for the event that you would like to generate. The event file name should begin with Eventffff and end with xxxx where x can be any valid hexadecimal number. For example, Eventffff1A2F and Eventffff1234 are valid event file names. Event012za8b is not. 3. Use the return key to create a new line in the text file. Page 25

26 4. This line contains the <AdditionalInformation> portion of the log file entry. You can specify portions of this text as event variables, which can be used to process the event with an Event Rule. Variables are specified using a data type and an integer. Valid data types are STRING, INTEGER, and IPADDRESS. Figure 8 shows a valid Parsemap file for the log entry show in Figure 7. The variable 1 stores Uplink as a String. The Variable 2 stores as an IP Address. Figure 8: Sample Parsemap File SPECTRUM event file name Eventffff1A2F Sending notification {STRING 1} to {IPADDRESS 2} <Additional Information> portion of the log file These variables are used to store the replaced text. 5. Save the text file in the <$SPECROOT>/SS/CsVendor/Parsemaps directory. The name of this text file should match the <MessageHeader> portion of the log file entry. In this case the file name would be SNMP-I-SENT_TRAP. The file name should not contain a file extension. WARNING! Only the first two lines of the Parsemap file are processed. Do not put a carriage return in the text of the log file. Data after the second carriage return in the file is ignored. Creating an Event Format File Each event code that you specify in a Parsemap file should have a separate Event Format file. When an event is asserted, the text of the Event Format file appears in the Event Log. When create the Event Format file, keep in mind that most of the information the troubleshooter receives about an event comes from the event message text. The Event Format file should be created using a text editor and should be placed in the <$SPECROOT>/SG-Support/CsEvFormat. The Event Format file must be named Event<xxxxxxxx> where <xxxxxxxx> is the event code Page 26

27 given to the event in Parsemap file. For example, if you have an event with an event code of 0xffff1A2F, SPECTRUM will use the Event Format file named Eventffff1A2F. To make the text of the event message meaningful, you can use the variables assigned in the event s Parsemap file as well as the built-in variable available for all Event Format files. For complete instructions on creating an Event Format file, including the built-in variables that are available, see the Formatting an Event Message with Event Format Files section of the Event Configuration Files Guide (5070). Example The following sample Event Format file would be appropriate to use for the event generated by the Parsemap File shown in Figure 8. The IP Address variable is inserted using the data type O (octet) and the variable assigned from the Parsemap file, 1. The device name variable is inserted using the data type s (string) and the variable assigned from the Parsemap file, 2. The built-in variables {d "%w- %d %m-, %Y - %T"}, {m}, {t}, and {e} show the date of the event, model name, model type name, and event ID. Figure 9: Sample Event Message File {d "%w- %d %m-, %Y - %T"} A device {m} of type {t} has reported a problem. Its ip address is {S 1} and the device name is {S 2}. - (event [{e}]) Generating an Alarm Based on the Event You can specify further processing on the event created in the Parsemap file. You can generate an alarm based on the event, or use the event as part of an Event Rule. To do this, determine all of the model types that this event could be asserted on and specify the appropriate event processing in each model type s EventDisp file. If you would like the event to be processed the same way for each model type, you can specify the event processing in a global EventDisp file. If you have specified that an alarm should be created based on an event, you must create a probable cause file that will be displayed in SPECTRUM s Alarm Manager when the alarm is asserted. Page 27

28 For complete instructions on EventDisp and probable cause files, see the Event Configuration Files Guide (5070). Apply the Changes to the SpectroSERVER To activate the new or updated Event Format and Parsemap files, you must apply the changes to the SpectroSERVER. This can be done via the Update command found in the Event Configuration Editor, via CLI, or by cycling the SpectroSERVER. See the Event Configuration Files Guide (5070) for complete instructions on each of these methods. Processing Traps that Contain an Application Log File Name If you are using the software to monitor application processes (see Process Monitoring [page 9]), you can also monitor application log files associated with those processes. Note: If you are using the process monitoring functionality available for a device which supports RFC2790, but do not have the software installed, you cannot monitor application logs. You must have the software installed on the third-party server to make use of the log monitoring capabilities. When the software sends a trap generated from entries in an application log file, the name of the log file is sent with the trap information. SPECTRUM extracts the name from the trap and looks for an appropriate Process model to assert the event on. In order for SPECTRUM to find the appropriate Process model, you must affiliate the Process model that represents the application whose log you are monitoring with the application log file name. To add to the flexibility of the configuration process, the association between an application log file name and a Process model can be created before the process or log file monitoring is configured and before the log file exists. To do this: Note: If the application log file entry conforms to the syntax discussed in Log File Syntax [page 19], you can use a ParseMap file to customize the event sent to the Process model. See Creating Parsemap Files [page 25] for instructions. Page 28

29 1. Highlight the model that represents the server containing the application log. 2. Right click on the model and select Log/Process Association(s). 3. The Log Monitor view shown in Figure 10 appears. This view shows two tables, the Log File Monitoring table and the Current Log Monitors Table. The Log File Monitoring table shows any associations between log files and Process models that have been established. The path and log file are shown in the Log File Name column and the Process model is shown in the Send Events to Models with Process Name column. The Current Log Monitors table shows the configuration for all of the application log files that are currently being monitored by the software. Figure 10: Log Monitor View 4. To create a new association, click the Associate a Log File to a Process button. The view show in Figure 11 appears. Page 29

30 Figure 11: Associate a Log File with a Process 5. Enter the complete path and name of the log file in the Log File Name field. 6. Enter the name of the process in the Process Name field. 7. Click OK. Once this association has been correctly made, all events that are generated based on information from this application s log file will be asserted on the Process model specified. WARNING! Since SPECTRUM does not verify the log file name or process name, no error message is displayed if this information is entered incorrectly. Page 30

31 The Flow of Events in SPECTRUM Each scenario below describes how SPECTRUM generates events when a trap is received from the server. Each scenario identifies a different SPECTRUM configuration that causes the event flow to change. In This Section Scenario 1: Correct Configuration for Monitoring a Log File [page 31] Scenario 2: Correct Configuration for Monitoring an Application Log File [page 32] Scenario 3: Missing Model [page 32] Scenario 4: Missing Application Process Model Match [page 33] Scenario 5: Missing Parse Map File [page 33] Scenario 6: Invalid Parse Map [page 34] Scenario 7: Unknown Message Header Format [page 35] Scenario 8: Missing Device Model [page 35] Scenario 9: Missing Parse Map and Device Model [page 36] Scenario 1: Correct Configuration for Monitoring a Log File The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. This event is not logged on the model, it is used as a mechanism for routing further event information. The event is then processed by SPECTRUM s internal intelligence and a source IP address or SPECTRUM model handle for the log file entry is found. The log file text is extracted and the message header conforms to one of the appropriate standards. A valid, matching Parsemap file is found. The Parsemap file parses the log file message and assigns a SPECTRUM event code to the message. Variables are also assigned. Page 31

32 The event is asserted on the device model whose IP address or model handle matches the source IP address or model handle. The event is processed per the instructions in the device model s EventDisp file. Scenario 2: Correct Configuration for Monitoring an Application Log File The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. This event is not logged on the model, it is used as a mechanism for routing further event information.the event is then processed by SPECTRUM s internal intelligence and a source log file name for the log file entry is found. SPECTRUM determines that a Process model has been mapped to this application log file name. The 0x3e00009 event is asserted on the matching Process model. Scenario 3: Missing Model The SpectroSERVER receives a trap from the server, but there is no model to receive and process the trap. Event 0x is asserted on the VNM Model. It will have an event message similar to the following sample: Wed 17 Mar, :15:34 - Trap 6.2 received from unknown SNMP device with IP address and community string ' /public'. Trap identifier (event [0x ]) Trap var bind data: OID: Value: /data/syslog OID: Value: Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SiS-5- CONFIG_I: Configured from console by vty0 ( ) Page 32

33 Scenario 4: Missing Application Process Model Match The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. The event is then processed by SPECTRUM s internal intelligence and a source log file name is found. SPECTRUM determines that a Process model has been mapped to this application log file name. The 0x3e00009 event is asserted on the matching Process model. Scenario 5: Missing Parse Map File The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. The event is then processed by SPECTRUM s internal intelligence and a source IP address or SPECTRUM model handle for the log file entry is found. The log file text is extracted and the message header conforms to one of the appropriate standards. However, a valid, matching Parsemap file is not found. Event 0x3e00009 is asserted on the model with an event message similar to the following example: Thu 18 Mar, :06:37 The following text was matched by an in file "/data/syslog". (name - Test). - (event [0x03e00009]) "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SUS-5-CONFIG_I: Configured from console by vty0 ( )" Event 0x d is generated on the Device model whose IP address has been found in the event. The event will have a message similar to the following example: Thu 18 Mar, :06:37 The following text was matched by the on host in file /data/syslog: "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SUS-5-CONFIG_I: Configured from console by vty0 ( )" Page 33

34 No Varbind Map named "SUS-5-CONFIG_I" could be found. No additional varbinds are available. Rtr_Cisco (name ). - (event [0x d]) Scenario 6: Invalid Parse Map The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. The event is then processed by SPECTRUM s internal intelligence and a source IP address or SPECTRUM model handle for the log file entry is found. The log file text is extracted and the message header conforms to one of the appropriate standards. A matching Parsemap file is found. However, the syntax in the Parsemap file is not valid and the message cannot be parsed by the Parsemap definition: Event 0x3e00009 is asserted on the model with an event message similar to the following example: Thu 18 Mar, :08:27 The following text was matched by an in file "/data/syslog". (name - Test). - (event [0x03e00009]) "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SYS-5-CONFIG_I: Not Configured from console by vty0 ( )" Event 0x a is generated on the device model with an event message similar to the following example: The received string: "NotConfiguredNOT from console by vty0 ( )" does not match the format defined in the Parse Map file SYS-5- CONFIG_I:"Configured from {STRING 1} by {STRING 2} ({IPADDRESS 3}) " If you are unable to resolve the mismatch please contact Customer Support and provide all information in this event. Regular Expression: "(?C0)([\s]*)(Configured from )(?C1)([\s]*)([ a-za-z-\t\/\.0-9\(\)=,\\\ \[\^\$\*\+\?\.}]+)(?C2)([\s]*)( by )(?C3)([\s]*)([ a-za-z-\t\/\.0-9\(\)=,\\\ \[\^\$\*\+\?\.}]+)(?C4)([\s]*)( \ ()(?C5)([\s]*)([0-2]*[0-9]*[0-9]+\.[0-2]*[0-9]*[0-9]+\.[0-2]*[0-9]*[0-9]+\.[0-2]*[0-9]*[0-9]+)(?C6)([\s]*)(\) )(?C7) " Page 34

35 The error occurred after the symbol (?C0) and before the symbol (?C1) on substring "NotConfiguredNOT from console by vty0 ( )". See the contents of the Message Map file SYS-5-CONFIG_I. Rtr_Cisco (name ). - (event [0x a]) Scenario 7: Unknown Message Header Format The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. The event is then processed by SPECTRUM s internal intelligence and a source IP address or SPECTRUM model handle for the log file entry is found. The log file text is extracted, but the message header does not conform to one of the appropriate standards. Event 0xe0000d is asserted on the model with an event message similar to the following example: Tue 16 Mar, :07:31 A matching string, "Mar 16 15:07: Kiwi Syslog Daemon - Test message number 0005", has been found in the file "C:\Program Files\Syslogd\Logs\ SyslogCatchAll.txt". (name ). - (event [0x03e00009]) Matched String: Mar 16 15:07: Kiwi Syslog Daemon - Test message number 0005 Found in file: C:\Program Files\Syslogd\Logs\ SyslogCatchAll.txt Scenario 8: Missing Device Model The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. The event is then processed by SPECTRUM s internal intelligence. However a source IP address or SPECTRUM model handle for the log file entry is not found. Event 0x3e0000d is asserted on the model with an event message similar to the following example: Thu 18 Mar, :53:26 The following text was matched by an in file "/data/syslog". (name - Test). - (event [0x03e00009]) Page 35

36 "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SYS-5-CONFIG_I: Configured from console by vty0 ( )" Event 0x03dc0000 is also asserted on the model with an event message similar to the following example: Thu 18 Mar, :53:26 - Device Test of type - Error processing event 0x3e Details: No model with a Network Address of could be found. The text "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SYS-5-CONFIG_I: Configured from console by vty0 ( )" could not be routed to the model. (event [0x03dc0000]) Event 0x b is also asserted on the model with an event message similar to the following example: Thu 18 Mar, :53:26 - An event occurred for model 'Test' of type '' for which no event format file exists. (event [0x b]) Scenario 9: Missing Parse Map and Device Model The SpectroSERVER receives a trap from the server. The model receives the trap and the trap is mapped to the event 0x3e00009, which is asserted on the model. The event is then processed by SPECTRUM s internal intelligence and a source IP address or SPECTRUM model handle for the log file entry is found. The log file text is extracted and the message header conforms to one of the appropriate standards. A valid, matching Parsemap file is not found. In addition, no device model is found for the extracted IP Address or model handle. Event 0x3e0000d is asserted on the model with an event message similar to the following example: Thu 18 Mar, :04:37 The following text was matched by an in file "/data/syslog". (name - Test). - (event [0x03e00009]) "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SUS-5-CONFIG_I: Configured from console by vty0 ( )" Event 0x03dc0000 is also asserted on the model with an event message similar to the following example: Page 36

37 Thu 18 Mar, :04:37 - Device Test of type - Error processing event 0x3e Details: No model with a Network Address of could be found. The text "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SUS-5-CONFIG_I: Configured from console by vty0 ( )" could not be routed to the model. (event [0x03dc0000]) Event 0x d is also asserted on the model with an event message similar to the following example: Thu 18 Mar, :04:37 The following text was matched by the on host in file /data/syslog: "Mar 15 12:11:59 [ ] 107: *Mar 15 03:48:07.768: %SUS-5-CONFIG_I: Configured from console by vty0 ( )" No Varbind Map named "SUS-5-CONFIG_I" could be found. No additional varbinds are available. (name - Test). (event[0x d]) Page 37

38 Troubleshooting This section describes some common problems you may encounter when working with the integration. In This Section MIB-II Data is Missing in the Windows Environment [page 38] Services are Missing or Do Not Run in the Windows Environment [page 38] Incomplete Information in the Solaris Environment [page 39] MIB-II Data is Missing in the Windows Environment When installing and running the software in the Windows environment, make sure that the Windows SNMP agent is installed, but not running. Instructions on configuring this can be found in the Windows Installation instructions in the SNMP Research International documentation. This documentation can be found in the /Snmpri/C/Doc directory on the server where the SNMP agent has been installed. If the Windows SNMP agent is not configured in this way, you may find that MIB-II data, such as IF, IP, ICMP, TCP, UPD, and SNMP information, is missing from various SPECTRUM views. To resolve this scenario, un-install the software and reinstall it using the Windows SNMP agent configuration instructions found in the SNMP Research International documentation. Services are Missing or Do Not Run in the Windows Environment When installing the software in the Windows environment, the Windows machine must have a c:\temp directory. This information can be found in the SNMP Research International documentation located in the /Snmpri/C/Doc directory on the server where the SNMP agent has been installed. Page 38

39 If the Windows machine does not have a c:\temp directory, the installation appears to be successful. However, the services are not present, or, if they are present, do not run. To resolve this problem, un-install the software and create a c:\temp directory before re-installing. Incomplete Information in the Solaris Environment If you are working in the Solaris environment, be sure to install the proper Solaris version of the software. If you are running the 64-bit kernel (even if you are running in 32-bit mode), you must install the 64-bit version of the software. If you are running the 32-bit kernel, you must install the 32-bit version of the software. If the incorrect Solaris version is installed, certain counters which need kernel information will not be populated. This includes the process table, which is found in the Process Monitor view of the model. Page 39

40 Case Study: Monitoring a Syslog File The following case study shows you how to configure the integration to handle a common configuration problem involving two switches. SPECTRUM s standard fault management would not detect this problem, called a duplex mismatch. However, you can configure the integration to monitor the Syslog file that would receive an error about the duplex mismatch and configure SPECTRUM s event processing to generate an appropriate event message and alarm when this error is generated. In This Section Error Scenario [page 40] Configuration Prerequisites [page 42] Configuring the Log File Monitor Entry [page 42] Creating the Parsemap File [page 43] Creating the Event Format File [page 45] Modifying the EventDisp file to Generate an Alarm [page 46] Apply the Changes to the SpectroSERVER [page 47] Error Scenario The following paragraph from a Cisco Document, on Spanning Tree Protocol (see concisely explains a duplex mismatch scenario and the problems that can occur as a result: Duplex mismatch on a point-to-point link is a very common configuration error. This occurs especially when one side of the link is hard-coded full-duplex. If you leave the other side in auto-negotiation mode, it ends up in half-duplex. (A port with duplex hard-coded does not negotiate any more.) Page 40

41 Figure 12: Duplex Mismatch The worst-case scenario is when a bridge sending BPDUs is configured for half-duplex on a link, but its peer is configured for full-duplex. In the above example, the duplex mismatch on the link between bridge A and B can easily lead to a bridging loop. Because B is configured for full-duplex, it does not perform carrier sense when accessing the link. B then starts sending frames even if A is already using the link. This is a problem for A, which detects a collision and runs the backoff algorithm before attempting another transmission of its frame. The result is that, if there is enough traffic from B to A, every single packet (including the BPDUs) sent by A is deferred or collisioned and eventually dropped. From an STP point of view, because it does not receive BPDUs from A any more, bridge B has lost its root. This leads B to unblock its port to C, hence creating the loop. Given the results of the worst-case scenario explained above, it is clear why you may want to monitor a Syslog file for a duplex mismatch error message. The following sections walk you through how to monitor the log file and process the resulting events in SPECTRUM. Page 41

42 Configuration Prerequisites This case study assumes the following: The software has been installed on the Syslog server. The software has been configured to send traps to SPECTRUM (see Basic Steps Required to Configure the Server [page 13]) The server (which is also the Syslog server) has been modeled in SPECTRUM using the model type (see Modeling the Server with SPECTRUM [page 16]) The devices that send data to the Syslog server have also been modeled (see Modeling Devices with SPECTRUM [page 16]). Configuring the Log File Monitor Entry When a duplex mismatch error is detected, an error is logged in the Syslog file. The following is a sample of the type of error message that is logged. Figure 13: Syslog Error Message Jun 2 10:22:00[ ] 11349: Jun 2 10:19:03.086: %CDP-4-DUPLEX_MISMATCH: duplex mismatch discovered on FastEthernet0/1 (not half duplex), with (Cat5000-sllmulti) 1/1 (half duplex). The first step in creating a configuration that monitors for the duplex mismatch error, is to create a log file monitor entry that monitors the log for the text string.*cdp-4-duplex_mismatch.*. When this entry is found in a log file, a trap is sent to SPECTRUM. 1. From your SPECTRUM interface, select the SPECTRUM model that represents the server. 2. From the model s Icon Subviews menu, choose the Configuration > LogFile Web Configuration command. 3. SPECTRUM launches your browser and the Log File Monitor Main page shown in Figure 5 is displayed. 4. Choose an integer value that is not already shown in the Index column of the Log File Monitor Table. Enter the integer value into the Create Row field and click on the Create Row button. Page 42

43 5. Set the polling interval to 5. This is the interval which determines how often, in seconds, the reads any new additions to the log file to see if there is a match to the defined configuration. 6. Enter the full path to the Syslog file in the Log File Location field. In this case the path is /data/syslog. 7. Enter Syslog in the Description field. 8. Enter.*CDP-4-DUPLEX_MISMATCH.* in the Regular Expression to Match in Log File field. 9. Set the Operational Status field to Create and Go. 10. Click the Make Changes button to save this new log file monitor entry. Creating the Parsemap File When an entry is written to the Syslog file that contains the text duplex mismatch, a trap is generated and sent to the SpectroSERVER. SPECTRUM matches the trap s OID with the SPECTRUM event 0x3e00009 based on the trap mapping in the s AlertMap file. The 0x3e00009 event is asserted on the model as shown in Figure 14. Page 43

44 Figure 14: The Event Log of the Model An event is also routed to the device model with this IP address found in the Syslog entry, If no Parsemap file is created, the event routed to the device model is the same event asserted on the model. This is not recommended since it is difficult to configure further event processing based on this event because the event processing would have to apply to each situation where this event is generated. To create a Parsemap file that generates a unique event to be asserted on the device model: 1. Use a text editor to create a new text file. 2. In the first line of the text file, enter the new event code for the event that you would like to generate. In this case, the event code is 0x d. 3. Use the return key to create a new line in the text file. 4. Enter the line of text contained in the <AdditionalInformation> portion of the log file entry and assign variables appropriately. Page 44

45 Event d duplex mismatch discovered on {STRING 1} ({STRING 2}), with {INTEGER 3}({STRING 4}) {INTEGER 5}/{INTEGER 6} ({STRING 7}). 5. Name the text file CDP-4-DUPLEX_MISMATCH and save it in the <$SPECROOT>/SS/CsVendor/Parsemaps directory. The name of this text file should not contain a file extension. Creating the Event Format File You should now create an Event Format file for the event you created in the Parsemap file. This Event Format file should make use of the variables assigned in the Parsemap file. 1. Use a text editor to create a new file. 2. Type the following text into that file: {d "%w- %d %m-, %Y - %T"} The host port {S 1} is {S 2} but the Cisco Discovery Protocol (CDP) reports that this interface is connected to port {I 5}/{I 6} on {S 4} which is configured for half duplex. {t} (name - {m}). - (event [{e}]) 3. Name the file Event d. 4. Save the file in the <$SPECROOT>/SG-Support/CsEvFormat directory. When the event is asserted on the device model, the event message shown in Figure 15 is available in SPECTRUM s event log. Page 45

46 Figure 15: Device Model Event Message Modifying the EventDisp file to Generate an Alarm If you would like the event to generate an alarm on the device model, add the following line to the device model type s EventDisp file located at <$SPECROOT>/SS/CsVendor/Cisco_Router/EventDisp. 0x d E 50 A 1,0x d Additionally, you must create a Probable Cause file to be displayed in SPECTRUM s Alarm Manager. 1. Use a text editor to create a new file. 2. Type the following text into that file: Duplex Mismatch SYMPTOMS: An error has been written to the Syslog server indicating a duplex mismatch. PROBABLE CAUSES: Page 46