# Migration from sensuclassic to sensugo: missing features

**URL:** <https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477>\
**Category:** Migrating to Sensu Go\
**Created:** [December 5, 2019, 8:55pm UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477 "2019-12-05T20:55:07Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![bovy89](https://avatars.discourse-cdn.com/v4/letter/b/e9bcb4/32.png) [@bovy89](https://discourse.sensu.io/u/bovy89)\
**Post date:** [December 5, 2019, 8:55pm UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/1 "2019-12-05T20:55:07Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![jspaleta](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.sensu.io/jspaleta/32/141_2.png) [@jspaleta](https://discourse.sensu.io/u/jspaleta)\
**Post date:** [December 6, 2019, 5:10pm UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/2 "2019-12-06T17:10:15Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![bovy89](https://avatars.discourse-cdn.com/v4/letter/b/e9bcb4/32.png) [@bovy89](https://discourse.sensu.io/u/bovy89)\
**Post date:** [December 12, 2019, 9:00am UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/3 "2019-12-12T09:00:12Z")

</div>

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:

```auto
/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:

```auto
/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>"
        }
    }
}

```

---

<div class="post-metadata">

**Author:** ![bovy89](https://avatars.discourse-cdn.com/v4/letter/b/e9bcb4/32.png) [@bovy89](https://discourse.sensu.io/u/bovy89)\
**Post date:** [January 10, 2020, 9:57am UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/4 "2020-01-10T09:57:44Z")

</div>

Hi, Any suggestion on how translate these standalone checks?

---

<div class="post-metadata">

**Author:** ![aaronsachs](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.sensu.io/aaronsachs/32/47_2.png) [@aaronsachs](https://discourse.sensu.io/u/aaronsachs)\
**Post date:** [January 10, 2020, 5:29pm UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/5 "2020-01-10T17:29:15Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![bovy89](https://avatars.discourse-cdn.com/v4/letter/b/e9bcb4/32.png) [@bovy89](https://discourse.sensu.io/u/bovy89)\
**Post date:** [March 11, 2020, 12:27pm UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/6 "2020-03-11T12:27:03Z")

</div>

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](https://github.com/sensu-plugins/sensu-plugins-rabbitmq/blob/master/bin/check-rabbitmq-alive.rb) 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?

---

<div class="post-metadata">

**Author:** ![edx](https://avatars.discourse-cdn.com/v4/letter/e/4da419/32.png) [@edx](https://discourse.sensu.io/u/edx)\
**Post date:** [September 30, 2020, 1:43pm UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/7 "2020-09-30T13:43:17Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![caseyhitt](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.sensu.io/caseyhitt/32/460_2.png) [@caseyhitt](https://discourse.sensu.io/u/caseyhitt)\
**Post date:** [October 13, 2020, 2:56am UTC](https://discourse.sensu.io/t/migration-from-sensuclassic-to-sensugo-missing-features/1477/8 "2020-10-13T02:56:32Z")

</div>

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