First, if your 3rd-party monitoring software allows, filter the SNMP traps to limit the number of traps to what you really need. SNMP traps are in general very chatty. Without filtering, you can expect to see large number of SNMP traps sending to your BPPM cell.
Second, pay attention to SNMP trap adapter log file. If you have large traps, the error messages in your log file will tell you to increase the value of parameter SnmpTrapLength in mcxa.conf. The default value for SnmpTrapLength is 8192 bytes. You need to double that value for large traps.
Third, implement high availability for SNMP trap adapter. In general, SNMP traps are not logged, buffered, or re-tried. You would easily miss some important SNMP traps from a short period of network outages. However since BMC doesn't provide out-of-box high availability for SNMP trap adapter, we would have to go with simple redundancy.
Install and configure two identical instances of SNMP trap adapter on two different servers. If you have an active/standby BPPM cell cluster, you can install a SNMP trap adapter on each server of the cluster. This is simply a convenience, not a requirement. Then configure these two SNMP trap adapter severs as two SNMP trap destinations from your 3rd-party monitoring software.
Now for each SNMP trap sent out from your 3rd-party monitoring software, you will receive two events with one event converted from each SNMP trap adapter. You will need to write a de-dup MRL rule in your BPPM cell to drop one of the events. Your de-dup rule should compare the original trap IDs to determine if two traps are identical. If the trap ID is short, meaning that the same ID can be re-used fairly quickly, you will also need to compare the original timestamps as well to determine if two events are truly duplicates.
No comments:
Post a Comment