Hello,
I wonder if it’s possible to manage client’s check parameters using client’s tags.
Example: two servers belong to different environments. Environment name is stored in client’s tag. Servers have the same role, which means the same subscription name. But for ‘prod’ i need to run checks more often or with different parameters than for ‘dev’.
As far as I can see, sensu check object does not have any conditionals or filtering properties.
At this moment I’ve implemented this logic using different subscriptions, for example ‘dev_cassandra’ and ‘prod_cassandra’,
and these subscriptions have different checks attached. But this approach causes a lot of code duplication if you have more than two environments.
Can I avoid having different subscriptions?
Thanks.
In my experience the only way to solve this is using configuration systems
like Ansible or Salt to distribute your checks and use stand-alone checks
(not server-scheduled checks), where the interval would be a template
variable (e.g in ansible {{ cassandra_check_interval }} and that variable
is set to different values depending on the environment.
···
On Thu, Sep 1, 2016 at 5:41 AM, Volodymyr Linevych <vo.on3z@gmail.com> wrote:
Hello,
I wonder if it's possible to manage client's check parameters using
client's tags.
Example: two servers belong to different environments. Environment name is
stored in client's tag. Servers have the same role, which means the same
subscription name. But for 'prod' i need to run checks more often or with
different parameters than for 'dev'.
As far as I can see, sensu check object does not have any conditionals or
filtering properties.
At this moment I've implemented this logic using different subscriptions,
for example 'dev_cassandra' and 'prod_cassandra',
and these subscriptions have different checks attached. But this approach
causes a lot of code duplication if you have more than two environments.
Can I avoid having different subscriptions?
Volodymyr,
Sensu provides a first-class primitive for this called “token substitution” and it is designed to solve the exact problems you are describing. See here: https://sensuapp.org/docs/0.26/reference/checks.html#check-token-substitution
I hope this helps!
#monitoringlove
···
On Thursday, September 1, 2016 at 2:41:17 AM UTC-7, Volodymyr Linevych wrote:
Hello,
I wonder if it’s possible to manage client’s check parameters using client’s tags.
Example: two servers belong to different environments. Environment name is stored in client’s tag. Servers have the same role, which means the same subscription name. But for ‘prod’ i need to run checks more often or with different parameters than for ‘dev’.
As far as I can see, sensu check object does not have any conditionals or filtering properties.
At this moment I’ve implemented this logic using different subscriptions, for example ‘dev_cassandra’ and ‘prod_cassandra’,
and these subscriptions have different checks attached. But this approach causes a lot of code duplication if you have more than two environments.
Can I avoid having different subscriptions?
Thanks.
Caleb, is it possible to use token substitution for handlers as well? The particular use I am thinking of is a definition for a mailer handler to go to particular teams for specific servers.
We could use a generic check, but in the client definition specify the support email handler for the specific team that manages the servers.
Eg, one mailer handler for internal servers, one mailer fordev servers, one mailer for live servers etc, but we have one set of standard checks that run for all of them.
Cheers,
Joel
···
On Friday, 7 October 2016 17:35:08 UTC+1, Caleb Hailey wrote:
Volodymyr,
Sensu provides a first-class primitive for this called “token substitution” and it is designed to solve the exact problems you are describing. See here: https://sensuapp.org/docs/0.26/reference/checks.html#check-token-substitution
I hope this helps!
#monitoringlove
On Thursday, September 1, 2016 at 2:41:17 AM UTC-7, Volodymyr Linevych wrote:
Hello,
I wonder if it’s possible to manage client’s check parameters using client’s tags.
Example: two servers belong to different environments. Environment name is stored in client’s tag. Servers have the same role, which means the same subscription name. But for ‘prod’ i need to run checks more often or with different parameters than for ‘dev’.
As far as I can see, sensu check object does not have any conditionals or filtering properties.
At this moment I’ve implemented this logic using different subscriptions, for example ‘dev_cassandra’ and ‘prod_cassandra’,
and these subscriptions have different checks attached. But this approach causes a lot of code duplication if you have more than two environments.
Can I avoid having different subscriptions?
Thanks.
To answer my own question, yes it is possible to use token substitution for handlers. Thus I have a check which uses the handlers
handlers => [‘mailer’,‘:::team_mailer|default:::’,‘graphite_status’],
``
and uses the token ‘team_mailer’ to refer to the mailer which has been defined on the server in question with some json like:
{
“client”: {
“team_mailer”: “dev_poc_mailer”
}
}
``
If team_mailer has not been defined, then it uses the handler ‘default’ instead.
···
On Wednesday, 12 October 2016 11:33:54 UTC+1, joel....@nhs.net wrote:
Caleb, is it possible to use token substitution for handlers as well? The particular use I am thinking of is a definition for a mailer handler to go to particular teams for specific servers.
We could use a generic check, but in the client definition specify the support email handler for the specific team that manages the servers.
Eg, one mailer handler for internal servers, one mailer fordev servers, one mailer for live servers etc, but we have one set of standard checks that run for all of them.
Cheers,
Joel
On Friday, 7 October 2016 17:35:08 UTC+1, Caleb Hailey wrote:
Volodymyr,
Sensu provides a first-class primitive for this called “token substitution” and it is designed to solve the exact problems you are describing. See here: https://sensuapp.org/docs/0.26/reference/checks.html#check-token-substitution
I hope this helps!
#monitoringlove
On Thursday, September 1, 2016 at 2:41:17 AM UTC-7, Volodymyr Linevych wrote:
Hello,
I wonder if it’s possible to manage client’s check parameters using client’s tags.
Example: two servers belong to different environments. Environment name is stored in client’s tag. Servers have the same role, which means the same subscription name. But for ‘prod’ i need to run checks more often or with different parameters than for ‘dev’.
As far as I can see, sensu check object does not have any conditionals or filtering properties.
At this moment I’ve implemented this logic using different subscriptions, for example ‘dev_cassandra’ and ‘prod_cassandra’,
and these subscriptions have different checks attached. But this approach causes a lot of code duplication if you have more than two environments.
Can I avoid having different subscriptions?
Thanks.
Joel,
Hi there! Good questions, and good job with your tests/findings. To provide a little clarification and/or context here, and potentially point you in a better direction, as of Sensu Core version 0.24 token substitution may be used in any check definition attribute (previously this was only allowed in the “command” attribute. While this may be useful for configuring event handlers, we do have a first-class feature for this called “Contact Routing” (Sensu Enterprise only). In your example use case (i.e. to send emails to different addresses based on the source of the check; e.g. development environment vs production environment), this is a first-class feature in Sensu Enterprise. See here for more information: https://sensuapp.org/docs/0.26/enterprise/contact-routing.html 
I hope this helps. Let me know if you have any further questions.
Cheers,
···
On Wed, Jan 18, 2017 at 8:47 AM, joel.smith1@hscic.gov.uk wrote:
To answer my own question, yes it is possible to use token substitution for handlers. Thus I have a check which uses the handlers
handlers => [‘mailer’,‘:::team_mailer|default:::’,‘graphite_status’],
``
and uses the token ‘team_mailer’ to refer to the mailer which has been defined on the server in question with some json like:
{
“client”: {
“team_mailer”: “dev_poc_mailer”
}
}
``
If team_mailer has not been defined, then it uses the handler ‘default’ instead.
On Wednesday, 12 October 2016 11:33:54 UTC+1, joel....@nhs.net wrote:
Caleb, is it possible to use token substitution for handlers as well? The particular use I am thinking of is a definition for a mailer handler to go to particular teams for specific servers.
We could use a generic check, but in the client definition specify the support email handler for the specific team that manages the servers.
Eg, one mailer handler for internal servers, one mailer fordev servers, one mailer for live servers etc, but we have one set of standard checks that run for all of them.
Cheers,
Joel
On Friday, 7 October 2016 17:35:08 UTC+1, Caleb Hailey wrote:
Volodymyr,
Sensu provides a first-class primitive for this called “token substitution” and it is designed to solve the exact problems you are describing. See here: https://sensuapp.org/docs/0.26/reference/checks.html#check-token-substitution
I hope this helps!
#monitoringlove
On Thursday, September 1, 2016 at 2:41:17 AM UTC-7, Volodymyr Linevych wrote:
Hello,
I wonder if it’s possible to manage client’s check parameters using client’s tags.
Example: two servers belong to different environments. Environment name is stored in client’s tag. Servers have the same role, which means the same subscription name. But for ‘prod’ i need to run checks more often or with different parameters than for ‘dev’.
As far as I can see, sensu check object does not have any conditionals or filtering properties.
At this moment I’ve implemented this logic using different subscriptions, for example ‘dev_cassandra’ and ‘prod_cassandra’,
and these subscriptions have different checks attached. But this approach causes a lot of code duplication if you have more than two environments.
Can I avoid having different subscriptions?
Thanks.
–
Caleb Hailey | President
503.209.4070 (Mobile) | @sensu | https://sensuapp.org