As mentioned above, the program must actively report exceptions. snmp provides the notification mechanism to implement this function. The procedure is as follows:
1. Start from the MIB file:
Add the following content in the file "/usr/local/share/snmp/mibs/FIGURE-IT-MIB.txt:
1 recordNotification NOTIFICATION-TYPE
2 OBJECTS { recordTrapsEntry }
3 STATUS current
4 DESCRIPTION
5 "Record's notifications "
6 ::= { record 2 }
7
8 recordTrapsEntry OBJECT-TYPE
9 -- SYNTAX SnmpAdminString
10 SYNTAX OCTET STRING (SIZE(1..512))
11 MAX-ACCESS accessible-for-notify
12 STATUS current
13 DESCRIPTION
14 "Record's notifications entery."
15 ::= { recordNotification 1 }
Run the snmptranslate-IR-Tp record command to check whether the mib file is correctly added.
2. Use mib2c to generate code:
# Sudo mib2c-c mib2c. Y. conf FIGURE-IT-MIB: recordNotification
The generated code, as shown in the following example, has some minor problems.
In fact, it is a function: send_recordNotification_trap (), which we use to send the trap message.
I made some minor changes to it: I added a string parameter so that we can send different messages.
3. Add the code to the project and call send_recordicationication_trap () When trap needs to be sent ().
4 .【Important!]
Modify the configuration file:/usr/local/share/snmp/Record. conf
Make sure that the following content is included:
trapsink localhost public
Otherwise, no traps will be sent even if the send_recordNotification_trap () function is called. I tested it for a long time and never sent it successfully. It is OK after this line is added.
This is described in the snmp faq:
"If this file contains 'trapsind', then the agent will send an SNMPv1 trap. if this file contains 'trap2sind', then the agent will send an SNMPv2c trap. and if this file contains both, then the agent will send * two * copies of this trap."
5. Receive trap messages:
(1) Modify/usr/local/share/snmp/snmptrapd. conf as follows:
1 authcommunity execute, log, net public # Set access permissions for all users: executable, record, and pass
2 # traphandle default log_it # receives the trap action. You can leave it unspecified.
(2) # sudo snmptrapd-d-f-Lo
If the output is similar to the following, it means that the trap message is successfully sent by name:
1 2012-03-29 16:52:54 192.168.110.68(via UDP: [127.0.0.1]:50370->[127.0.0.1]:162) TRAP, SNMP v1, community public
2 FIGURE-IT-MIB::record Enterprise Specific Trap (2) Uptime: 0:00:00.17
3 FIGURE-IT-MIB::recordTrapsEntry.0 = STRING: "[2012-03-29 16:52:51] NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNsnmp service is up and running."
At the same time, you can also see the sent trap message through tcpdump:
# Sudo tcpdump-I lo udp
6. Someone reported a bug on the internet saying that the send_v2trap () function used to send the trap has memory leakage. To be studied.