Skip to content
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

[MDS] Full TSVB Support #6290

Closed
huyaboo opened this issue Mar 28, 2024 · 1 comment · Fixed by #6543
Closed

[MDS] Full TSVB Support #6290

huyaboo opened this issue Mar 28, 2024 · 1 comment · Fixed by #6543
Assignees
Labels
enhancement New feature or request multiple datasource multiple datasource project v2.14.0

Comments

@huyaboo
Copy link
Member

huyaboo commented Mar 28, 2024

Proposal

As of today, Time Series Visual Builder (TSVB) does not support remote datasource connections (also referred to as multiple datasource or MDS). #6005 provides most of the building blocks to support TSVB. However, there are a few features to consider to fully integrate MDS into TSVB:

  • Export/import logic: With #5712, users can specify which datasource to import from. TSVB should seamlessly import from different datasources.
  • Timeseries annotations: One feature of the timeseries graph visualization is the ability to place annotations or markers on the graph. Each annotation has its own index pattern to fetch data from.

In this issue, these features will be the main focus. For details on how TSVB can support MDS, refer to #6005.

High-Level Approach

TSVB, like other visualizations, store all configurations within the visState. For TSVB, an example visState looks like the following:

{
  title: 'Test',
  type: 'metrics',
  aggs: [],
  params: {
    annotations: [{
      fields: '',
      template: 'field',
      index_pattern: 'open*',
      query_string: {
        query: 'some-query',
        language: 'kuery'
      },
      color: '#F00',
      icon: 'fa-asterisk',
      id: 'c1693f50-e7ae-11ee-a975-3b6cd68aa468',
      ignore_global_filters: 1,
      ignore_panel_filters: 1,
      time_field: '@timestamp'
    }, {
      fields: 'some-field',
      template: 'field',
      index_pattern: 'open*',
      query_string: {
        query: 'some-query',
        language: 'kuery'
      },
      color: '#F00',
      icon: 'fa-tag',
      id: 'c278da90-e7ae-11ee-a975-3b6cd68aa468',
      ignore_global_filters: 1,
      ignore_panel_filters: 1,
      time_field: '@timestamp'
    }],
    axis_formatter: 'number',
    axis_position: 'left',
    axis_scale: 'normal',
    background_color_rules: [
      [Object]
    ],
    bar_color_rules: [
      [Object]
    ],
    default_index_pattern: 'test*',
    drop_last_bucket: 0,
    filter: {
      language: 'kuery',
      query: ''
    },
    gauge_color_rules: [
      [Object]
    ],
    gauge_inner_width: 10,
    gauge_style: 'half',
    gauge_width: 10,
    id: '61ca57f0-469d-11e7-af02-69e470af7417',
    index_pattern: 'opensearch_*',
	// New field to be added in params
	data_source_id: 'some-datasource-id',
    interval: '',
    isModelInvalid: false,
    series: [
      [Object]
    ],
    show_grid: 1,
    show_legend: 1,
    time_field: null,
    tooltip_mode: 'show_all',
    type: 'timeseries'
  }
}

#5717 introduced new datasource picker components exposed from core for plugins to consume. This provides the plugin with dataSourceId information that can be used to pass into the /api/metrics/fields and /api/metrics/vis/data API calls. When a user selects the datasource, the params object will be updated to add a new field data_source_id: <id>.

Below is an example of the new component added to the Panel options tab:
TSVB Panel options edit box

As for export/import logic, there first needs to be a datasource reference since the TSVB visualization will make use of a datasource. This can be configured at save time where the reference will be appended. To do this, a custom saved objects client wrapper can be defined within the server/plugin and the create() call can be overridden to update the datasource reference. Then, in the saved objects import logic (src/core/server/saved_objects/import/), the visState object will be updated to add/remove/update the datasource id and the associated datasource reference.

Alternatives

Timeseries, one of the visualization types of TSVB, supports annotations as a feature of the timeseries graph. Annotations are a way to place markers at specific points in time on the timeseries graph. A common use case for annotations is to mark an event on the graph that would be associated with the timeseries data. For example, OpenSearch can ingest some CPU utilization from a VM in an index pattern cpu-utilization-* and in a separate index deployment-info-*, store any instance of restarting/starting a VM job. If the user wants to monitor which VM job caused the spike in CPU utilization, the user could make the cpu-utilization-* the timeseries graph with the deployment-info-* pattern as the annotation.

Below is an example of annotations rendered alongside the timeseries graph.
TSVB with annotations

The current proposal will use the datasource taken from the Panel options tab meaning annotations can only pull data from the same datasource as the panel. However, since TSVB makes separate search queries to obtain annotation data, there is a use case to enable a user to select which datasource to pull the annotation from via a datasource picker component added under the Annotations tab. This means that a user can create annotations from indices of different datasources.

Below is a mockup of the new component:
Annotation edit box

However, there are caveats with this added feature:

  • Complex import/export logic: import was designed with one datasource in mind. Import will be complex and capturing user intent can be a challenge. However, another issue (#5927) faced a similar issue so this visualization can follow a similar approach. It is not a blocking challenge but is listed here nonetheless as there does not exist a perfect solution to address this limitation.
  • Increased search() API calls: the current annotations make one bulk search() call to fetch annotation data. This was only possible because there was no consideration for the datasource used. With this proposal, there is a chance that each annotation will call a different datasource, therefore increasing the number of search() calls and incurring additional performance costs.

Open Questions

@huyaboo huyaboo added the enhancement New feature or request label Mar 28, 2024
@huyaboo huyaboo mentioned this issue Mar 29, 2024
7 tasks
@bandinib-amzn
Copy link
Member

Thanks @huyaboo for creating issue. It is great a start. For annotation, I think for a start let's keep simple and keep only one datasource for multiple index pattern to avoid complexity. I'm not very much inclined to make multiple search call instead of one bulk call, just to add annotation from different data sources. We can review this use case with product team and see if it really adds value to user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request multiple datasource multiple datasource project v2.14.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants