Internal Errigal Collaboration Wiki

User Tools

Site Tools

Trace:
Writing /app/www/public/data/meta/onboarding/snmpmanager/object_model_-_the_basics.meta failed
onboarding:snmpmanager:object_model_-_the_basics

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
onboarding:snmpmanager:object_model_-_the_basics [2017/05/12 13:24] – mmcconboarding:snmpmanager:object_model_-_the_basics [2021/06/25 10:09] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== Object Model - The Basics ======
 +
 +Author: Cathal O'Keeffe
 +
 +===== Introduction =====
 +
 +You should read 
 +[[development:applications:snmpmanager:snmpintro:start|SNMP & Traps in a Nutshell]] before reading this wiki entry.
 +
 +Now that we know what traps are, we have to figure out what to do when we get them. 
 +
 +Our software is designed to monitor equipment and report when things go wrong. We do this by raising alarms.
 +
 +Our trap handling revolves around that - a trap is either telling us that we have a problem and we need to create an alarm, or that a problem has passed and we need to clear an alarm. 
 +
 +We need to store this information in a database.
 +
 +Grails provides an object-relational mapping between our code and the database - this means that the way the data is stored in the database very closely resembles the objects we use in code, which is pretty convenient for us. 
 +
 +These classes that are saved to the database this way are called **domain classes**. 
 +
 +For trap handling and storage, our most important domain classes are: **Traps, Varbinds, General Trap Summaries and Active Alarms**.
 +
 +
 +----
 +
 +
 +===== Traps =====
 +
 +The trap and varbind tables save all of the raw information from each trap we receive into the system. 
 +
 +This information is saved to the database before we start to create general trap summaries (GTS) or active alarms. 
 +
 +The only processing done on the trap at this point is translating the OID values using the appropriate MIB. 
 +
 +The trap table stores the name of the trap, the date and time we received it and the IP address we received it from, as well as extra information that depends on whether it is a SNMPv1 or SNMPv2 trap.
 +
 +
 +----
 +
 +
 +===== Varbinds =====
 +
 +Varbinds store the information of all of the variable bindings of each trap. 
 +
 +This includes both raw OIDs and values that have been translated by the relevant MIBs.
 +
 +
 +----
 +
 +
 +===== General Trap Summaries =====
 +
 +General Trap Summaries are the standardised format we translate all incoming traps into so that we can handle each trap in a consistent way. 
 +
 +How the fields are populated will vary depending on the technology and the types of traps involved. 
 +
 +This processing is done through groovy scripts we call [[onboarding:snmpmanager:trap_rule_testing|Trap Rules]]. 
 +
 +These are editable at run time so we can support new types of traps or change how we handle traps without a redeployment of the SNMP Manager.
 +
 +The General Trap Summary stores information about the trap, including the network element it belongs to, its severity (information, warning, minor, major or critical), and its alarm identifier.
 +
 +The alarm identifier field appears in both the GTS and active alarm tables and is very important. 
 +
 +It uniquely identifies each type of trap or alarm and is used in many places in the alarm handling process. 
 +
 +Only one open alarm of each alarm identifier should exist on a given network element at any given time. 
 +
 +The alarm identifier field is used to match clear traps to alarms in order to clear alarms. It is also used to lookup the [[onboarding:snmpmanager:demonstration_of_trap_knowledge_and_question-time|trap knowledge]] table to provide the NOC users with more information on each alarm in the UI.
 +
 +
 +----
 +
 +
 +==== Active Alarms ====
 +
 +After a trap is processed, it usually does one of three things:  
 +   * Opens a new alarm
 +   * Clears an existing alarm
 +   * Increments the repeat count on an existing alarm. 
 +
 +Alarms come in different severities - information, warning, minor, major or critical. 
 +
 +Alarms are either open (while there is still an ongoing problem on a system) or cleared. 
 +
 +Critical or major alarms that are open for fifteen or twenty minutes respectively are automatically "acknowledged" by the system which means that a ticket is created for them in the Ticketer. 
 +
 +The NOC can also manually acknowledge alarms through the Node Monitor UI.
  

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki