Before you rush out and deploy a network management system in a production environment.
Think about network management planning in a lab such as with genius 3.
This is perhaps not as important but it's very important when doing this in the real world network management
planning includes translating business requirements into monitoring needs thresholds and Network Performance
Monitor or NPM configurations other things to consider with network management planning include building
and leveraging reports that meet the needs of the various stakeholders as well as determining and monitoring
scope and impact on the network.
And don't forget about the network topology having an impact on the actual monitoring system translating
business requirements means doing things such as surveying key stakeholders and departments for their
monitoring and reporting needs.
It also means documenting goals for your network management system and this really needs to be stressed.
It's very important that you document the goals of your network management system otherwise how do you
determine if the network management system deployment has achieved what you set out to do.
An organization may have the goal of increasing the availability of the network.
However if you don't document those goals and don't base line your network before you deploy your network
management system how will you determine if the network management system has had a positive effect
on the network and what it was originally intended to do it's important that your goals be documented
before you deploy and in addition make sure that you have a baseline of the network.
In other words you have an indication of what the network looks like in its current form before you
deploy the network management system.
If you don't do that how will you know three months from today or six months from today whether the
network management system has had a positive effect on the network and has accomplished what it was
originally intended to do.
Key measures also include things like data granularity.
In other words how granular or detailed should the data be that you're collecting.
For example if you are looking at bandwidth utilization on an interface how often are you importing
that data.
Is it once every five minutes or once every five seconds.
If you only look at the bandwidth utilization of an interface every five minutes you may miss a spike
during that five minute interval.
On the flip side if you are collecting data every second you may end up storing a very large amount
of data.
Another thing to keep in mind when translating business requirements into monitoring needs is data retention
data retention means.
How long are you going to keep the data that your network management system collected before it's either
deleted or summarized.
In other words how long are you going to keep detailed records of your network before it's deemed unnecessary
to keep that data.
Or at least that level of detail of the data other things you're going to want to do in documenting
these monitoring needs is to define both the needs of the teams involved in projects and the thresholds
now what thresholds mean is the level at which you want to start seeing errors states or paying more
attention if an interface is running at 25 percent utilization and then goes up to 50 percent utilization.
You may not want to be notified of that but when it goes to 90 percent utilization you may want to be
informed that something's happened on your network.
So you need to decide the thresholds before you get notified of possible problems on your network.
This becomes important when you build your alerts and configure the different reports available in NPM
NPM of course has many options and settings that you can change based on your network as well as your
business requirements.