-
Notifications
You must be signed in to change notification settings - Fork 74
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
Revisit integrations' dashboards and visualizations naming conventions #450
Comments
I just looked at the System dashboard created by @flash1293 @timductive and team which should server as a sample dashboard. In quite a few cases it does not contain titles at all or a short version without the old convention. Can the Kibana team please also chime in here? |
In general I agree that we can simplify the naming convention with the new by-value visualizations and tagging system. The system dashboard may need to be re-examined to update these best practices. @stratoula @markov00 @andrewctate @ninoslavmiskovic |
As discussed with the @elastic/kibana-presentation team a few days ago, I think we should clearly distinguish between the name used to describe a saved object and the name/title given to a dashboard/visualization. A name on a saved object is chosen to be easily searchable, probably with tagging to (in the name or externally). This, to me, is really similar to what you usually do when naming the file of a Doc or a Presentation. Instead the title of the dashboard/visualization, is itself a clean, well written, precise title of what you are looking at. In this context I don't care much about team/tags, etc but I care most about the content. The similarity here is the title of your Doc or Presentation, longer or concise, descriptive, clear. And where those titles are used, are two different contexts too:
We should really consider those two different contexts and two different scopes too. |
One consideration around using tags instead of title prefixes is that tags cannot currently be shared between integrations. So, if you install two integrations, both with "Threat Intel" tags, you get two distinct tags with the same name, not so useful for filtering. At the same time, sharing tags between integrations might complicate installations. Worth some further research, perhaps. |
Articulated the limitations of the current system in elastic/kibana#149982 |
Currently dashboards and visualizations of packages follow almost the same naming conventions as in beats .
There is this guide that package developers follow.
These conventions are:
[<Metrics | Logs> <PACKAGE NAME>] <Name>
, e.g. [Metrics Kubernetes] Cronjobs<NAME> [<Metrics | Logs> <PACKAGE NAME>]
, e.g. CronJobs Informations [Metrics Kubernetes]As mentioned in elastic/kibana#67258 this is done mainly for organizational reasons, so that the customers can find the dashboards and visualizations they want among multiple.
With the new features of Kibana like saved object tagging (elastic/kibana#74571) we could use tags for the dashboards instead of the prefix.
Also regarding the visualisations, it seems even simpler.
Migrating visualizations to by value practically means that individual visualizations are not saved as separate objects in Kibana but only as part of the dashboard.
So it does not seem to be any strong reason why the visualizations should have a suffix.
This was important when all those visualizations were saved as objects and some could have the same names(coming from different dsahboards) which could cause conflicts and confusion.
In general those extra suffixes and prefixes create noise and may also make the titles really long and not readable.
The text was updated successfully, but these errors were encountered: