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

[Fleet] Unified Integrations view #93084

Closed
51 of 63 tasks
Tracked by #94207
mostlyjason opened this issue Mar 1, 2021 · 7 comments
Closed
51 of 63 tasks
Tracked by #94207

[Fleet] Unified Integrations view #93084

mostlyjason opened this issue Mar 1, 2021 · 7 comments
Assignees
Labels
design Feature:Unified Integrations Unified Integrations view feature Team:Fleet Team label for Observability Data Collection Fleet team

Comments

@mostlyjason
Copy link
Contributor

mostlyjason commented Mar 1, 2021

Describe the feature:
When integrations UI becomes the default experience for adding data in Kibana, we want to help users discover all the ways to add data to Elastic. We also want to have a unified landing page for adding integrations. This will provide a single place for new deployments to get started with the Elastic stack. It will promote adding their own data as the best way to get started.

Today, users have to check multiple places to identify which sources and use cases we support. They have to check integrations UI for agent integrations, add data UI for beats, enterprise search for content sources, apm for languages, and stack management for alert connectors. A unified page makes it easier for users to discover all the use cases we support.

To provide a unified list, we need to add support for non-Elastic Agent integrations like Enterprise search, Beats modules, Logstash, sample data, etc. This is also important when we have not yet published a GA integration for specific data source, or the user encounters one of the other limitations of Agent/Fleet. As a fallback, users can discover how to add data with Beats modules or Logstash plugins.

To provide discoverability, we could add link-type integrations. They provide tiles on the browse and search UIs for discoverability. They would include a title, description, icon, and a link to where users can add data for that source. It could link to an internal app in Kibana like Enterprise search or the Add data UI or a documentation page. They will not show up on the manage integration or data streams pages.

We can gradually transition those from link-type integrations to full integrations as we add support for new data sources. If we included them in the Elastic Package Registry, we could even release new GA integrations and replace the old ones out of band. This offers the teams creating integrations more flexibility to the control the timing of updates.

Describe a specific use case for the feature:

  • As an enterprise search user, I would like a link to point me where I need to set up enterprise search after creating a new deployment.
  • As a user of a service without a GA Integration available, I would like a link to point me to instructions to set up a Beats module or Logstash plugin.

Open questions:

  1. At what granularity should we expose the integrations tiles when there are mutliple use cases per source? For example, Microsoft O365 supports both a logs module and workplace search. One solution is to expose two tiles: one for logs and one for search. Another solution is similar to what we have on https://www.elastic.co/integrations where there is a single tile with links for each use case.

Implementation

Phases

Implementing this has two primary phases, one implementing the base framework in the integrations app to support displaying, searching, and filtering cards registered by other Kibana plugins, followed by a second phase of items that can be tackled in parallel to add support for each type of card we need to add.

Base implementation:

Second phase, all top-level bullets should be able to be done in parallel:

Services

UI

Additional Cards

Bugs

Tech Debt

* = stretch goals that are not necessary to swap over the default onboarding experience to the ingestions app

Service Design

Registry API

This API would be exposed on the Fleet plugin's client-side Setup interface (which is currently empty) so that plugins could call fleetSetup.integrations.registerCard

export interface IntegrationsServiceSetup {
  registerCard(card: CustomCard): void;
}

Card Interface

/**
 * Parameters that other plugins can use to define a custom card in the integrations UI.
 *
 * Designed to closely map to the {@link PackageListItem} type to make merging custom card results with registry search
 * results as seamless as possible.
 */
export interface CustomCard {
  /** User-visible title of card. Max characters XXX */
  title: string;

  /**
   * Machine-readable name of integrations.
   * For Beats modules, this should match the `moduleName` (eg. apache)
   */
  name: string;

  /** User-visible description of card. Max characters XXX */
  description: string;

  /**
   * Type of card to describe the behavior when a user clicks on card.
   * Defaults to `ui_link` which is the only currently supported type.
   */
  type?: 'ui_link';

  /**
   * UI path to link user to when clicking this integration.
   * Should not include basePath.
   * Only applicable to cards with `type: 'ui_link'`
   * Exmaple: /app/home#/tutorial/activemqMetrics
   */
  uiInternalPath: string;

  /**
   * List of available icons for this card.
   * If not present, UI will fallback to the EUI icon type for `logo${name}`
   */
  icons?: Array<{
    /** URL path to icon, should not include basePath */
    src: string;
    /** Mimetype of icon file. Only image/svg+xml is supported at this time */
    type: string;
  }>;

  /** Categories this card should be shown in. At least 1 category is required. */
  categories: PackageSpecCategory[];

  /** Used for mapping Beats modules tutorials to corresponding integrations */
  beatsModule?: {
    moduleName: string;
    type: 'logging' | 'metrics';
  };
}

Handling Beats

One tricky aspect is how to handle the mapping between tutorials for Beats modules and their corresponding integration. In summary, the behavior we want is:

  • Custom cards for Beats modules should only be shown if the corresponding integration is not yet GA
  • Integration details pages should show a callout to the corresponding Beats module tutorial(s), with a link to the filebeat (logging) and metricbeat (metrics) tutorials if available.
  • Users without superuser access should see cards for all Beats modules, regardless of integration release status (@mostlyjason can you confirm this?)
  • All of the logic above also needs to apply to the global search integration

In theory, we could provide a very generic API on the CustomCard interface to allow plugins to define some of this replacement behavior. Since we only need to support this for Beats at this time, I think it's safer if we provide an explicit field for this now (see above CustomCard.beatsModule) and handle this logic internally to the Integrations app. This makes the API less powerful but allows us to keep the scope low and puts less onus on external plugins to integrate correctly.

It'd be best if we could execute the bulk of this logic in a code path in the layer where we fetch the package list for integrations. The logic should likely follow something similar to this pseudo-code:

const getResolvedCards = async (isSuperUser: boolean, customCards: CustomCard[]) => {
  if (!isSuperUser) {
    return customCards;
  }

  const packages = await getPackages();
  const nonGaPackages = packages.filter(p => p.release !== 'ga');
  const gaPackages = packages.filter(p => p.release === 'ga');

  const filteredCustomCards = customCards.filter(c => {
    const matchingPackage = gaPackages.find(p => p.name === c.beats?.moduleName);
    return !matchingPackage;
  });

  const filteredNonGaPackages = nonGaPackages.filter(p => {
    const matchingCard = customCards.find(c => c.beats?.moduleName === p.name);
    return !matchingCard;
  })
  
  return [
    ...gaPackages,
    ...filteredCustomCards,
    ...filteredNonGaPackages
  ]
}

CC @mukeshelastic @sorantis

@mostlyjason mostlyjason added the Team:Fleet Team label for Observability Data Collection Fleet team label Mar 1, 2021
@elasticmachine
Copy link
Contributor

Pinging @elastic/fleet (Team:Fleet)

@ruflin
Copy link
Contributor

ruflin commented Mar 3, 2021

@mostlyjason I assume these integrations would also exist in the package-registry?

@mostlyjason
Copy link
Contributor Author

@ruflin Yes that would make sense, I mentioned a benefit of including them there

@mostlyjason mostlyjason changed the title [Fleet] Add discoverability for non-Fleet integrations [Fleet] Add discoverability for non-Elastic Agent integrations Aug 25, 2021
@mostlyjason mostlyjason changed the title [Fleet] Add discoverability for non-Elastic Agent integrations [Fleet] Unified Integrations view Sep 3, 2021
@thomasneirynck
Copy link
Contributor

#112330 is a POC for the new proposed flow. Not intended for review, just a workable demo to get a feel for the behavior and some of the edge-cases.

@dikshachauhan-qasource
Copy link

Hi @jen-huang

Could you please share the mocks for UI changes mentioned in ticket summary, so that we can also initiate work upon same.

As most of the changes described are mainly with UI so that will be helpful to cover relating testing.

Thanks
QAS

@joshdover
Copy link
Contributor

@dikshachauhan-qasource We're still iterating on UX here, but we'll be sure to share it once things have been stabilized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
design Feature:Unified Integrations Unified Integrations view feature Team:Fleet Team label for Observability Data Collection Fleet team
Projects
None yet
Development

No branches or pull requests

8 participants