IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.

« Opsgenie connector and action Server log connector and action »

› › ›

PagerDuty connector and action

edit

PagerDuty connector and action

edit

The PagerDuty connector uses the v2 Events API to trigger, acknowledge, and resolve PagerDuty alerts.

Create connectors in Kibana

edit

You can create connectors in Stack Management > Connectors or as needed when you’re creating a rule. For example:

Connector configuration

edit

PagerDuty connectors have the following configuration properties:

Name: The name of the connector. The name is used to identify a connector in the management UI connector listing, or in the connector list when configuring an action.
API URL: An optional PagerDuty event URL. Defaults to https://events.pagerduty.com/v2/enqueue. If you are using the xpack.actions.allowedHosts setting, make sure the hostname is added to the allowed hosts.
Integration Key: A 32 character PagerDuty Integration Key for an integration on a service, also referred to as the routing key.

Create preconfigured connectors

edit

If you are running Kibana on-prem, you can define connectors by adding xpack.actions.preconfigured settings to your kibana.yml file. For example:

xpack.actions.preconfigured:
  my-pagerduty:
    name: preconfigured-pagerduty-connector-type
    actionTypeId: .pagerduty
    config:
      apiUrl: https://test.host
    secrets:
      routingKey: testroutingkey

Config defines information for the connector type.

apiURL: A URL string that corresponds to API URL.

Secrets defines sensitive information for the connector type.

routingKey: A string that corresponds to Integration Key.

Test connectors

edit

You can test connectors with the run connector API or as you’re creating or editing the connector in Kibana. For example:

PagerDuty actions have the following properties.

Severity: The perceived severity of on the affected system. This can be one of Critical, Error, Warning or Info(default).
Event action: One of Trigger (default), Resolve, or Acknowledge. See event action for more details.
Dedup Key: All actions sharing this key will be associated with the same PagerDuty alert. This value is used to correlate trigger and resolution. This value is optional, and if not set, defaults to <rule ID>:<alert ID>. The maximum length is 255 characters. See alert deduplication for details.
Timestamp: An optional ISO-8601 format date-time, indicating the time the event was detected or generated.
Component: An optional value indicating the component of the source machine that is responsible for the event, for example mysql or eth0.
Group: An optional value indicating the logical grouping of components of a service, for example app-stack.
Source: An optional value indicating the affected system, preferably a hostname or fully qualified domain name. Defaults to the Kibana saved object id of the action.
Summary: An optional text summary of the event, defaults to No summary provided. The maximum length is 1024 characters.
Class: An optional value indicating the class/type of the event, for example ping failure or cpu load.

For more details on these properties, see PagerDuty v2 event parameters.

Connector networking configuration

edit

Use the Action configuration settings to customize connector networking configurations, such as proxies, certificates, or TLS settings. You can set configurations that apply to all your connectors or use xpack.actions.customHostSettings to set per-host configurations.

Configure PagerDuty

edit

By integrating PagerDuty with rules, you can:

Route your rules to the right PagerDuty responder within your team, based on your structure, escalation policies, and workflows.
Automatically generate incidents of different types and severity based on each rule’s context.
Tailor the incident data to match your needs by easily passing the rule context from Kibana to PagerDuty.

Support

edit

If you need help with this integration, get in touch with the Kibana team by visiting support.elastic.co or by using the Ask Elastic option in the Kibana Help menu. You can also select the Kibana category at discuss.elastic.co.

Integration with PagerDuty walkthrough

edit

In PagerDuty

From the Configuration menu, select Services.
Add an integration to a service:
- If you are adding your integration to an existing service, click the name of the service you want to add the integration to. Then, select the Integrations tab and click the New Integration button.
- If you are creating a new service for your integration, go to Configuring Services and Integrations and follow the steps outlined in the Create a New Service section, selecting Elastic Alerts as the Integration Type in step 4. Continue with the In Elastic section once you have finished these steps.
Enter an Integration Name in the format Elastic-service-name (for example, Elastic-Alerting or Kibana-APM-Alerting) and select Elastic Alerts from the Integration Type menu.
Click Add Integration to save your new integration.

You will be redirected to the Integrations tab for your service. An Integration Key is generated on this screen.
Save this key, as you will use it when you configure the integration with Elastic in the next section.

In Elastic

Create a PagerDuty connector in Kibana. You can:
- Create a connector as part of creating an rule by selecting PagerDuty in the Actions section of the rule configuration and selecting Add new.
- Alternatively, create a connector. To create a connector, go to Stack Management > Connectors, click Create connector, then select the PagerDuty option.
Configure the connector by giving it a name and entering the Integration Key, optionally entering a custom API URL.

See In PagerDuty for how to obtain the endpoint and key information from PagerDuty and Connector configuration for more details.
Save the connector.
To create a rule, go to Stack Management > Rules or the application of your choice.
Set up an action using your PagerDuty connector, by determining:
- The action’s type: Trigger, Resolve, or Acknowledge.
- The event’s severity: Info, warning, error, or critical.
- An array of different fields, including the timestamp, group, class, component, and your dedup key. By default, the dedup is configured to create a new PagerDuty incident for each alert and reuse the incident when a recovered alert reactivates. Depending on your custom needs, assign them variables from the rule context. To see the available context variables, click on the Add variable icon next to each corresponding field. For more details on these parameters, see the Actions configuration and the PagerDuty API v2 documentation.

« Opsgenie connector and action Server log connector and action »