Chef - Bulk check changes / management

Sensu Classic (EOL)
1

Hi Sensu’s,

We currently deploy and configure our checks for Sensu using Chef. Ping checks are a common one, and we have many individual standalone ping checks that run on our master sensu server.

Specifically we use check-ping.rb: https://github.com/sensu-plugins/sensu-plugins-network-checks/blob/master/bin/check-ping.rb

Currently we write out the settings for each individual cookbook. It is still early days for our deployment but we are already up to about 10 ping checks. An issue we have run in to now is there are some options we would like to apply to every ping check we have created, however if possible it would be nice if we could do this without actually having to modify every single check. Rather, I am wondering if we can have a generic ‘default’, either in chef or elsewhere that we can modify and will be applied to all of our pings to make it easy for us to quickly update things like, for example the count (-c) value.

I know we could probably just modify check-ping.rb on our end, but if possible I prefer to avoid modifying the plugin files.

Thanks in advance for any assistance.

Kind Regards,

Todd

2

I suggest you check if chef has something similar to puppet’s defined types: https://docs.puppet.com/puppet/4.10/lang_defined_types.html

With this I write e.g. my checks for certificates:

Define: services::sensu::tls_check

allows TLS checks by only specifying subdomain to check

define services::sensu::tls_check($port = ‘443’, $source = ‘’)

{

if ($source == ‘’)

{

$source_internal = “${name}.our.domain.com”

}

else

{

$source_internal = “${source}.our.domain.com”

}

sensu::check

{

“check_tls_certificates_${name}”:

command => “check-ssl-host.rb --warning 15 --critical 5 --host ${name}.our.domain.com --port ${port}”,

interval => ‘300’,

handlers => ‘default’,

subscribers => ‘proxy’,

standalone => false,

source => $source_internal,

require => Package[‘sensu-plugins-ssl’],

custom =>

{

impact => ‘Secure connections will throw warnings or not work at all.’,

suggestion => “Check connectivity. Renew the TLS certificate for the subdomain ${name}.our.domain.com.”,

}

}

}

``

Then, to apply one such section with the customized parameters I do the following:

class services::sensu::certificates

{

$host_is_subdomain = [‘subdomain1’,

‘subdomain2’,

‘subdomain3’]

services::sensu::tls_check{$host_is_subdomain:}

services::sensu::tls_check{‘subdomain4’: source => ‘actual_hostname’}

services::sensu::tls_check{‘subdomain5’: source => ‘actual_other_hostname’}

services::sensu::tls_check{‘subdomain6’: port => ‘993’, source => ‘example_hostname’}

}

``

···

On Monday, June 5, 2017 at 2:11:40 AM UTC+2, tmurphy wrote:

Rather, I am wondering if we can have a generic ‘default’, either in chef or elsewhere that we can modify and will be applied to all of our pings to make it easy for us to quickly update things like, for example the count (-c) value.

3

There are many strategies you could take, in my deployment as I wanted to create a way for people with very little chef knowledge (noc in India) to be able to easily add checks that were specific to their application, env, etc with just having to essentially just give us the appropriate config in a simple attribute namespace. Since it is now 100% chef attribute driven that means that you can interpolate things from your env like your domain and go crazy. Here is a gist of the boiled down version of how we accomplish this. Whether this makes sense for you that I do not know.

···

On Wednesday, June 7, 2017 at 1:08:18 AM UTC-7, Alexander Skiba wrote:

On Monday, June 5, 2017 at 2:11:40 AM UTC+2, tmurphy wrote:

Rather, I am wondering if we can have a generic ‘default’, either in chef or elsewhere that we can modify and will be applied to all of our pings to make it easy for us to quickly update things like, for example the count (-c) value.

I suggest you check if chef has something similar to puppet’s defined types: https://docs.puppet.com/puppet/4.10/lang_defined_types.html

With this I write e.g. my checks for certificates:

Define: services::sensu::tls_check

allows TLS checks by only specifying subdomain to check

define services::sensu::tls_check($port = ‘443’, $source = ‘’)

{

if ($source == ‘’)

{

$source_internal = “${name}.our.domain.com”

}

else

{

$source_internal = “${source}.our.domain.com”

}

sensu::check

{

“check_tls_certificates_${name}”:

command => “check-ssl-host.rb --warning 15 --critical 5 --host ${name}.our.domain.com --port ${port}”,

interval => ‘300’,

handlers => ‘default’,

subscribers => ‘proxy’,

standalone => false,

source => $source_internal,

require => Package[‘sensu-plugins-ssl’],

custom =>

{

impact => ‘Secure connections will throw warnings or not work at all.’,

suggestion => “Check connectivity. Renew the TLS certificate for the subdomain ${name}.our.domain.com.”,

}

}

}

``

Then, to apply one such section with the customized parameters I do the following:

class services::sensu::certificates

{

$host_is_subdomain = [‘subdomain1’,

‘subdomain2’,

‘subdomain3’]

services::sensu::tls_check{$host_is_subdomain:}

services::sensu::tls_check{‘subdomain4’: source => ‘actual_hostname’}

services::sensu::tls_check{‘subdomain5’: source => ‘actual_other_hostname’}

services::sensu::tls_check{‘subdomain6’: port => ‘993’, source => ‘example_hostname’}

}

``

4

would be helpful to actually include the gist: Recipe to create a bunch of sensu checks from attributes · GitHub

···

On Tuesday, July 4, 2017 at 8:49:18 AM UTC-7, Ben Abrams wrote:

There are many strategies you could take, in my deployment as I wanted to create a way for people with very little chef knowledge (noc in India) to be able to easily add checks that were specific to their application, env, etc with just having to essentially just give us the appropriate config in a simple attribute namespace. Since it is now 100% chef attribute driven that means that you can interpolate things from your env like your domain and go crazy. Here is a gist of the boiled down version of how we accomplish this. Whether this makes sense for you that I do not know.

On Wednesday, June 7, 2017 at 1:08:18 AM UTC-7, Alexander Skiba wrote:

On Monday, June 5, 2017 at 2:11:40 AM UTC+2, tmurphy wrote:

Rather, I am wondering if we can have a generic ‘default’, either in chef or elsewhere that we can modify and will be applied to all of our pings to make it easy for us to quickly update things like, for example the count (-c) value.

I suggest you check if chef has something similar to puppet’s defined types: https://docs.puppet.com/puppet/4.10/lang_defined_types.html

With this I write e.g. my checks for certificates:

Define: services::sensu::tls_check

allows TLS checks by only specifying subdomain to check

define services::sensu::tls_check($port = ‘443’, $source = ‘’)

{

if ($source == ‘’)

{

$source_internal = “${name}.our.domain.com”

}

else

{

$source_internal = “${source}.our.domain.com”

}

sensu::check

{

“check_tls_certificates_${name}”:

command => “check-ssl-host.rb --warning 15 --critical 5 --host ${name}.our.domain.com --port ${port}”,

interval => ‘300’,

handlers => ‘default’,

subscribers => ‘proxy’,

standalone => false,

source => $source_internal,

require => Package[‘sensu-plugins-ssl’],

custom =>

{

impact => ‘Secure connections will throw warnings or not work at all.’,

suggestion => “Check connectivity. Renew the TLS certificate for the subdomain ${name}.our.domain.com.”,

}

}

}

``

Then, to apply one such section with the customized parameters I do the following:

class services::sensu::certificates

{

$host_is_subdomain = [‘subdomain1’,

‘subdomain2’,

‘subdomain3’]

services::sensu::tls_check{$host_is_subdomain:}

services::sensu::tls_check{‘subdomain4’: source => ‘actual_hostname’}

services::sensu::tls_check{‘subdomain5’: source => ‘actual_other_hostname’}

services::sensu::tls_check{‘subdomain6’: port => ‘993’, source => ‘example_hostname’}

}

``