Alerting: Opsgenie tags configuration simplification

[gotjosh]

Opsgenie configuration for tags it's currently very convoluted. We provide users with an option to send tags as:

• As part of the details field of an alert
• As part of the tags field of an alert
• Both

Here's the Opsgenie documentation as a reference: https://docs.opsgenie.com/docs/alert-api#create-alert

I don't think these make sense unless there's a use case I'm missing. The details of an alert are used to identify the alert, in my eyes, these are the labels - tags don't seem to belong in this context.

I think we should do a couple of things here to improve:

• Provide an option to define tags. The frontend supports an element type of string_array, we should use this as part of the channel configuration to provide our users with a way to define a set of tags.
• We should remove the configuration option for "send tags as".
• Make sure we're able to determine the priority of the alert based on the annotations
• Have a default of send "annotations" as tags (if no tags are present) by combining the key/value pairs with an : e.g. "key:value" and a way to turn this behaviour off.

If users think this behaviour is not desired, please feel free to speak up.

[josefzahner]

I do agree with you (however I'm an enduser), I've opened a discussion with a similar issue (#42807) but without any comments yet.
One small optimization for Opsgenie will arrive with 9.0.1 (#47813) but not directly related to tags. For me it looks like that not a lot of people are using the Opsgenie Integration. On 9.0.0 it's a mess.