User-friendly way of managing SNMP MIBs and traps for alerting/eventing

Currently, in order to manage SNMP MIBs and traps for alerting, you must create a rules file that will map the OIDs and Varbinds of the trap, as defined in the vendor's MIB, to the event schema.

We do offer some tooling that will take a vendor MIB and convert it to a base set of rules... specifically the MIB Manager. However, SNMP traps generally do not strictly define things like Severity, problem/resolution for clearing, and may not even provide a human readable text string that clearly defines what the trap means (often it is in the MIB comments or documentation). So in almost every case, it is required to modify the auto-generated rules to define many criteria. Additionally, the MIB Manager is not built in to the standard Web-based UI, it must be run as a desktop application or from the server via X windows or VNC.

Now, there are pros and cons to managing traps with a rules file. The pros are the ability to have full and complete flexibility as to how you process and structure the event that is raised in the Event Manager event list, do some enrichment with data that is contained in CSV files, complex if/then/case processing, etc.  The cons to this method is that there is a fairly deep learning curve... a customer must be fluent in rules file syntax, regular expressions, and the like. 

What I am proposing is a purpose-built UI for managing vendor MIBs and SNMP traps, available in the Watson AIOps and NOI User Interfaces, That would:

1. Allow a user to add any MIBs to the Watson AIOps MIB library and compile it.

2. Present the user with a list of vendors, and MIBs, that are loaded and compiled in the system, making it clear which MIBs have SNMP trap/inform definitions (maybe even offering the ability to filter down)

3. Allow a user to select which traps that exist in a vendor MIB that they are interested in collecting, and allow them to define the Summary, Severity, problem/resolution, Identifier (dedup), etc for any given trap that would exist in a vendor MIB file. 

4. I could also see a tool which would allow an administrator to select a trap that was collected by the system and go directly into the trap definition so they could easily modify the appearance of the event and other criteria. When I started in this industry, I was an HP OpenView NNM administrator in the late 90's and even then they could do this.

5. Make it clear in the event list which traps have been received which don't have an associated MIB loaded/compiled


Note that while SNMP is widely used to manage network devices (routers, switches), it is also used for other types of devices such as SAN components, Server hardware (e.g. HMC, Dell, etc), commercial off-the-shelf software systems. Additionally it is quite common for element management systems to forward their alerts via SNMP traps to one or more northbound manager of managers.

I will attach a file with some mock-ups on how the capability could be laid out for simplicity and ease of use.

Note that this should not be used as a replacement for rules processing, but rather a simpler way of managing SNMP traps/informs. For power users who want ultimate control (and we do have many users currently) they will prefer to use the rules approach.