Automating Resolution of Zabbix Alerts in Jira Service Projects

[Hanner Mendoza]

Hello Jira Support Community,

I'm a dedicated user of Jira Software and currently seeking assistance with automating processes within my Jira Service project's alerts board. Here's a brief overview of my situation:

I rely on Zabbix, a robust monitoring system, to keep track of my VoIP system. Whenever an alert arises, Zabbix promptly notifies me via email. For instance, an alert email might contain the following information:

Problem: Load average is too high (per CPU load over 2 for 5m)
Severity: Average
Host Name: Zabbix server
Alert triggered by: Google Zabbix

Similarly, upon resolution of the alert, I receive a subsequent email, such as:

Resolved in 2m: Load average is too high (per CPU load over 2 for 5m)
Severity: Average
Host Name: Zabbix server
Alert triggered by: Google Zabbix

To streamline my workflow, I have integrated the Jira board's email address into the Zabbix alert's mailing list. As a result, a ticket is automatically created on the board whenever a problem or resolved alert is received. Additionally, I've set up a Google Chat space linked to the same Jira board, enabling me to receive alerts through that channel as well.

However, I face a challenge where numerous open alerts accumulate over time, requiring manual deletion. Therefore, I'm seeking a solution that automatically resolves both the "problem" alert and its corresponding "resolved" alert when the latter is received.

I kindly request your support and guidance in implementing an automation mechanism to address this issue effectively.

Thank you, esteemed community members, for your valuable assistance.

Best regards,
Hann

[Ash Yadav · Accepted solution]

Hi @Hanner Mendoza 

You could have an automation rule that parses a certain part of the email if the format is consistent. 

Do all resolved emails that are created in JSM contain the "resolved" or "problem" in the summary? 

If they do, try the following: 

You could have it even more specific such as Summary contains "Resolved in" if that works better, feel free to play around with it. 

If it isn't consistent and this was a useless answer, please let me know and I'll dig deeper :) 

All the best, 

Ash 

[Hanner Mendoza]

Dear Ash Yadav,

Thank you for your prompt response.

I have implemented the configuration you suggested, and it seems to be partially effective. Only the "Resolved" alert is correctly marked as resolved, while the "Problem" alert remains in progress.

My objective is to ensure that when the "Resolved" alert is triggered, it resolves the corresponding "Problem" alert.

Additionally, I have encountered some errors in the logs related to the rule. Here are the details:

ACTION DETAILS:
TRANSITION ISSUE
Destination status could not be resolved. If you are using a smart-value, please ensure that it resolves to a numeric status ID or an untranslated name for the issues. The current status of the "Problem" alert is as follows:
ALTS-38085 (Waiting for support - 10052)

IF BLOCK
The following issue has passed the condition:
ALTS-38085

ASSOCIATED ITEMS:
ISSUE EVENT
ALTS-38085

I appreciate your assistance in addressing these concerns. Let me know if you require any further information.

Best regards,

[Ash Yadav]

Hi Hanner, 

In this case you can experiment around with the logic of the automation rule, here in my example I had it set to just transition to open but you can very well change it to resolved too for the problem issue, it's entirely up to you. 

Can you post a screenshot of the current automation rule that you've created? 

It's a little hard to explain over text, I think I'd be more help if I saw how you've created the rule. 

All the best, 

Ash

[Andrew Laden]

See my note below for my strategy. The problem with using automation rules is that they run AFTER the issue is created. Which is why your rule has a problem in that it is already creating the issue based on the resolved email.

I supposed if you wanted you could have the automation search for an open issue that matches the problem in the resolved issue mail, and then close both issues. (and link them together for good measure.) But you are still creating a 2nd issue each time. You need something that can catch and process the email BEFORE it creates a new issue, and that is going to be difficult with built in tooling.

[Andrew Laden]

(caveat, I use on prem, not cloud)

You are going to have some trouble doing this out of the box. Jira's built in email handler does have some logic to try to group emails to identify emails relating to a existing issue vs a new one.

I have zabbix integrated with Jira, but I use OpsGenie as the "filter" between them. Zabbix sends the alert to OpsGenie, which can then use its rich processing engine to determine if this is a new alert, or a close relating to a previous alert. I then use OEC to allow OpsGenie to create or close the alert in jira.  You can probably use the built in integration if you are all cloud though. Not sure how much of an option this is for you, ie can you afford to buy opsgenie, even for a few users. If you are just using it to take advantage of its filtering engine, and not using it for notification or escalation, then you dont need many users.

If you don't want to use OpsGenie, then another option would be a 3rd party mail handler, like JEMHC, which can "pre-preprocess" the emails have better logic that would allow you to group the emails together.