feat: allow nested details fields in pagerduty

[siavashs]

This change allows nested key/value pair in pageduty configuration.

Events API V1 supports an object in details field: https://developer.pagerduty.com/docs/send-v1-event#parameters

Events API V2 supports an object in payload.custom_details field: https://developer.pagerduty.com/docs/send-alert-event#parameters

The configuration and message/payload types where changed from map[string]string to map[string]any.

The default template is updated to use the new toJson function.

Fixes #2477 Fixes #3218

Signed-off-by: Siavash Safi [email protected]

[grobinson-grafana]

I don't think it is intentional that the default template is valid YAML, it's just meant to be plain text. I'd even argue it's meant to be Markdown. If I understand the use case, you would like to be able to add structured objects (with nesting) to the custom_details field?

[siavashs]

I don't think it is intentional that the default template is valid YAML, it's just meant to be plain text. I'd even argue it's meant to be Markdown. If I understand the use case, you would like to be able to add structured objects (with nesting) to the custom_details field?

Correct, our teams prefer that so they can add logic on PagerDuty side depending on the field values. I tried to keep the logic generic so it would resolve the 2 referenced issues as well.

[grobinson-grafana]

Have you considered changing Details in the configuration file from map[string]string to map[string]interface{}?

// PagerdutyConfig configures notifications via PagerDuty.
type PagerdutyConfig struct {
...
	Details        map[string]interface{} `yaml:"details,omitempty" json:"details,omitempty"`
}

Would this avoid having to embed YAML inside existing YAML? I haven't checked if this will affect existing configurations, but it would be good to understand if this is a better option.

[siavashs]

Have you considered changing Details in the configuration file from map[string]string to map[string]interface{}?

That was the initial approach I though about. It will create a free style format and would require checking the interfaces one by one as they can be either maps or templated strings. I'm open to experiment with it.

[Daniel-Vaz]

Curious to know... Is this going forward ? Seems a real blessing having PD Custom Details properly rendered from the Alert Payload.

[siavashs]

I'll update this PR with the suggested map[string]interface{} to support nested fields.

[siavashs]

Thinking about this more, using a template like alerts: {{ .Alerts }} will translate into alert key with value of string as templates are only rendered into strings.

Parsing template results into maps or slices is possible but could be error-prone and we'd need a format for it. Alternative option could be toggles to include specific details in the payload:

details: ...

details_include:
  alerts: true
  ...