I had an idea to rewrite index .kibana for different groups. For example:
group1 -> rewrite .kibana to .kibana-group1
group2 -> rewrite .kibana to .kibana-group2
This would allow group1 to have one set of dashboards while group2 would have a second set of dashboards.
Did anyone attempt this and succeeded?
First problem i hit (that is easy to work around) is that if you rewrite an index to another index that doesn’t exist RoR will return Forbidden which then confuses Kibana and Kibana won’t create the other index. I think it would be more logical if RoR would return Not Found in case the rewritten index doesn’t exist.
Anyway, it’s easy to workaround that issue by just manually creating the indices.
The second, more serious problem was that once .kibana index was rewritten to .kibana-group1, Kibana somehows managed to break the indices. You could no longer access original .kibana index (with no rewriting) because index UUIDS somehows got mixed up and on any attempt to do anything with original .kibana ES would throw IllegalStateException. It seems that there is something that Kibana Managment page does that can make index rewriting unsafe. I had to manually delete the indices from disk while ES was shut down to repair this.
I’ll try to reproduce this and post steps that lead to this situation.
Anyhow, if anyone succeeded with creating separate dashbords for separate groups via .kibana index rewritting, please let me know.
Indices rewriting is a monumental pain in the butt. There’s so many edge cases: i.e. templates, reindex API, Index UUID rewriting.
Not to mention the error management decisions to be made. Like the one you rightfully proposed. For now, indices_rewrite works well for a limited number of operations. Specifically search, index and a few others.
Handling “.kibana” correctly is the holy grail of index rewriting skills, but unfortunately we’re not there yet.
If you see the code, rewrite relies in a number of ad-hock reflection flicks in the request side and even more on the “onResponse” and “onError” side of things.
This field is the second most important field where I’d love to have some help. The first is to ease the multi-es-version releases, but @coutoPL is well on top of it
haha oh no…
On the bright side, in the new Kibana plugin (ReadonlyREST PRO) it’s a feature in the roadmap to change the “kibana.index” setting on the fly per-request according to the identity cookie.
