Migration from sensuclassic to sensugo: missing features

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.

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.

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>"
        }
    }
}

Hi, Any suggestion on how translate these standalone checks?

@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).