Ep. 36: Introduction to different types of checks for monitoring with Checkmk
[0:00:00] | What are checks and services in Checkmk? Let's find out. |
[0:00:13] | Welcome to the Checkmk Channel. You might have come across several terms when looking at Checkmk. |
[0:00:20] | We have Services, we have Checks, we have Active checks, we have Passive checks. There are Local checks and MRPE-checks. And there is also native plugins or plugins in general. |
[0:00:32] | So, there's a lot of terms and sometimes that creates confusion, what is what. So, in this video, we'll take a closer look at all of these terms and you will learn what is what and how to differentiate between them. |
[0:00:44] | So, let's start with the first one. Let's take a look at services and checks. So, let's take a look at our example host over here. |
[0:00:54] | That has a lot of services, as you can see. And if we navigate to the Service configuration, there was a very easy way to see and understand the difference between services and checks. |
[0:01:05] | We have the option to show the plugin names here. And if we take a look at that, then we can see we have services on the left side. That's this column here. |
[0:01:17] | And we have the check plugins, which are on this side here. And this is what's commonly called checks, which is actually check plugins. And here you can see, for example, we have the df check plugin. |
[0:01:30] | That's there several times and each time it is one service. So, a service basically is the result of a check plugin. And a check plugin can create several services or several instances, if you want to put it that way. |
[0:01:44] | That's the main difference here. And in this view, you can instantly see the difference and what it is. |
[0:01:53] | So, as a consequence, if you want to disable services, for example, you can think about how to approach this question. Because if you look at this, we see there is the df plugin. |
[0:02:05] | So, say, you want to disable all file system checks for some reason, I don't see a reason here, but just for the matter of discussion, you would want to disable all the file system services. |
[0:02:17] | Then we can take a look at the Setup, search for disabled. And there we have the option to, say, Disabled checks. |
[0:02:25] | And that will disable the file system plugin or in this case, or specifically, the df plugin. |
[0:02:31] | But that means that you will get no file system Services whatsoever, no matter where they are, depending on how you configure the rule, of course. But that would disable the monitoring for all file systems. |
[0:02:44] | If you just want to disable the monitoring for certain file systems, then you would go with the rule Disabled services, which would effectively just disable the services that you put in there. |
[0:02:55] | Say, you just don't want to monitor the root file system or the C drive on a Windows system, doesn't make sense at all, don't do that, but you could do it like this. |
[0:03:06] | This is especially interesting if we think about SNMP devices because there you have the possibility to actually disable sections. |
[0:03:15] | So, if you disable services, then you just disable them on the server side. The information is still queried, but the server will not display it in the running monitoring configuration. |
[0:03:26] | With SNMP devices, that would mean that all the information is still queried. But you don't want that because you want to reduce load. |
[0:03:33] | If you're not seeing a service, you don't need the information queried. That's when you would go with the disabled sections because in that case, you wouldn't even fetch the information. |
[0:03:44] | And that also works for the agent, so you could also disable complete sections there and just not fetch the information. |
[0:03:49] | So, this is the first part. This was the difference between services and checks and how to work with disabling them. |
[0:03:58] | So, now let's take another look at what active and passive checks are and what it means. |
[0:04:07] | For that, we navigate again to our example host but this time in the running monitoring configuration. There we are. |
[0:04:15] | And there we can see all the services in here and I'm actually going to use a little trick here to easily showcase what's going on. |
[0:04:24] | This might be something that might help you in a daily business as well. I'm gonna change the built-in icon visibility. And I want to have the reschedule button directly in the column. |
[0:04:38] | You will see in a moment what that does. And if we now go back again to our host, then we can see the circles here, and those are used to reschedule the check. |
[0:04:50] | So, if we want to have up-to-date information, we could reschedule the Checkmk service, and that would fetch all the information. |
[0:04:57] | If you've worked with Checkmk before, you know that the agent fetches all information at once, and then on the server side the results get calculated. |
[0:05:05] | And we can see that here because the Checkmk agent has a yellow circle here. And most of the other services like the file system services, for example, if we scroll down really every most of the services that we have here, have a gray circle, and that means those are passive checks. |
[0:05:23] | And if we hover over them, we can see that it says, "Reschedule 'Checkmk' service," which means, if we reschedule any of these Services effectively, the Checkmk service will be rescheduled and fetch all the information. |
[0:05:36] | And that's the difference here. And a passive check receives information from a data source and then gets presented here. An active check directly does something. |
[0:05:47] | So, in this example, that's the Checkmk agent. That is actively fetching the information, and there are some more checks, as you could see. |
[0:05:54] | So, we have the discovery service, we have the hardware software inventory service, both of them are active checks. |
[0:06:00] | They are not based on the agent themselves, they run directly. And also, we have, for example, other checks which we will discuss in a few moments, which are also active checks and are not based on the agent here. |
[0:06:17] | So, that's the general concept of passiveness and activeness. The next topic that we have are MRPE Checks. |
[0:06:28] | MRPE Checks come from the old Nagios world or from Nagios compatible plugins, and Checkmk can integrate those, and that's what we call MRPE. |
[0:06:40] | That's a system that enables you to use this plugins just like they were Checkmk plugins. |
[0:06:47] | Yeah, they're becoming kind of rare, to be honest. There is certain use cases, but Checkmk covers most of the use cases that you have, so it's kind of a rare situation where you might need them. |
[0:07:00] | But it's still possible to integrate those plugins. Of course, they are not configurable through the user interface or at least, not as nicely as native Checkmk checks. |
[0:07:12] | Yeah, but they're still available. The next thing to extend the services that you're monitoring or to extend the plugins are so-called Local Checks. |
[0:07:21] | That's the easiest way to extend your monitoring because you can write them in really any language your Checkmk agent can run, depending on whether it's on Windows or Linux, for example. |
[0:07:32] | And you can just use the language that you want, but all the logic will be inside that plugin, so it will be a file that's run by the agent, it has to be executable. |
[0:07:42] | And then you put all the logic in there, and you just need to follow a certain format in the output. And this output then gets sent to Checkmk to the Checkmk server. |
[0:07:50] | And that will calculate the results, but there is no configuration done from the Checkmk server side. And how that looks like? We can see in the web UI because I already prepared a check here. let's quickly scroll down. |
[0:08:09] | And that's this nice little service here, My first service. It's an example taken from our official guide, and you can see it's in an OK state. |
[0:08:18] | It just says, yeah, this is a static service, it's always OK. And what that looks like on the agent side? |
[0:08:25] | We can see in the terminal right here. So, if I take a look at that file, I already put it in the local folder of the agent, and there you can see it's just called foo.sh. |
[0:08:37] | And if we take a look at that, we can see the basic format of this local check, which is simply the status code here. |
[0:08:45] | Actually, if we replace that, for example, with 1 for a warning State and write that, we will see that in the user interface in a few moments, then we can see after the status field, we have the service description. This is where the My 1st service comes from. |
[0:09:02] | If there are blanks in there, you have to quote that string, otherwise you just have to get rid of blanks. But you're free how to name your service there, completely free. |
[0:09:12] | Then here where the - is you could put in performance data, that would actually be computed by Checkmk. In this case there is none, so there is this -. |
[0:09:22] | And the last part is the long output, where you can really write anything you want. That gets just sent to the Checkmk server, and as you saw, it is shown in the service summary. |
[0:09:33] | That can be an information that you want there. So, switching back to the user interface, and you can see, as I said, the status has changed here because it's entirely based on the script, but everything else is the same. |
[0:09:47] | The service name is the same and even the long output because I didn't change it. It's the same here and it still says, "it's always OK", although it's not. |
[0:09:55] | So, that's a really easy, really approachable way to extend your monitoring, but it's also quite limited in what you can do with it. So, as a last option that you would have is the Native Checkmk plugin. |
[0:10:13] | And that's really the the gold standard, that you would want to have in the end. |
[0:10:18] | But you have to have Python skills to do that because you need to actually code something, you need to have a check plugin on the server side, that calculates the results of the data that is fetched. |
[0:10:31] | And you need some sort of agent site plugin that will fetch some data for the check plugin to consume and to compute. |
[0:10:38] | That could be, for example, an SNMP check, so it could be fetching an SNMP or ID and using the check plugin to calculate that data. |
[0:10:46] | Or you could put a piece of code into your agent that's fetching some information from that system, sending it to the Checkmk server, and the check plugin there would then compute the result. |
[0:10:58] | But I said, you need some Python skills for that to get started. But then in the end, you will be able to have the very same experience as with built-in plugins that we already ship with Checkmk. |
[0:11:10] | With that, I'm going to leave you for today. Thank you so much for watching. Be sure to subscribe to never miss another video, and I will see you around. |
Want to know more about Checkmk? Join us for our Introduction to Checkmk Webinar