Github user nickwallen commented on a diff in the pull request:
https://github.com/apache/metron/pull/780#discussion_r142215715
--- Diff: metron-platform/metron-indexing/README.md ---
@@ -163,6 +163,36 @@ Both of these functions are handled under the hood.
In addition, an API endpoint is added for the meta alert specific features
of creation and going from meta alert to alert.
The denormalization handles the case of going from meta alert to alert
automatically.
+With Elasticsearch 2.x, there is an additional requirement that all
sensors templates have a nested alert field defined. This field is a dummy
field, and will be obsolete in Elasticsearch 5.x. See [Ignoring Unmapped
Fields](https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-sort.html#_ignoring_unmapped_fields)
for more information
+
+Definition of the expected field:
+```
+ "alert": {
+ "type": "nested"
+ }
+```
+
+Without this field, an error will be thrown during ALL searches (including
from UIs, resulting in no alerts being found for any sensor):
+
+Exception seen:
+```
+QueryParsingException[[nested] failed to find nested object under path
[alert]];
+```
+
+To put a new template into Elasticsearch to resolve this issue, update the
template with the new field:
+```
+curl -XPUT 'http://node1:9200/$SENSOR*/_mapping/$SENSOR_doc' -d '
--- End diff --
Can we make it more clear that `node1:9200` is the Elasticsearch API
host:port that may be different outside of Full Dev?
There may be a better way, but maybe something like the following. If I
install Metron using the MPack, do we call the Elasticsearch REST API something
in there that might make sense here?
```
export ELASTICSEARCH="node1:9200"
curl -XPUT 'http://$ELASTICSEARCH/$SENSOR*/_mapping/$SENSOR_doc ...
```
---
