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