OpsGenie Action

This package contains a template for creating a webhook action that sends LogScale alerts and scheduled searches to OpsGenie. The action template provides the same content as the built-in OpsGenie action type, but in addition it allows you to, for example, add additional fields and otherwise customize it to meet the needs of your organization.

Installing the Package in LogScale

Find the repository where you want to use OpsGenie actions or create a new one.

  1. Navigate to your repository in the LogScale interface, click Settings and then Packages on the left.

  2. Click Marketplace and install the LogScale package for OpsGenie (i.e., crowdstrike/logscale-opsgenie).

  3. When the package has finished installing, on the top menu go to Alerts and then click Actions on the side menu.

  4. Click + New action, a pop-up is displayed.

  5. Type a name for the action, select From package and click Continue.

  6. An action is created with pre-filled fields, where you need to set the API key (replace INSERT_KEY) in the Http Headers. You can also change the priority from P3, which is the default value to one of the possible values, which are P1, P2, P3, P4, and P5.

Package Contents Explained

This package contains:

OpsGenie - An action that corresponds to the built-in OpsGenie action.

Customizing Your Action and Triggers

Take a look at the OpsGenie API documentation to see which fields you can send. You can use Message Templates and Variables to fill in information about the trigger, the query and the events found by the query.

That link also describes how you can use these message templates in the name or the description of the trigger. In that way, you can use the same action for multiple triggers and get customized messages, where the customization happens in the trigger.

Example

You create an action where; the message contains {description} which will be replaced by the description of the trigger. In the description of one trigger, you can then write Host {field:$host} failed. If the result of the trigger had a field host=3, this will be expanded to Host 3 failed, before being put into the {description} message template in the action.

Another trigger could have a different description using different fields.