Kibana [SOLVED] Filter Applies to Incorrect Index: Visualize: failed to find geo_point field [nginxgeo1]

[seth.yes (Seth S)]

I'm geomapping some data, all of which is located on my nginx index (e.g. nginx-2017.05.01) which contains the geo_point; nginxgeo1.

However I'm receiving an error that Elasticsearch can't find the geo_point field nginxgeo1 in the logstash index; logstash-2017.05.01. I of course do have a logstash index, but no data on this dashboard is being populated by the logstash index. Regardless, I still get this error:

Error: Request to Elasticsearch failed: {"error":{"root_cause":[{"type":"query_shard_exception","reason":"failed to find geo_point field [nginxgeo1]","index_uuid":"g6Uj2Qg3SialK4tqxccIyw","index":"logstash-2017.05.01"},{"type":"query_shard_exception","reason":"failed to find geo_point field [nginxgeo1]","index_uuid":"eN_0ify2RFO811SLs3iWrA","index":"logstash-2017.05.02"}],"type":"search_phase_execution_exception","reason":"all shards failed","phase":"query","grouped":true,"failed_shards":[{"shard":0,"index":"logstash-2017.05.01","node":"aC2_igyIQPivgRcTNEaMCQ","reason":{"type":"query_shard_exception","reason":"failed to find geo_point field [nginxgeo1]","index_uuid":"g6Uj2Qg3SialK4tqxccIyw","index":"logstash-2017.05.01"}},{"shard":0,"index":"logstash-2017.05.02","node":"x-ghbSl5Rf6ObX50KRY4DQ","reason":{"type":"query_shard_exception","reason":"failed to find geo_point field [nginxgeo1]","index_uuid":"eN_0ify2RFO811SLs3iWrA","index":"logstash-2017.05.02"}}],"caused_by":{"type":"query_shard_exception","reason":"failed to find geo_point field [nginxgeo1]","index_uuid":"eN_0ify2RFO811SLs3iWrA","index":"logstash-2017.05.02"}},"status":400}
    at http://opuscache/bundles/kibana.bundle.js?v=14823:28:19338
    at Function.Promise.try (http://opuscache/bundles/commons.bundle.js?v=14823:75:22403)
    at http://opuscache/bundles/commons.bundle.js?v=14823:75:21773
    at Array.map (native)
    at Function.Promise.map (http://opuscache/bundles/commons.bundle.js?v=14823:75:21728)
    at callResponseHandlers (http://opuscache/bundles/kibana.bundle.js?v=14823:28:18950)
    at http://opuscache/bundles/kibana.bundle.js?v=14823:28:7080
    at processQueue (http://opuscache/bundles/commons.bundle.js?v=14823:38:23621)
    at http://opuscache/bundles/commons.bundle.js?v=14823:38:23888
    at Scope.$eval (http://opuscache/bundles/commons.bundle.js?v=14823:39:4619)

Yet I have confirmed that all 7 visualizations are pointed to data on the nginx index, the one markdown widget is of course connected to no index. Furthermore, the only visualization that should be even querying the geo_point nginxgeo1 is the tilemap, which is properly populated.

What could be causing Kibana to query the incorrect index?

##Update: it appears to be the Kibana filter which is causing this issue.

The error toggles with adding/removing this geofilter.

The filter:

{
  "geo_bounding_box": {
    "nginxgeo1": {
      "bottom_right": {
        "lat": 35.7008015333603,
        "lon": -114.24146653153002
      },
      "top_left": {
        "lat": 36.633162103994366,
        "lon": -115.87568284012377
      }
    }
  }
}

[Joe_Fleming]

Are you sure you have a nginxgeo1 field in your logstash indices? If so, perhaps check your field mappings and make sure Elasticsearch thinks that field is a geo_point type.

[seth.yes (Seth S)]

I must not be clearly communicating the issue.

I do not have a field named nginxgeo1 in my logstash index, never have. Nor do I call on nginxgeo1 from any visualization other than the tilemap, which is pointed to the nginx index, which does have the expected geo_point field and displays properly.

The issue is that Kibana for some reason is expecting the geo_point field to appear under the logstash index, however nothing I've configured in Kibana tells it to look for any geo_point field in the logstash index.

Does that make sense?

[seth.yes (Seth S)]

Found a workaround and posted it here: [SOLVED] Kibana Geo Filter: Add Filter for Index

[Joe_Fleming]

Thanks for following up. I'll do you the same kindness. This was actually fixed recently, in this PR, and the fix will ship in 5.5.0. I'm checking with the author to see if that should be backported too.

UPDATE: It's been backported, and will be included in 5.4.1.