EV Observe - Create the Trap Definition Files

Last modified on 2022/08/11 19:16

SNMP traps contain information sent from a monitored host to a monitoring server using the SNMP protocol.

Trap definition files are used to define the actions to be performed when a Box receives an SNMP trap.

  • If an action is defined for the received trap in a trap definition file, it will be run. The trap will be written to a TRAP file with the IP address of the machine that sent it.
  • If no action is defined, the trap will be written to an unknown trap file.
     

You set up monitoring for SNMP traps in the Box using the TRAP-Handle service template.

Notes

  • To use services based on SNMP traps, specific prerequisites must first be met. Open url.png See the detailed procedure.
  • To interpret the events received, the monitoring server must have an MIB file containing the OIDs (message IDs) and their descriptions.
    • Standard MIBs use standardized OIDs.
    • Manufacturers can also define their own MIBs for their host templates. You should retrieve the manufacturer MIB files from the equipment manufacturer.
  • You can create trap definition files manually or automatically using an MIB file.
     

List of files for monitoring SNMP traps

  • /etc/snmp/snmptt.ini: List of trap definition files to be taken into account.
  • /etc/snmp/trapConf/*: List of trap definition files. One action is configured for each trap.
  • /var/log/snmptt/*.trap: File containing the traps received by the Box. There is one file for each server that generates traps.
  • /var/log/snmptt/snmpttunknown.log: List of files containing unknown traps, i.e. unspecified in trap definition files.
     

Purpose of the TRAP-Handle service template

  • It checks the trap log file generated by SNMPTT.

Characteristics of an SNMP trap definition file

  • An SNMP trap definition file is a text file that contains two rows for each event.
    • EVENT row: Description of the type of event, with the name of the event ({Event_name}) and its OID ({Event_OID}).
    • EXEC row: Description of the action to be performed when the trap is received, with the description of the event ({Event_description}). 

EVENT {Event_name} {Event_OID} "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| {Event_description} $1" >> /var/log/snmptt/"$aA".trap
#

  • The trap complies with a specific syntax.
    • Fields in the message written in the trap file are separated using the  |-|.
    • The description written in the third field appears in the Web app via a dataviz.
    • $1 indicates the first variable in the trap.

Examples

Trap definition file for a Juniper SRX host used to capture UP and DOWN events for a network link and Fan Fail events

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link down on interface $1" >> /var/log/snmptt/"$aA".trap
#
EVENT linkUp .1.3.6.1.6.3.1.1.5.4 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link up on interface $1" >> /var/log/snmptt/"$aA".trap
#
EVENT fanDown .1.3.6.1.4.1.2636.4.1.2 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Fan down" >> /var/log/snmptt/"$aA".trap

File containing received traps

 10 10 16:09:32 |-| .1.3.6.1.4.1.2636.4.1.2 |-| Fan down
 11 10 09:05:03 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 11 10 09:05:04 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 12 10 08:05:29 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 12 10 08:06:31 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 12 10 09:37:50 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 12 10 11:25:52 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 13 10 03:27:40 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 13 10 03:27:41 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 13 10 17:05:27 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 13 10 17:05:51 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 14 10 01:06:46 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 14 10 01:06:51 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 14 10 09:07:38 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 14 10 09:07:52 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 14 10 17:08:40 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 14 10 17:08:54 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535
 15 10 01:09:42 |-| .1.3.6.1.6.3.1.1.5.3 |-| Link down on interface 535
 15 10 01:09:55 |-| .1.3.6.1.6.3.1.1.5.4 |-| Link up on interface 535

Best Practice

  • To find out more about the variables in host traps, see the relevant MIB description.
  • To display all of the variables in a trap, use the instruction $*.

Procedure: How to create an SNMP trap definition file

Note: To use services based on SNMP traps, specific prerequisites must first be met.
     Open url.png See the detailed procedure

Step 1: Create trap definition files to define the actions to be performed when an SNMP trap is received

Manual creation of the trap definition file

1. Create a trap definition file.

  • Log in to the Box.
  • Run the commands below.

cd /etc/snmp/trapConf
vim myTrapDef.conf

2. Specify the information on the new event.

  • Add the rows below to the file.
    Replace:
    • {Event_name} with the name of the event Caution: Do not insert any spaces in the name.
    • {Event_OID} with the OID of the event as specified in the MIB file

EVENT {Event_name} {Event_OID} "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link down on interface $1" >> /var/log/snmptt/"$aA".trap
#

example  

EVENT linkDown .1.3.6.1.6.3.1.1.5.3 "Status Events" INFORMATIONAL
EXEC echo "$x$X |-| $o |-| Link down on interface $1" >> /var/log/snmptt/"$aA".trap
#

Automatic creation of the trap definition file

1. Generate the trap definition file automatically using an MIB file.

snmpttconvertmib --in=path_to_mib --out=file_to_create --exec='echo "$x$X |-| $o |-|" >> /var/log/snmptt/"$aA".trap

example  

snmpttconvertmib --in=/usr/share/snmp/mibs/STORMSHIELD-ALARM-MIB.mib --out=stormshield.conf --exec='echo "$x$X |-| $o |-|" >> /var/log/snmptt/"$aA".trap'

2. Copy the file to the folder called /etc/snmp/trapConf.

3. Run the command below to restart the snmptt service.

systemctl restart snmptt

4. Check that the trap is correctly received.

  • Run the command below in the Box to generate a trap for itself.
    Remplacez :
    • {Event_OID} with 
    • {Community_name} with

snmptrap -c {Community_name} -v 2c 127.0.0.1 "" {Event_OID}

example  

snmptrap -c coservit -v 2c 127.0.0.1 "" .1.3.6.1.6.3.1.1.5.3

  • Check that a file called snmptt/127.0.0.1.trap is successfully created in the /var/log/ folder and that it contains the trap.
     

Step 2: Use a trap definition file

1. Run the commands below to open the snmptt.ini configuration file.

vim /etc/snmp/snmptt.ini

2. Run the command below to add the path of the trap definition file to the [TrapFiles] section at the end of the file.

Caution : Remember to add instructions <<END and END.

snmptt_conf_files = <<END
/etc/snmp/trapConf/linkState.conf
/etc/snmp/trapConf/myTrapDef.conf
/etc/snmp/trapConf/anOtherDef.conf
END

3. Run the command below to restart the snmptt service.

systemctl restart snmptt

 

Step 3: Set up monitoring for SNMP traps in the Box using the TRAP-Handle service template

1. Go to the Web app.

2. Create a new service template.

  • Select  Configuration > Services > List in the menu.
  • Click + Add in the Mode: Box tab. 
  • Specify the information below.

General information tab
         TRAP-Handle configuration.png

  • Service template: Select the TRAP-Handle service template.
  • Name: Enter the name of the new service to be created. Its name should correspond to the event to be captured.

    example Link Down

Availability and checks tab
         TRAP-Handle configuration - Availability and checks tab.png

  • Output text: Enter the value $3 corresponding to the third field in the EXEC row of the trap.
  • Critical pattern: Specify the OID indicating the critical status of an event.
  • OK pattern: Specify the OID indicating the correct status of an event.
  • Click Validate.
  • The *TRAP file of the monitored host is read every minute.
  • The plugin will read each new row added since the last control to check the presence of one of patterns configured in the service. It will then return the corresponding status. 
  • Note: The pattern taken into account is the one for the last trap received.
Tags:
Powered by XWiki © EasyVista 2022