Conversation
|
Jira is so customisable that I'm not sure we can sanely offer a notifier for it, as everyone is likely to need custom code for their particular team's setup. For example there might be additional mandatory fields in a given organisation that this doesn't handle. I'd suggest a look at https://github.com/fabxc/jiralerts |
The |
there's a base set of required fields, and everything else can be set in the issue request, so can have an equivalent piece of alertmanager config. the choice of transition can be explicitly configurable (rather than the magic in https://github.com/fabxc/jiralerts) which should also avoid custom user code. |
|
@fabxc got quite deep inte the JIRA thing when he wrote https://github.com/fabxc/jiralerts . (I still remember his curses.) He should be able to spot if this PR ingeniously solves all the problems or, alternatively, where it fails to do so. |
| return false, err | ||
| } | ||
|
|
||
| req, err := http.NewRequest("POST", "https://jira.atlassian.com/rest/api/2/issue", bytes.NewBuffer(body)) |
There was a problem hiding this comment.
This will create a new JIRA every group_interval:
https://prometheus.io/docs/alerting/configuration/#route-route
I'm guessing it'll also create a new JIRA for every resolved alert notification.
There was a problem hiding this comment.
Correction: VSendResolved is set to false, so it won't create JIRAs for resolved alerts.
|
+1 Would like to see this merged. |
|
The main issue with it was indeed the heavy customisability of JIRA, in particular for issue transitions. See here, how jiralerts attempts to do an best effort thing based on common possible transitions. Also consider what happens with flapping alerts. If the same alert goes on and off 10 times in a row, do you really want 10 tickets? jiralerts puts a key in the description that is used for deduplication. Overall it is still unlikely to do what works for everyone's JIRA workflows. |
This is solved by simply not supporting closing or reopening tickets. If an alert fires, it is worth investigating, regardless of whether the condition stops being active, so the ticket should not be closed automatically. If a ticket has been closed, it has been declared as solved, so a new alert should file a new ticket. If a ticket has been closed but the alert is still firing, the issue will be bumped by filing a new ticket after repeat_interval. All that's left is filing new tickets, which does not seem to be workflow-dependent.
Would it make sense to add a group_retain_period or similar in alertmanager to handle flaps instead of having to do this in each plugin? |
Add `go get` and source directory requirements to the build instructions.
|
Hello, |
|
FYI, I've just put together an initial release of JIRAlert, a webhook receiver based on this PR and the comments it received, plus some ideas (and naming inspiration) from jiralerts. One issue is created (or reopened) per distinct group key and never closed (a human is expected to be in the loop for that part). Even though it is a separate binary it provides the same templating support as Alertmanager (a tiny bit of borrowed code, again) and it keeps the If any functionality/behavior you might need is missing, feel free to implement them. Or ask nicely, who knows? :o) |
8 participants
Add a notifier that can open tickets in Jira. This version does not support resolving alerts as mapping that onto ticket states is a little more complex.
This has been tested by running alertmanager with config for a cloud jira setup and manually triggering an alert.
@beorn7