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.
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.
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.
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.
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.
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.
**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.
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.
**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.
