PagerDuty dynamic/additional fields

[arisonl]

Currently the PagerDuty action fields are hardcoded. In addition, there are are requests for support of additional fields, e.g. 1) custom_details, images, links and 2) urgency.

cc @YulNaumenko

[elasticmachine]

Pinging @elastic/kibana-alerting-services (Team:Alerting Services)

[mikecote]

@arisonl is this a duplicate of https://github.com/elastic/kibana/issues/63933?

[arisonl]

@mikecote It contains it as it is broader. Also it is about making the action fields dynamic.

[mikecote]

@arisonl gotcha, thanks! Should we close the other one in favour of this one?

[pmuellr]

making the action fields dynamic

Not sure what this means. The ability to add new action parameters to a specific invocation of a connector? Is this like the ServiceNow mapping fields?

[pmuellr]

I was going to try to reform this as a meta issue, but I still have some questions that we should settle on before re-orging all the PagerDuty issues:

• re: urgency - that's not a field in the PD events API: https://developer.pagerduty.com/docs/events-api-v2/trigger-events/ - so there's nowhere for us to put a value like that

• for images, I'll end up referring to https://github.com/elastic/kibana/issues/49908 as a blocker, since I think we'll want to somehow create images from Kibana views, and will need some fundamental architecture to do this. For additional complication, it doesn't appear PagerDuty has "image upload" support, for us to upload an image, like Slack and GitHub do. That means we would need to arrange to either upload the images somewhere else, or host them in Kibana, but then how do we provide RBAC, or any auth, on those? I'm hesitant to even create an issue here because there's so little known about how we would deal with this

• for links, I think UI wise this is going to mean we'll allow the user to create a "list" of links, where each link has link text and a URL. So kinda like webhook headers. Is that acceptable?

• for custom details, this could also be similar to webhook headers - key/value pairs. Or were we thinking this should be more aligned with the way we do custom fields in ServiceNow, etc?

[pmuellr]

Here's a list of (at least some of the) relevant issues, once we re-org this:

• this issue
• https://github.com/elastic/kibana/issues/63933 - custom_details, images, links, urgency
• https://github.com/elastic/kibana/issues/49908 - image support in actions
• https://github.com/elastic/kibana/pull/64120 - PR to add some new fields, not merged, but some commentary
• https://github.com/elastic/elasticsearch/issues/67203 - es urgency

[pmuellr]

@arisonl just noticing I'm still assigned to this issue, so wanted to see what we want to do about it. Not sure if there's anything actionable, if we need some more work on it somehow? It's also not being tracked in our project ...

[runtman]

I was going to try to reform this as a meta issue, but I still have some questions that we should settle on before re-orging all the PagerDuty issues:

• re: urgency - that's not a field in the PD events API: https://developer.pagerduty.com/docs/events-api-v2/trigger-events/ - so there's nowhere for us to put a value like that

You are absolutely right but severity is still something. Can this be customised in favour of urgency?

payload.severityRequired | String | The perceived severity of the status the event is describing with respect to the affected system.

From memory watcher creates everything as critical.