Plixer Scrutinizer Reviews

The primary use case was statistics. Now, it's mainly security and operations.

I am using the latest version.

It has become an essential and helpful tool for in my daily work. If we didn't have access to the tool, we would have more difficulty getting a long-term overview on the growth of our network. As we have gathered statistics for more than 10 years, we know about the implementation of traffic on our network to also justify our work and investments. From my point of view, it would be more difficult without a NetFlow accounting tool.

The solution helps enrich the data context of our network traffic. A very good example is a feature recently discovered denied firewall flows, which helps us understand what's going on in our DMZ. It also helps us figure out misconfigurations, It is really a very helpful feature.

It shows us the saturation of the network of devices. It gives us a clear view of the flows in the network to understand, for instance, planning upgrades in the network to get an idea of what's going on in the network for traffic flows. It gives us insight, for instance, on what's going on our VPN Client. There are a lot of things where it provides very helpful information. It also gives us our security reports with quite detailed information on what's going on in the network, and whether there are data exfiltrations and so on.

In a few cases, it has helped resolve network events. It has also helped resolve security events. We found a couple of security issues that we wouldn't have found without the tool.

• The automatic reports that we use for statistical purposes.
• The security analytics.
• The security alarms.

I have been using it for more than 10 years. My company has been using it longer.

On a scale from zero to 10, the stability is about an eight. From time to time, we have some issues that need to be fixed by their support. Usually, the support fixes the issues quite quickly. I would say it is between good and very good, in that range.

There is one person (the head of the network group) who maintains the server right now. There is also a backup if they are not available. We have a few people who are able to do some configurations on the system.

My personal impression right now is that we've reached a limit, or we are near a limit of flows per second, because we see that our system is getting quite slow. I suppose it's a hardware issue, not an issue of the software.

The actual size of the network is above 3000 users.

They are really great. With my most recent experience, two days ago, they responded quite quickly. They're immediately available. Usually, they have a solution to fix the issue during the call or web conference. With the most recent call, I had four questions and issues. They didn't say open four cases. They fixed or answered the four questions, then asked me whether I had other questions at the end. The support is perfect.

I never used another NetFlow accounting solution. I got to know the NetFlow concept at my current company.

The initial setup didn't seem to be that complicated. I found it already implemented, but we did a lot of migration steps. It seems to be quite easy to implement.

If I would have to implement it again, Scrutinizer is not that difficult to implement versus any other appliance. It is more complex to configure the exporters, but there is a lot of current, good documentation on the Plixer site for this.

In our situation with 25 exporters, it might take a half a week to do the implementation of the server. It's usually performed by Plixer, or with the help of Plixer and the hotline. First of all, I would use the test license to do a proof of concept to do the implementation. Then, I would test one or two devices, gathering some reports. I would also create an implementation plan.

We have seen ROI.

We recently bought a license upgrade, so we will integrate more exporters. We upgraded from a 25 exporter license to a 50 exporter license. Therefore, there will be more flows, and this will be an extension.

Compared to other solutions, the functionality Scrutinizer delivers is better.

I have one comparison to another product, which also has very basic NetFlow accounting.

When dimensioning the server hardware, we decided to have many CPUs, much memory and a large storage, but we learned that the storage has to be as fast as possible. It would have been better to invest in SSDs instead of HDDs.

We thought about using FlowPro. We see a very good use case for it, but right now we are working just with the flow collector for enhanced reporting.

It is really a very good security improvement. In the last two years, we learned that it's a very good security tool to learn more about what's going on in the network, not only in terms of network saturation, but mainly in terms of security incidents and break out.

Our primary use case is monitoring bandwidth and being able to go back and look at bandwidth issues.

We are on the latest version.

It helps us determine what is going on with our Internet and who is hogging it all up. If we get a real high throughput or a throughput that's going over and getting dropped fairly quickly, we can tell who (or what device) is consuming that traffic. That was our main use case for buying it to start with. Going forward, we will start using it for other stuff too.

We have only had it a couple of months, so we've not really dug into it a lot, but being able to know bandwidth is the main thing.

• Being able to monitor VPN user traffic has been nice. 
• Being able to monitor interfaces, in general. 
• We do a little bit of reporting, but we're just getting into that.

I wish the reporting side was easier to work with, but it does a decent job. I also wish the reporting side was a little more intuitive or they offered more reporting examples.

Their user videos could be a little better. They provided me a couple of training videos, but they were very generic in nature. E.g., if they had training videos specific to Cisco or Palo Alto firewall to give training to show you specifically within Scrutinizer what you could be looking at. They did provide a basic and an advanced training video. However, even the advanced training video doesn't break down into detail, and on the configuration side, that would be nice.

We've had it about two months.

I haven't had any stability issues with it at all. I haven't seen it flake out or experienced database issues.

I'm the only person who maintains and upgrades it.

It is easily scalable. I haven't seen any issues with it.

It is in full production. It monitors several firewalls, like Cisco Firepower, and IPS.

We only have three users who are using this solution as end users. We are all network administrators. It gives anybody within our group the ability to troubleshoot it easier.

The technical support was good.

We have Splunk, but Splunk doesn't give us the type of info that this does. Splunk is really clunky and hard to use. We still have Splunk, but we use it more as a security means for network means.

We have used the free version of PRTG, but that solution was clunky.

It was a pretty straightforward setup. I wouldn't call it complex.

The deployment took about four hours. We still expanding on it though.

I did the deployment.

We have seen ROI.

The solution has helped to reduce the time to resolution for network and/or security events by 50 percent.

There are no extra costs. It's about $8,000 a year. The bang for the buck (cost) is definitely a plus.

They gave us a 30-day license. We did a 30-day demo. We installed it, knowing that if we bought it, we could just add a license and continue on. So, we did a 30-day PoC, and they gave us good support during that time.

The solution has been around for a while. The monitoring of our firewalls was the driving concept for choosing it. They did well with demonstrating that ability.

We evaluated Cisco Stealthwatch, but it was so cost prohibitive that we did not go that route. It was about 10 times more expensive than Scrutinizer. Cisco Stealthwatch was very clunky and use. The menus were very different. While you could get a ton of information, you really had to dig to get it. There was some better features obviously, because the cost is a lot higher. It's more of a security network product, but it was hard to use and cost prohibitive. Also, we saw that its ongoing maintenance to keep it running would be a nightmare. There was a lot you had to do to keep it working correctly.

I would rate it an eight (out of 10).

It's a NetFlow collector.

It helps provide reporting information to our customers, which is also part of certain regulations that we have in the UK. 

The solution is similar to an automation process because we can automate and schedule reports. From a workflow process, the pipeline is automated. We would need to have a lot of people doing many reports in Excel instead of using one product. The solution emails us when we need it and on a periodic basis automatically.

The insight the solution provides as a result of its correlation of traffic flows and metadata is very good, fast, and accurate. It is one of our go-to tools when there is an issue and we want to do some accounting on the network.

The solution has helped reduce the time to resolution for network and security events by three to four hours.

Visualization of the network traffic is the most valuable feature. It allows you to drill into information quite quickly.

The solution helps enrich the data context of our network traffic. It allows us to easily visualize data flows and data usage. This helps keep management happy.

It would be useful if there was a way to back up the configuration information. E.g., if you wanted to deploy a new instance or disaster recovery, you could quite easily deploy and restore the config, as opposed to having to restore all the NetFlow data. If there was just a button that said "backup config information", that would be good.

About four years.

We're happy with it. The solution is stable.

We have one person who is required for deployment and maintenance. Their role is network administrator.

It's scalable for what we need. It has a lot more functionality than what we use. We can distribute the collection engine and some things like that, but we're not using that because we don't need to. It is there if we do need it.

There are varied roles across different teams. There are about 20 users, in total, who are mainly network operators.

The technical support has been excellent. Any problems that we have had, the technical support has been able to remedy and resolve them. But, there haven't been very many problems.

The workflow integration within a single platform has allowed us to remove redundant tooling. So, it streamlines that process into less workflows. It's allowed us to consolidate network statistical information. We have eliminated tools like SolarWinds, ntop, and some Linux utilities.

The primary reason that we switched to Scrutinizer was the interface. I saw a demonstration of the product at one of the security seminars where it was advertised as Splunk for network data. That's exactly the type of product we were looking for and it gave us that functionality. It was also able to deliver as expected.

Other requirements that we had were that it was multi-vendor, scalable, and a single-appliance solution. So, we didn't need to have a lot of database servers or Microsoft Servers and could run it as a virtual machine.

The product, Scrutinizer, was simple and straightforward to set up. Where we had trouble was not with the actual Plixer product, but with the sFlow sending. Although the issue wasn't with Scrutinizer, the support was able to help us resolve the issue.

The deployment took two weeks, start to finish. We had a test environment. A large part of those two weeks was setting a test environment up, having to play around with how we send data to Scrutinizer, and the NetFlow data. When we did a pilot, it resolved any problems with Scrutinizer directly. Then, we deployed into the live environment.

We deployed it. Plixer was there with technical support from the sFlow perspective. We didn't need them for the actual deployment.

It probably saves somebody at least one day a month at minimum.

We have increased the license over time. We have added more licenses as the network has grown.

There is a recurring maintenance fee after the initial purchase or if we want the license upgrade.

We already had some solutions in place. So, we evaluated Scrutinizer, which did what we needed it to do. At the same time, we were evaluating open source and SolarWinds.

Scrutinizer does exactly what we need it to do. We're very happy with it. We're not looking to change in the short-term or long-term. It's a product that runs without any issues and gives the information that we need.

Compared to previous solutions that we have used, this solution is a lot more intuitive, less clunky, and resource-hungry.

• Remember to save the reports.
  
• Give reports different file names.
• Understand how to back up and restore the configuration information. 
• If you use the building tools for the sizing for history information, they're quite accurate. 
• If you want to go back many months or years, you need more storage for that. 
• If you want a higher resolution to get into the data, make sure you size appropriately.

Try the free demo or evaluation copy of it. You should be happy with it, if it does what you need it to do. 

I would rate the solution a nine (out of 10). 

The primary use case is all bandwidth utilization.

Our solution is up-to-date. We're using the standard NetFlow v9 and IPFIX with the products that currently support NetFlow.

Scrutinizer gives us an answer. Time to resolution for problems has been reduced, because I now have a tool where I can look at historical data. I no longer just say, "Well, you're going to have to call us when it happens again. Maybe we'll catch it." It's pretty much the only tool that gives me this type of visibility.

The internal reputation of our IT to resolve historical bandwidth problems has 100 percent improved. The general time to resolution has improved by having a tool where we can look and see what is going on, even in the last half hour, with alignment that isn't performing well.

The insight the solution provides as a result of its correlation of traffic flows and metadata is really all that I have, so it is extremely valuable. If I were to give it a number on a scale, I'm probably holding it around a seven or eight, as far as usefulness, compared to my other tools.

We found the solution helps eliminate data silos because we do allow all company access to the product, since it's a read-only tool. We have shown a number of different departments in DevOps how to look at it themselves and diagnose their own problems, e.g., when they're having slowdowns to Azure. We have our express routes tagged to the Scrutinizer product. They can tell when the line is saturated and what's saturating it. This has empowered them to self-police what they're doing on the line, and it reduces the ticket count that we get. This gives us an insight on how to manage the traffic flows. More people can see IT data in real-time without having to ask IT a question and wait.

It is a workflow for the basic troubleshooters to always check anytime someone says there is slowness or a performance loss. You check Scrutinizer for that site to see what it is doing. So, it is in our workflow.

Our biggest lesson from using this solution is how to control and manage Commvault. Our biggest clobber of traffic was Commvault backups. There was a lot of stress on the network as backups ran into the daytime activation hours. We were able to track when and where they were running their backups just based on how NetFlow showed Commvault's usage.

History features are the most useful for going back and looking at when a problem has been reported, anything prior to immediately right now. A lot of it is, if we had really slow traffic over the weekend, and I come in on a Monday, it will not be slow now. So, I have nothing to look at, it's in the history.

The solution helps to enrich the data context of our network traffic. It allows me to see what applications are most in use on a slightly historical basis, going back a day or week at tops. It allows me to tune QoS or traffic shaping around what's being used. It saves me from having to unnecessarily upgrade, if I don't need to.

It is an easy go-to tool.

The visual acuity of how it presents data can sometimes be confusing. It takes a bit for people to spin up how to look at the graphs. It's how the graphs are displayed and how busy the information is. When you first take a glance at anything that's displayed, other than just the single line drawings, there is a lot of information displayed. It can be overwhelming if you're not used to it. In a lot of cases, a product like this only gets looked at when there's a report of a problem. It's not an everyday tool. Thus, most people don't get used to it.

I have been using this solution for five to six years.

It is extremely stable. I don't ever play with it. I have never had to tweak or tune it. We have had to upgrade it in the past when they have made a major architecture change. Other than that, we sort of forget that the box is running, use the GUI, and go. It does what it does. It doesn't crash.

One person is required for maintenance and deployment. There is a backup guy, but all he does is look at my docs and repeats what I do. He doesn't spend any time on it because I don't spend any time on it. If it were to crash right now and had to rebuild it, we would just download a new one and start over because that is how infrequently we touch the product. So, no one probably remembers the database passwords anymore because in six years we haven't had to touch it.

I haven't ever used more than a single collector. So, I've never really tried to scale. My quantity count for device input has always been below a 1,000. Thus, I have never pushed the box to its max.

Out of IT, there are about eight technicians who either configure debt flow on a device or are directly effecting a ticket. After that, we have about 40 to 50 end users that view data to understand their own areas of the network in the different regions, such as Asia, Europe, etc. These are IT professionals, but they are monitoring, not networking. For example, "What's my internet usage? What's my MPLS usage, so I can see how my site's doing?" It's become more of an overview.

We are not really looking to create any new usage. In fact, we've pulled back some of its usage only because we have gone away from traditional MPLS and routers and onto an SD-WAN solution that already brings onboard its own version of the same metrics. Therefore, we've reduced the number of inputs to it, but we're almost topped out there. 

That's pretty much our way in infrastructure. It's pulled back from the use of NetFlow. NetFlow is still being used for most of our major Internet connection points over the globe. It probably still is being used on all of our ties with other vendors, as they're private lines into our company. Also, it can be anything at the data centers that use traditional networking. So, we're not really growing it. It's not really shrinking anymore, but it was. Last year, it shrunk by quite a bit.

We are primarily a retail shop. We have a lot of little stores which used to be part of a much larger network. Those are all SD-WAN now, so they're not seeing anything with Scrutinizer. However, it's still on all of our Internet lines. So, it's pretty stagnant and stable.

The technical support is stellar. It feels like Plixer really has the one product that they're doing, and that's pretty much all they do. They're not overly divested. When you call them, it's almost as if they're waiting on the hook for someone to have a problem so they have something to do. That's what it feels like. 

When I try to contact either Jamie or Jake, it feels like they're ready to start up GoToMeeting within a minute or two of my email going out. It does almost feel like they're on the hook hoping somebody will have a problem somewhere so they have something to do. That's the response level that I get.

The company was using the old MRTG, which doesn't really provide application visibility at all. It's not really a commercially supported product. So, if anything went wrong, it was like, "Well, I don't know how it works." We switched to get onto something that was commercial.

The initial setup was straightforward because I've used the product in a number of other companies. I'm very familiar with NetFlow. For me, it was rather easy. Then again, it could have been really complex and I would have thought it was easy.

There was really not a lot to get it setup. I would give its construction of maps a bit of a ding for complexity. Trying to get maps and lines to show up so people can look at it and understand what they're seeing was a little on the complex side because their little drawing manipulator is not exactly the greatest. It's like using crayons.

It wasn't a hard product to set up. The hardest part was getting the resources out of VMware to get it set upon. But, that's not their fault. A product like this comes in, and says, "I need this much storage." Then, the people that run VMware freak out, "Why would anything need that much storage?"

I was the one who set it up. I came in as the expert. 

I talked to Jamie and Jack directly at Plixer because I already knew them from other jobs. I use them because, as a technical person, I suck at doing reports. So, anytime a boss will ask me for some type of oddball historical reporting on a site, I still go right back to them, and go, "Okay, guys, show me again how this works," because they do it maybe once a year, and we don't have a reseller who does this.

It was probably up and running inside of four hours.

My implementation strategy was just to gain visibility. It was to set up the company's product, send everything at it, and show my employers what they can see. It was to show them a blind spot.

For historical questions, it has reduced time to resolution by a significant amount since we previously didn't have the data. So, there were some problems that never went resolved because we didn't have the data. In some cases, it's just flat out allowed a time to resolution rather than cancelling the ticket. Easily, it is a solid 70 percent time reduction.

It allows us to show as a department that we can answer some technical problems from past complaints, so we look like we are tracking what has been going on in the network rather than its current state. The goodwill that comes out of seeing the IT department as someone who can solve a problem is where the biggest return on investment has come. 

Just for my team of eight, having something that they can look at, and go, "Oh, that's what's taking up the traffic." Now, we have a smoking gun to go address. Was it backups? Was it someone's download? That's another good return on investment rather than, "I don't know. Let's try this." We are not taking the shotgun approach to troubleshooting anymore.

I saw a gap in our visibility, and I already knew what solution would make that work. This solution was something I knew we needed to bring in. Because Plixer is dedicated to the idea of NetFlow, I don't think there is anything out there that could be gleaned from NetFlow that they haven't thought of or built into their product. So, I'm comfortable giving them a leader role in that technology because that is where they're focused.

We did evaluate other products. We had a minimal capital for an expense on a tool, and I was put up against the guy who does all the Voice over IP. They had Actionware's QoS manager look at all of the QoS network-wide and keep it tuned so we were at least flowing the right data for the right reasons in all the right places through and through so everything matched. He wanted a tool that kept all of that in place. I felt that watching the data flow outside of where QoS ran would be a bigger bang for the buck. I won out on this one.

The differences between the two products is that they service a different master. They're not apples to apples by any means. One is just making sure that your policies are uniform and balanced for QoS, not crossed all of your products. Whereas, Scrutinizer is there to show you what your product's actually doing. It can be used for tuning QoS if you wish to, but then you would be doing that part manually. It could be used for telling you how your site has been over the last week or month, as it does capacity planning. It's real easy for the end user to look at it too. It gives them a view so they get that self-help. High level management can build their own views and look at it, whereas nobody else can really look at the QoS tool because it actively changes the network. So, you don't want to give that tool out. Therefore, it really wasn't apples to apples. 

For our business, it was which direction was the right way to go for the money involved to make our department more visible. It made better sense to have this solution than just something that helped our one engineer engineer QoS better. 

Our SD-WAN is not directly a product that needs Scrutinizer to be effective. I would almost consider it a slight competitor. Its internal metrics and tools provide a very similar insight to what Scrutinizer does. It is the only product that I probably have in my entire architecture that doesn't need Scrutinizer to watch it. It watches itself with a little better clarity, but that is only because it knows itself really well. 

Our SD-WAN solution, CloudGenix, is able to do some IPFIX. We don't send it at Scrutinizer, because their data is just as good, and there is no need to duplicate it on the network.

I would strongly advise that you look at selling the tool as a self-visibility tool to other departments and areas of your business. It makes a great internal status page that others can look at. If an end user or manager hears a complaint about something, then they have a page that they can go to, to say, "How's the network doing?" It saves a lot of calls. I think for the tool to be its own internal health selling point is something to not overlook.

I would rate the product as a 10 (out of 10).

The primary use case is to analyze the flow found within the network. It helps us understand how the network is used, e.g., if it is mainly used for email or private application.

It is very difficult to use functionality and provide features to understand how in the future the network will be used because the application is growing and developing so fast. So, the data flow could be exponential. That's why it's a daily challenge to understand how the network is in use and how we can manage to renegotiate the contract to improve the bandwidth, but it has very good tools concerning the network and network analysis. It has helped us a lot with troubleshooting.

I am using the latest version.

If an application is encountering an issue, and some people say, "Oh, this is the network's fault." We need to prove otherwise the problem application isn't working. Therefore, Scrutinizer helps us to verify the info and comply.

We have SQL Server all around the world. Because most replication happens almost equally, if we want to understand how the replication is doing, we can use Scrutinizer to put a filter on it. We can match older servers around the world, comparing the data transfer from each site to understand if some behaviors are different and why they are not the same. The tool helps developers to improve the application.

We use the solution specifically to help reduce the time to resolution for network and/or security events. It reduces the time to resolution by two to three hours (if everything is done by hand). With Scrutinizer, it takes maybe 15 minutes.

People are usually calling me, or bombing me by emails, and asking me to check what exactly is happening. So, Scrutinizer helps me have a better picture of network traffic and a few security issues.

It has a very user-friendly interface. 

The mapping is most key. It is very important for us and is very nice. It's important for us to see who is communicating with what and where. So, we have had many requests to understand in the network which devices are connected to others. Most people don't have this information or are able to establish a map of data flow everywhere around the network. Scrutinizer can really help with this. We are using it to understand who is talking to what, how, and which protocols can help us to improve security and analyze flow.

We use the flow analysis and graphical interface to analyze a different flow along with using some filters in order to drill down where the problem is coming from. These are the main features that I use Scrutinizer for. We implement them in specific reports. But, with so much information, in the end, we had to stop.

We have tried to extract a map of data flow information, but I think we have to use a JSON query with API in order to query Scrutinizer to pull out some information in order to make some correlation with other third-party tools. We never had the opportunity to do this. It is something that would be nice to do, but it's very labor intensive.

I really would like to exploit the metadata to match it with other applications using the API, but this is not yet available. I'm not sure that we'll go that way because all the work that we have to do in order just to extract the metadata from Scrutinizer. We'll have to correlate with all the information from other systems. For that reason, I'm not sure it's going to happen. It will be very interesting though. 

I would like them to improve the update process. It's so complicated now that it switched to Linux. This makes the server more stable because before we were running it on Windows. The fact that they use Linux is very good and makes it more stable. However, updates never happen in one day or on our own. So, every time we need to call Plixer to proceed with the update, and they are very efficient in that. However, if they could make it a bit easier to upgrade, e.g., a click from the web interface to update the system, this would be nice.

For updating the Scrutinizer platform, when we have the actual data, it never happens in one day. Every time we have the data, we are obliged to install a new server in order to integrate the old data, and every time it has a problem. Most of the time, we were obliged to scrap all the data because we couldn't transfer it to the new server. So, it would be very good if they could improve this part.

Concerning the NetFlow, we have encountered many issues with some routers that don't send proper tickets. All the time, we're obliged to logon to SSH and run pcap. Pcap is just the packet capture. We are obliged to enter into the Linux to run some pcap on the common line, which is not great. It would be very nice if they integrated the pcap features through the web in order to analyze them. It's very easy. Most of the tools that we're using, and that are on the market, provide this feature. It would be great if Plixer integrated the pcap functionality through the web interface without having to enter into the Linux system.

The security part could also be improved. It would be great if they could implement a better algorithm inside the Scrutinizer to detect if there were attacks. The current algorithm to check if there has been a DNS attack is very light.

I have using the solution for a pretty long time, since 2013.

It is quite stable. We did just encounter a very strange device (a network scanner) which sends us so many flows that the device almost crashed the server of Plixer. However, this is exceptional. We just discovered this issue about a one week ago. Otherwise, Plixer is very steady and has worked very well. We usually never encounter an issue. It is great. 

Because we use the main dashboard for maps to understand the use of the link and present it on the big screen TV, sometimes we are obliged to reset the browser everyday in order to refresh it. We had some little bugs because of this, but we don't know yet if this is coming from Mozilla Firefox, the browser, etc. Otherwise, it is very good.

It is very good. It's very scalable, as long as you have their license.

There are no more than 10 people who have access to the solution. We have 10 to 15 administrators with accounts who are technical. 

Two network administrators are more than enough for deployment and maintenance. Usually, one network administrator is taking care of this. Sometimes, I'm backing up, but otherwise, only one person is necessary to manage it.

This was our first solution to collect the flow. We were looking for a device for a long time, and we are very happy with Scrutinizer.

The first time the initial setup happened with an integrator, and it was very easy because we just implemented on Windows. After that, we changed to the new version of Scrutinizer, then we just call Plixer in order to do it because there are too many things to take into consideration, especially if we don't want to lose data. This also has room for improvement.

Anytime a deployment happens, because it's Linux, we require the help of Plixer. We are very happy to work with Plixer. They are very efficient and know what they are doing. With one simple call, they can help us update the system.

The initial deployment was done by Plixer, so it took one hour to install it. We provided the OVA to deploy it, then Plixer configured it. The new implementation was one hour and very fast. 

I would base ROI on the time that we gained and productivity. It is difficult to make a return of investment based on productivity. Mainly, I would say the time saved.

The license is per device. We have 50 devices.

We just renewed. The pricing is 5,000 euro per year. This is the final price. All tax (20 percent) is included.

We did look at other vendors and solutions, but because of our current monitoring system, we needed a complimentary system. During 2013, we made this substantial investment using Plixer. But, if we had to change everything now, it depends on the correct strategy. To replace Scrutinizer would be very difficult. That's the reason way we don't want to change it.

In terms of monitoring, the biggest competitor would be SolarWinds because they integrate an operations manager from another managing giant. They also provide a data flow collector and reporting variability with extensive monitoring ability for SMTP and troubleshooting. So, if you want an all in one solution, then maybe it will be different with them. 

Most users in our company have all the monitoring tools, people prefer to logon to Scrutinizer to see how the network is going instead of using all the monitoring tools because it is so user-friendly.

It is a pretty good tool.

The deployment plan was to help us be more efficient and proactive regarding data flows and security on this domain.

It helped me realize the main data flow is not controlled by anybody. By using these tools, it made me realize that developers and all these people that create applications don't know anything about the application that they've developed. It made me realize that developers are developing approximately. They are not very precise when we analyze it.

You can trust the Plixer developer, because they are a very capable company. If you really want to know what's happening on your network, this is one of the best tools that you can use. Especially after something happens, you can really use it and count on the tool to help find out the issue.

I would rate the solution an eight (out of 10).

Our primary use case is network monitoring, and security goes hand in hand with that. They're two sides of the same coin. From a network-monitoring perspective, we keep an eye on network links at all times, on the bandwidth usage percentage. It allows us to quickly identify what is consuming bandwidth on a link.

On the security side, it allows us to see issues that occur in the network. Someone might be running up a Tor session. Someone might be trying to hack into something internally or externally. Or there might be excessive use against a particular host or a particular port in our host. 

So those two use cases go hand in hand.

It's strictly on-prem. We're a financial organization within Australia and our government regulators say that you must keep all your data, whether it be financial or IP addressing or network related, on-prem. We run a virtual machine with 250 endpoints.

Scrutinizer helps enrich the data context of network traffic. For example, one of our sub-organizations is primarily responsible for stock trading. They use a time-critical stock trading application called IRESS, here in Australia. I believe it's similar to a Bloomberg-based system in the U.S., but it's based across the Australian stock exchange. That sub-organization of ours has people onsite in their Sydney office who may be doing database operations. They might be copying a 25 GB database across the network. We can immediately tell the head of operations there that they've got an issue because this particular person is copying this database from this source to this destination and that this is the reason that all the network bandwidth is being used.

In addition, the insight that the solution provides us as a result of its correlation of traffic flows and metadata is invaluable. As a network engineer, I don't understand how people operate without it. Without that sort of visibility into what's actually going on in the network, you're running blind. There are other very similar tools in the marketplace, but nothing comes close to the Plixer solution.

Another way it benefits our organization is that it gives us the ability to identify faults and rectify them quickly. It allows us to look at the way people operate in the environment. For example, people were moving around between PCs in a hot-desking scenario, with full home-drive sync and full email sync on. That was consuming a lot of bandwidth across the network. I was able to work with our Exchange teams and Windows teams and explain to them that they should turn off the full email sync and do headers only, and that they needed to stop syncing the entire H drive component. Some of our end users had up to 25 GBs on their home drive, so when they're moving from PC to PC in a hot-desking scenario, that's crazy. We could see that they were consuming all the bandwidth constantly on this particular link. I would estimate that we have improved bandwidth availability by at least 25 percent, throughout the entire day. That's the sort of value we get out of the tool. We knew it was happening, but the ability to prove it to the business units and say, "This is what's actually causing the problem," is just invaluable.

Moreover, we previously we had a 1 GB DCI between our two data centers and we could quite clearly see that it was running at 100 percent the entire time. It got to the point, with the backup solutions running between our primary and secondary data centers, that it was never able to catch up. Using that information, we were able to make a case to our business that we needed to increase our DCI from 1 GB to 10 GB. That improved the backup performance and backups were able to complete successfully. The business is able to continue without any worrying about the backups not being successful.

We're very unique within Australia because we have our data sovereignty laws requiring us to have an on-premise control plane. The customers I've been working with mostly use off-prem or cloud-based control planes. Because we'd set up our vSmart/vManage inside our own data centers, it was unique. Only about 5 or 10 percent of their customers actually had that capability. So to be able to give them access to our environment to actually help develop the solution allowed them to move forward, and provide relatively good visibility, visibility which enhanced what came out of the vManage control plane. That helped us to proactively know when SD-WAN topology changes. In the vManage, we knew events were occurring, but the Scrutinizer solution allowed us to visualize that in a graphical format and to show the business how telephony calls or video or business-critical applications are being moved between links, based on the real-time performance of those links.

As a result, the first thing we did — because we had a combination of fixed wireless and fibre — was to go back to our service provider and say we don't want any more fixed wireless. Most of our branch sites were dual MPLS. We did have a sub-unit that was franchised using Ethernet solutions, but our dual MPLS connections were provided by fiber, primarily, and fixed wireless as a backup or alternate link. We could see quite clearly that our data was constantly being moved over fixed wireless due to issues with the way that the radios were deployed or the ways that the radios were tuned. As a result of that, the service provider went back to its fixed wireless division and made them do some work to improve the service.

Scrutinizer has also helped to reduce the time to resolution, especially for network events. Without some sort of application visibility and control system, you have no visibility into what the problem is. All you have is your best guess. Having that recorded data, and being able to play it back and look across time at bandwidth utilization, enables us to show problems to the business and eliminate them immediately. I had it on a big screen next to the operation sections. As soon as something went red, we clicked on it and we understood the traffic flow that was causing the problem. And if it was not legitimate, we were able to go directly to that end-user, because we had it tied into our AD, and tell that end-user to stop doing what they were doing or to do it outside business hours. Now, our mean time to remediation is about five to 10 minutes, maximum. Without using Scrutinizer, we'd be best-guessing for hours on end. When you have a look at, for example, what's going through a router, you look at the percentage usage on the interface. You can't look at per-flow analytics.

The whole package is valuable.

Personally, as a network engineer, the ability to identify what traffic on the link is consuming all the bandwidth at any given time, and provide immediate feedback to the business, is the most valuable feature.

We've also got the advanced reporting on the security side of it, not the NetFlow side. We've always had that integrated into our SIEM solution. It's one of the things you can add on top of what Plixer offers as a base package. It runs analytics over all the NetFlow and then provides signature-based recognition of problems in the network environment and provides that feedback through a reporting mechanism. We've customized it to push that into our SIEM solution.

There is room for improvement around the data that they have on the website about solutions. I understand that putting a particular appliance into any given organization is going to bring its own challenges — and Plixer does do a good job of blogging it — but they should have more templated solutions on their website. Going out and identifying how to do RTP performance with a Cisco router, or how to do application response times in an Arrista data center deployment was where most of the work was. We had to identify the end-vendor's configuration where Scrutinizer worked. They should spend some more time documenting solutions and putting together white papers.

I've been using the product since 2014.

It's very stable. It can go up to a year or two without a reboot. It mainly gets rebooted when I do an upgrade.

During 2015 there were a couple of releases and I had a few stability issues. That was mostly because I moved the database from a Windows appliance to the Linux back-end. It didn't quite sync across. I just deleted the maps and rebuilt them from scratch and that fixed all the problems. That was the only real stability issue we've had across the journey.

We had one upgrade that didn't go as well as it could have, but Anna was able to jump on it with our support engineer and fix it within 15 minutes. It was just a matter of reaching out. They were on the phone within 20 to 30 minutes and got it sorted for us.

We're running 250 reporting end-points across our firewalls, data center switching, the SD-WAN deployment, and our branch and campus switching — all off a VM. If I was going to run any more than that, I would probably look at a hardware appliance or a distributed model.

We don't currently have plans to increase usage, but our organization invests in a lot of other organizations and that's when we would use it more. For example, in 2016 we bought another financial organization and we had to deploy to another 10 branches with 20 appliances, plus switches. It just depends upon what the business requires. I've got good visibility across my entire environment at the moment.

Their tech support is unbelievable. They're really good. I've never been out of sorts for more than 15 minutes. That's a fantastic response time, considering I'm in Australia and they're in the U.S. The guys are mostly in Maine and they jump on after hours to help me out. These guys are awesome and if I've got problems with it, I know that I can reach out and they'll sort me out immediately.

There's no comparison to some of the other vendors I've worked with. I've had maintenance with Cisco and it has taken them nine days to replace a device. It's to the point where I no longer have maintenance of any of my Cisco gear with Cisco. I've gone to a third-party. 

My predecessor made the decision. He's a very security-minded, security-focused individual. Most of the other vendors are providing a solution that looks at NetFlow analytics and that's it. Scrutinizer provides NetFlow analytics of network performance, but also provides security.

We do use Darktrace for a different reason, on top of Plixer. But the advanced reporting from Plixer is providing me more detail than Darktrace. Darktrace is giving us some good PLP stuff, but they are for different purposes. Darktrace is looking for more shadow-IT stuff, where Plixer is looking at more real-time flow and analytics.

Plixer's years of experience in delivering security and network visibility solutions influenced our decision to go with them. They seemed to have a solid solution, out-of-the-box, in 2014. Back then, AVC was not something that was widely deployed. That was pretty much the stone age of application visibility control, especially in Australia. There are still not a lot of people using AVC.

It has a steep learning curve, not because the product is hard to use but because to actually deploy application visibility control, you need to have a fairly in-depth understanding of networks, network flows, and application visibility control. In my case, it was an NBAR deployment, which is the Cisco Layer 7 DPI. You need to understand quality of service and how that actually all ties in. To be able to use the product effectively, you need to be a fairly advanced network engineer.

Once you've got it set up, you can then give that information to the service desk and the service desk can immediately see what's happening, without having to annoy me. Once it was set up and deployed, we were able to give it to everyone within the IT infrastructure, and the service desk, and they were able to find the problems on their own, straight away, without having to deal with the network team.

The initial deployment to get it set up was a matter of a change to include NetFlow export on all my WAN routers and my internet routers. The deployment of the appliance took about half an hour. But it was the going around and configuring all the routers that took up most of the time. With all the configuration it took a very long time. In a production environment, you can't just go around and make changes on devices. I had to go and present the change to the change advisory board. There was all the paperwork associated with a particular change. And then rolling it out across the entire production environment, where I had 80 branch sites that were dual MPLS, and 40 or 60 non-MPLS Ethernet-based connection sites, it took about 100 hours. But that is not a reflection on the Plixer solution, that was a reflection on the way that my system internally works with change and the time it takes to actually do things.

The strategy was that once we got it up and saw flows in there, we then went and deployed it globally on all our routers. Over the years we gradually made changes. Once a year, we sit down and have a look at our quality of service and application visibility control. That's a pretty intensive process of understanding what sort of applications are running in the environment and then categorizing them through the quality of service side of the house. We then look at what we want to be monitoring in detail — in particular, with response time for applications or real-time flows in the environment, and fine-tuning our IPFX policies that are deployed on our Cisco routers. That's a little bit time-consuming, but again, that's not a reflection on the Scrutinizer.

I did it all myself.

We didn't need a great deal of time with Plixer, once we got it up and running. I worked with someone there for about three to four hours who gave me some more information about how to use the appliances properly. Because she was very good at what she does, I was able to get that information and deploy it immediately. It came down to working with the individual vendors' products: Palo Alto firewalls, Cisco Nexus data center switches, Arrista sFlow. I had it deployed on Cisco ISR 2s, ISR 3s, and ISRs. I had it running on the Cisco 9300 and 3850 series switches, as well.

The ability to fault-find and provide business continuity and the speed to resolution has been the return on investment. People can see what's going on in the network. They're not wandering around for two to three hours, not being able to do their job because there are problems in the network. We can immediately see that this person is doing the wrong thing and we can say, "Stop it." Previously, we would have had to wait for that person to finish what they were doing, and that could bring all 2,500 users down for a period of time.

We pay our one-off cost for the licenses, per device, in blocks of 50. And then we pay an annual maintenance fee of about $15,000 Australian, which is, at this point in time, about $9,000 US, for those 250 devices. The upfront costs for the 250-license use, were about $50,000 Australian, which is about $32,000 US.

There is also the cost of the infrastructure, but that's a little bit hidden: the storage infrastructure and computer infrastructure to run it.

The price point is on par with its competitors, but you get more value for money out of Plixer because you get that security focus as well.

We evaluated quite a few, including open-source. The one that came closest was the LiveAction Networks solution, because that's what Cisco recommended at the time. But it was looking at network performance, not security. Plixer was like killing two birds with one stone. It had a better platform for network performance monitoring and it gives you the bonus of security monitoring.

The way that LiveAction displays traffic between devices in a map is probably a little bit better. Aside from that, the level of data that you can drill down to within Plixer is significantly enhanced, compared to LiveAction.

Overall, Scrutinizer has much better functionality.

The biggest lesson I've learned, personally, by using Scrutinizer, is that not many people understand what's going on in their network with their own applications.

My advice would be more around the equipment you're deploying it on, the exporters. Plixer is very easy to set up and get running. If you're going to be running more than 30,000 or 40,000 flows, go with the hardware version. But, be aware that IP effects exporting on Cisco devices; it can take a heavy toll on CPU.

For maintenance, it's pretty much just me. It's pretty easy to keep up and running. My team can do it, but I'm the guy who handles it. There isn't a massive overhead to manage it. The things that took a little bit of time were fine-tuning data retention, policies, etc., based upon A) what the business needs, to be able to fault-find, and B) the storage availability, based upon the number of flows in our environment, because we're running up to 30,000 flows per second.

We have about 30 users across the whole of the IT infrastructure. There are five primary users within the network team, plus me. Then we have the rest of the infrastructure team, which has about 15 people, and we have the service desk personnel, where there are 10 to 15 users.

I honestly don't think there are many areas where Scrutinizer could be improved. It's a pretty robust, out-of-the-box solution. When you compare it to other AVC solutions for monitoring purposes, it's fairly feature-packed. To use 100 percent of the features is almost impossible. For the first few years, until I became comfortable with the solution, I was only using 10 to 20 percent of them. Once I understood, and spent some time working with the team at Plixer, and they gave me some good feedback on how I could use this in our environment, that's when I started using 50 to 60 percent of the feature set. I still don't use 40 percent of the features because I just don't have a need for them in my particular environment.

I've been really happy with it. And because they're such a well-meshed organization, I've had access to everyone from my sales rep to the head of support to the VP to the CEO of the organization. I've talked to all these people over the years. They're very customer-focused. It helps you to be able to achieve your goals. As a network engineer, you don't want to be whining about your monitoring solutions. You want to be using them to worry about the problems that are happening in the network. They've taken the concern about monitoring off my plate and allowed me to focus on my job.

Our primary use is troubleshooting. Our secondary use is capacity planning, investigations, and reporting. We use it with multiple vendors sending flows to us.

The solution helps us enrich our network traffic. It's really because of the ability to do host-to-host troubleshooting. We can see and isolate where the challenge or problem might be.

When used to troubleshoot a potential bad actor or issue, we have literally able to cut down our time to resolution drastically. For example, we had a "runaway instance" of hogging and taking up excessive resources from a source to a destination, and this allowed us to isolate it within minutes. Any tool of this type, if you know how to use it, will drastically reduce your time to troubleshoot.

The whole thing is valuable because it's such a massive product. We love every bit of it. We use every bit of it that we can. The reporting and generating troubleshooting reports would be the best feature; our host-to-host conversation reporting.

Knowing that they're coming out with a new user interface, that is an area where there is room for improvement. There are so many variables. They should limit the variables in the user interface and create some classes, like "simple," "novice," and "expert" to narrow down the variables within it.

We have been using the solution for about five years. We keep the version up to date, within 30 days of whenever it's deployed. We use it on-premise, but we literally just asked for a quote for the private cloud version.

It's rock-solid. 

It sits there and it runs solidly. There are multiple people in there every day doing some sort of report-generation or review. We don't have any plan to expand usage.

The scalability is excellent. It more than meets our needs. We had a certain size and we've had no problems scaling up and down.

The solution's technical support is second to none.

They set it up for us. It was straightforward. Start to finish, we were done in two days because that's how long they were onsite.

It was done by the vendor. Our experience with them was fantastic. They are some of the most knowledgeable people. I would put their knowledge — the people that they have and how long I've worked with them, how long they retain them, and how good they are, and how much they all know — I would put them on par with the best I've worked with in my 25 years in IT.

Our entire solution, amortized over five years, is in the vicinity of $40,000 to $50,000 a year. There are no additional costs because they're appliances. We buy them full-blown.

We liked this one the best of the ones we evaluated. We chose Scrutinizer over two other solutions. One was the incumbent but it was so long ago that I don't remember its name. We also reviewed LiveAction LiveNX.

The capacity the Plixer system can handle and the cost of that capacity were among the deciding factors, as was the performance when you run reports and get results. This is a big tool and it's analytics. Minutes count when something's broken. Scrutinizer did it faster. If something took five minutes, Scrutinizer took three.

I don't think it lost in any category that we cared about.

Compared to the other solutions, it is in the top two for usability, and it is at the top for capacity, performance, and cost.

In addition, the vendor's years of experience in delivering security and network visibility influenced our decision absolutely. We knew their support was excellent, that the vendor has the knowledge, and there was also the fact that they did this one thing and this one thing only. They concentrate on doing it really well. It wasn't a secondary offering. This is their job. This is their only task, and they do it really well.

Whatever other solutions you want to look at, benchmark them against this solution. No matter what product you're looking at, do a bake-off with this and see who wins. If you don't give him a chance, you're not going to know. You're going to miss out. I really feel, after reviewing three at one time and knowing some other ones, the bang and performance for the dollars, and the capacity and the flexibility; it's really second to none in those situations. Other ones might have matched it in one or two of those criteria, but all they did was match it. They didn't win in any of them.

It's a collector of information and it works great.

Our biggest lesson from using Scrutinizer is that, even as you generate reports and use it, it feels like an educational tool. It helps to educate us. You learn a lot more about general networking using the tool mainly because you understand it, in the same way you learn your ABCs before you learn to spell. It's the whole crawl, walk, run theory.

There are about 25 people using it, and their roles are all IT infrastructure. This helps everybody in the organization, all 3,500 people. But if you ask them, aside from the 25, only five in the broader organization would know that it helps them. You couldn't even ask them whether it helps them because we get warnings and reports and we're able to isolate and troubleshoot in ten minutes an issue that might have taken more than ten minutes. That's why we have the tool. We let everybody view certain things, so if I click "Send a Report" to somebody in IT, all 500 people in IT could look at it and it might mean something to them; it might not.

In terms of maintenance, there are only two people who maintain and run this on an ongoing basis and it takes less than one percent of their time. They have plenty of other stuff to do. That's why it's good to have this tool. It's just stable and solid.

We were looking for something that would tell us what our bandwidth utilization is. My security guy uses it every once in a while to see if an IP address or URL has ever crossed our network. He can get that kind of information from a security standpoint. I know there are other uses that we really haven't used it for, but our primary still remains the bandwidth utilization. 

Whenever it happens that my first responders get a call about a problem at one of our 16 locations, it's one of the primary tools that they'll grab to see what it's saying. 

Currently, we have Plixer deployed on-premise. We have just recently moved some of our servers to the cloud, and I am looking to talk to them in the next month or two about setting up monitoring on the cloud, because we are on AWS.

I once got a call from one of my branch operations and they said that the teller line had just frozen up and they just flat were not able to do business. It just wasn't working. I said, "Okay, well let me do some troubleshooting." I grabbed Scrutinizer and looked to see if, in fact, the bandwidth was being slammed pretty hard. It revealed, really quickly — within a couple of minutes after I started troubleshooting the problem — that somebody was running a video capture across a very slow link. I was able to find out who the employees were, via Plixer. I quickly called the lady who was in charge of our security cameras, and said, "Wait a minute, you're taking the whole place down. Can you turn it off and let me see if that fixes it?" She said, "Oh, I'm sorry." She turned it off, and as soon as I saw her turn it off in Scrutinizer, they were back in operation.

It has definitely helped to reduce time to resolution for network and security events. This is the tool that I grab first. It gave us better than 50 percent accuracy when we started using it. My boss was a little bit skeptical and I was a little bit skeptical. I told the sales team at Plixer, "We'll go ahead and purchase it for the first year. If everything that you guys are telling me is true, then we're going to be really happy with it." And my boss and I have been very happy with the product.

Whenever I have Microsoft SQL or even workstations that all of a sudden start running amuck, taking way more bandwidth than what they normally should be taking, I can usually pinpoint things very quickly. I've got to be able to see what's going on in the wires, so, I call Scrutinizer my "Superman X-ray vision" for looking at the wires.

It's agnostic as far as what your network gear is. As long as it supports an sFlow, JFlow, NetFlow, some kind of flow monitoring, Plixer will support it very well.

It also facilitates the enrichment of the data context of network traffic because you get a very clear picture of what's going on across your wires. I gave my managers the following example: If I can't see into the wires regarding what's going on across them, then I can't really manage them or troubleshoot things. Scrutinizer allows me to do a little bit of both. It allows me to analyze things — not to the point of being a packet analyzer; it doesn't do that and that's not its function — and can give me an idea and point me in the right direction if I'm troubleshooting something. 

It can also be what I would call a "projection tool." If you do daily or weekly or even monthly reports, it'll keep pretty good track of how much your bandwidth utilization goes up or down, allowing you to do predictive analysis via some of their reports. It's helped me know whenever I've had a circuit that was heading towards saturation.

The insight the solution provides as a result of its correlation of traffic flows and metadata is unique. It provides you with a unique perspective that I've only found with a couple of other tools. There are other tools out there that will do what Scrutinizer does. But what I have found with Scrutinizer is that it does it very quickly. I've taken 25 million individual data fragments from the different sensors, and it has graphed that and mapped it and presented a picture within 30 seconds. It has a very efficient database algorithm that I am really impressed with.

I do believe, if you ask the CEO of Plixer, that speed is one of their guiding milestones. They have a goal of being able to present data to the user, whenever it's requested, within 30 seconds or 60 seconds. In comparison to what I had previously, I could start a report, go to lunch for an hour or hour-and-a-half, come back, and it would still be grinding away on the database and not have generated the report. When I do that same type of analysis with Scrutinizer, I'm able to see that report within 30 seconds.

They're working on the security areas, so it can provide more insight. What they have is still pretty much IP-concentric. If they were to make it IP and URL, they'd be a little bit ahead on that. I'm not sure exactly where they're at on that topic.

I've been using Plixer for about three to four years.

It's one of the most stable platforms I've worked with.

The scalability comes from Plixer's ability to have different log collectors. You can separate the database collection point from the log collectors. You can also have different database points as well, and roll those up. That seems to be very scalable. Although, to be fair, I didn't have to scale mine up that much for 63 devices. I just have the one device which is also the log collector, so I was able to keep it all on one server.

We do not have plans to increase its usage. The majority of current usage, about 80 percent if not higher, is as a first-responder type of setup. If we have a problem, Scrutinizer is almost the first thing that we look at to determine what's going on, traffic-wise.

Whenever we call in for support, 99 out of 100 times, the first person we talk to can resolve our issue. They have an extremely good support team set up. Their folks are very knowledgeable. And that covers everything from troubleshooting a problem to actually doing upgrades. 

I have called in and said, "I really don't have the time right now, but I know I need to upgrade. Can I just give you access remotely and then let you upgrade it?" And they've done it for me. We're very happy with their support.

I work with a small credit union near Seattle, Washington. I found Plixer by checking and doing some blog searches and asking for recommendations from other network engineers.

Previously, we used SolarWinds' NetFlow Traffic Analyzer module. It did the job, but it was extremely slow. That was the primary reason we switched. So we looked around, and this was the best solution that we came up with, as far as bandwidth utilization goes.

The initial setup was fairly straightforward. I did engage their engineers during the setup to make sure that I was following their best practices. Overall, it's fairly straightforward, not only for the installs but for their updates which are very consistent as well. I don't even think updating takes it offline, except for whenever you have to do a reboot. You're online 24/7 and 365, unless you have to reboot for an update. And then it takes about 15 to 20 minutes to reboot it. It checks itself all over the place.

The full deployment took me about a week and that also involved the configuration and acquiring the sensors. Fixing up the base unit for Scrutinizer took a very short time. I did that in almost an afternoon, four hours or less. What did take some time — and if you do go with Scrutinizer, I will tell you to allocate the time — was that I had 60 devices that I had to go around and configure and get working. It took me a week to get it all dialed in, but that was just making sure that everything was recording correctly and working.

Our deployment plan was to first get the Scrutinizer base unit installed, up, and operating. We tested that by having one device report into it, a device that we were pretty familiar with what it was doing. Once we got that one base unit up and running, we configured the one device so that it was reporting JFlows, because we're using Juniper. Once we were satisfied that the unit was up and was accepting traffic and that we could do what we wanted, I had a total of 63 other devices that I went around to within my organization and pointed them at it.

We believe we have seen ROI with Plixer.

I said, "I need a tool." And they said, "Well, okay fine. One, tell us the cost. And two, tell us how long your projected return on investment is going to be." I found Plixer, and I said, "For the cost of what we're paying," at that time for SolarWinds, which was well over $20,000 a year, "this will do everything that we need it to do and will reduce our costs from what we currently have." 

There was an ROI calculation done on SolarWinds, but once their licensing exceeded $15,000, because it just kept going up and up, we were actually losing ground with them. That's one reason we replaced SolarWinds with the Scrutinizer.

They charge you by the number of sensors. The licensing model that they use, because it's on a number basis, means you don't have to have any cryptic SSL certs or anything else to install that are really difficult. For that part of it, the deployment and the installation, you have to make sure that server is right. Once it's up and running, you start pointing your devices towards it and there's no crypto that you have to decrypt or anything else. The licensing is all maintained through the number of sensors that are reporting into it.

Compared to some of the other tools we have, it's incredibly reasonably priced. The best part about that is that if you talk to their sales force, they'll give you a demo for either 30 or 60 days. In that 30 or 60 days, when we set the server it was for a couple of devices, just to test-harness it and see if it was going to do what we thought it was going to do. They'll let you see if you think you're going to be happy with it.

There are some additional modules that can be activated. I believe there's advanced reporting but I don't actually use some of their advanced features. There are additional modules that come with additional costs.

We did compare it against SolarWind's NTA and against another product as well.

SolarWinds was more of an all-things-to-all-people type of tool with a lot of different blades on the Swiss Army knife. Whereas Scrutinizer is pretty much one blade. I've got to be careful when I say that, because it still does a lot. But its main function is traffic analysis on the wire. And that's what makes it shine, because it does that one thing really well.

The biggest lesson I have learned from using Scrutinizer is don't be afraid to give the little guy a chance.

In terms of advice, every environment is different. You really need to kick the tires on it a little bit and try it before you buy. While it met my needs, and it met our environment very well, your mileage could vary on that. While I believe it to be a very solid, very good product, I would say: Put it in your environment and kick the tires on it a little bit.

When I did kick the tires, during that initial demo time, I wasn't able to get everything set up that I wanted to. They immediately gave me an additional 30 or 60 days. They're really good about that.

Plixer is a fairly young company, as far as Scrutinizer goes. That's usually a strike against somebody but, in their case, I think they went into it without any preconceived notions. Instead of being all things to everybody, they said, "Okay, we want to be able to do one thing really well," and they did it. That's what they specialize in. Although they could branch out and do all kinds of things with it, they're staying pretty true to what they originally planned to use the tool for. I'm going to be very surprised if they're not bought up by a bigger company which integrates Scrutinizer into its product as a module, because it's just that efficient.

It's its own little data silo. It's got a database in it. We've never really used it for eliminating data silos, although it certainly could be used for that.

I'm just now deploying an SD-WAN. When I saw that they were supporting that, I was ecstatic about it. I called them up to make sure that the SD-WAN we had chosen would be supported. In talking with them, they said they didn't have support yet for the particular brand that I had selected, but they were very interested in working with me, once I got it deployed and that they would support it. That was really nice.

Something that I hope they keep doing is maintaining the database efficiency that they get the speed from. It is just absolutely astounding how they can take data in and get those graph pictures, which they call "Plixers," painted. If they can keep doing that, and keep that efficient with all the changes that they make, they're going to be miles ahead in my book.

We have five different roles using it. My managers will look at it occasionally for reporting. My desktop folks will use it as a first-responder tool. My security manager will look at it to see if something has crossed our network that was never picked up. In my role, as a network engineer, I will use it the same way as the desktop people, as a first-responder. Finally, I haven't had anybody doing this until now, but I've got one which is going to be for cloud, for my developers to use. For maintenance of the solution, it's just me.

We mostly use it to monitor the network bandwidth utilization on various links.

The solution has helped eliminate data silos for us because now, instead of looking at one or two different places, we can look at it all at once. It aggregates the data so it's not in silos anymore.

Scrutinizer has helped to reduce the time to resolution for network events. We are able to identify a problem and resolve it quickly, within about ten minutes, once the issue has been raised. Before, we had to do more work to get there, about a half-an-hour to 40 minutes. 

In general, there are multiple valuable features, but the ability to view the status of the top-10 at a glance is helpful. We immediately know which link is over-utilized or heavily used. We watch the traffic on different network links. For example, we can see what's going on in New York, how much of the network traffic is on New York links and how much of it is in different cities, wherever our customer has offices. That's a good feature, and it's all in real-time.

We can also run reports. We can generate reports for specific links and look at the historical data.

I would like to see a better user interface for creating what they call maps. The solution creates a visual map of a particular location and how the network flows. You need to spend time to generate all those maps. If they could figure out a way to reduce the time needed to generate the maps, that would be great.

I have been using Scrutinizer for four years.

The stability is pretty good. We like it.

It's scalable. They're coming up with a new way of scaling up. Ours is an appliance but I believe their VM products may be scalable. As far as we are concerned, all we need to do is increase the storage, which we can do by replacing a hard disk.

We are collecting data and the network traffic from almost 70 offices throughout the U.S. If everything goes well and we have the opportunity, we will probably try to increase the Scrutinizer footprint. But right now we're okay with what we have.

Technical support is good. If we open a ticket they call back and we work together to solve issues. They are very responsive. I have no complaints.

Before Scrutinizer, we had to do a lot of things manually. It took more time. But now, with this appliance, we have a more automated way of doing things.

This is an appliance. It's pretty straightforward. It came already implemented and installed. Our deployment took a couple of hours. The plan was to place it in a location where we could see all the traffic.

We did it ourselves.

We have definitely seen a return on our investment. This is a pretty good product. If the opportunity continues, we'll continue to extend the license and keep it.

We did use other products, but they were small network monitoring tools. This is a better way because it comes in an all-in-one package. 

Scrutinizer is a good solution compared to other products because, if you use it correctly, it gives you a lot of data and it has good integration. With other products, we may have to install additional modules or do some additional deployment and integrations, which takes time and maintenance. Scrutinizer is all in one box so we don't have to worry. It internally integrates all the features we need.

Go with it but make sure that you have enough storage. If you don't have enough storage then you'll have to expand it. Talk to the Plixer guys to get the right configuration, depending on your environment.

We see things that we did not see before. It's opened up peoples' eyes, among our network folks. Overall, it has had a good, positive impact.

It's a product where we don't have to give too many people access. There are two or three people, admins, who are watching it, including me. They are network administrators and our system administrators. For deployment and maintenance it requires just one person.

We are using it as one of the key elements in our monitoring infrastructure, certainly on a daily basis. It's very good. It's almost there. With each version they have been improving features. If you compare the latest version which we are using, it's much better than the old versions they had. There are pretty good feature improvements and it's good enough for us for now.

The primary use case is to track utilization flows for security and for scalability. We use it to see network usage.

It has improved our fault-finding by at least 50 percent, and as much as 60 to 70 percent in day-to-day networking because we can now look through historical data. When a user contacts us and says, "I'm having this issue," we can review that person's historical data and see what the device is doing, what the issues are, and where the issues might be. In terms of security, our fault-finding has improved 100 percent because we've now got a total view of what the network is doing, right down to a low level. We can set alerts based on traffic behaviors that we know, and track the behaviors that we detect. The alerts tell us exactly what's going on. That is something we just couldn't do that before.

The context base will then allow us then to take it further, from just the device to the user; who was logged in on that machine. The context base allows us to detect who was using it. And even if they move machines, we will be able to see that movement.

The solution has definitely helped to reduce the time to resolution for network and security events by at least half and by as much as about 70 percent. We've now got all the information that we need.

The workflow helps us in terms of security. We've got Cisco ISE which provides endpoint data, and the Scrutinizer provides traffic data on the endpoints. That integration has helped tremendously because we now have two stacks of data. One tells us where the endpoint is, how it was authenticated on our network, and the other, from Scrutinizer, tells us what it was doing on the network. So that integration workflow has helped us tremendously in identifying what network activity is happening, and where it's happening.

The most valuable features of the solution are the ability to track what a device is doing and to go back historically. It is also able to go down to, and identify, very low levels of traffic. It gives us 100 percent reporting on network activity.

It's valuable in two cases. It assists in network issues and it helps the security of the infrastructure, so that we can see what would normally be innocuous levels of traffic. If people are "tapping on doors" with very low levels of traffic, trying to do scans and the like — we can detect and identify that. We can then set up the scene to alert us when that happens and that's very useful. That is something that we would normally miss.

Scrutinizer also very much helps enrich the data context of network traffic. It can integrate with Active Directory and with other security products like Cisco Identity Services Engine. We can get context-based information from those sources. So we've not only got the traffic levels, but now we've got the context from which those sources are taken. That's very useful.

The insight the solution provides as a result of its correlation of traffic flows and metadata means I can tell you who's doing what at any time.

One of the areas that needs to be looked at is how the databases are created and managed, because they are collecting a massive amount of data. It's a big-data model.

The reporting structure, the front-end GUI, also needs some work. It needs some getting used to. It works fairly well, but it's a technical tool rather than a user tool. You have to understand the structure of the databases before you can really use it. Work is needed on how the front-end user-tool accesses the data and what decisions it makes in terms of accessing that data to get you the response that you need.

I have used the solution for about five years.

It's very stable. We have not had a problem with it.

We have a rather large network and it can cope. So it is scalable. We're running somewhere in the region of about 40,000 active devices, which is rather a lot.

We don't have plans to increase usage. That would depend very much on the university rather than me. I'm happy that the current implementation of Scrutinizer will take what we have right now. We may have to go to a multi-deployment model if we increase our usage dramatically, but within the scope of the next five years I think we'll be fine.

Technical support is very good, very honorable, and very helpful.

The vendor's years of experience in delivering security and network visibility influenced our decision to go with Scrutinizer. Up until recently, up until Cisco bought StealthWatch, Scrutinizer was the NetFlow product for Cisco. They've really got a lot of experience in terms of looking at these things, and the chats reflect that, because you've got all sorts of people writing in and telling you how to do things.

The initial setup was very straightforward. There's a script that creates the Scrutinizer. It creates the network management tool. They have what you would call it a Wiki page, a set of enthusiasts, which tells you exactly how to configure each of the different types of devices to report to Scrutinizer. All you do is create the application, set up each of your devices to report to Scrutinizer, and then you sit back and wait for the data to flow in. The analysis tool then analyzes that data as it comes in.

Deployment time depends on how many end devices there are. In terms of building up the management station, I can do that in half-an-hour. It takes a couple of minutes to add the relevant config lines to each end station.

The implementation strategy was to get information from the core and distribution devices. That covers pretty much all of the traffic associated with our network. All our core and distribution devices are reporting on the traffic they see and then we analyze that data as it comes in.

ROI, for us, is a much better, much faster resolution to security and network incidents, and the ability to make assessments on traffic utilization. For the SIEM, it cuts down our time by half. It's a valuable tool.

We had a look at SolarWinds. The issue with SolarWinds is that it's a statistical model, so it doesn't capture everything, it captures a subset. We dismissed it on that basis. 

We've recently had a look at the Cisco StealthWatch solution but I believe it's a statistical model as well. I need to have a closer look into it. It's fine, but it's about averages. We need a model that captures everything, and that's what Scrutinizer does.

Scrutinizer is better than SolarWinds in terms of functionality. The new Cisco NetFlow product looks to provide — I wouldn't say better functionality — but a better set of graphs, a better user interface. They recently bought a company that provides a better user interface. It's not that you can't do that with Scrutinizer, it's just that it comes out-of-the-box with StealthWatch. But StealthWatch provides it on statistical data, which means that they miss stuff, and it doesn't have a SIEM. Scrutinizer has a SIEM.

If you have a large network then this product is totally invaluable. If you have a large network, this product will tell you exactly what's going on in it. It's not just flows, and this amount of traffic is going out on the internet, but who's doing what on your internet pipes. It will help you. It will cut your incident times in half.

The biggest lesson we have learned from using Scrutinizer is "more data." A lot of data is good. There are tools that can help you. You need to spend some money, but there are tools that can help you.

In terms of eliminating data silos, Scrutinizer does and it doesn't. It creates its own data silo, but the ecosystem approach to the solution helps because now we've got a silo of data that can talk to the likes of SolarWinds, so it doesn't need to keep its own NetFlow data. So it does help.

We haven't used it for SD-WAN visibility yet because we haven't implemented SD-WAN. It's something we're doing at the moment. But I would expect that to be part of that solution.

The solution is largely confined to the network and security teams at the moment, which consist of about 20 to 25 people. We haven't made it available to the end-user support teams yet. That is something that we're thinking about. For deployment, only one person is needed and it's the same for maintenance, from the networking side.