Check limited to platform

Sensu Go
1

Hello,
We are starting to add RHEL to our environment and run into an issue with checks. We need to have specific checks run only on certain platforms due to their differences.
For example, services sshd.service on RHEL vs ssh.service on debian.
Is there a way to do this? I would like to avoid adding platform specific subscriptions to all servers to run general checks.

2

One approach you could take would be to include the parameter as a label in the agent configuration, and use token substitution to pass that parameter to the check command. Let me give you an example, using this asset.

{
  "type": "CheckConfig",
  "api_version": "core/v2",
  "metadata": {
    "name": "check_sshd",
    "namespace": "default"
  },
  "spec": {
    "command": "check-systemd.rb -s {{ .labels.check_sshd |default \"ssh.service\" }}",
...

If no label is specified, its default behavior will be to look for sshd.service, which is great for your Debian-based hosts. On your RHEL hosts, you would add a label to your agent.yml file (or however you choose to configure it) to override the default check parameter.

##
# labels (attributes which can be used with filtering)
##
labels:
  check_sshd: "sshd.service"

If you use a configuration manager to deploy the Sensu Agent, you can automate the addition of this label depending on the host OS.

3

Yes,
If the differences are check configuration options… you can encode them as entity level labels or annotations and use token substitution. This would work with most if not all of the publicly available check plugins as most of them are reasonably platform agnostic.

If the check in question is home grown business logic that doesn’t expose configuration options sufficiently – and lets be honest it’s really easy to write a bash script in anger that isn’t platform agnostic, I’m not judging, it is what is – you can also roll your own private asset with different asset builds for each platform and use the asset platform filter expression to make sure the correct build gets pulled in based on what the entity reports.

4

I have actually tried this already and I could not get it to work. When I just copied your example, it did work. Not sure why, since I was taking it from token docu, probably my fault.
Thanks, this will solves the issue for me.
I have custom solution for server deployment, adding this will not be a problem.