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