Alias for auto-close alerts from SNS via HTTPS

[Andrii Ovcharenko]

Hi. We setup notification from Amazon SNS to https endpoint in Opsgenie. Alert contains a specific hostname like host-001-host.name. Please advise how we can setup aliases for auto-closing alerts after receiving status OK.

[Nick Haller]

Hi Andrii,

That would be dependent on what dynamic field the hostname is being parsed in on the integration. You can drag and drop these fields to specify what the alias will be in the different actions such as Create or Close:

If the hostname is not parsing in any of these provided fields, but is parsed in the payload of the alert -> then we see customers using some form of string processing or regex to extract the data into the alert fields / alias:

https://docs.opsgenie.com/docs/string-processing-methods

https://docs.opsgenie.com/docs/regular-expressions

It might look something like {{_payload.substringBetween("hostname:",",") }}

The logs can be reviewed under Settings -> Debug -> Logs. You can search the timestamp and look for the SNS processed/received integration logs.

Let us know if you have any additional questions or issues.

-Nick 

[Andrii Ovcharenko]

Hi Nick, please review my reply below.

[Andrii Ovcharenko]

Hi Nick,

Incoming data contains string

message [AmazonSns] ALARM: "host-name-001"

I configured alias {{ subject.substringAfter(":") }} in Create Alert and Close Alert actions and filters:
Create alert:
Event type equals create
Message contains ALARM

Close alert:
Event type equals close
Message NOT contains ALARM

But all the same, different alerts are generated for ALARM and OK events

[Nick Haller]

Hi Andrii,

It looks like you have added another condition in those actions along with what the default filters are;

Create action default filter: Event Type = create

Close action default filter: Event Type = close

Not to say addition conditions can't be done, but have you tried testing with the default filters?

Without review the logs of the alerts that were created for "different alerts generated for ALARM and OK events," this will be difficult to troubleshoot.

If you're comfortable doing so, feel free to share screenshots of your logs here - but don't feel like you need to if you do not want expose any private information. Otherwise please open a ticket with support@opsgenie.com and I can help there. You can even reference me and our conversation, and I'll pick it up. 

-Nick

[Andrii Ovcharenko]

.

[Nick Haller]

Hi Andrii,

Thanks for providing those. I'd need to take a deeper look at some other logs and your account to really make an assessment. 

I just sent you a message through our in-app chat tool that can be found at the bottom-right corner of the screen:

If you do not see this - it's most likely due to an ad-blocker. If temporarily disabling any of those does not show the chat-app (after a hard refresh) - please open a ticket with support@opsgenie.com. I'll pick up that ticket and we can discuss further.

Thanks!

[Nick Haller]

Hi Andrii,

Thanks again for your time just now via in-app chat! Glad we could sort this out.

For others that might face the same/similar problem - there were a few steps to troubleshoot and resolve this issue. In order for the Integration's Close Alert action to apply, two things must match;

1) The filter conditions of the Close Alert action.

The filter of the Integration's Close Alert action was not matching. After reviewing the logs - we realized the Event Type was always sending create (vs. close) - so we adjusted the filter from looking at: Event Type Equals "close" -> Subject Contains "OK".

2) The alias of the Close Alert action needs to match the alias of an open existing Opsgenie alert.

The substring being used to parse the alias of the actions (see screenshots above) was off just a bit. Instead of {{ subject.substringAfter(":") }} -> the substring needed to be {{ Subject.substringAfter(":") }}.

Note these are case sensitive - so Opsgenie could not recognize subject (vs. Subject) - and was creating an alias based off the alert's ID instead of what appeared after the :

In these scenarios, the Logs (found under the Settings tab) are always your best friend to review the processed incoming data, and troubleshoot/review where the integration may be misconfigured. https://docs.opsgenie.com/docs/logs

-Nick