What about the reporting of real time alarms and alerts? These need to be processed on a near real time basis. The data needs to be disseminated as fast as possible to the concerned parties in a meaningful manner. The Help Desk is usually the best place to send these alerts but the problem is that the "ifIndex = 77" type message doesn't mean anything to that Help Desk person -- unless you are using experts on your Help Desk! The cryptic data needs to be converted to a format Help Desk personnel can understand.
Second, what does the Help Desk person do once a message is received? The Help Desk person may not know about Unix or Windows NT or a specific network component resource or service running. The network management application must place, at their fingertips, a list of processes to be accomplished once an alarm has been displayed. Information such as who to call, procedures to accomplish, and who to page, needs to be available at their desktop to effectively track a problem through. Remember, if a Help Desk person doesn't know what to do, they could spend the next few critical minutes trying to find out where to start. This time is dead or non-productive time and should be eliminated if at all possible. If a Help Desk person receives a symptom via the telephone, if they have to return a call, costs the company 10-20 minutes every occurrence.
It is through this "Knowledge Base" that Mean Time To Repair (MTTR) cycles get more efficient. Think about it; a problem is detected faster, a Help Desk person sees the Notification trap or alarm and starts the diagnostic process, then dispatches the technician with enough information to know the most probable cause (what parts to take!) of the problem.
The actual alarm display needs to be simple and informative. In some application the message ‘PerformanceException’ is displayed; the question becomes ‘what performance and of which service? What exactly is the exception? By focusing these messages away from graphical depiction, distribution of the information is made much simpler -- and faster. Textual messages should be displayed easily and modified easily and to the specific User whom the message is most likely to be of concern only and to the particular User representing a particular department. Another example is to pass critical alarms to a display pager, especially during off hours or weekends.
The Trap and Notification messages display depends on the ‘SmartMIBService’ operating system service and the ‘TrapListener’ SmartMIB service process module. This ‘TrapListener’ service is started automatically at boot time by the ‘SmartMIBService’ operating system service when the later is set to run automatically by the system administrator in the ‘System Setup’ menu
The ‘TrapListener’ service is in charge of (as the name implies) listening to the protocol port(s) where traps and notifications are sent from the managed elements on the network. The ports are set from the ‘System Setup’ menu option of the SmartMIB application GUI.
Traps and Notification Journals are launched directly from the SmartMIB main application GUI. The Journals are started by clicking on the “Traps Journal” button to start the “Traps Journal” window (See Figure 1 below).
Each Trap message received is displayed with a stamp containing the Date and exact Time in which it was received by the Trap Listener process Engine (TRE), a sample display of Traps and Notifications is shown also in Figure (1) below. Furthermore; the SNMP trap version is also displayed along with the text based trap’s description message.
The Start and Stop buttons
A ‘Start’ button is used to actually start the ‘Trap Listener’ SmartMIB service process module. The ‘Stop’ button on the other hand is used in the Journal to stop the ‘Trap Listener’ Service. This is in fact the difference between the Message Logger and the Trap Listener processes where the message Logger doesn’t run as a service with in the operating system environment. To stop and start the Trap Listener; the ‘TrapListener’ Service has to be stopped or started respectively from the Start and Stop buttons.
The Search and Filter buttons
The search button locates a single received Trap event by its full or partial content, while the Filter button captures a set of Traps received within the User specified period of time.
Figure (1):

Any of the displayed Traps or Notifications could be highlighted by clicking on it once for its variable bindings (We call ‘Trap Objects’) to be also displayed on the lower window pane. The display includes the object descriptions and the reported values contained in the specific Trap or Notification received.
|
Previous Page Page 3/5 Next Page |
[White
Papers], [Open a Support Ticket],
[Report Defects],
[Enhancement Requests], [Beta
Solution Program]
[Home],
[About], [Solutions
Center], [NMS Market], [Products
& Services],
[Management Technology],
[Technical Support], [Contact us],
[Site Map]