Prevent visualizations from different indices types filter each other in a dashboard

[rcrezende]

It's an excellent feature to have Visualizations from multiple indices (with different types) in the same dashboard.
Let's say you have a dashboard with three Visualizations, V1 and V2 getting data from Index1_TypeA and V3 getting data from Index_TypeB.

If the user clicks on V1, kibana will apply the filter to V1, V2 and V3, regardless the type of V3 is different than V1. Very likely this will in most of cases filter all data of V3 and (at least in my case) is very counter intuitive to have no results in V3 (instead, I understand as Not Applicable filter to V3 and so it shouldn't filter).

My proposal is to apply the filter only to the visualizations that share the same type of "click"-visualization-source.

In the previous example, after clicking in V1, V1 and V2 would be filtered, but V3 untouched.
V3 only filters V3.

[jimmyjones2]

I personally find the current way useful - I have different indices but keep some of the fields the same (eg. customer_id) so filtering across indices works fine. Maybe this could be an option?

[ajrasch]

I agree that as an option it would be a very nice option but not forced. I
expect filters to apply to everything I see and if they aren't really doing
that it could be misleading....

On Wed, Apr 8, 2015 at 9:06 AM jimmyjones2 [email protected] wrote:

I personally find the current way useful - I have different indices but
keep some of the fields the same (eg. customer_id) so filtering across
indices works fine. Maybe this could be an option?

—
Reply to this email directly or view it on GitHub
#3538 (comment).

[rcrezende]

Notice that I'm referring to types not indices. But since your are saying "keep some of the fields the same" and there is no concept of type specialization/inheritance at ES level, I see two options:
a) an option :-P;
b) if the filter contains any field not part of the type, then it's Not Applicable.

Thoughts?

[rashidkpc]

This is unlikely to be something we implement, specifically the type thing. Elasticsearch has no concept of relating types across indices.

Also, we don't acknowledge types in Kibana at all. See this ticket for the reason: #2943

[rcrezende]

Ok, maybe type is not the way to go. But if we have two views, V1 attached to data from index 1 and V2 attached to index 2. If someone clicks in a field-value in V1, it's unexpected filter all data out from V2 just because the index 2 has no such field. If the field is not there, the data should not be filtered out because the filter is not applicable to index 2.

[kumarsubodh]

We have very similar request. I am not worried about the type but we have a section of dashboard that pull data from a grandparent index which should stay static as the child indexes are filtered. For example, I have an storage array that connects multiple hosts. At the top panel, I have summary information about storage array, in following sections, we display details for hosts, and other children. If we filter on a component of host (Or a host), it does not make sense to filter the storage array panel and show no value there. I find this very valuable to build general purpose dashboards in hierarchical data models. This will help kibana enhance the monitoring abilities of data center operations.

[TheSecMaven]

We have dashboards with uptime monitors on the heartbeat-* index and then we have another index for our application logs. The filter is being applied to the whole dashboard and thus is breaking our heartbeat visualizations since those are on separate indexes and have different fields (app log fields allow us to filter down to our app and production, for example).

We actually got around this by using https://www.elastic.co/guide/en/kibana/current/advanced-options.html

There is an option

courier:ignoreFilterIfFieldNotInIndex	Skips filters that apply to fields that don’t exist in the index for a visualization. Useful when dashboards consist of visualizations from multiple index patterns.

That solved this for us!