Sensu-Plugins Update

[Matt_Jones]

The split of the community-plugins repo is complete. The new repos can be found here. Details on the ongoing migration can be found here and here.

The short of it is that no functionality has changed and gems have not been created for each repo yet. There are however several breaking changes that need to be accounted for.

All plugins in the new repos now follow a standard naming scheme of being prefixed by either handler-, check-, metrics-, extension-, or mutator- depending on their primary function. This was done to make things easier to deal with as all binaries now live in /bin, regardless of function. This means that the ec2 handler and the ec2/elb checks are included in the same repo and will be built into a single gem. If you want to monitor amazon you only need install the aws gem or clone the aws repo

There is an ongoing refactor of all amazon checks to not allow keys, passwords, or tokens to be passed as commandline arguments. If you have thoughts on this or would like to offer insight please take a look here

When looking for a check, please don’t assume the repo will be the same as the directory name in the community plugins repo. In many cases they will be nearly identical but some changes have been made for example:

check-fs-writeable used to be in /disk but has now been moved to the filesystem-checks repo.

Some checks that didn’t fit anywhere were broken off into their own repos as well.

While the community-plugins repo is still considered authoritative, these new repos are going to be our future. The community-plugins repo will never go away but at some point later this year, most likely mid-summer, it will be archived and we will no longer accept PR’s or Issues for it.

When the new repos reach more stable states, within the next few months, the corresponding checks in the community-plugins repo will be frozen for all new features. At this point when submitting a feature PR you may be asked to pull the new repo containing the check and submit it there. Bug fixes will still continue to be accepted for all plugins until the actual hard cutover.

Release tags will start to appear for many of these repos fairly quickly as well, most will be flagged as prerelease to account for anything that may still break as things are shifted and moved but rest assured semantic versioning will be strictly followed and once the github prerelease flag or the alpha tag from the gem is removed, no breaking changes will occur.

There is a still a lot of work needed to get these repos to stable, production grade state but rest assured they will get there and we will all be able to sleep a little better at night.

···

Matt Jones @DevopsMatt

Infrastructure Engineer - Yieldbot Inc.

Core Contributor - Sensu Plugins

[John_Dyer]

Matt,

Where will extensions be managed?

-John

···

On Tuesday, February 17, 2015 at 11:14:45 AM UTC-5, Matt Jones wrote:

The split of the community-plugins repo is complete. The new repos can be found here. Details on the ongoing migration can be found here and here.

The short of it is that no functionality has changed and gems have not been created for each repo yet. There are however several breaking changes that need to be accounted for.

All plugins in the new repos now follow a standard naming scheme of being prefixed by either handler-, check-, metrics-, extension-, or mutator- depending on their primary function. This was done to make things easier to deal with as all binaries now live in /bin, regardless of function. This means that the ec2 handler and the ec2/elb checks are included in the same repo and will be built into a single gem. If you want to monitor amazon you only need install the aws gem or clone the aws repo

There is an ongoing refactor of all amazon checks to not allow keys, passwords, or tokens to be passed as commandline arguments. If you have thoughts on this or would like to offer insight please take a look here

When looking for a check, please don’t assume the repo will be the same as the directory name in the community plugins repo. In many cases they will be nearly identical but some changes have been made for example:

check-fs-writeable used to be in /disk but has now been moved to the filesystem-checks repo.

Some checks that didn’t fit anywhere were broken off into their own repos as well.

While the community-plugins repo is still considered authoritative, these new repos are going to be our future. The community-plugins repo will never go away but at some point later this year, most likely mid-summer, it will be archived and we will no longer accept PR’s or Issues for it.

When the new repos reach more stable states, within the next few months, the corresponding checks in the community-plugins repo will be frozen for all new features. At this point when submitting a feature PR you may be asked to pull the new repo containing the check and submit it there. Bug fixes will still continue to be accepted for all plugins until the actual hard cutover.

Release tags will start to appear for many of these repos fairly quickly as well, most will be flagged as prerelease to account for anything that may still break as things are shifted and moved but rest assured semantic versioning will be strictly followed and once the github prerelease flag or the alpha tag from the gem is removed, no breaking changes will occur.

There is a still a lot of work needed to get these repos to stable, production grade state but rest assured they will get there and we will all be able to sleep a little better at night.

–

Matt Jones @DevopsMatt

Infrastructure Engineer - Yieldbot Inc.

Core Contributor - Sensu Plugins

[Matt_Jones]

Yes, they will be in each repo as well if they belong to a specific app such as those associated with aws or logstash, etc, if they are not associated with a specific app then they will be in their own repo.

There will not be an extensions specific gem at this time, each non-app-specific extension will be its own gem, even if it is only a single file. One of the primary goals is the separation of components, if you don’t have elasticsearch in your environment there should be no need for you to install or mange any elasticsearch monitoring components.

The simplest way to find a specific check would be to use the github advanced find. In 99% of cases this won’t be necessary as the repos are logically laid out, the only confusion may be the checks that used to be in the system directory as they are now scattered into ~5 repos including process checks, disk checks, filesystem checks, environmental checks, etc.

At some point in time GIR will be able to tell a user where a specific plugin is located in the org and you will be able to ask him for all checks, handlers, etc that should be used to monitor a given app. He is mostly living in my mind still at this point, but he has some useful functionality.

···

On Wed, Feb 18, 2015 at 8:49 AM, John Dyer johntdyer@gmail.com wrote:

Matt,

Where will extensions be managed?

-John

On Tuesday, February 17, 2015 at 11:14:45 AM UTC-5, Matt Jones wrote:

The split of the community-plugins repo is complete. The new repos can be found here. Details on the ongoing migration can be found here and here.

The short of it is that no functionality has changed and gems have not been created for each repo yet. There are however several breaking changes that need to be accounted for.

All plugins in the new repos now follow a standard naming scheme of being prefixed by either handler-, check-, metrics-, extension-, or mutator- depending on their primary function. This was done to make things easier to deal with as all binaries now live in /bin, regardless of function. This means that the ec2 handler and the ec2/elb checks are included in the same repo and will be built into a single gem. If you want to monitor amazon you only need install the aws gem or clone the aws repo

There is an ongoing refactor of all amazon checks to not allow keys, passwords, or tokens to be passed as commandline arguments. If you have thoughts on this or would like to offer insight please take a look here

When looking for a check, please don’t assume the repo will be the same as the directory name in the community plugins repo. In many cases they will be nearly identical but some changes have been made for example:

check-fs-writeable used to be in /disk but has now been moved to the filesystem-checks repo.

Some checks that didn’t fit anywhere were broken off into their own repos as well.

While the community-plugins repo is still considered authoritative, these new repos are going to be our future. The community-plugins repo will never go away but at some point later this year, most likely mid-summer, it will be archived and we will no longer accept PR’s or Issues for it.

When the new repos reach more stable states, within the next few months, the corresponding checks in the community-plugins repo will be frozen for all new features. At this point when submitting a feature PR you may be asked to pull the new repo containing the check and submit it there. Bug fixes will still continue to be accepted for all plugins until the actual hard cutover.

Release tags will start to appear for many of these repos fairly quickly as well, most will be flagged as prerelease to account for anything that may still break as things are shifted and moved but rest assured semantic versioning will be strictly followed and once the github prerelease flag or the alpha tag from the gem is removed, no breaking changes will occur.

There is a still a lot of work needed to get these repos to stable, production grade state but rest assured they will get there and we will all be able to sleep a little better at night.

–

Matt Jones @DevopsMatt

Infrastructure Engineer - Yieldbot Inc.

Core Contributor - Sensu Plugins

–

Matt Jones @DevopsMatt

Infrastructure Engineer - Yieldbot Inc.

Core Contributor - Sensu Plugins

https://linkedin.com/in/mattyjones

[Joao_Carlos]

Matt,

I would like propose a chance in plugins checks and metrics:

today is ruby “socket gethostname” My idea is chance it to use the name in the client.json. I think it’s more flexible.

tks

João

···

Em terça-feira, 17 de fevereiro de 2015 14:14:45 UTC-2, Matt Jones escreveu:

The split of the community-plugins repo is complete. The new repos can be found here. Details on the ongoing migration can be found here and here.

The short of it is that no functionality has changed and gems have not been created for each repo yet. There are however several breaking changes that need to be accounted for.

All plugins in the new repos now follow a standard naming scheme of being prefixed by either handler-, check-, metrics-, extension-, or mutator- depending on their primary function. This was done to make things easier to deal with as all binaries now live in /bin, regardless of function. This means that the ec2 handler and the ec2/elb checks are included in the same repo and will be built into a single gem. If you want to monitor amazon you only need install the aws gem or clone the aws repo

There is an ongoing refactor of all amazon checks to not allow keys, passwords, or tokens to be passed as commandline arguments. If you have thoughts on this or would like to offer insight please take a look here

When looking for a check, please don’t assume the repo will be the same as the directory name in the community plugins repo. In many cases they will be nearly identical but some changes have been made for example:

check-fs-writeable used to be in /disk but has now been moved to the filesystem-checks repo.

Some checks that didn’t fit anywhere were broken off into their own repos as well.

While the community-plugins repo is still considered authoritative, these new repos are going to be our future. The community-plugins repo will never go away but at some point later this year, most likely mid-summer, it will be archived and we will no longer accept PR’s or Issues for it.

When the new repos reach more stable states, within the next few months, the corresponding checks in the community-plugins repo will be frozen for all new features. At this point when submitting a feature PR you may be asked to pull the new repo containing the check and submit it there. Bug fixes will still continue to be accepted for all plugins until the actual hard cutover.

Release tags will start to appear for many of these repos fairly quickly as well, most will be flagged as prerelease to account for anything that may still break as things are shifted and moved but rest assured semantic versioning will be strictly followed and once the github prerelease flag or the alpha tag from the gem is removed, no breaking changes will occur.

There is a still a lot of work needed to get these repos to stable, production grade state but rest assured they will get there and we will all be able to sleep a little better at night.

–

Matt Jones @DevopsMatt

Infrastructure Engineer - Yieldbot Inc.

Core Contributor - Sensu Plugins