I am still new to Sensu, so anyone feel free to correct any of my inaccuracies.
You can only have one sensu client definition per host. As the client.json tells sensu ‘this is who I am’. It cannot have multiple personalities. You would setup a different client.json on the remote system running sensu-client to define who/what it is.
You have a second goal here, which is what some on the list are labeling ‘masquarading’ as another host for the event data. This feature currently is not in the sensu release builds. Discussion is still going on with method to execute (if it will be incorporated).
I have branched the sensu-client adding two lines which permit this ‘proxy’ of event creation. Still working on solving how to process events for hosts which SensuServer is not aware of yet.
In my model, I have a few dedicated hosts running the sensu-client to run high quantity or cpu expensive checks from. Example of port check of 1200 remote hosts within 20 seconds. This proxy then can perform a single check, determine which hosts are failing and generate “masq’ed” events as if the event was created from the target host(s). The final result is sensu would believe the target host created the given event and report the alarm sourcing from the target. You can then route the event as if it was a normal check => handler action sensu expects to take action on.
Looking at the code and how Sensu has been written it feels as though it is more of a check of systems, system health, or service availability checked from the target host. i.e. is DNS resolving for webserver#1, #2, #3, …, against DNS#1 server. Large environments need these checks because of complex network ACL configurations.
Did this cover your questions?
On Tuesday, September 23, 2014 5:09:26 PM UTC-7, Florin Andrei wrote:
Is it possible to run multiple clients on the same instance?
I would like to separate the alerts generated by the instance itself (disk usage, too many users logged in, etc) from the alerts generated on that instance by remote network tests - e.g. testing port 80 on a bunch of remote Web instances. Having these alerts coming from different client names would neatly separate the alerts visually in our alert system (PagerDuty or whatever). It makes it very easy to tell immediately, at one glance, that this is an alert concerning the Web stuff, so it’s really important - or it’s an alert concerning only this particular monitoring instance, which is not that important.
I’ve tried this:
root@monitor-01:~# cat /etc/sensu/conf.d/clients.json
"subscriptions": [ "webservers" ]
"subscriptions": [ "accmon" ]
But it doesn’t seem to work. After I’ve created the second client entry there, I got a message that the client “monitor-01” has not sent keep-alives in over 180 seconds, which seems to indicate that it’s not operating anymore. But “accmon-us-west-1” is still working just fine.
I am using “accmon-us-west-1” to test several Web sites in various locations. I want to reserve the “monitor-01” client just to self-monitor that instance alone (memory, CPU, etc).