[
https://issues.apache.org/jira/browse/METRON-1272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218860#comment-16218860
]
ASF GitHub Bot commented on METRON-1272:
----------------------------------------
Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/811
### Testing
Testing purely based on the REST API. Having said that, if you want to do
like @nickwallen did and pull in https://github.com/apache/metron/pull/803 into
the same branch, you should be able to follow his examples that he posted
screenshots for. Having done this myself, there should be no merge conflicts.
Throughout the following instructions, make sure to substitute GUIDs and
index appropriately.
Create a meta alert.
```
{
"groups": [
"string"
],
"guidToIndices": {
"c4060f38-aa20-4670-a85f-9d6e9fe0931a":"bro_index_2017.10.25.13"
}
}
```
Retrieve the meta alert. Either use curl or use `findOne` endpoint on the
returned GUID from the previous response.
```
curl -XGET
"node1:9200/metaalert_index/metaalert_doc/54f979ec-1491-4c8d-9292-db9202cdba86?pretty"
```
Ensure the contained alert has the appropriate guid, e.g.
```
...
"guid": "c4060f38-aa20-4670-a85f-9d6e9fe0931a",
...
```
Retrieve the child alert, again through curl or `findOne`
```
curl -XGET
"node1:9200/bro_index_2017.10.25.13/bro_doc/c4060f38-aa20-4670-a85f-9d6e9fe0931a?pretty"
```
Ensure the meta alerts field contains a link to the meta alert we created.
```
"metaalerts": [
"54f979ec-1491-4c8d-9292-db9202cdba86"
]
```
Run a search that should match both and ensure only the meta alert is
returned
```
{
"fields": [
"*"
],
"from": 0,
"size": 10,
"indices": [
"metaalert",
"bro"
],
"query": "guid:\"c4060f38-aa20-4670-a85f-9d6e9fe0931a\" OR
alert.guid:\"c4060f38-aa20-4670-a85f-9d6e9fe0931a\""
}
```
returns
```
{
"total": 1,
"results": [
{
"id": "54f979ec-1491-4c8d-9292-db9202cdba86",
"source": {
"_timestamp": 1508942592157
},
"score": 1,
"index": "metaalert_index"
}
]
}
```
This can also be run where multiple matches happen
```
{
"fields": [
"*"
],
"from": 0,
"size": 10,
"indices": [
"metaalert",
"bro"
],
"query": "ip_dst_addr:192.168.66.121 OR alert.ip_dst_addr:192.168.66.121"
}
```
Results are omitted for size, but the child alert should not show up, but
the meta alert should. Just do a find on the results if there are a lot or
modify the query.
Updating Status
A status update will carry through for all the child alerts. I.e. going
from "active" to "inactive" and vice-versa will manage the links.
```
{
"guid": "54f979ec-1491-4c8d-9292-db9202cdba86",
"index": "metaalert",
"patch": [{
"op": "replace"
, "path": "/status"
, "value": "inactive"
}],
"sensorType": "metaalert",
"source": {}
}
```
Retrieving the meta alert will now give an "inactive" status
Retrieving the alert itself again will now have the metaalerts field as
follows (assuming this alert isn't in any other meta alerts):
```
"metaalerts": []
```
It should also show up in our search again (but the metaalert won't!)
Try changing it back to active and ensure the child is linked again and is
hidden from the results.
```
{
"guid": "54f979ec-1491-4c8d-9292-db9202cdba86",
"index": "metaalert",
"patch": [{
"op": "replace"
, "path": "/status"
, "value": "active"
}],
"sensorType": "metaalert",
"source": {}
}
```
The link in the alert should also be back.
> 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)
