State Based Status vs. Event Browser for Network Management

Having been in Network Operations and Network management for many years, I am aware of the type of alert view most Network/Systems operations centers are using. This would be the traditional “event browser” that most products provide. With the traditional event browser you get a scrolling list of the most current events generated be network/system devices as well as from polling/thresholding from your NMS. In most cases this view truly is scrolling a constant stream of new events or sometimes referred to as noise. Even a “map” centric operations view can only show a propagation of underlying events based on criticality. Is this the best way to manage operations, is an event list the best way to see the status of your environment.

Event Browser for Network Management

How do you know what is actually up now, or what is down or in a fault/performance degradation condition. The only way to try to figure this out is to match up the fault events from the recovery events. What if you had a view into the actual “state” of the network/systems environment. An actual list of icons or navigation tree view of what devices/managed entities are in what states. What specific interface is down now or in an excessive error state. What router/switches/servers are up or down now, which have another type of fault or performance problem based on what the problem actually is (ie process not running state, interface has high rate of errors state, server is down state) as opposed to Critical, Major, Minor, etc. This would be based on analysis from the network/system/application management system. With this type of status view the operators would have true situational awareness. They would not be spending their time sifting through event lists or logging into devices, running show commands or running manual ping tests to see where things are at. This type of Operations View or “Flash Board” is on the drawing board for NerveCenter, now is the time to provide your feedback or thoughts.

Tags: , , , , , ,

Request for Information