Prerequisites
Before using this document, the reception of traps must be configured on the SNB. See procedure : 1 - Configure the box to receive traps
Purpose of this document
This document is intended for anyone (customer or consultant) who wants to add a trap definition file to define the actions to be taken in case of reception.
Configuration files
- /etc/snmp/snmptt.ini -> snmptt configuration, will be used to indicate the trap definition files to be taken into account.
- /etc/snmp/trapConf/* -> trap definition files. For each trap an action is configured.
- /var/log/snmptt/*.trap -> one file per server generating traps; file where traps received by the box are stored.
- /var/log/snmptt/snmpttunknown.log -> file where the unknown traps will be located, traps not specified in a definition file.
Principles
When a trap is received, the box will check in the definition files in snmptt.ini if an action is defined when the event is received.
- If so, the action specified in the definition file will be executed. This action will be to write the trap
received in a *.trap file where * will be replaced by the IP address of the machine that sent the trap. - If not, the trap will be written to the unknown traps file (/var/log/snmptt/snmpttunknown.log)
Create a trap definition file
Manual creation
Connect to the box that collects the traps.
Go to the /etc/snmp/trapConf folder:
cd /etc/snmp/trapConf
Create a definition file :
vim myTrapDef.conf
After analysis of the MIB of the equipment.
For each trap you want to process you have to add 2 lines:
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 #
The parts in red are the only things that can be modified. The rest is to be written as is.
The first line "EVENT" will describe the type of event. The name of the event should be put in one word and
the oid of the trap.
The second line "EXEC" will describe the action to be taken when the trap is received. Here the trap will be written to a file.
It will be formatted in a specific way. The fields of the message written in the file must be separated by the |-| separator.
The sentence written in the 3rd field will be the one displayed in the plugin output on the web interface.
In the example, the variable $1 is the first variable of the trap. To know the variables contained in the traps of a device, we must analyze its MIB.
If we want to display all the variables of the trap, we will use $*.
Example
A definition file for a Juniper SRX device that will capture UP and DOWN traps from a network link and a Fan Fail trap:
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
Here is the file where the received traps are written:
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
Automatic creation with snmpttconvertmib
It is possible to generate the definition file automatically, from a MIB file.
Ordering :
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
Place the generated file in /etc/snmp/trapConf
Restart the snmptt service:
systemctl restart snmptt
Test trap reception:
Generate a trap from the box for itself:
Retrieve an existing OID from the previously generated definition file. Put in place of "OID" in the
order below.
snmptrap -c -v 2c 127.0.0.1 "" Example:
snmptrap -c coservit -v 2c 127.0.0.1 "" .1.3.6.1.6.3.1.1.5.3
A file /var/log/snmptt/127.0.0.1.trap must be created and must contain the trap.
Using the definition file
Edit the file /etc/snmp/snmptt.ini
vim /etc/snmp/snmptt.ini
At the end of the file, in the [TrapFiles].
Add the path to the definition file :
Note :
Be careful to keep the structure of the lines below.
The <<END and END must be positioned as in the example:
snmptt_conf_files = <<END /etc/snmp/trapConf/linkState.conf /etc/snmp/trapConf/myTrapDef.conf /etc/snmp/trapConf/anOtherDef.conf END
Restart the snmptt service:
systemctl restart snmptt
Instantiate a checkpoint in ServiceNav
Create a checkpoint with the TRAP-Handle model
Every minute, the plugins will read in the *.trap file of the monitored machine.
For each new line that appears since the previous check, the plugin will look to see if it finds one of the patterns set
as a parameter and will return the status according to it. It is the pattern of the last trap received that will be taken into account.