Closed hvisage closed 6 years ago
You can do this by copying the visualization documents in elasticsearch and changing the parameter for index. I don't see us supporting a UI on for this sort of functionality any time soon.
:( It then becomes an quickly intractable O(M*N) issue (N=the number of indexes, and M the number of visualizations.
Is it possible with the current architecture? The index appears bound to the visualization, not the dashboard in K4. This would be hugely useful for me. Like most people (I imagine) I have each of my environments split into separate indexes; maintaining the dashboards becomes difficult...
In Kibana 3 I have hacked in a select list box which allows users to switch indexes for each dashboard, meaning only 1 dashboard needs to be maintained for all environments. Kibana 4 however binds the index to the visualisation not the dashboard. It might be helpful if the dashbaord could (optionally) override the index on its visualisations? I can see how it is useful to have a dashboard that is index agnostic in some use cases however.
+1
Copying the visualization documents in elasticsearch is not really an option. That generates a lot of duplicated information and updating would be a nightmare.
+1 on this. The "index pattern" concept naturally maps onto a "source" of data and the dashboard currently make it impossible to do this.
At the very least, the search bar at the top of the dashboard page should allow filtering by a "more specific" index pattern but it doesn't seem to accept searches with _index:...-*
patterns (nor specific values for that matter).
Our current workaround is to have a separate document type for each source because it's the only way to quickly filter by source while staying the same dashboard, but this creates Yet Another Configuration Problem (tm) because we need to create new type mappings for each environment...
We face a situation where we will have users from different departments doing different roles accessing the same data via their own dashboards. e.g. developers vs front line support staff.
How can we restrict the dashboard modifications - so that the set of dashboards created by developers for eg. cannot be modifed by support staff?
If shield is tied solely to the index, it wouldnt work as the underlying data for both dashboards is the same.
Thank you.
+1 for this. At this moment I am using Ansible and templates to at least automate a bit of the copy and substite process but this should not be THE way to do it. Redundancy is not cool from a maintenance perspective...
+1
+1 for this. It would be very usefull to have this feature when you have one index patter for every environment (dev, homolog, prod) but dashboards and visualizations are the same.
+1 Having index tied to visualization, embedded in dashboards, is a complete nightmare. It makes impossible to use aliases for recent data and long term logstash data, without rewriting completely the dashboards.
Please have a look at how dashboard interface and design works in Grafana 2, that totally nailed it form my point of view. For example, graphs are not separate entity but created inside a dashboard.
+1 Right now it is a complete nightmare when you have complex platforms.
+1 Please add this support fast...
+1
+1 It's a huge nightmare for us to have to create and then upkeep 3 different dashboard across 3 different environment. The dashboards should be the same for us in each environment but without this feature we have to manually create visualizations and dashboards 3 times over.
+1
+1
+1
+1 Duplicate visualizations is not the way. Why did you change Kibana 3 way to handle dashboards!?!?
+1
+1
+1
+1
+1
+1 this would be really important for us
+1
In Bitergia we have created a tool to create automatic dashboards from a template dashboard. One of the main tasks is modifying the index.
Here is the open source tool in case it is useful to anybody:
+1
+1
@rashidkpc : I tried your suggestion, and I'm having difficulty with creating the proper entries. Then I get a Kibana warning:
"Proceed with caution
Modifying objects is for advanced users only. Object properties are not validated and invalid objects could cause errors, data loss, or worse. Unless someone with intimate knowledge of the code told you to be in here, you probably shouldn't be."
Can you provide an example of copying such a dashboard? It looks like users could very well mess up their kibana instance mucking with this.
+1
+1
+5
+1
+1
+1
+1
+1
Hi @rashidkpc Still feel the same about this issue a year later with the responses given above?
Perhaps an "official" response as to how to handle the environments mentioned above?
+1
+1
+1
+1
+1 please.
+1
+1
+1
+1
+1
+1
+1
Update on April 4th 2018 We really appreciate all of your feedback on this mega issue so far, but we need your help as we break this down into more concrete items to work on. Even if you've already +1'd this specific issue, it would be extremely helpful if you could +1 and describe your use case in the more granular issues that are provided below. We won't ignore all the feedback folks have provided so far in this issue, but more focused feedback on the individual feature proposals would be invaluable.
Here are the three sub issues that I believe make up this mega issue:
Changing index patterns on a visualization: #17542 Dashboard level index patterns: #16917 Improved export/import to include referenced objects. Then you can do a search/replace on an index pattern id in a single file: #16831 Nested dashboards: https://github.com/elastic/kibana/issues/16919
Dashboard level index patterns seems to match this initial request best and there is a currently available workaround for it, which is mentioned in https://github.com/elastic/kibana/issues/16917.
If those three issues do not cover your particular case, please let us know!
Original Issue Request:
I'm in a situation where I have the exact same dashboard and it's visualizations, but want it to use different aliases/indexes.
The idea would be to segregate different user's data/views, but each have the same view/dashboard (just his/her index/alias differs), especially as I read Shield does authorization/access control via aliases/indexes and that is what I need/want to use for the user authorization/access control then.