NETSCOUT nGeniusONE Reviews

We used to use it for application debugging, in particular SMS and MMS, but lately, we've been turning towards using it for OpenStack and cloud-issue debugging.

In a network deployment, it provides us with increased visibility.

From the service assurance perspective, in SMS in particular, they use it very heavily to proactively try to hit issues. There are a lot of times where NETSCOUT will catch something spinning up the SA organization and then, in turn, spinning up the operations organization to go catch and kill it; or it comes over to network development. So it's used fairly extensively.

We use it on the cloud side more from a reactive perspective and it's certainly helped us catch and kill a couple of issues that we wouldn't have been able to otherwise. 

It helps us get to root cause quickly. We had an OpenStack Cinder issue, a storage-type issue, and we chased our tails on that for quite some time until we managed to get the data over to a NETSCOUT probe. Then we were able to very rapidly figure out what the heck was going on.

When we can get the data into the tool, we absolutely see a decrease in mean time to know and mean time to repair, and similarly for overall troubleshooting time. With that Cinder issue, we spun our wheels for almost two weeks before we managed to get the data over to the tool and, once we did, we solved it fast. So it can be days or weeks of saved time.

In terms of application uptime, it's deployed and leveraged for almost all the applications in our organization: VoLTE, SMS, MMS, etc. So as heavily as the service assurance groups and operations use it, I'd say that they consider it pretty essential at this point.

Among the valuable features, if it's TAP'ed well, are the density of the data that you can get and the relatively high veracity or accuracy rate that we see from it.

In terms of additional features, Bruce Kelly was talking about the NFV and 5G aspects of it, in monitoring all the APIs for all of those functions. We're really looking forward to seeing that so that we can give better visibility into the functioning of the cloud and the orchestrator itself.

There is room for improvement in its stability and by expanding into the cloud and orchestration sphere, which I think is on the roadmap.

The stability is only fair. It goes down a lot.

It scales out fairly widely, horizontally. And with the new virtual one, we'll be doing it a lot wider. So it has good scalability.

Technical support is good. We've got good onsite support and those guys are generally available.

We knew we needed to invest in a new solution because we couldn't fix things.

We see ROI through the ability to fix and to keep the perception that our network is up 100 percent. That is absolutely critical. It keeps the customers coming in.

We also looked at Empirix.

Consider what your applications are for this and purchase your features accordingly.

Regarding the single pane of glass view, we don't think we've really fully deployed it from a cloud perspective, but from a VoLTE perspective, I know they're starting to get on top of it. From an SMS perspective, we found it very useful.

I'll give it an eight out of ten as it stands today. It's very useful, but we do see some stability concerns. There is a lot of maintenance around the probes, and I think there needs to be more development done in the cloud sphere.

We use it mainly for north-south, and soon to be, again, east-west: Troubleshooting, visibility into the VoLTE cloud that we've designed. Initially, it was very small, baby clouds, per se, but now as we redesign and go to scale, so that we have the visibility we need, we need better tools. We have the infrastructure, but we need to take the next step into the virtual lane.

We use the solution for proactive monitoring of remote sites. We have 29 data centers where these clouds are built and we're moving out to edge and we will have even more.

It has provided us with increased visibility, not during deployment, but downstream, once we actually turn up services, whether it's microservices or a VNF.

During outages, and in terms of visibility into VNF and container behavior across the various versions of our cloud, it has helped our organization.

nGenius also helps us get to root cause quickly. Signaling is one example. We have challenges between applications that share the same baby clouds but that utilize storage differently than the network. We don't have that visibility now in some of our deployments. Our new deployments will have that visibility because we're not using copper for a lot of the east-west traffic in the cloud. We're actually moving to fiber so that we have that visibility. The next step will probably vSTREAM.

In addition, I believe it has cut overall troubleshooting times for the OSS and DevOps teams, and it has increased uptime. I'm not in the operations lane, but I know that is something that we have to have.

The most valuable features are visibility, real-time, on-demand.

I need more details on the vSTREAM and how that scales from a CPU perspective. I know that we can start with one virtual CPU, but at the same time, our clouds are still limited by compute nodes. That's an ongoing question and it's part of why we're here at NETSCOUT Engage 2019, to see how we architect that out.

I'd like to see improvement in scalability and the CPU perspective on the actual cloud nodes. It would be good to have a roadmap of what impact to our underlying cloud we will see as we add vSTREAM vCPUs.

We haven't had any problems with stability.

The scalability needs some work. From a probe perspective, we are limited to a certain amount of throughput on the devices themselves. Without having actual hooks into the bare metal hardware for the solutions, it's a bit of a "thumb in the air" as to when we hit our capacity or when our high watermark is. I'm not sure if our operations teams have that capacity under control. So when we have to scale, it's a very large expense.

I'm not aware of whether the initial setup is straightforward or complex. We have a standard template when we build them out.

A lot of it was internal or direct with NETSCOUT.

We've had ongoing RFPs back and forth for multiple years. As far as new solutions for our visibility needs go, as we're right in the middle of our cloud journey from an LTE to NFV to 5G, we're trying to get a grasp. We're always on the cusp, looking for the next set of roadmaps and how we integrate that into our network to provide for our customers.

Our shortlist included the usual culprits: Empirix, Gigamon, all of them in the same build with NETSCOUT. We still have a very vast mix of everything.

We can't ever walk into our builds or our support models blindly. This solution is one of many options, but it's obviously one of the better ones that we've worked with for years, and it's an integral portion of our architecture upfront.

"Single pane of glass" is a very overused cliche in our business for the past couple of years, same with "Agile." I like the idea of being able to stitch it all together. Our operations team definitely insist on it.

I would rate NETSCOUT a seven out of ten. Not to be a detractor, but I don't have the hands-on experience from an operations standpoint, so that's why I rate it a seven.

Troubleshooting is our primary use case for the solution.

We get increased visibility from nGenius while conducting an IT deployment. If the deployment has issues then we can always go back, look at the logs, and figure out what may be happening.

A lot of times people blame the network, and since I'm responsible for the network, people call me. Through troubleshooting using the tool, I verify that it's not our issue, and I also use the tool to help figure out what the issue really is.

It helps us get to root cause quickly. For example, troubleshooting an application issue without the tool would mean we wouldn't have the collection of data to go through to figure out what the problem is. Now that we have X number of hours, maybe even days of data, depending on what we're actually watching, we can look at the data. It's possible that somebody's having an application issue and they come to us figure out what the problem is and we can help them solve their issue a little faster.

We have seen a measurable decrease in mean time to know and mean time to repair. It's a little hard to say how much because it depends on what you're troubleshooting, but I would estimate it at 25 percent, or even less, of what it would normally be. And our overall troubleshooting time, in most cases, is down to a day, as opposed to multiple days. Without the data, it's almost impossible to figure out what a problem may have been.

The packet capture is the most valuable feature for us. It gathers data from the device. In case somebody has a problem, I can go back X amount of time - days, hours - and get the data to do real troubleshooting.

In terms of the single pane of glass view, it's good, but trying to set up dashboards is hard to figure out at times, if you don't do it every day. It's not really intuitive to set them all up. Other than that, it's a good dashboard. A lot of people are using it.

If there were a wizard to take us through, step-by-step, creating dashboards and the like, that would be really helpful.

It's very stable. Every once in a great while we'll have to reboot the nGeniusONE server. That may be server-related and not application related.

We haven't really scaled it very much. We're not a really big shop. We've got five InfiniStreams collecting into our nGeniusONE. It's supposed to scale pretty well, but I don't really have much comment on it because we're pretty small as it is.

Technical support is very good.

We didn't have a previous solution at all, other than Wireshark to capture packets when we needed them. We knew we needed something better than that.

The initial setup was a little complex, only because it was the first time we were getting into such a tool. We didn't know much about it. We had to learn while going along. It was complex, but quite doable.

We did it ourselves.

I don't see the numbers, because I'm a technical guy. But I would imagine there probably is a return on investment because we're fixing these applications faster, causing less of an outage. I would say we're actually saving money, or at least not losing as much money when these applications are down. It's a big help there.

I would show someone who is looking into this type of product what I know about the product, how I use it, and help them make a decision on whether it's the right product for them.

The product has a lot of capabilities and we're just using a small fraction of it. So, right now, I would call the solution a nine out of ten, because we only use a small portion of it. But for what we do, it helps us out tremendously.

Troubleshooting our LTE network - any situations that come up in our cellular network. We also use the solution for proactive monitoring of remote sites, as we use it to monitor all the towers in our cellular network, as well as our core applications.

We're still in the beginning stages, learning how to use it.

It's a great monitoring tool. At a glance, we can get an idea of what's going on in our network.

Also, while I don't track it personally, I know that time to repair has been reduced and that it has cut our overall troubleshooting time.

The most valuable feature of this solution is being able to drill down into any kind of troubles that are reported to us, by use of identifiers.

Some of the filters could be easier to see and to set up. That's the only thing that I've ever had any trouble with. The ones that I've seen here, at NETSCOUT Engage 2019, are part of a newer version that we don't have yet, and it looks better. So, it may already have been fixed.

It's 100 percent stable.

The scalability is great.

I'm sure it's great, but I haven't had to deal with technical support. I'm a technician.

I assume the setup was straightforward. I'm a telecom tech. The engineers did all the setup and I only use the tool. I didn't help set it up.

I would recommend it. It's the best tool that I've used as far as troubleshooting quickly, at a glance, and for being able to drill down into any issues, any complaints we might have from customers.

I do know that we would like to get TrueCall, but we don't have that yet. We're working on it.

I would rate nGenius a nine out of ten because I don't rate anything a ten. There's always room for improvement.

Network troubleshooting is our primary use case.

nGeniusONE provides us with increased visibility while conducting a deployment. I'm not on the IT side, I'm on the carrier side, but it provides that increased visibility for us.

From the standpoint of VoLTE and related things, it's providing visibility into the network and how it operates. It has also improved our ability to troubleshoot end-customer issues.

One of the valuable features is permanent user perspective, getting to the one pane of glass, so that they can use one tool for multiple purposes.

In terms of the single pane of glass view, NETSCOUT has many tools. I think NG1 provides that single pane for a lot of things, but users are still using several different applications within the NETSCOUT realm of applications, and more integration would be helpful.

Our biggest area of concern right now, supporting the applications, is that while NETSCOUT does a good job of monitoring the network and the applications, we need more visibility into system health and performance monitoring. We need something that will monitor the tool that monitors the network.

Stability, for us, has been an issue but, to some degree, I think that's from a standpoint of capacity. People are wanting more from the system than what we originally deployed it for, so it's pushed it to its limit. As a result, we're deploying additional capacity.

It seems to be scalable. We have a pretty big installation. Once we get capacity in place, I think it will resolve a lot of our issues.

The main driver was VoLTE, but also getting to a single pane of glass, so that we can have one tool to monitor end-to-end performance. Before nGeniusONE we used Empirix and we still have that solution in place today for some things.

To some degree, the initial setup was complex because of the nature of the application. But, as things go, I wouldn't describe it as any more complex than anything else.

We worked directly with NETSCOUT.

I don't have access to the numbers to give a black and white answer, but I think that our company will get that return on investment over time.

I didn't get to choose. I support what the business chooses. I've supported several applications in this area, and my experience with NETSCOUT has been positive to date.

I've been speaking to people who were having some technical issues with our NETSCOUT deployment, but when it works it absolutely helps us get to root cause more quickly.

I would rate it pretty close to a ten out of ten. It's a very complex application and system, and the support from our NETSCOUT resources has been stellar.

Over the years, it's been more for packet-capture troubleshooting. But in the last two or three years, we have been using it for application monitoring and expanded our usage because of voice over IP and the communications stuff. It has really expanded a lot, and we've creating dashboards and reports. Originally, it was just a reactive tool. If there was a problem, we'd go capture something and move on. But it has really expanded quite a bit in the last four or five years.

The solution gives us increased visibility while conducting an IT deployment. It's recording data all the time, so we have the "before" picture and the "after" picture. That's a big thing.

The Dependency Mapping is very helpful. When everything is instrumented correctly, and we can bring up a Dependency Mapping, sometimes it even surprises people in terms of what the applications are talking to and where the single failures might be.

In addition, in the troubleshooting area, we are able to zero in on an issue more quickly and get things working faster. In areas where we have instrumentation, we have seen a measurable decrease in mean time to know and mean time to repair.

The solution is very reliable.

The best feature is when we have it connected permanently via TAPs. That enables us to constantly collect data and then we can go back in time. Of course, we don't want a given problem to keep happening, but if we weren't able to use the solution to go back in time to when a problem happened, then we would have to hope the problem happens again so we can capture it and figure out what's going on. To be able to rewind, back in time, and see the problem as it happened, is very helpful.

In terms of additional features, they have the virtual clients here at NETSCOUT Engage 2019, and they have really expanded that. That type of coverage is going to be crucial. The COTS that they are doing now are a very good idea, to lower the price some. We work with them weekly, and if we uncover something, a feature that would be relevant, we usually report it. A lot of times it will get included.

Regarding room for improvement, on a network the size of ours, the loading times seem a little extensive, 20 or 30 seconds to load up some graphs. But there is a lot of data being crunched. That's all server hardware.

nGeniusONE is very stable. We have very few problems with it.

It scales well also. We are about up to 350 InfiniStreams. We have a multi-tier architecture for the NG1, locals and globals, and backup solutions and the failover solutions for disaster recovery work well.

Technical support is very responsive. We have two people onsite that we pay. They work for NETSCOUT and they're very helpful.

We've had NETSCOUT so long I can't even remember what previous solution we had. We did have a couple of areas where we had Riverbed Technology but we are phasing that out.

For an organization of our size, the setup was fairly complicated. We have a lot of equipment, a lot of tiers. We have a lot of security concerns so we had to shut down ports and we have firewalls and things like that. It may not have been complicated because of NETSCOUT, it just may have been complicated because of the environment.

We did not use any outside resources for the deployment, but we do have onsite people from NETSCOUT.

Take a good look at this. It's been good for us. I've looked at some other solutions and everybody has the same problems to fix. The way that NETSCOUT, the company, is integrating so you get to reuse the data, is good. One of the problems we had originally was that everybody was doing something else. If you are going to capture all this network wire data, why not use it for security and everything. It's all in there. That's a big opportunity with these guys. If you go out and get something for voice from one company, and something to work on your network issues from another company, it's really hard to work them together. You never get to that single pane of glass.

We use the solution for unified communication application performance but that's not really my area. People do use that constantly, and I don't think we'd be paying hundreds of thousands, or millions of dollars, if it didn't help with uptime and end-user experience.

I rate the product pretty highly, a nine out of ten. The biggest problem we have with this product is the expense. Also lately, the network traffic loads, getting up to 100 gigabytes, are taxing the hardware a little bit. That's a problem everywhere, so it's not really particular to NETSCOUT. They are responding to that. I rate them very highly.

We use it for when an app team or somebody comes to us and tells us that we have a problem with a server, that they're experiencing slowness, or latency, or the like. We like to take two IPs end-to-end. It will give us a server IP and the client IP, and we can plug that into nGeniusOne to hopefully give us some kind of error codes or a breakdown of what's going on from the packet level of the transaction. Hopefully, it gives us an idea of what's wrong.

The solution gives us increased visibility while conducting an IT deployment, depending on what the deployment is. As long as it's still monitoring in places that we're deploying something - for example, if it's in the DMZ, and it's going over a firewall - we have sniffers and tasks with this product deployed. In that case, we should be able to use it.

Another example would be when we're in the process of doing a lot of backups to the cloud. The teams come to us and they want a certain amount of bandwidth and a certain amount of resources, and they constantly ask us whether it's too much or too little, or can they use more overnight or at certain times. I can go back to my NETSCOUT reports and find out whether they're in trouble or actually have more capacity so they can ramp up their operations. It provides a view into that.

When we actually can use the product, we can see a measurable decrease in mean time to know or mean time to repair. It definitely has been something we wouldn't do otherwise, especially for capacity planning. We will get there when we have more proactive alarming and monitoring in place. It can greatly cut overall troubleshooting time once you know how to use it and it's properly and fully implemented.

Its troubleshooting capabilities are the most effective because we have it deployed in and out of our data centers, with our servers on-prem. And even now, going off-prem with Azure, we want to have visibility. For example, if one of our network pipes is getting plugged up by somebody using too much bandwidth, we can use the NETSCOUT tool to examine and find out what is going on.

I like the Dependency Mapping the solution provides, as long as it works. If you have it properly deployed it will. Being able to have dependencies is very critical in figuring out any path, and the more we can have that functionality it's nice because we can see if something's talking to multiple devices. We can see if one is actually the cause, rather than just "seeing blindly."

In terms of the single pane of glass view, when we build it out in the nGeniusOne platform, there are multiple tiles and, depending on what we're trying to examine, it doesn't all fit in one single pane of glass. It would be nice to have that functionality, but you really do have to categorize things because there is so much data.

The biggest thing is being able to provide net path. One of the products we use is SolarWinds, and it provides a very cool mapping of an agent from end-to-end. If NETSCOUT could somehow implement that into their design, whether it be sniffer-to-sniffer, or that kind of thing. I know they have some functionality along those lines, but if they could make it quicker and easier to get those net paths, it would be huge. I could quickly plug in problem IPs and get a full hosted view of where it's going from end-to-end. That would be really useful.

Finally, the GUI, the interface, has room for improvement. It's user-friendly to a degree, but when comparing it to other products, such as in the Cisco environment or SolarWinds, I found that I could just fumble my way through those tools very easily without training. Whereas with NETSCOUT, I need training in order to set stuff up because I would never figure that out on my own.

The stability has been pretty good. I haven't had any issues with the hardware, for the most part. It's a little tricky working with if you don't go through NETSCOUT for the packet flow switching. Right now, we use Gigamon, which we've had some older iterations of and some issues with. But as far as the hardware from NETSCOUT goes, we've had no issues.

The scalability is huge because certain ISPs have hundreds of these things out there monitoring their deployments, versus our having a few. It's very scalable.

Tech support started off poorly a few years ago, when we first implemented this, but I don't think we had the right resources on hand. In the last year, my company has worked directly with an OSC onsite, and the support has been much better.

We've actually had NETSCOUT for a long time, but originally it was implemented as a security tool, pre- and post-firewall, to just monitor traffic that way, to see how effective it was.

Now that firewalls have improved, and we use Check Point for that, it's been transitioned to the network team - to where I am - and now we're just using it as an NPM-type solution. It didn't really come in as a replacement. It was more, "Here are some assets that we want to use for network performance," so we're learning how to use it and deploy it better.

I don't know how they came to the decision to use NETSCOUT five years ago, but we kept it because we've had an investment with them.

The initial setup has been very complex. Just understanding our own environment, we definitely needed a dedicated resource, an OSC, to really figure out where we needed to deploy these things, what the capacity we needed to build out was, and what we needed to spend; what we currently had versus what we need. It has definitely been complex.

We've always gone straight through NETSCOUT in terms of the support and the hardware. We have never gone through a reseller.

We have seen some initial return on investment, on a small scale. We definitely hope to get more out of it once we implement it properly with the OSC. We're in the early stages.

We were looking at some of the Cisco stuff, and LiveAction, and SolarWinds, but NETSCOUT has its own little deep-dive triage packet part of the market that no one really, that I know of, touches. There is definitely still value there when considering.

If you want deep-dive, triage, packet-capture-type data, rather than just using Wireshark, it's very effective for that. It's definitely good for complex troubleshooting. There are other solutions, going into the cloud with the thin clients, and the vSTREAMs and vSCOUTs are definitely good, as is the nGeniusPULSE - I really like the PULSE product. We're not currently using that.

I think nGenius is very useful. You have to know your own environment, and see if it's good for you or not. My recommendation is mixed, to be honest. Depending on what you're looking for would determine whether I'd recommend it or not, which I actually have, to a colleague.

The solution can help us get to root cause more quickly, but not always. It is definitely a good stepping-stone, and when we have the visibility and the deployment properly implemented, it definitely can quickly get to a root cause.

We use the solution for proactive monitoring of remote sites to an extent. We have all of our sniffers, and all the stuff that's TAP-ed is in our central areas that get reported back from remote sites. As long as it crosses over one of those TAPs, it works. We're currently in the process of actually redefining and restructuring our build so that it does give baselines and some proactive monitoring, but we're not there yet.

For responding to issues, it can help the network uptime, especially when it comes to capacity, but as far as actually helping the stability of the network, I don't think it's really done that.

nGeniusOne is a seven out of ten, but improving. Originally, about a year or two ago, it was like a four out of ten for us because we weren't using it properly. When it's implemented properly, and the training is there to use the interface and have it work in your company, and people understand it, it can be very effective. As we do more and get it properly implemented, I think that score can even go up.

Visibility into the network is our primary use case.

We're just starting to use the solution for unified communication application performance, but we're not there yet.

The solution provides us with increased visibility while conducting an IT deployment.

It also helps us get to root cause quickly. We've had some voice issues, unified communication issues, over the last few months, and it gave insight that the voice team didn't have. We could actually pin it down to the point that we had a bad DSP box.

It has cut our overall troubleshooting time. It's taken the complexity of having to do SPAN sessions from the core and other places, by just going straight to this tool and applying the proper filters and getting the information.

The details it provides are among the most valuable features; the ability to drill down and get to the packet level.

I like the Dependency Mapping the solution provides. I wish there was a better way to show large groups, greater than 500, instead of just not displaying anything.

I would like to see it closer to more of an APM-type, or at least have that availability to compete with APM - the AppDynamics and solutions like that. I feel it's a natural step to at least have that available. 

Also, some integrations with ticketing systems like ServiceNow would be helpful.

Overall, it seems to function really well. We've only had one issue, but that was due to a power outage. It seems to perform well in a virtualized environment and I don't have anything bad to say about the stability.

I haven't had to use technical support yet.

The sales engineer helped me, and I got a lot of help from the website itself.

Be prepared to invest a lot of your own personal time to get the best use out of the system.

Regarding the single pane of glass view, you've got to have a lot of time on the console. Even though it's single pane, you've got to be able to at least get all the phrasing and catch stuff located properly.

I would give nGenius a seven out of ten. I think it could have an easier to understand interface. Other than that it would be a 10.