[ 
https://issues.apache.org/jira/browse/METRON-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218425#comment-16218425
 ] 

ASF GitHub Bot commented on METRON-1272:
----------------------------------------

Github user justinleet commented on a diff in the pull request:

    https://github.com/apache/metron/pull/811#discussion_r146826488
  
    --- Diff: 
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/files/bro_index.template
 ---
    @@ -154,6 +154,10 @@
             "alert": {
               "type": "nested"
             },
    +        "metaalerts": {
    --- End diff --
    
    I was actually double checking if these changes were actually needed when 
you commented on this.  I thought it was, but after actually implementing it, 
it's not.  We don't search on this field or use it as anything other than a 
list of source strings, so we don't actually care that the analyzer may slice 
and dice the GUID.
    
    I just removed those changes from the PR, because while it may be nicer 
ES-wise to have them defined, I'd personally prefer to keep the overhead on new 
sensors as low as possible.  Let me know if that's alright with you and we can 
figure out if we want to add it back and document it or not.
    
    Basically, to check this, do the following:
    
    Create a meta alert, note the id (e.g.  
"bcf91b5b-1b14-42c1-98be-ef405ed48c70")
    ```
    {
      "groups": [
        "string"
      ],
      "guidToIndices": {
    "7764f686-f0b0-4657-90d4-42601a4e5ef1":"bro_index_2017.10.24.20"
    }
    }
    ```
    
    Pull back the child alert.  It'll have a meta alert field similar to this:
    ```
          "metaalerts": [
             "bcf91b5b-1b14-42c1-98be-ef405ed48c70"
          ]
    ```
    
    Create another meta alert, with the same alert as a child. Again, note the 
id ("1685d5ac-c3c7-4bdb-b4f1-ba9a17a00947")
    ```
    {
      "groups": [
        "string"
      ],
      "guidToIndices": {
    "7764f686-f0b0-4657-90d4-42601a4e5ef1":"bro_index_2017.10.24.20",
    "0241c002-2198-4fa4-a2e6-a33725fd9901":"bro_index_2017.10.24.20"
    }
    }
    ```
    
    Pull back the child alert again.  It'll have a meta alert field similar to 
this:
    ```
          "metaalerts": [
             "1685d5ac-c3c7-4bdb-b4f1-ba9a17a00947",
             "bcf91b5b-1b14-42c1-98be-ef405ed48c70"
          ]
    ```
    
    The second meta alert should properly have populated the field. 


> 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)

Reply via email to