Blog series: How 60-polling saves you time and money
If your current NMS only polls your network devices every five minutes, how can you be sure that you’re not missing transient, but important, network events? Could you accurately identify where on the network a cascade failure started?
The helpdesk support line rings. It’s an all-too-common complaint: ‘We’re being told that customers can’t access our customer portal. We’ve raised this as an issue before. It always seems to happen when it’s our busiest time of the month for new enquiries. It’s costing us money. There must be a problem with the network. It needs fixing now!’
It’s possible the user is correct. There might be a problem with the network, although as your team monitors the network and there haven’t been any red flags, you think it unlikely. It could equally be a hardware failure, software issue or an internet provider issue.
Could your current network monitoring set-up help you uncover the root cause? Because if you can’t find the problem, you can’t address it. As network engineers, we want to be able to show that the network performance is reliable to support the business in carrying out its revenue-generating activities.
Fast and accurate root cause tracking
Most network monitoring solutions will poll your network devices at intervals of five minutes (or sometimes longer). Statseeker is different. Statseeker polls at 60 second intervals, meaning it captures transient events and peaks and troughs in network performance that a monitoring tool with longer polling intervals might miss.
And if you’re not aware of a change on the network, you don’t know there’s a problem until your users tell you.
[Utilization-Resolution Interval Example]
Whatever your business, losing a network connection for only two minutes can be financially damaging and cause customer frustration. A two-minute lost connection would cause ATMs to stop dispensing cash, point of sale systems to not accept payments, or ticketing machines to crash.
Let’s go back to the helpdesk example.
The user said that this wasn’t the first time he’d reported the problem. As the network manager, you need to understand exactly what happened on the network at the time of the problem and figure out what occurred in the minutes leading up to and during the issue, on this occasion and for each occurrence of the issue, which could mean going back weeks or, as in this example, months into your network data.
Statseeker keeps all polled data in its original format, never averaging or rolling it up. This means you can ‘wind back the clock’ to identify exactly what happened on your network at a specific point in time, going back weeks, months, or years, and examine and compare each issue and prove the root cause. A quick glance at your historic data in calendar view can also be helpful in spotting any patterns that might be occurring on the network.
[Interval Statistics, Calendar View]
So, whether the event you’re investigating happened today, or two months ago, the analysis can be carried out in the same level of detail.
If the network is at fault, you can follow the chain of events leading up to the failure. If the network was working as expected, then Statseeker provides you with clear, accurate data to support this claim.
Statseeker also allows you to rewind time on a network topographical map. You can quickly visualise where high network loads, discards, or temperatures occurred prior to the incident, or spot where an anomaly occurred, just before a failure event was registered.
[Topographical Image Map]
Accurate reporting, in seconds
Once you have a full picture of the period under review, Statseeker reports on the data in your required format in seconds. You can share access to a specific dashboard and show the data live or export any data to a mailed PDF or CSV in seconds.
Being able to bring all this evidence together quickly, going back months or even years, can help prove the root cause, and depending on the issue, highlight whether remedial action is needed by the networking, ISP, application or even security teams.
And if you’re wondering how the helpdesk story ended, here’s what happened. The network admin traced the large amount of data which was clogging the pipe to a particular port on an access switch. The user was downloading a new movie release. Turns out the ‘network problem’ was down to Dr Strange, not the network!
Try Statseeker free, for 45 days – request your trial copy.
Interested to learn more about Statseeker? Try one of these resources: