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