[
https://issues.apache.org/jira/browse/METRON-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16215834#comment-16215834
]
ASF GitHub Bot commented on METRON-1272:
----------------------------------------
Github user nickwallen commented on the issue:
https://github.com/apache/metron/pull/811
> I find that extremely confusing as a user of the tool.
To explain that a bit more (and continuing with that same basic example)...
As a user I created a meta-alert where the hostname is "ip-addr.es". Since
I created a meta-alert around that specific hostname, that must be a pretty
important host name. It is probably something I am investigating right now.
Now imagine I ask my Tier III to take a look at that weird hostname. He's
going to do something like this to attempt to find that problematic hostname.

It appears that the hostname "ip-addr.es" is completely missing. It is as
if we lost data. This is the kind of work flow that I think is very confusing.
> 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)