Kibana PagerDuty Connector - ability to select document field as DedupKey option

Elastic Stack Kibana
1

Hi,

As part of PagerDuty integration, we would like to use a document field as a DedupKey field in the setup.

I am struggling to find documentation that explains how to reach out, if possible at all, to document fields which are in the scope of the index chosen for this connector setup.

The documentation available here PagerDuty connector and action | Kibana Guide [8.3] | Elastic briefly mentions what the Dedup Key is and its default value ().

I tried via {{context.<doc_field_name>}} or {{context.<doc_field_name>.keyword}} but that doesn't work.

Am I trying to do something that is not possible?

Many thanks.

2

You will need to align the alerting rule with the ability to use a field the alerting rule exposes via context variables. Each rule provides different context variables, so we need to know which alerting rule you want to use. For instance, if you're using the Elasticsearch query rule, here are the context variables available: Elasticsearch query | Kibana Guide [8.3] | Elastic

If it's not clear what context variables are available, you can use {{.}} in an action's message (email, server log, etc), to render a JSON representation of all the context variables available.

I'm guessing the Elasticsearch query won't actually work out in this case, as you'd have to be accessing it's hits array context variable to access your document's field. The index threshold rule type provides the field values when grouping over a particular field, which may end up working out here. Otherwise, the metrics and logs threshold rule types are aimed at specific observability indices, but could work out in your case.

3

Thanks for your reply.

It's about the Elasticsearch query actually.

I originally thought the Dedup field's sole purpose is to point at a doc field. Now I'm starting to think it's about alerting data in particular. Is my thinking wrong, to assume it's normal to want to use the original data to dedup? What's more trustworthy than that?

Using hits array on Dedup field will likely not work as I have no way to iterate over context.hits array. Right? Maybe if there is a way to access the last event only and then select its doc fields.

Many thanks.

4

I believe you can access a field from the first entry in hits via something like {{context.hits.0.someField}} - individual array elements are accessible via .n in mustache. Again, try using {{.}} in some kind of "test" action to see what values are available.

For rules that do grouping, you would typically use the grouped field value for dedup'ing, though technically these would all have different alert ids, so the default of {{rule.id}}:{{alert.id}} will distinguish them. Since the elasticsearch query doesn't group, pulling a value from hits seems like it would work out.

5

Thanks for your help. In the end I revisited the whole approach on how this needs to work. We've come to the conclusion this is not the best way to push data out of Elasticsearch since PagerDuty requires the original data source and that is hard to get to using Alerting overall.
We will workout an interface to do that instead.

But this was useful information. Thanks again.

6

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.