-
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
[Fleet] Unified Integrations view #93084
Comments
Pinging @elastic/fleet (Team:Fleet) |
@mostlyjason I assume these integrations would also exist in the package-registry? |
@ruflin Yes that would make sense, I mentioned a benefit of including them there |
#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. |
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 |
@dikshachauhan-qasource We're still iterating on UX here, but we'll be sure to share it once things have been stabilized. |
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:
Open questions:
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
/app/home#/tutorial_directory
/app/home#/tutorial_directory
to/app/integrations/browse
kibana/x-pack/plugins/fleet/public/plugin.ts
Line 202 in 3cdced3
Additional Cards
support pngs as icon-display in a card (required for language clients integration)[EDIT] not necessary. @dborodyansky regenerated to SVGBugs
Tech Debt
custom_integrations
-plugin tointegrations
:)* = 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
Card Interface
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:
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 aboveCustomCard.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:
CC @mukeshelastic @sorantis
The text was updated successfully, but these errors were encountered: