-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
[Lens] Decide where to store annotation data that is authored in Lens #87562
Comments
Pinging @elastic/kibana-app (Team:KibanaApp) |
cc @timroes @flash1293 for the Kibana team parts and @dgieselaar since you implemented the |
@wylieconlon I think part of why we decided to use an index was that there were some doubts about whether Saved Objects would give us the flexibility we might need, e.g. ILM, transforms, ECS, etc. We are not using any of those things right now so I'm not sure if in hindsight it was the right choice. Some of the use cases I considered back then:
|
We have settled on an approach. Pasting it here and resolving this issue To store these, a saved object for the annotation group is stored along with one annotation saved object per manual and query based annotation. A group can either be stored as persistable state within another saved object like a Lens visualization (migration, extraction and injection helper functions provided by the event_annotations plugin) or as separate annotation_library_group / annotation saved objects which are referenced by a Lens visualization or another saved object using regular saved object references. To make it easy to add differently keyed annotations later on, the “key” property of the annotation saved object has a “type” property which determines which information is available for showing the annotation in the right place (e.g. for point in time annotations there’s a single timestamp, for range of time annotations there’s two timestamps etc.) Annotation group saved object:
Manual annotation saved object:
Query based annotation saved object:
|
We are planning to add a Lens feature which lets users author annotations. An annotation for the purposes of Lens has these fields:
There are several open questions about how we should store the data. I think there are three outcomes that are possible, and the questions are the factors that will lead us to decide on one of these outcomes:
a. We create a new saved object type called
annotation
which becomes a standard across Kibanab. We create a new saved object type called
lens-annotation
which is available only in Lensc. We extend the
observability-annotations
index to support the features described, because annotations are most often used in observabilityThe easiest factors to address are the reasons not to use saved objects:
My opinion is that the answer is no to all of the above, because I expect that users who want to insert annotations will be able to use the Kibana API. I also expect that we'll provide a way to query annotations from an arbitrary Elasticsearch index which can be self-managed.
The second factor to decide is whether we want to have a single standard of annotations across Kibana. There are two downsides:
I would weight these issues as low-impact, and recommend that we create a new saved object type called
annotation
that can be used in Lens and solutions.Related issues and prior discussion:
TSVB annotations should be first class objects
Ability to insert TSVB annotations, not read-only
The text was updated successfully, but these errors were encountered: