Ad Widget

Collapse

Default alerting for SNMP Traps

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • DonPook
    Member
    • Dec 2019
    • 38

    #1

    Default alerting for SNMP Traps

    Hello,

    I would like to create a default alert for all traps that might come from any system. Is this possible? Basically our customer is literally sending all traps from his systems, so there is no possibility to create an alert for each trap differently. Can I have an alert that would match the IP of the host sending it (I believe this is done automatically), and notify that this host has a trap (if the name of the trap is available or something, even better)

    Kind Regards
  • ISiroshtan
    Senior Member
    • Nov 2019
    • 324

    #2
    Yes, yes you can indeed. You can check documentation and it mention snmptrap.fallback item key that would collect any traps that were not collected by any of the other items.

    There is catch tho. How exactly you gonna handle information from there onward? Optimally, is to use this fallback item to get notification that there was unhandled trap, and then create a separate item/trigger for said unhandled trap.

    I can throw some ideas how you can still default all traps by one rule, but I would HIGHLY DISCOURAGE to take any of them as long term solution.

    #1
    Trigger name: {ITEM.VALUE}
    Expression: find(host/snmptrap.fallback,,,like,"SNMPv2-MIB::snmpTrapOID.0") =1
    (Expression pretty much just should return true on any trap)
    PROBLEM event generation mode: multiple

    Pros:
    - you will get separate problem for each trap
    - problem name will contain full trap.
    Cons:
    - Problem name will be SUPER bloated and unreadable
    - If device supports problem resolution traps - they will also GENERATE a new problem
    - Problems need to be closed manually

    #2
    Trigger name: {{ITEM.VALUE}.regsub("SNMPv2-MIB::snmpTrapOID.0\s*type=6\s*value=OID:\s*(.*)",\ 1)
    (assumes you have at least basic MIBs to translate this OID into name)
    all else the same.
    (Pros and cons compared to approach #1)
    Pros:
    compared to previous approach trigger name will not be bloated and will contain name of Trap received. For example: "CISCO-SYSLOG-MIB::clogMessageGenerated" for Cisco syslog message generated notification.
    Cons:
    - to have at least minimum level readable problem names it would require to have installed MIBs from all devices that can send messages(which is actually a good idea, but based on your description might not be easy to get for you). If MIB is not present, problem names will be as: ".1.3.6.1.4.1.9.9.41.2.0.1" (same Cisco log message generated notification)
    - it will not contain any more details as to what exactly is inside of the trap. Only trap type.

    #3
    Trigger name: Trap Received: {{ITEM.VALUE}.regsub("CISCO-SYSLOG-MIB::clogHistMsgText.\d+\s*type=4\s*value=STRING:\ s*(.*)",\1)
    all else is same as #1
    (Pros and cons compared to approach #1)
    Pros:
    - This way you actually extracting meaningful names for problems.
    Cons:
    - This approach tailored for specific MIB traps. Exact text i used is based on Cisco Sys-log related traps. Other products would fail to be properly named by this approach and would just have "Trap Received" as their name.


    Best approach in your scenario is:

    Request full list of equipment that reports via SNMP Trap with vendor names/specifications.
    Request MIBs used by said vendors(possible to search online yourself. But for some proprietary equipment might not be possible to find.)
    Start building(or search for existing) templates for said vendors, add them respectively and drop snmptrap.fallback item to catch any that don't fall into template configurations.
    Whenever snmptrap.fallback catches anything - create a new item + trigger(if needed) on respective template to handle said traps.

    Hope it helps.

    Comment

    Working...