Alert Catcher - 2.0.0

UI updates, changing configuration location

In version 2.0 we changed default configuration location. Now you can configure plugin on Connection page in top side bar.

 

Connection security settings, API token for every connection

This update allows you create issues in Jira by using AC endpoint with API key, that configured in Connection Security settings. A primary use case for API token is allowing creating incidents using this key as X-API-Key parameter in request header.

 

Simple example of POST request for creating new incident/alert via Alert Catcher.

curl --request POST \ --url http://my-instance:2990/jira/rest/catcher/1.0/alerts/zabbix \ --header 'content-type: application/json' \ --header 'x-api-key: <your api key>' \ --data '{ "id": "3734", "rule": "Lack of free swap space", "params" : { "Host": "10.100.0.5" } }'

Connection type

We introduce you Connection type - simplest feature to integrate your Jira with remote monitoring service. 

Connection type defines a remote system which Jira integrate with.

 

Rule synchronization

It's a tiny interface, that allows you import all rules(triggers) into Jira:

 

After importing rules you can configure actions for problem creation and set assignee for every rule.

Alert acknowledge

This feature allows you to close/acknowledge alert that came from external system. You should add Acknowledge alert post function to workflow transition. In example above, when you transition issue to status Done, alert from remote system should be acknowledged.

 

 

If you configured Rule actions and after a hardware failure, many incidents were created that caused the problem. After some time, you resolved the problem and you need to close all incidents related.

In release 2.0, we added the function of assigning incidents a certain status.

You need to set up a workflow alert and add the Transition Linked Issues (Alerts) post function to workflow transition. In the settings you need to specify the target status for your incidents.

 

In the example above, when the incident changes to the Resolved status, all incidents will be transferred to the Closed status.

HTTP multipart request

Now you can create incidents in Jira using HTTP multipart requests. This case may be useful when you integrate your Jira instance with systems like PRTG Paessler.

curl --request POST \ --url http://my-instance:2990/jira/rest/catcher/1.0/alerts/zabbix \ --header 'content-type: application/x-www-form-urlencoded' \ --header 'x-api-key: <your api key>' \ --data id=777-888 \ --data 'rule=System failure'



curl --request PUT \ --url http://my-instance:2990/jira/rest/catcher/1.0/alerts/zabbix/777-888 \ --header 'content-type: application/x-www-form-urlencoded' \ --header 'x-api-key: <your api key>' \ --data id=777-888 \ --data 'rule=System failure' \ --data Host=10.100.0.5



Transition incidents to particular status on update

In previous version you can update incident by alert id. Now you can change status when you update your incident.

You should add Status  value with destination status of issue workflow in JSON body.













 





 

Creating incident from a specific reporter

In some cases you need to set up reporter of your incident manually. In your connection settings you set up your default reporter for every incident.

Now you can set reporter when you create new incident by adding reporter param with Jira user' username.

This code snippet creates incident with reporter Alana Grant.

Result

 

Creating problem from current alert

 Now, you can ignore Rule action settings (Maximum number of incidents and maximum time). You can set isProblem parameter to value true and your incident creates with your problem' issue type.

Also you can specify issue type of your incident manually with parameter issueType.

This code snippet creates incident with Alert issue type. Be careful, issue type with name Alert must exist in your system and added to issue type scheme of your project.

Minor fixes and improvements

  • Connection and Alert ID  Alert Catcher' fields now are not required in your screens. You can add this fields if you want to make advanced filters/reports based on this fields.

  • Maximum time field now is not required. Problem creation action will triggered even if you reached critical number of incidents. Also you can specify any positive value in these fields.

  • On your connections page you can see icon that represent current connection type of your connection.