Publishing check results directly via amqp


#1

I’m looking at publishing some check results directly via AMQP. Since I already have a ton of metrics flowing directly to Graphite, I want a “zero-cost” way to do alerting from them. I’m working on a proxy in Node.js that will live on the Graphite server and will have the ability to selectively perform actions as the metrics flow in, rather than polling the Graphite render URL. I think this has the potential to be extremely flexible and efficient: rather than checking the load via a script invoked from sensu-client, I’d be able to just publish a check result with the value of the collectd.my-hostname.load.load.midterm metric.

Anyway, I haven’t found any documentation or an example of an integration like this. I fiddled around with the amqp module in Node.js and was able to get sensu-server to recognize a JSON string published to the ‘results’ exchange as a check result. What I’m looking for is what the proper structure of the JSON payload should be. My example – which appears to be doing what I want – uses the following payload

{

client: “vagrant-ubuntu-precise-64.local”,

check: {

name: “graphite_foo”,

standalone: true,

interval: 10,

subscribers: [ “default” ],

command: “/bin/echo -n OK”,

handlers: [ “default” ],

issued: 1378642413,

executed: 1378642413,

output: “OK”,

status: 1,

duration: 0.029

}

}

I can figure out the minimum properties via trial and error, but I’d like a little more formal direction if someone could help me out. This seems like potentially a very powerful way to implement standalone checks.

Thanks,

Brian

···


Brian Lalor
blalor@bravo5.org


#2

Is there any doc regarding this?

···

On Sunday, 8 September 2013 21:36:35 UTC+2, Brian Lalor wrote:

Anyway, I haven’t found any documentation or an example of an integration like this. I fiddled around with the amqp module in Node.js and was able to get sensu-server to recognize a JSON string published to the ‘results’ exchange as a check result. What I’m looking for is what the proper structure of the JSON payload should be. My example – which appears to be doing what I want – uses the following payload

{

client: “vagrant-ubuntu-precise-64.local”,

check: {

name: “graphite_foo”,

standalone: true,

interval: 10,

subscribers: [ “default” ],

command: “/bin/echo -n OK”,

handlers: [ “default” ],

issued: 1378642413,

executed: 1378642413,

output: “OK”,

status: 1,

duration: 0.029

}

}

I can figure out the minimum properties via trial and error, but I’d like a little more formal direction if someone could help me out. This seems like potentially a very powerful way to implement standalone checks.

Thanks,

Brian


Brian Lalor
bla...@bravo5.org
http://github.com/blalor

I’m looking at publishing some check results directly via AMQP. Since I already have a ton of metrics flowing directly to Graphite, I want a “zero-cost” way to do alerting from them. I’m working on a proxy in Node.js that will live on the Graphite server and will have the ability to selectively perform actions as the metrics flow in, rather than polling the Graphite render URL. I think this has the potential to be extremely flexible and efficient: rather than checking the load via a script invoked from sensu-client, I’d be able to just publish a check result with the value of the collectd.my-hostname.load.load.midterm metric.


#3

From what I remember, you can publish directly to the client socket, typically on 3030.

One sample I’ve seen online is just:

handlers, name, output & status. Looks like the client will add all the rest.

···

On May 20, 2014, at 3:02 PM, Adrià Casajús acasajus@cloudjutsu.com wrote:

Is there any doc regarding this?

On Sunday, 8 September 2013 21:36:35 UTC+2, Brian Lalor wrote:

Anyway, I haven’t found any documentation or an example of an integration like this. I fiddled around with the amqp module in Node.js and was able to get sensu-server to recognize a JSON string published to the ‘results’ exchange as a check result. What I’m looking for is what the proper structure of the JSON payload should be. My example – which appears to be doing what I want – uses the following payload

{

client: “vagrant-ubuntu-precise-64.local”,

check: {

name: “graphite_foo”,

standalone: true,

interval: 10,

subscribers: [ “default” ],

command: “/bin/echo -n OK”,

handlers: [ “default” ],

issued: 1378642413,

executed: 1378642413,

output: “OK”,

status: 1,

duration: 0.029

}

}

I can figure out the minimum properties via trial and error, but I’d like a little more formal direction if someone could help me out. This seems like potentially a very powerful way to implement standalone checks.

Thanks,

Brian


Brian Lalor
bla...@bravo5.org
http://github.com/blalor

I’m looking at publishing some check results directly via AMQP. Since I already have a ton of metrics flowing directly to Graphite, I want a “zero-cost” way to do alerting from them. I’m working on a proxy in Node.js that will live on the Graphite server and will have the ability to selectively perform actions as the metrics flow in, rather than polling the Graphite render URL. I think this has the potential to be extremely flexible and efficient: rather than checking the load via a script invoked from sensu-client, I’d be able to just publish a check result with the value of the collectd.my-hostname.load.load.midterm metric.


#4

Euh… The question was about for structure of the JSON payload. Is it documented somewhere?

···

On 20 May 2014 21:09, Matthew Barr mbarr@kensho.com wrote:

From what I remember, you can publish directly to the client socket, typically on 3030.

One sample I’ve seen online is just:

handlers, name, output & status. Looks like the client will add all the rest.

On May 20, 2014, at 3:02 PM, Adrià Casajús acasajus@cloudjutsu.com wrote:

Is there any doc regarding this?

On Sunday, 8 September 2013 21:36:35 UTC+2, Brian Lalor wrote:

I’m looking at publishing some check results directly via AMQP. Since I already have a ton of metrics flowing directly to Graphite, I want a “zero-cost” way to do alerting from them. I’m working on a proxy in Node.js that will live on the Graphite server and will have the ability to selectively perform actions as the metrics flow in, rather than polling the Graphite render URL. I think this has the potential to be extremely flexible and efficient: rather than checking the load via a script invoked from sensu-client, I’d be able to just publish a check result with the value of the collectd.my-hostname.load.load.midterm metric.

Anyway, I haven’t found any documentation or an example of an integration like this. I fiddled around with the amqp module in Node.js and was able to get sensu-server to recognize a JSON string published to the ‘results’ exchange as a check result. What I’m looking for is what the proper structure of the JSON payload should be. My example – which appears to be doing what I want – uses the following payload

{

client: “vagrant-ubuntu-precise-64.local”,

check: {

name: “graphite_foo”,

standalone: true,

interval: 10,

subscribers: [ “default” ],

command: “/bin/echo -n OK”,

handlers: [ “default” ],

issued: 1378642413,

executed: 1378642413,

output: “OK”,

status: 1,

duration: 0.029

}

}

I can figure out the minimum properties via trial and error, but I’d like a little more formal direction if someone could help me out. This seems like potentially a very powerful way to implement standalone checks.

Thanks,

Brian


Brian Lalor
bla...@bravo5.org
http://github.com/blalor


Adrià Casajús

www.cloudjutsu.com

acasajus@cloudjutsu.com

acasajus.cloudjutsu
@cloudjutsu

**This message contains information which may be confidential and privileged. **

Unless you are the intended addressee (or authorized to receive for the intended addressee), **you may not use, copy or disclose to anyone the message or any information contained in the message. **

If you have received the message in error, please advise the sender by reply legal@cloudjutsu.com and delete the message.


#5

This is the JSON of an event:
http://sensuapp.org/docs/0.12/events

The spawn an event manually, you send the “check” part of the JSON into localhost:3030. (at least name, status, and output)

···

On Tue, May 20, 2014 at 1:05 PM, Adrià Casajús acasajus@cloudjutsu.com wrote:

Euh… The question was about for structure of the JSON payload. Is it documented somewhere?

On 20 May 2014 21:09, Matthew Barr mbarr@kensho.com wrote:

From what I remember, you can publish directly to the client socket, typically on 3030.

One sample I’ve seen online is just:

handlers, name, output & status. Looks like the client will add all the rest.

On May 20, 2014, at 3:02 PM, Adrià Casajús acasajus@cloudjutsu.com wrote:

Is there any doc regarding this?

On Sunday, 8 September 2013 21:36:35 UTC+2, Brian Lalor wrote:

I’m looking at publishing some check results directly via AMQP. Since I already have a ton of metrics flowing directly to Graphite, I want a “zero-cost” way to do alerting from them. I’m working on a proxy in Node.js that will live on the Graphite server and will have the ability to selectively perform actions as the metrics flow in, rather than polling the Graphite render URL. I think this has the potential to be extremely flexible and efficient: rather than checking the load via a script invoked from sensu-client, I’d be able to just publish a check result with the value of the collectd.my-hostname.load.load.midterm metric.

Anyway, I haven’t found any documentation or an example of an integration like this. I fiddled around with the amqp module in Node.js and was able to get sensu-server to recognize a JSON string published to the ‘results’ exchange as a check result. What I’m looking for is what the proper structure of the JSON payload should be. My example – which appears to be doing what I want – uses the following payload

{

client: “vagrant-ubuntu-precise-64.local”,

check: {

name: “graphite_foo”,

standalone: true,

interval: 10,

subscribers: [ “default” ],

command: “/bin/echo -n OK”,

handlers: [ “default” ],

issued: 1378642413,

executed: 1378642413,

output: “OK”,

status: 1,

duration: 0.029

}

}

I can figure out the minimum properties via trial and error, but I’d like a little more formal direction if someone could help me out. This seems like potentially a very powerful way to implement standalone checks.

Thanks,

Brian


Brian Lalor
bla...@bravo5.org
http://github.com/blalor


Adrià Casajús

www.cloudjutsu.com

acasajus@cloudjutsu.com

acasajus.cloudjutsu
@cloudjutsu

**This message contains information which may be confidential and privileged. **

Unless you are the intended addressee (or authorized to receive for the intended addressee), **you may not use, copy or disclose to anyone the message or any information contained in the message. **

If you have received the message in error, please advise the sender by reply legal@cloudjutsu.com and delete the message.


#6