Roadmap to Sensu 1.0

Sensu Classic (EOL)
1

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

···

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

2

Forgive my ignorance if this already exists, but I’d love an option to temporarily silence a check or all checks for a node (this is like Nagios’s “down for maintenance” option). We could write a wrapper which adds an item to the stash and then manually removes it later, but an “expires” option would be nice to automatically expire an entry. Also, an endpoint to temporarily silence all checks for a node (perhaps under clients/ or stashes/?).

Maybe this already exists? The documentation for the stashes API endpoint is lacking. This feature is critical for us before we can fully move to Sensu, and I’m sure others would find it useful as well.

···

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

3

Adding sensu-dev

···

On Thu, May 23, 2013 at 4:01 PM, Christopher Armstrong chris@chrisarmstrong.me wrote:

Forgive my ignorance if this already exists, but I’d love an option to temporarily silence a check or all checks for a node (this is like Nagios’s “down for maintenance” option). We could write a wrapper which adds an item to the stash and then manually removes it later, but an “expires” option would be nice to automatically expire an entry. Also, an endpoint to temporarily silence all checks for a node (perhaps under clients/ or stashes/?).

Maybe this already exists? The documentation for the stashes API endpoint is lacking. This feature is critical for us before we can fully move to Sensu, and I’m sure others would find it useful as well.

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

4

Cc:

sensu-dashboard and sensu-admin have support for silencing a client and or one or all checks, using Sensu stashes, combined with sensu-plugin’s filters :slight_smile: All of which can be improved.

···

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

5

Christoper,

I put in sensu-cli the ability to add an expires. You must run this check though to make it work.

I’d say having this native to the server checking for expired stashes would be a good 1.0 feature.

Justin,

The client history can be viewed by hitting the api like so http://localhost:4567/clients/client_id/history

···

On Thu, May 23, 2013 at 6:09 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: “Sean Porter” portertech@gmail.com

Date: 23 May 2013 16:09
Subject: Re: Roadmap to Sensu 1.0

To: “Christopher Armstrong” chris@chrisarmstrong.me
Cc:

sensu-dashboard and sensu-admin have support for silencing a client and or one or all checks, using Sensu stashes, combined with sensu-plugin’s filters :slight_smile: All of which can be improved.

On 23 May 2013 16:01, “Christopher Armstrong” chris@chrisarmstrong.me wrote:

Forgive my ignorance if this already exists, but I’d love an option to temporarily silence a check or all checks for a node (this is like Nagios’s “down for maintenance” option). We could write a wrapper which adds an item to the stash and then manually removes it later, but an “expires” option would be nice to automatically expire an entry. Also, an endpoint to temporarily silence all checks for a node (perhaps under clients/ or stashes/?).

Maybe this already exists? The documentation for the stashes API endpoint is lacking. This feature is critical for us before we can fully move to Sensu, and I’m sure others would find it useful as well.

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

6

sorry; this check https://github.com/agent462/sensu-check-stashes

···

On Thu, May 23, 2013 at 8:11 PM, Bryan Brandau agent462@gmail.com wrote:

Christoper,

I put in sensu-cli the ability to add an expires. You must run this check though to make it work.

I’d say having this native to the server checking for expired stashes would be a good 1.0 feature.

Justin,

The client history can be viewed by hitting the api like so http://localhost:4567/clients/client_id/history

On Thu, May 23, 2013 at 6:09 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: “Sean Porter” portertech@gmail.com

Date: 23 May 2013 16:09
Subject: Re: Roadmap to Sensu 1.0

To: “Christopher Armstrong” chris@chrisarmstrong.me
Cc:

sensu-dashboard and sensu-admin have support for silencing a client and or one or all checks, using Sensu stashes, combined with sensu-plugin’s filters :slight_smile: All of which can be improved.

On 23 May 2013 16:01, “Christopher Armstrong” chris@chrisarmstrong.me wrote:

Forgive my ignorance if this already exists, but I’d love an option to temporarily silence a check or all checks for a node (this is like Nagios’s “down for maintenance” option). We could write a wrapper which adds an item to the stash and then manually removes it later, but an “expires” option would be nice to automatically expire an entry. Also, an endpoint to temporarily silence all checks for a node (perhaps under clients/ or stashes/?).

Maybe this already exists? The documentation for the stashes API endpoint is lacking. This feature is critical for us before we can fully move to Sensu, and I’m sure others would find it useful as well.

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

7

Thanks guys - I was previously unaware of both the sensu-admin and sensu-cli projects. I’ll take a look.

···

On Thu, May 23, 2013 at 6:12 PM, Bryan Brandau agent462@gmail.com wrote:

sorry; this check https://github.com/agent462/sensu-check-stashes

On Thu, May 23, 2013 at 8:11 PM, Bryan Brandau agent462@gmail.com wrote:

Christoper,

I put in sensu-cli the ability to add an expires. You must run this check though to make it work.

I’d say having this native to the server checking for expired stashes would be a good 1.0 feature.

Justin,

The client history can be viewed by hitting the api like so http://localhost:4567/clients/client_id/history

On Thu, May 23, 2013 at 6:09 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: “Sean Porter” portertech@gmail.com

Date: 23 May 2013 16:09
Subject: Re: Roadmap to Sensu 1.0

To: “Christopher Armstrong” chris@chrisarmstrong.me
Cc:

sensu-dashboard and sensu-admin have support for silencing a client and or one or all checks, using Sensu stashes, combined with sensu-plugin’s filters :slight_smile: All of which can be improved.

On 23 May 2013 16:01, “Christopher Armstrong” chris@chrisarmstrong.me wrote:

Forgive my ignorance if this already exists, but I’d love an option to temporarily silence a check or all checks for a node (this is like Nagios’s “down for maintenance” option). We could write a wrapper which adds an item to the stash and then manually removes it later, but an “expires” option would be nice to automatically expire an entry. Also, an endpoint to temporarily silence all checks for a node (perhaps under clients/ or stashes/?).

Maybe this already exists? The documentation for the stashes API endpoint is lacking. This feature is critical for us before we can fully move to Sensu, and I’m sure others would find it useful as well.

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

8

+1 to making ‘expires’ and ‘owner’ first-class citizens in silence stashes. I think all sensu tooling should support these =)

···

On Thu, May 23, 2013 at 6:11 PM, Bryan Brandau agent462@gmail.com wrote:

Christoper,

I put in sensu-cli the ability to add an expires. You must run this check though to make it work.

I’d say having this native to the server checking for expired stashes would be a good 1.0 feature.

Justin,

The client history can be viewed by hitting the api like so http://localhost:4567/clients/client_id/history

On Thu, May 23, 2013 at 6:09 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: “Sean Porter” portertech@gmail.com

Date: 23 May 2013 16:09
Subject: Re: Roadmap to Sensu 1.0

To: “Christopher Armstrong” chris@chrisarmstrong.me
Cc:

sensu-dashboard and sensu-admin have support for silencing a client and or one or all checks, using Sensu stashes, combined with sensu-plugin’s filters :slight_smile: All of which can be improved.

On 23 May 2013 16:01, “Christopher Armstrong” chris@chrisarmstrong.me wrote:

Forgive my ignorance if this already exists, but I’d love an option to temporarily silence a check or all checks for a node (this is like Nagios’s “down for maintenance” option). We could write a wrapper which adds an item to the stash and then manually removes it later, but an “expires” option would be nice to automatically expire an entry. Also, an endpoint to temporarily silence all checks for a node (perhaps under clients/ or stashes/?).

Maybe this already exists? The documentation for the stashes API endpoint is lacking. This feature is critical for us before we can fully move to Sensu, and I’m sure others would find it useful as well.

On Thu, May 23, 2013 at 3:52 PM, Sean Porter portertech@gmail.com wrote:

---------- Forwarded message ----------
From: Sean Porter portertech@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foomatty@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

On Thu, May 23, 2013 at 3:47 PM, Matt foomatty@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” portertech@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

9

Hey folks - new to the group. I’m very interested in the features suggested for v1.0. Is there a prospective release date?

Cheers,

Max

···

On Thursday, 23 May 2013 23:52:38 UTC+1, portertech wrote:

---------- Forwarded message ----------
From: Sean Porter porte...@gmail.com

Date: Thu, May 23, 2013 at 3:52 PM
Subject: Re: Roadmap to Sensu 1.0
To: Matt foom...@gmail.com

I’m obsessed with the idea of using nested colour coded blocks to represent subscriptions, clients, and checks. Anyone know if another piece of software does something along these lines? I like the idea of human readable UTC stamps, perhaps iso8601.

I think a Sensu extension, “event-history-graphite”, would be useful for many.

On Thu, May 23, 2013 at 3:47 PM, Matt foom...@gmail.com wrote:

I’d second UI work on the dashboard, a view of current history of checks passing and failing. Clients and checks grouped by subscription. Epoch conversion to UTC datestamp

Embedded checking of graphite values for notifying handlers would be cool. i.e for values sensu doesn’t see, but it might gather and send to graphite as a metric. I know there are other tools that do this, but having this in one place is nice.

On 23 May 2013 23:33, “portertech” porte...@gmail.com wrote:

I believe UI & documentation improvements are the logical next step. I would love to see sensu-dashboard adopt an “overview” visualization, one that utilizes the Sensu client execution history functionality, that was recently added by Jeremy Carrol. The UI currently suffers from many small bugs, these can probably be remedied without much pain.

On Sunday, 7 April 2013 11:51:40 UTC-7, Joe Miller wrote:

Sensu has been in the pre-1.0 stage for over a year now, and while there’s still cool new features coming with every point release, I wanted to ping the community and start a discussion about what a “Sensu 1.0” looks like.

The new sensu-dev list seems like a great place to start this conversation. So after talking to Sean I figured now is as good a time as any to give this a shot.

A few things that I had in mind when I picture a Sensu 1.0 are:

  1. Revocation support for SSL (rabbitmq). Right now we recommend single certificates and fast re-key/deployment via your CM tool because RabbitMQ lacks a simple revocation mechanism for SSL. There may be some possible ways we could accomplish this without requiring rabbitmq modifications, such as building our own module in erlang and exporting a ‘verify_fun’ function and coercing rabbit to load that. Or, perhaps there’s other ways.
  2. Jeremy Carroll had some thoughts on things that he feels would be important in pushing Sensu adoption further such as feature parity in the UI with other systems. If he’s on this list, I’d ask him to speak up.
  3. Finalized API/interface for extensions is probably a key 1.0 feature so that folks are more confident that they will not have to refactor their extensions
  4. **100% doc coverage =) **At least for all the core features.
    Anything else? throw ideas out here, let’s see what sticks!

Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }

–

–
Cheers,

Sean Porter

{ blog: “http://portertech.ca”, projects: “https://github.com/portertech” }