Jira and Jira Service Desk
FortiMonitor's Jira and Jira Service Desk integrations allow you to post incidents as issues to your Jira and Jira Service Desk environments.
Set up the integration
The integration can be setup via the Integrations page.
-
From the navigation menu, select Teams & Activity > Integrations.
-
Choose whether you want to post issues in Jira or Jira Service desk then select Configure.
-
Select Authorize to allow FortiMonitor access to your Jira or Jira service desk environment.
-
On the next screen, select Accept.
-
Configure your Jira or Jira service desk integration. The configuration options are detailed in the following table:
|
Field |
Description |
|---|---|
|
Projects |
Select which project the Jira or Jira Service Desk will be created when an incident occurs. |
|
Issue type |
Select the type of issue to be created. Values:
|
|
Close incident in Jira upon incident resolution |
Select this option if you want Jira or Jira Service Desk to automatically close issues once an incident is resolved. |
|
Close Type |
Enter the name of the transition to apply when an incident is resolved. |
|
JSON Payload |
The customizable JSON payload sent to the Jira API. You can create a payload for the following actions:
|
6. Select Save Integration.
7. Go to the Configured Integrations tab to verify your Jira or Jira Service Desk integration.
8. To set up notifications, configure the integration's Alert Timeline.
JSON payload
Incident creation
The following JSON payload is sent to Jira whenever an incident is detected. See Parameters for details on how to customize the payload.
Incident closure
The following JSON payload is sent to Jira once an incident is resolved. See Parameters for details on how to customize the payload.
Parameters
|
Parameter |
Description |
|---|---|
|
$trigger |
The type of event that triggered this payload (outage, ack, broadcast, clear) |
|
$fqdn |
The Fully qualified domain name of the server experiencing the incident/clear. |
|
$name |
Name of the server experiencing the incident/clear. |
|
$timestamp |
UTC timestamp of when the incident/clear occurred. |
|
$event |
The type of event, either incident event or clear event. |
|
$outage_id |
The ID number of the associated incident. |
|
$services |
For service incident: services experiencing the incident/clear. |
|
$compound_service_id |
The ID number of the compound metric affected. |
|
$network_service_id |
The ID number of the network service affected. |
|
$resource |
For resource anomalies: resources experiencing the anomaly/clear. |
|
$server_resource_id |
The ID number corresponding to the resource affected. |
|
$items |
Services experiencing the incident/clear or resources experiencing the anomaly/clear. |
|
$reasons |
The reasons for network service incidents or the details for anomalies. |
|
$duration |
The duration of incidents/anomalies which will be filled in on-clear. |
|
$tags |
The tags for the server. |
|
$server_key |
The server key for the server. |
|
$server_id |
The ID number of the server experiencing the incident/clear. |
|
$partner_server_id |
The partner server id for the server. |
|
$item_type |
The service type textkeys of the services experiencing the incident/clear, or plugin_textkey/resource_textkey combinations of the resources the experiencing the anomaly/clear, or the OID name of SNMP resources experiencing the outage/clear. |
|
$custom_attribute |
You can pass custom server attributes that are set on your servers. Use the attribute type as the key. |
|
$alert_label |
Alert label of the incident/anomaly. |
|
$severity |
The severity of the outage/anomaly, either critical or warning. |
|
$metric_tags |
The tags for all of the metrics involved in the outage. |
|
$location |
A comma-separated list of the primary monitoring probe names for all network services affected. |