-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for Kibana Spaces in Beats modules #7942
Comments
In any case we should add support for this in Beats. So the user could run something like:
I assume Kibana knows in which space the users is when looking at the add data ui so this could be dynamically generated? Does Kibana have any capabilities to copy / make available the same dashboards across multiple spaces? |
cc @jsoriano |
That's correct, we'll have to make sure that this is exposed in such a manner that the add data UI can take advantage of it.
For the initial implementation of Spaces, a Dashboard/Visualization will only exist in a single Space and there's not a mechanism to make something available in every space. |
@nreese you might be interested in following this thread as well |
To expand on @kobelb's answer, my understanding of the spaces presentation is that it will be possible to export and re-import dashboards across spaces, just like one could export/import across clusters. But you won't be able to "make available" per se, as he said. And from what I understood, it seems like the approach of having Kibana Objects 100% independent from one space to another is rooted pretty deeply in the implementation of spaces. |
@alexfrancoeur said:
Poking around the tutorials code in Kibana I found that the Kibana UI requests tutorials from the Kibana server via the So if we want to add more dynamic-ism / intelligence to the tutorial content, this will require a bit of work on the Kibana side. @nreese thoughts? |
@ycombinator Have you considered moving saved object loading into Kibana? Checkout the Maybe beats should no longer load kibana saved objects? |
@nreese It's definitively one of the directions we should be heading long term. I would treat removing dashboards from our repos as a breaking change so I don't think we should do it in a minor. |
Started a PR to show what one potential solution would look like |
Started a PR which builds on Nate's PR above to supply the |
I have a PR in kibana to address this: elastic/kibana#22998 |
We've merged Spaces into Kibana's Let us know what we can do to help, and of course, let us know if you run into any issues integrating with Spaces. |
Cherry-pick of PR #8045 to 6.x branch. Original message: Resolves #7942. Kibana is implementing a new feature called Spaces, in which Kibana saved objects (such as dashboards) and advanced settings can be restricted to a user-defined namespace. Spaces are identified by a unique ID, e.g. `my-space`. There is also a notion of a Default space which corresponds to how Kibana worked up until the Spaces feature was introduced. Beats have the ability to import dashboards into Kibana as well as export dashboards out of Kibana. With Spaces, dashboards may belong to a specific space. So Beats must learn to accept an optional Space ID and operate against it when importing or exporting dashboards. This PR teaches Beats to do just that. Concretely, if a user wishes to import or export dashboards from a specific space, say with ID = `my-space`, they must either: * Edit `<beat>.yml` and set `setup.kibana.space.id: my-space`, _or_ * Run `<beat> setup` or `<beat> export dashboard` along with the `-E setup.kibana.space.id=my-space` option. Similarly, if a Beat _developer_ wishes to export dashboards from a specific space, say with ID = `my-space`, they must run: ```sh go run dev-tools/cmd/dashboards/export_dashboards.go -space-id my-space [other options] ```
We are currently targeting Kibana Spaces for 6.5 (elastic/kibana#18948). With this implementation, Kibana will support multi-tenancy. If we change nothing today, every user that follows the add data instructions will end up importing the module dashboards into the default space (assuming they even have access to this). As an end user, if I followed these instructions, I would expect the dashboards to be available in the space that I'm currently in.
As modules currently utilize the dashboard import/export API (elastic/kibana#10858), I want to make sure we support Spaces out of the box. This actually works today as long as the URL is formatted appropriately.
Today
API endpoint
/api/kibana/dashboards/export?dashboard=7adfa750-4c81-11e8-b3d7-01146121b73d
With Spaces
Default Space API endpoint (same as above)
/api/kibana/dashboards/export?dashboard=7adfa750-4c81-11e8-b3d7-01146121b73d
Specific Space API endpoint
/s/space-id/api/kibana/dashboards/export?dashboard=7adfa750-4c81-11e8-b3d7-01146121b73d
I've tested this with a Space ID and it does work. Are there any changes that we need to add to support this? Should we have users add the default Kibana URL and add an option to add one or multiple Spaces from CLI or the config yaml? How important is it to have a single data source (the beat) and dashboards in multiple Kibana Spaces?
We should also either intelligently add the URL / space ID to the UI tutorials or add some descriptive text around using the Space URL generically.
cc: @ruflin @tsg @legrego @kobelb @acchen97
The text was updated successfully, but these errors were encountered: