[
https://issues.apache.org/jira/browse/METRON-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215855#comment-16215855
]
ASF GitHub Bot commented on METRON-1272:
----------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/811
> @nickwallen suppose you have a metaalert that contains 2 alerts. Then
suppose each alert has a different value for the host field. If you grouped on
host, which group would you expect the metaalert to appear in?
I would say both. Let me try and explain that.
To me, the "group by" functionality is super-powerful for digging down deep
into the alerts data. When I group by hostname and open that accordian, I
expect to see all the alerts related to that hostname. That would include a
meta-alert that has even 1 contained alert related to that hostname.
Maybe there are other corner cases that I am not considering, but that's
what I would expect.
> Hide child alerts from searches and grouping if they belong to meta alerts
> --------------------------------------------------------------------------
>
> Key: METRON-1272
> URL: https://issues.apache.org/jira/browse/METRON-1272
> Project: Metron
> Issue Type: Improvement
> Reporter: Justin Leet
> Assignee: Justin Leet
>
> If an alert is already grouped into a meta alert, it's nice to route
> everything through the same query structure and allow sorting alongside them,
> etc. However, showing alerts that are already contained in a meta alert is
> potential clutter for a user and gives the impression an event has occurred
> twice if it's in a standalone alert and a metaalert.
> This should hide alerts contained in a meta alert from searches (which will
> always match the enclosing meta alert anyway, so nothing will be lost from
> the search).
> They should also be hidden from grouping calls, because the user has already
> manually grouped them during prior slicing and dicing.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
