If you were talking to someone whose organization is considering Plixer Scrutinizer, what would you say?
How would you rate it and why? Any other tips or advice?
I would rate it an eight (out of 10).
* 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).
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).
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).
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.
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.
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.
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.
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.
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.