ia-Redmonk-GroundWorkOpenSourceMonitor52Part1585-3

14:45 · SRT · archive.org · all RedMonk TV

0:00

Today we're talking with Groundwork Open Source, or as I just like to shorten it, Groundwork. And we're going to check out some of the features in one of their new product, Groundwork, version 5.2. And we've got two people joining us. Would you like to introduce yourself? Sure. My name's Rich Trezor. I'm the Director of Sales Engineering at Groundwork Open Source. I'll be taking you through a technical overview as well as showing you some of the new features of version 5.2. I'm David Dennis. I'm Senior Director of Product Marketing here at Groundwork. And people may remember you from Groundwork the video that we did a little bit. Perhaps infemously so, yes. That's right. What are we going to take a look at, Rich? So we thought we'd just kind of give you a quick overview of the system with some emphasis on some of the new features. Version 5.2 of the product shipped about three weeks ago. There were some advances in the product that make it easier for users to use some excellent open source applications that we've integrated together in a complete enterprise-ready package. So you're looking at just a basic screen. One of the ways Groundwork makes open source monitoring easier for end users is by packaging together different open source tools together in an integrated way that allows you to maintain the moving forward. So with a single RPM, you've got things like MySQL configured with Apache to run Nagios and SyslogNG and a lot of other common tools that are used by organizations but not really in an integrated way. So as an example of some of the kind of background stuff that you never really look at in pre-dose are just some basic config things that we make easy. For example, we've got different open source tools running. We provide a single sign-on capability between different applications. So I'm expanding down here both the users that are defined on the system as well as some of the packaging that Groundwork provides. So you'll see things like performance applications powered by RRD tool. Customers don't have to worry about compiling from source, open source components.

2:01

We're doing that packaging here as illustrated in this package. Now some of the packaging is also configurable. So here's an example of a log reporting application. So that's part of the enterprise version. It's a reporting engine for the database where we're gathering things like availability as well as performance data. So in some cases, the packaging, kind of that glue between the tools that Groundwork provides is configurable. So here's where I can define the logins to my logging database. The directory where Groundwork is going to aggregate and store traps and syslogs is set here. I can set up some file types. So when those messages are coming in, I want to associate them with hosts. I might do something like this in a configuration to say there's a Windows machine that's sending its logs across. I'm going to associate them. That allows me to set up some types and some classes. And then you can apply filters on those logs. And this can produce for you a summary report. In the default product, we provide some expressions we found useful to monitor over time. So some failed logins for Windows machines. There's also some other expressions set up for things like Cisco firewalls. And you can, of course, also set up your own expressions. And this is going to power underneath one of the reporting applications, the log reporting engine. This is kind of more the illustration of the packaging, right? So Groundwork isn't just giving you a bunch of scripts to go install things. We're actually packaging these because this is a way that we can ensure a smooth upgrade over time. As the different components change, this is how we can track versions. We can, again, avoid the command line setup that's common to a lot of open source applications. And as you get familiar with the system, one of the new upgrades in the 5.2 was changing the way that we deliver the help applications. So here I've just gone into the bookshelf application, which can pop out. Now, as I want to get familiar with, again, the different components, I can go through contents. Or I may have a specific need where maybe I'm looking for a VMware profile.

4:03

And I want to see, well, how does Groundwork set up monitoring of ESX? So right through here I can start to get familiar with, again, the how-tos. You'll see it also shows up in ESX 3. And this was a change in 5.2 because we needed to be able to update the documentation without a whole upgrade of other components. So we actually created a separate package. And I believe this component we're using for the help is called RoboHelp. Oh, right. It's familiar? Absolutely. If I was an admin or someone setting up Groundwork that was going to use it, can I add in my own documentation here for people to look at? You cannot do that with this at this time. Okay. We hear more and more about customers that want to combine like a wiki functionality for them to say, hey, I used this and here were my notes. So we don't have that in the help message. But we do have, and I'll just jump over to, so Groundwork Connect is our support portal. I'm already logged in there, and you'll see that I'm looking at a new plug-in that a customer can download. And they can also make contact, make comments on certain things. So, for example, this group status check is a new kind of profile of plug-in. As customers say, they access that documentation about a particular new feature that's available. We do have the ability to make things like comments on docs, so maybe I want to add a comment here on having this kind of problem. And that's how customers, again, can share information both with Groundwork and we can then publish new contributions to others. All right. That's great. And, again, we want to try to drive more of the ability to have living documents rather than, you know, old paper that's got to be updated and redistributed. Right, right. You're constantly updating things that go out of date once they've been distributed, right? Yeah. As long as we're on Groundwork Connect, maybe we also want to show that in addition to documentation, there's plug-ins and other things you can download from here, too.

6:04

Sure. Yeah, we were just going through this. So here's some contributed content. Now, sometimes this is risky for customers, and there might be a warning that says, hey, only try this if you're an expert. In other cases, you may want to engage with Groundwork's professional services. But here's the current list of checks and plug-ins. And, again, any user both can access content with Groundwork Connect, but you can also maintain your cases. All right. So you'll see here on my cases, I've got a couple of open cases here where I can actually run through them. And, again, Groundwork University training is a great way for users to get familiar with some advanced capabilities as well. So, for example, WMI Exchange is a profile. Now, this is shipped with the product, but rather than have to wait for a new release, the idea with Groundwork Connect is that profiles can be made available more rapidly. So applications in the system, again, are based on the permissions. You would have access to administration, or if you're an operator, you would probably just have status or dashboards. New to version 5.2 is the idea of auto-discovery. What we've done there is we've combined a couple of ways to create configurations. You'll see in this example, we've got NMAP doing the TCP scan. And then when we find SNMP devices, we'll actually walk the device to try to identify and automatically assign some monitoring statistics to it. Right. Configuration. Again, it's all graphical. I have to edit some profiles and content. But first, what we'll do is we'll come down to a status and then kind of see how things kind of can get set up. When someone sets up Groundwork for the first time, do you guys recommend that they just run discovery, or is there a different sort of initial setting up that they should do? There's definitely some things that you want to think through first.

8:07

One of the considerations is if you're replacing a monitoring tool, you probably have a good sense of the coverage you need to replace it with. And that gets a little easier. But we also get a fair number of customers that really haven't been putting attention on monitoring. So they're using very little, if anything. And in that case, discovery is a good component because they may not be sure of what devices are out there, as well as what components are running on those devices. Right. And is there a way to do, I don't know what you'd call it, sort of manual discovery, like if you have a spreadsheet or something of all the devices you care about and just import those? Yes, you can. So the idea is that at a high level, you can have a status roll-up of an entire environment. I can create any number of different device groupings, and then the status of those devices is signaled up inside of the internet. So I always like to demonstrate, again, the real value of why we selected Nagios as a key component in the product. And that is because you can see different states of hosts and services. I was an administrator way back, and I remember getting errors or alarm storms where 16, 17, or 30, or 40 things are coming back as failing. Right. Well, how can you set up some dependencies, and then how can you boil that up to know which problem should I be working on first? So here we see we're summarizing, as far as hosts, sorry, they don't have any hosts that are in trouble. Nothing's down, nothing's unreachable. But those are two different states that the system will maintain. Again, think firewall is down instead of 18 web servers. You know, you've got a Nokia checkpoint cluster running with two firewalls. If they're down, nobody gets your web servers. With a proper configuration of network dependencies, Nagios will account for the fact that these firewalls are in my path to those web servers. And it can make web servers, or replace web servers in an unreachable state, and then the firewalls are found to be down. That's one way on the host basis, Nagios allows you to find root cause faster.

10:11

Same thing can happen with services. So Nagios breaks it down into critical warning, unknown, and pending is kind of obvious. But in the case of if I'm doing checks of a website and DNS is down, if I make my website checks dependent on DNS, well, now I'll be able to see that my websites are unknown because the dependencies failed, and the only thing down is my DNS service checks. Right, and like you're saying, the point of all this is to get to the root cause, like the thing that you need to fix, rather than just knowing what the effects of this broken thing may be. Exactly, exactly. And more and more, the operators who are looking at screens like this, they're quite often responsible for two or three areas of IT. Right, this guy's doing storage, he's doing servers, and he's doing security. So how can he, again, save time and really prioritize his activities? Right. I've seen some very large groundwork deployments where you've got two or three people handling thousands of machines. And they're also doing, again, things like storage and multiple tasks. And I've seen those accounts where they have, on any given day, 20 things that could be wrong. That's a lot of equipment to be able to, say, have only got three or four problems at the moment. And, again, owing to its NAGI as being a core feature, it's being able to trend and be dealing with warnings as opposed to criticals. So the illustration and the demonstration, what we show is, here I want to see what are the two warnings that I have. Well, here I can see that I've got a disk problem on a specific host, and I've got another problem with a web check. Because that's in a warning state, I'm able to handle it before there's an outage. All right, tell me that the disk is almost out of space. Don't tell me that the host is down because it's out of space. Exactly. And then further, as part of the workflow, here I can see that this problem has been acknowledged. So a key component is escalations for our customers.

12:12

They want to be able to know that particular problems, if they haven't been addressed within four hours or ten hours, if they've got an SLA on that particular component, they've got to respond within a certain period of time. NAGIOS can escalate, so we make that easier and, again, allow the workflow for somebody to acknowledge. For an example, let's go in and now acknowledge this problem. So I can see that I've been in a warning since March 26th. Now I want to acknowledge this problem, and it will automatically grab my name, and I can report what I'm doing. And this will all be part of the record. I'm checking this now. For me to go back and show that I did my SLA if I needed to. Right. That makes sense. That would be a three-week SLA in this case. That's right. It's a very low-priority thing, like the fax machine server or something like that. We were talking about the difference between a host and a service and so forth and so on. And where can people build those services? So that's a good segue into the configuration. So you were asked earlier, should somebody begin, as soon as they get the product, should they run a discovery? This technician would say, no. You want to think through, almost from a standards-based, what it is that you want to monitor and what it is that we're looking for. For example, my switches, do we know what data we really need to have when we monitor a switch versus a firewall or versus a router? Or if we're running a Windows operating system, what are the basics that we need to be monitoring? And find the variations. With profiles, you can layer them together. But the idea is to kind of know what you're looking for rather than trying to turn on everything. So, again, the company name Groundwork kind of comes from the opposite of what a lot of the more expensive proprietary tools will do.

14:14

And that is they'll very quickly create mountains of data. So now you need lots of personnel to go through that data and try to correlate lots of events and see, well, what's really wrong? So we're taking the opposite approach. We're saying, look, we've got to get CPU disk and memory on any server that we have for good, effective, general-purpose monitoring. Rather than try to get every last possible metric that's there, let's start with the basics and then add on top what we need rather than strip it out from the beginning.

RedMonk TV · 🍕 Get more pizza.