Add default handler to all checks

Sensu Go
,
1

Sorry if this has been mentioned elsewhere but i could not find it anywhere and thought i would ask here.

I have a Centos 7 EC2 instance which is running the sensu go backend and agent and i was wondering if we have default handler which would be applied to all checks as was the case earlier in Sensu Core (https://docs.sensu.io/sensu-core/latest/guides/intro-to-handlers/#create-the-set-handler-definition). I want to send an alert to OpsGenie via my opsgenie handler on any check created when there is an incident.

Currently i have to manually add handler by adding "handler": ["opsgenie"] and i would like to avoid that for any new checks that are created.

Current setup is

=== check-cpu
Name:              check-cpu
Interval:          60
Command:           check-cpu.rb -w 75 -c 90
Cron:
Timeout:           0
TTL:               0
Subscriptions:     system
Handlers: opsgenie
Runtime Assets:    cpu-checks-plugins, sensu-ruby-runtime
Hooks:
Publish?:          true
Stdin?:            false
Proxy Entity Name:
Namespace:         default
Metric Format:
Metric Handlers:

Ideal setup is to not mention handler during creation time and the handler is auto-populated with opsgenie handler.

I have tried to create a handler named “default” which is of set type with opsgenie as one of the handler but this is not applied to the checks automatically.

=== default
Name:                  default
Type:                  set
Timeout:               0
Filters:               is_incident
Mutator:
Execute:               CALL: opsgenie
Environment Variables:
Runtime Assets:
2

Hey,
No Sensu Go doesn’t automatically attach a default handler any longer if no handler is specified. You’ll need to explicitly add your default handler when constructing checks.

I believe this was an explicit design decision to allow for workflows with events to exist in an unhandled manner. So instead of doing shenanigans like having to invoke a noop handler to prevent the default from firing to avoid tripping the default in the namespace, the more reliable pattern is to be explicit about what handler you want to call.

A metrics check for example, may not need to have a default status handler attached as well as a having a metrics handler. Some events may be used solely for aggregate check conditionals, and won’t need to be handled. Or maybe you are putting a new check into production in a just in time mannter during an incident to capture new information and you want to test it a bit before enabling the normal automated remediation and so you leave the handlers unspecified when you first deploy it so you can capture the event in sensu to inspect manually.