We are currently in the process of migrating our alerting infrastructure from OMD to Atlassian’s OpsGenie. Most of the features (SMS, phone call etc.) worked out of the box but we struggled with pushing alerts back into our on-premises Jira instance.
Enable logging of POST requests
OpsGenie does not provide debug logs of all executed HTTP requests against Jira’s REST API. Instead, only the very generic HTTP status code is provided like
Lucky for us, our Jira instance is running behind an Apache HTTPD webserver acting as a proxy. With help of the mod_security module we were able to trace the communication between OpsGenie and our Jira instance:
LoadModule security2_module modules/mod_security2.so
<VirtualHost *:443>
# ...
<IfModule mod_security2.c>
SecRuleEngine On
SecAuditEngine On
SecAuditLog /var/log/httpd/modsec_audit.log
SecRequestBodyAccess on
SecAuditLogParts ABIJDFHZ
</IfModule>
</VirtualHost>
Configuring the Jira worfklow schema
OpsGenie requires you to have atleast a workflow with the following status transitions:
- TODO/Open -> In Progress
- In Progress -> Resolved
It is important, that
- the statusses are named exactly as “Resolved” and “In Progress” as OpsGenie’s internal Jira connector is case-sensitive
- you are not confusing the status name with the status category
In English-based Jira installations, this should not be an issue but in our localized German environment, we had to add both statusses to Vorgänge > Status and add its English translation to the status:
To check the correct names, you can access the REST API of your Jira instance like https://jira/rest/api/2/issue/${OPSGENIE_PROJECT}/${ISSUE_ID}/transitions. The transitions[].to.name field inside the JSON response must match the statusses above, like
{
"expand":"transitions",
"transitions":[
{"id":"41","name":"Öffnen",
"to":{
"self":"https://jira/rest/api/2/status/10617",
"description":"Der Vorgang wird aktuell nicht bearbeitet und wurde noch nicht vollständig fertig gestellt.",
"iconUrl":"https://jira/images/icons/statuses/open.png",
"name":"Offen","id":"10617",
"statusCategory":{"self":"https://jira/rest/api/2/statuscategory/2","id":2,"key":"new","colorName":"blue-gray","name":"Aufgaben"}
}
},
{"id":"61","name":"Resolve",
"to":{
"self":"https://jira/rest/api/2/status/5",
"description":"Resolved",
"iconUrl":"https://jira/images/icons/statuses/resolved.png",
"name":"Resolved",
"id":"5",
"statusCategory":{"self":"https://jira/rest/api/2/statuscategory/3","id":3,"key":"done","colorName":"green","name":"Fertig"}
}
}
]
}
After we had configured the workflow schema, OpsGenie was able to create issues and transitions them to the In Progress status.
Configuring the screen mask for solving open alerts
When we tried to close an open alert in OpsGenie, Jira failed with the HTTP 400 error described above. In our mod_security logs we saw the following output:
POST /rest/api/2/issue/${ISSUE_KEY}/transitions HTTP/1.1
Accept: text/plain, application/json, application/*+json, */*
Content-Type: application/json;charset=UTF-8
....
Accept-Encoding: gzip,deflate
--8ddfb330-C--
{"transition":{"id":"61"},"fields":{"resolution":{"name":"Done"}}}
--8ddfb330-F--
HTTP/1.1 400 Bad Request
The transition.id 61 pointed to the transition from In Progress to Resolved but its screen mask was obviously missing the “resolution” field. You can easily check the fields for a transition by accessing the issues’s transition configuration: https://jira/rest/api/2/issue/${ISSUE_KEY}/transitions?61&expand=transitions.fields.
We added the missing Lösung (Solution) field to the screen mask of the transition but the error still occurred.
Translating the “Solution” field
Again, the solution fields have to be translated so that is called “Done” and not “Fertig”. You can change the translations at https://jira/secure/admin/ViewTranslations!default.jspa?issueConstantType=resolution.
In the end, everything is working and OpsGenie is now able to create issues and move them through the expected statusses/transitions.
