We are starting from scratch with Checkmk RAW v2.1. Because the agent bakery is not included in the RAW edition, we will need to manually install the desired plugins on each host to be monitored. We are aware of this limitation and are okay with it for the time being.
However, because we are fallible humans, we would like to implement a server-side check to ensure that the expected plugins are in place. For example, if we flag a host as being a Windows Domain Controller, we would like to have a check that ensures that the AD Replication Status plugin is present.
Is this something that can be accomplished in Checkmk? Are there reasons that this might be a bad idea?
Well, you can always use mk_filestats for that. Define a group for your plugins and then create a rule under Size, age and count of file groups (mk_filestats). There you can define the minimum and maximum number of files in the group.
Or, if you want to take things to the next level, I advise to implement puppet (or a similar product) to automate plugin distribution.
Using mk_filestats is a good suggestion. I took a look at the documentation (both single and multiple) and this check seems to require agent-side configuration. This creates a chicken-egg problem where we would need to configure the agent to make sure that the agent is correctly configured. Is there something I am missing that explains how this could be implemented server-side only?
While following up on your suggestion I also came across the concept of enforced services, which seems to be what we are looking for. If I am understanding the concept correctly, this would effectively raise an error if the specified service is not found. Is this correct?
In the case of our Windows DC example, I’m looking at Enforced services > Active Directory Replication. The form has a field for “Replication Partner” but it is not clear whether this field accepts regex. The inline help just says “The name of the replication partner (Destination DC Site/Destination DC).” I suspect this means the field will only take a static string, which doesn’t really work. This would require that we create several rules with different replication partners and apply them to different DCs. The administration overhead this creates would negate any value the check offers.
Any additional thoughts or suggestions are greatly appreciated.
Thank you,
Jason
P.S., I agree that the long-term solution should be automated either via a configuration management solution like Puppet or Chef or, more likely in this case, buying an Enterprise license for Checkmk and using the Agent Bakery. We are looking at this as an interim solution only. A sort of configuration management-lite, if you will.
Yes, I’m aware of the chicken / egg problem with using mk_filestats. Now I don’t know how many servers you’re talking about, but since in this case you’ll be wanting it on every server, regardless of the fact if it’s used, so I figured you could make it part of the installation instructions for the client. Then again, if your landscape is already configured, yes you would have to manually install it on every server.
As for the enforced services, before your post I’d never heard about it, so I’m afraid I’m not going to be of much help there. Sorry. But from what I can see it may very well be what you’re looking for.
The reason I suggest a configuration management solution is not that I want to keep you from investing in CheckMK (au contraire; the enterprise edition comes with some other nice features like reporting), but it’s not limited to CheckMK, so you can manage other parts of your servers as well. I’ve been using the open source version of puppt for that for years.
Sorry I cannot be of more help. Maybe someone who knows more about the enforced services can be of better help.
I think the need to configure mk_filestats client-side prevents it from being the solution we want. We could include “make sure you set up mk_filestats” in the rollout documentation for each server, but since mk_filestats configuration would be dependent on the server role, it probably makes more sense to just document the required plugins.
Enforced services seems to fit the bill, but I am still struggling a bit trying to wrap my head around the correct way to implement them. Hopefully someone with experience can chime in and either nudge me along or explain why I am on the wrong path here.
As for configuration management; I totally agree. It is already on the (admittedly long) list of things we want to start doing. Our infrastructure is fairly static, though, so the immediate problem we are trying to solve is making sure that everything is running properly. Making sure it is configured properly is “tomorrow’s” problem.
Yes, in reading the werk, I think that is what JPH was referring to. After searching the plugins, I believe that werk is related to this plugin:
In turn, I believe that plugin is related to the Checkmk Agent installation auditing rules in Checkmk. Is this correct?
In looking at the Checkmk Agent installation auditing rules, it seems we are able to specify minimum versions for plugins and local checks (via Agent plugins: versions and Local checks: versions, respectively), with the option to exclude certain services (via Agent plugins: Regular expression to exclude plugins and Local checks: Regular expression to exclude files). However, we do not seem to be able to create a rule that says “this plugin” or “that local check” must be present. Is there something I am missing here? Is there a different rule that we should be looking at?
Of everything I have seen so far, it looks like enforced services is the way to go. It may simply be that, because there is no Active Directory replication link that can reasonably be expected to exist on every Domain Controller, that particular plugin is not really compatible with the enforced services concept. Creating an enforced service for the state of a specific IIS application pool seems like it would be a sane way to ensure that the IIS Application Pool State plugin is installed on every server in a web farm, though.
I’m still fairly new to Checkmk, though, so it’s entirely possible that I am on the wrong track here.
One other thing you can do is to use “enforced services” rules. With this you can add services for hosts without having them discovered. If the plugin providing the data for one of these services is not running this service will be seen as unknown.
Thank you for the feedback, Udo. That seems to confirm that I am on the right track with enforced services.
Unfortunately it also seems that we are out of luck as far as checking for the AD replication plugin in particular. While it would be possible to create an enforced service for a specific replication link that is known to exist on each DC, the effort spent creating those rules and making sure they get bound to the correct DC(s) is likely greater than the effort of manually checking each DC to ensure the plugin is present.
You could install the agent using Powershell, we do that, from System Center. That way you could easily have section in the installer that installs the right plugins based on the type of device.
Here you of course have a lot of options. If you have system center then its easy as I guess you already have a selection for your domain controllers.
But you can install this manually as well (running powershell) and identify your domain controllers somehow based on the hostname, based on if adds services are running, based on SYSVOL etc.
That way all your things will be installed.
We also use the same Powershell script to uninstall the agent before we install a new version, just to be sure no files are left behind that we don’t know what they do when I new version comes out.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed. Contact an admin if you think this should be re-opened.
