Migration from sensuclassic to sensugo: missing features

Sensu Go Migrating to Sensu Go
1

After migrating from sensuclassic to sensugo, we will lose the following features (see https://docs.sensu.io/sensu-core/1.8/migration/#2-translate-checks):

  • standalone checks
  • subdues
  • check aggregate (licence is required)
  • check dependencies

How can we replace the features above?
In my opinion:

  1. standalone checks can be replaced by subscription based checks: some effort required, it would be easier with an example (before vs after);
  2. subdue may be replaced with a a “cron” check that will silence a client/check/subscription using REST api;
  3. check aggregates: check type may be changed from “check” to “metric” (some effort required) and we could used grafana as alert system
  4. no clue for check dependencies.

What do you suggest?

Any feedback or recipe would be appreciated.

1 Like
2

Hey!
Real quick response to cover some of the things.

  1. If you can share an existing stand-alone check, I can probably show how I’d transition it.

  2. subdues:
    yes cron style scheduling is a good approach here.

  3. check_aggregates
    There is a check aggregate check plugin now that interacts with the sensu-backend API, aggregating around check label metadata using the API label select commericial feature in the official binaries.
    https://bonsai.sensu.io/assets/sensu/sensu-aggregate-check

Important note on licensing:
The new pricing model introduced with the 5.15 release, you’ll be able to use the API label selection feature (and all the commercial features in the official binaries) on deployments below 100 entities.

  1. Check dependencies
    This is probably the work flow we need to figure out how to re-implement in Sensu Go still.
3

Ok thanks.

So check_aggregates is only usable with commercial features and check_dependencies it’s not implemented yet.

Here below an existing standalone-check:

Context: Host with multiple postgresql DB

Standalone checks:

/etc/sensu/conf.d/checks/check-postgres-alive_mydb1.json
{
    "checks": {
        "check-postgres-alive_mydb1": {
            "command": "check-postgres-alive.rb -u :::postgresql_mydb1.user::: -p :::postgresql_mydb1.password::: -h localhost -d mydb1 -P 5432",
            "handlers": [
                "slack",
                "email"
            ],
            "high_flap_threshold": 60,
            "interval": 60,
            "low_flap_threshold": 20,
            "occurrences": 3,
            "refresh": 59,
            "standalone": true,
            "timeout": 30
        }
    }
}

/etc/sensu/conf.d/checks/check-postgres-alive_mydb2.json
{
    "checks": {
        "check-postgres-alive_mydb2": {
            "command": "check-postgres-alive.rb -u :::postgresql_mydb2.user::: -p :::postgresql_mydb2.password::: -h localhost -d mydb2 -P 5432",
            "handlers": [
                "slack",
                "email"
            ],
            "high_flap_threshold": 60,
            "interval": 60,
            "low_flap_threshold": 20,
            "occurrences": 3,
            "refresh": 59,
            "standalone": true,
            "timeout": 30
        }
    }
}

Client conf:

/etc/sensu/conf.d/extra_postgresql_mydb1.json 
{
    "client": {
        "postgresql_mydb1": {
            "user": "mydb1",
            "password": "<password_here>"
        }
    }
}

/etc/sensu/conf.d/extra_postgresql_mydb2.json 
{
    "client": {
        "postgresql_mydb2": {
            "user": "mydb2",
            "password": "<password_here>"
        }
    }
}
4

Hi, Any suggestion on how translate these standalone checks?

5

@bovy89 you should be able to change the check so that the subscription targets just the entity (e.g., entity:your.entity.name.example.com. You could include the user/pass as env vars for the entity and reference those in the check(s).

6

Ok, but usually standalone checks are dynamically generated on client by a configuration management tool (e.g. Puppet).

Just think at RabbitMQ with multiple vhosts. This script only supports one vhost at time, so I need to call it multiple times, one for each vhost, example (puppet code@client):

$vhost_list = ['vhost1', 'vhost2']
$vhost_list.each |String $this_vhost| {

    # vhost configuration here

    sensu::check { "check_rabbitmq_alive_${this_vhost}":
        command    => "check-rabbitmq-alive.rb -v %2f${this_vhost} -u ${this_vhost} -p :::rabbitmq_${this_vhost}.password:::",
        standalone => true,
    }
}

This generate on client two standalone check definitions, one for each vhost.

I think that manually declare these two check server-side (in this example), is a lost in flexibility, example (puppet code@server):

sensu::check { 'check_rabbitmq_alive_vhost1':
    command     => "check-rabbitmq-alive.rb -v %2fvhost1 -u vhost1 -p :::rabbitmq_vhost1.password:::",
    subscribers => ['<entity_id>'],
}

sensu::check { 'check_rabbitmq_alive_vhost2':
    command     => "check-rabbitmq-alive.rb -v %2fvhost2 -u vhost2 -p :::rabbitmq_vhost2.password:::",
    subscribers => ['<entity_id>'],
}

Is this the only way?

7

Does the check aggregates are now able to use by OSS users?

8

I prefer the client-side config as well (using Chef). I ended up making my own solution to enable some more flexibility without having to use tokens or tons of subscriptions.

On the client side I create a new folder named /etc/sensu/commands. That folder has a file with the name of the sensu check (e.g. proc_sshd) which is a one line bash script with the command inside of it, like:
/etc/sensu/plugins/check_proc -w 1: -C sshd

Then the check definition on the sensu backend is just a generic: /etc/sensu/commands/proc_sshd
It’s certainly not the most elegant, but it gives me the sensu 1.x parity with ease of config on client side via Chef, using Chef attributes. It also makes it so I can disable a check on just one client, e.g.:
/etc/sensu/plugins/check_proc -w 0: -C sshd
or
/etc/sensu/plugins/check_dummy 0 "This check is disabled"