[Security Solution][Detections][Threshold Rules][7.12] Threshold summary view

[madirey]

Summary

Users have complained that matching threshold fields were removed from the generated synthetic signals (here is one example: https://discuss.elastic.co/t/threshold-detection-ignoring-group-by-field/264873/5). The fields were removed in 7.11 for 2 reasons: 1) we attempted to add fields from the rule's KQL query to the signal, but the query can contain wildcards. Thus you could end up with a set of matching events with cardinality(field) > 1, which makes it unclear which value to add to the synthetic signal; and 2) a user could group by signal.rule.building_block_type and generate a signal that differs semantically from the intended behavior.

In this PR, I've attempted to address those concerns in a different way.

1. Adds threshold fields to summary view. Marks "generated" threshold fields as [threshold] for clarity. Some fields may be repeated if they were already in the summary view (host.name for example).
   

2. Adds back threshold fields to the synthetic signal, and thus back to the alerts table view. We don't attempt to add fields from the query, as this can be difficult to ascertain and also can contain wildcards which results in a set of values with cardinality > 1. Fields starting with signal. are excluded, so that a user can't override functionality with signal.rule.building_block_type for example.
   

Checklist

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/security-solution (Team: SecuritySolution)

[elasticmachine]

Pinging @elastic/security-detections-response (Team:Detections and Resp)

[banderror]

Just a random idea regarding UX (if I'm getting it correctly): in this PR you take some data specific to signals generated by threshold rules, take it from a signal, map it to a bunch of artificial fields and show in this summary table. As an idea, what do you think about showing these rule-specific parameters in a separate view, let's say right below the generic summary view?

Signal fields
=====
field | value
field | value
...

Threshold stuff
=====
whatever view would be the best for this data

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 414a639
• Storybooks Preview

Metrics [docs]

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
securitySolution	7.8MB	7.8MB	+1.8KB

History

• 💛 Build #112747 was flaky 7447ac7
• 💔 Build #112605 failed acc28d5
• 💛 Build #112565 was flaky e8f4d57

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

[banderror]

Thanks for addressing my silly comments :) It looks good to me 👍
I will need more time to debug threshold rule execution and this summary view to really connect all the dots. So it would be great if someone else could look into it, give more meaningful feedback than me and give an additional approval.

[yctercero]

This is gonna be a big ➕ for users! This LGTM. There are a few things I saw that can be followed up on as it's more UX and may be worth getting some feedback from @dontcallmesherryli . I like @banderror 's suggestions too.

A few notes:

• when query does not include group by fields, it still includes the threshold value which could be useful to include in the summary.
• May be worth adding tooltips to the threshold fields so someone can look at the summary and know exactly what it means (like that the fields listed are the group by fields)
• It looks like on hover of the threshold field values, it's giving the field, not the value