Associate proxy check with valid entity

Sensu Go
#1

Hi all. I’m a long time Nagios user giving Sensu Go a crack and am stuck trying to migrate some of my existing check logic into it.

I’m trying to migrate a simple check_ping check that runs on our Nagios host that just checks response time and packet loss between it and the remote nodes. I can do this in Nagios by just setting up a service and specifying check_ping as the command and setting the target to be $HOSTADDRESS$:

# 'check_ping' command definition
define command{
        command_name    check_ping
        command_line    /usr/lib/nagios/plugins/check_ping -H '$HOSTADDRESS$' -w '$ARG1$' -c '$ARG2$'
        }

Then I assign this check to hosts and it fills it all out for me. Basically the Nagios host just does ping checks to whatever the $HOSTADDRESS$ (IP or hostname, depending on your config) ends up being for the hosts.

My understanding is that the way to do this in Sensu Go would be to reverse the way the ping goes and instead ping my Sensu backend host, is this correct?

Alternatively is it possible to create checks that run from any agent that isn’t the current one but targets it? For example if I have three systems called agent1, agent2 and agent3 and all of them have the ping check assigned they would then test like this:

  • agent2 and agent3 run tests against agent1
  • agent1 and agent3 run tests against agent2
  • agent1 and agent2 run tests against agent3

But the check would be associated with the actual entity, not a proxy entity. From this thread I think I need to do something with the proxy_requests param but I don’t understand where to go from there.

Any help would be greatly appreciated! Am really enjoying Sensu Go so far.

#2

I actually just did this yesterday! I was pinging items that weren’t using Sensu, using proxy_requests with tokens and labels. However, I just went ahead and tested the same thing on an entity that was already a sensu-agent, and that works great too. :+1:

To start I followed the example on this docs page:
https://docs.sensu.io/sensu-go/latest/observability-pipeline/observe-schedule/checks/#proxy-checks
I used the section that says:
Example proxy check using proxy_requests

I first created the entity via a json file and sensuctl create -f entityname.json. In your case, you wouldn’t do that part, what you would want to do is just add a new label to the existing sensu-agent entity. I happen to have a Chef Ohai plugin to get the json from the live sensu server… But to do so manually you could get it from sensuctl dump entity --format wrapped-json --file allentities.json and then pick out the one entity your looking for and copy it to a new file. You could also use sensuctl entity info entityname --format json, but you would have to add the headers needed for the create command.
So I added this to the labels:
"metadata": { "labels": { "proxy_type": "ping" }}
Then used the same sensuctl create -f entityname.json to update it.

Then I created a new check definition like they have on that docs webpage, with it searching for the “ping” label:

"proxy_requests": {
  "entity_attributes": [ "entity.labels.proxy_type == 'ping'" ]
}

And I used the token {{ .name }} to get the entity name for the command part of the check definition:
"command": "check_ping -p 2 -w 500,100% -c 500,100% -H {{ .name }}"

If you want you could add the other arguments for the ping command as attributes in the entity json file, such as:
{{ .attributes.ping_critical }}

The check definition would have a subscription association with it, in my case I made a subscription named “proxy”. I also set round robin true and splay true. Then I selected a 3-4 servers that are dedicated to just my team which I gave the “proxy” subscription to run the checks. During testing, I just started with 1 server (didn’t have to turn off round robin for this).

Let me know if you need any more details, since I already have a working setup to refer to.