Concept of Check Freshness?


#1

In Nagios with passive checks there is the concept of "freshness":
http://nagios.sourceforge.net/docs/3_0/freshness.html

Kinda like the client heartbeat, if a passive check doesn't check in
after a certain period of time, it triggers.

Does anyone have any kind of advice on how I could emulate this
behavior with Sensu? As far as I can tell, only the client itself has
a heartbeat check.

I'm open to advice on how to attack the problem in a different way, as
long as it is not an active check.


#2

Does somebody have some idea of how to accomplish what Kyle has proposed?

I have the same doubt

Thanks !

···

On Friday, December 20, 2013 2:38:50 AM UTC-2, Kyle Anderson wrote:

In Nagios with passive checks there is the concept of “freshness”:

http://nagios.sourceforge.net/docs/3_0/freshness.html

Kinda like the client heartbeat, if a passive check doesn’t check in

after a certain period of time, it triggers.

Does anyone have any kind of advice on how I could emulate this

behavior with Sensu? As far as I can tell, only the client itself has

a heartbeat check.

I’m open to advice on how to attack the problem in a different way, as

long as it is not an active check.


#3

API /clients/:name/history

···

On Nov 14, 2014 11:31 AM, “Erick Barros” darvin.denmian@gmail.com wrote:

Does somebody have some idea of how to accomplish what Kyle has proposed?

I have the same doubt

Thanks !

On Friday, December 20, 2013 2:38:50 AM UTC-2, Kyle Anderson wrote:

In Nagios with passive checks there is the concept of “freshness”:
http://nagios.sourceforge.net/docs/3_0/freshness.html

Kinda like the client heartbeat, if a passive check doesn’t check in
after a certain period of time, it triggers.

Does anyone have any kind of advice on how I could emulate this
behavior with Sensu? As far as I can tell, only the client itself has
a heartbeat check.

I’m open to advice on how to attack the problem in a different way, as
long as it is not an active check.


#4

It is true that the history api is available now for use.

I'm thinking I'm going to do something like this:
* Iterate over all the checks, look for anything with a
staleness_threshold set in the metadata
* If the check has not reported in (per the history, last_execution),
then take the last event data, masquerade the hostname, and re-emit
it, replacing the exit code and status
(data.merge({'status'=>1, 'output'=>'Critical: Check hasn't reported
in in X minutes'}))

Obviously this is going to take some tooling and depends on the
ability to masquerade.

A co-worker of mine suggested that an alternate approach would be to
generalize the "keepalive" function to any potential check.

This would make the client "keepalive" check not special, and would
potentially give *any* check the capability of getting this feature.

Both situations have the issue of "how do I let Sensu know I no longer
need to be monitoring something? On the client, you remove the whole
client.
With this... I'm not sure.

···

On Fri, Nov 14, 2014 at 11:33 AM, Sean Porter <portertech@gmail.com> wrote:

API /clients/:name/history

On Nov 14, 2014 11:31 AM, "Erick Barros" <darvin.denmian@gmail.com> wrote:

Does somebody have some idea of how to accomplish what Kyle has proposed?

I have the same doubt

Thanks !

On Friday, December 20, 2013 2:38:50 AM UTC-2, Kyle Anderson wrote:

In Nagios with passive checks there is the concept of "freshness":
http://nagios.sourceforge.net/docs/3_0/freshness.html

Kinda like the client heartbeat, if a passive check doesn't check in
after a certain period of time, it triggers.

Does anyone have any kind of advice on how I could emulate this
behavior with Sensu? As far as I can tell, only the client itself has
a heartbeat check.

I'm open to advice on how to attack the problem in a different way, as
long as it is not an active check.


#5