bin/handler-opsgenie.rb
bin/check-opsgenie-heartbeat.rb
handler-opsgenie
{
"opsgenie": {
"customerKey": "the-key",
"teams": [
{ "name": "the-team" },
{ "id": "4513b7ea-3b91-438f-b7e4-e3e54af9147c" }
],
"recipients": "the-recipients",
"source": "alert-source",
"overwrite_quiet_hours": true,
"tags": ["sensu"]
}
}
To get this to work you need to specify a few different things. For a list of fields that are required/available look at the sensu documentation. These files need to be on the server and the client boxes. Once there restart sensu-server and sensu-api.
- declare this as a handler:
/etc/sensu/conf.d/handler_opsgenie.json
{
"handlers": {
"opsgenie": {
"type": "pipe",
"command": "/opt/sensu/embedded/bin/handler-opsgenie.rb"
}
},
"opsgenie": {
"customerKey": "YOUR-KEY-HERE"
}
}
- add it to the check:
/etc/sensu/conf.d/check_xxx.json
{
"checks": {
"check_elastinats_is_running": {
"command": "/opt/sensu/embedded/bin/check-process.rb -p cron",
"interval": 60,
"handlers": [ "opsgenie" ],
"subscribers": [ "core" ]
}
}
}
- optionally add it to the default handler:
/etc/sensu/conf.d/default_handler.json
{
"handlers": {
"default": {
"type": "set",
"handlers": [
"opsgenie"
]
}
}
}
How does the handler map the various Sensu values into the OpsGenie alerts and alert fields created?
The OpsGenie message alert field is comprised of the Sensu client name, and the Sensu check name, e.g.:
web01 : check_mysql_access
The OpsGenie team alert field uses the values in the Sensu check configuration if any, otherwise it uses the value from the handler configuration.
The OpsGenie recipients alert field uses the values in the Sensu check configuration if any, otherwise it uses the value from the handler configuration.
The OpsGenie alias alert is field is comprised of the Sensu client name, and the Sensu check name to create a unique key, e.g.:
web01:check_mysql_access
Note that this can be changed via configuration; see notes below.
The OpsGenie entity alert field uses the Sensu client name.
The OpsGenie description alert field is populated with the Sensu check output.
The OpsGenie priority alert field is not explicitly set; OpsGenie will thus assign the default priority of "P3" to the alert.
If the check definition uses the custom alias
attribute, e.g.:
{
"checks": {
"check_mysql_access": {
"opsgenie": {
"alias": "MyCustomAlias",
then the handler-opsgenie.rb
handler will use that attribute value as the
OpsGenie event ID. This can be useful for alert deduplication; checks on
different clients for the same downstream resource can specify the same
alias
attribute, so that multiple alerts for the same resource are
de-duplicated.
By default, handler-opsgenie.rb
creates an event ID from the client name
and the check name. Thus:
{
"checks": {
"check_mysql_access": {
"command": "/opt/sensu/embedded/bin/check-database.rb -h mysqldb",
"interval": 60,
"handlers": [ "opsgenie" ],
"standalone": true
}
}
running on a client named web01
will create an alert using an event ID of
web01:check_mysql_access
. And on a client named web02
, it would create an
alert with a different event ID of web02:check_mysql_access
, even though
the mysqldb
server being checked is the same for these clients.
We can define a custom alias
attribute in this check:
{
"checks": {
"check_mysql_access": {
"command": "/opt/sensu/embedded/bin/check-database.rb -h mysqldb",
"interval": 60,
"handlers": [ "opsgenie" ],
"standalone": true,
"opsgenie": {
"alias": "mysqldb"
}
}
}
And with this, running on multiple clients, any alerts would be generated
with the same event ID of mysqldb
, by using that alias
attribute as the
event ID.
By default, an OpsGenie alert is created with a default priority value of "P3". The priority for a specific
check can be explicitly set using the custom priority
attribute, e.g.:
{
"checks": {
"check_mysql_access": {
"opsgenie": {
"priority": "P1",
The list of valid values, per OpsGenie alert docs, are:
- P1
- P2
- P3
- P4
- P5
Any value other than these will be ignored.