sensu-plugins / sensu-plugins-opsgenie

Sensu plugins for OpsGenie
http://sensu-plugins.io
MIT License
4 stars 24 forks source link
sensu-handler sensu-plugins

Sensu-Plugins-opsgenie

Build Status Gem Version Code Climate Test Coverage Dependency Status

Functionality

Files

Usage

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

Installation

Installation and Setup

Configuration

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.

OpsGenie Alerts

How does the handler map the various Sensu values into the OpsGenie alerts and alert fields created?

Message

The OpsGenie message alert field is comprised of the Sensu client name, and the Sensu check name, e.g.:

web01 : check_mysql_access

Teams

The OpsGenie team alert field uses the values in the Sensu check configuration if any, otherwise it uses the value from the handler configuration.

Recipients

The OpsGenie recipients alert field uses the values in the Sensu check configuration if any, otherwise it uses the value from the handler configuration.

Alias

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.

Entity

The OpsGenie entity alert field uses the Sensu client name.

Description

The OpsGenie description alert field is populated with the Sensu check output.

Priority

The OpsGenie priority alert field is not explicitly set; OpsGenie will thus assign the default priority of "P3" to the alert.

Configuration Notes

Per Check Attributes

alias

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.

priority

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:

Any value other than these will be ignored.