Statseeker Reviews

We have about 800 schools and we use Statseeker to monitor the WAN router at each site. Up/down (uptime and downtime) is our biggest thing. After that, we use it for monitoring bandwidth, interface utilization and different things like that. We use it for all the statistics it can provide in real-time and for historical usage. We use those statistics to plan if there is a need for upgrades — things like that.

The product has improved our organization by simplifying monitoring and giving real-time alerts for issues we might not immediately be aware of otherwise. If we notice five devices with latency or errors, I wouldn't know that if I didn't command line into 800 devices and check every day. I can see the status on the dashboard and it just makes it easy to know where the problems are.

If we didn't have that capability by using Statseeker, then it would be very complex to monitor. We'd need to have another tool or manually log into every device to try to check things. And this product just does it all for us. That streamlines and improves our workload so that we only need to have two people in our office for the network team. 

It improves availability. If a circuit goes down texts and email alerts get sent out. So, even if it's in the evening or we're not on premises, we'll know if something's down. 

We use it all the time because it really helps.

We use it for bandwidth monitoring and email alerts when there are significant events like interfaces or devices that are down. Those are our big use cases.

Just recently, we were having some issues with a certain site, and it was only Statseeker that showed us what the problem was. It was a lot of errors on a certain circuit. Then we were able to resolve that.

There are other tools for network monitoring, but not to the level that Statseeker does. It tends to consolidate a lot of the questions that we would be going to other tools for. It helps in picking and choosing the answer.

I think this solution has reduced the workload time of our network admin team. It reduces the troubleshooting time when there is a problem.

I would like to think that it's increased our network availability.

I work in a distributed simulation. It's a much smaller network and it is a closed one. It's classified and it's behind encryption devices. You can't actually get there from the outside.

We had a unique situation here. We are using this solution with distributed simulation for military purposes. Packet loss is equated with a lack of credibility in your simulation. You basically can't trust the data if you lose packets.

After a lot of testing and verification, we decided that we cannot afford more than 1% packet loss. You can't say zero, because zero isn't possible to achieve. We tested and we said that if 1% packet loss is all we have, then that's what we can live with.

The question we had was how we can measure the 1% data loss in a distributed environment. We instrumented all of the sites with this solution. There are about 25 sites in the hub. The interface is going to decide. We're collecting data on that. I worked with the development team in Australia to give us a script that exports the data for us so we can actually obtain the data. We made our own dashboard out of it. It's a dashboard, or a line chart, that shows the usage on each interface, but all of the lines are on one graph.

Statseeker didn't have that capability. I don't know if they have that now. Rather than looking at 25 charts and trying to figure out which one might be going over 50 MB, we put all of the charts into one chart. We had one inbound and one outbound chart, and we normalized it to 50 MB so we would see, at one glance, if somebody is overriding. One person overriding ruins the whole experiment. This was a unique use of Statseeker.

It's different than what most IT enterprise people use it for. They look at their environments one at a time. They look at one connection from a server to a client. In our case, we wanted to see all of it combined into one. We can't afford any losses. even at the most insignificant site, a loss means losing the credibility of the event.

It's very expensive to set these up. It costs a couple million dollars for each experiment that runs only for two weeks out of the year. We can't afford any loss during that time. The best choice for that was Statseeker. We exported the data in real time and we're putting it on our dashboard charts ourselves.

Our primary use case for this solution is network alerting.

This solution helps us to track down problems faster. Whether it is a down network switch or a down router, we can get back online faster for the customers.

When we are alerted as to something going down, it could just be power related or a circuit from the ISP. After finding out that it is down, five minutes later I might get an alert to say that it’s back up. This saves me the hassle of having to contact the customer.

Our primary use of Statseeker is for our interface. In our data center, we are typically a Cisco shop. We can now look thirty days into the future based on past stats of trends or fashion. 

If we have 10 servers in the field office, we can jump up to twenty based on utilization. We have the evidence. It is a lot of manual work to create those reports, but a bit easier now.

Statseeker helps solve an asymmetrical routing issue we had before. We could see traffic going out of one interface, but not coming back in.

An operations guy made a change and told us it was good. We didn't check it, we had too much going on. When I clicked in and looked at the traffic, you could tell it wasn't right. I had to log in and correct them so. That is a pretty good example of basic metrical routing.

We primarily use this solution for polling and interface utilization. 

This solution is used by our network operations center to identify down interfaces. It also allows us to predict the capacity on WAN circuits, as well as other circuits, to help us plan for upgrading.

We use this solution to control bandwidth congestion, and also for the recovery of unused data network ports.

It has somewhat helped the workload of our network admin team. The recovery reports have streamlined our process, and diagnosing certain congestions is easier.

This solution provides a deeper investigation into certain circuit congestions. It’s a much quicker way to drive into troubleshooting congestion issues.

Our primary use case for this solution is network monitoring.

We have Statseeker alerts emailed to a Google group, and one of the members of that group is a Slack integration. This means that we get instant alerts on Slack, from Statseeker, whenever an event happens.

All of our UPS units are set to send SNMP traps to Statseeker whenever their batteries are in need of replacement, or they start failing self-tests. Statseeker then generates an alert based on that trap, which proactively tells our UPS people that this battery is in trouble.