[GS] Feature results provider

[alexfrancoeur]

Building off of the work done with #65222 and #65633 I'd like to track the need to add search results that are one level deeper than applications.

We have a number of features that fall under larger applications that I believe should be easily accessible through search. Some examples include Index Management. When searching for Management, I believe you will only see the overarching stack management application and not any of the features related to it. The same could be said for our Security solution for example. Maybe a user wants to navigate directly to Cases?

We currently have a feature directory that's main purpose today is to populate the home page. There are a number of features missing, but as @cqliu1 suggested, we could potentially repurpose this to provide more granular search results for some of the larger applications with key features associated with them.

Feature mapping

Below you’ll find an initial stab at features that may be beneficial to return as part of the Kibana’s new navigational search.

Global

• Home

Kibana

• Not many new additions, most views are populated by applications in navigation (and search results)
• Machine Learning
  • Overview (same entry point as Machine Learning app)
  • Anomaly Detection
  • Data Frame Analytics
  • Data Visualizer
  • Settings

Enterprise Search

• No new additions, all views are populated by applications in navigation (and search results)

Observability

Overview

• No new additions, all views are populated by applications in navigation (and search results)

Logs

• Stream (same entry point as Logs app)
• Anomalies
• Categories
• Settings

Metrics

• Inventory (same entry point as Metrics app)
• Metrics Explorer
• Settings

APM

• Services (same entry point as APM app)
• Traces
• Service Map

Uptime

• Overview
• Settings

Security

Overview

• No new additions, all views are populated by applications in navigation (and search results)

Detections

• Detected signals (same entry point as Detections app)
• External Alerts
• Manage signal detection rules

Hosts

• All hosts (same entry point as Hosts app)
• Authentications
• Uncommon processes
• Anomalies
• Events
• External alerts

Network

• Flows (same entry point as Network app)
• DNS
• HTTP
• TLS
• Anomalies
• External alerts

Timelines

• Timeline (same entry point as Timeline app)
• Templates

Cases

• Cases (same entry point as Cases app)

Administration

• No new additions, all views are populated by applications in navigation (and search results)

Management

Dev tools

• Console (same entry point as Dev Tools app)
• Search profiler
• Grok Debugger
• Painless Lab

Ingest Manager

• Overview (same entry point as Ingest Manager app)
• Integrations
• Configurations
• Fleet
• Datasets
• Add agent

Stack Monitoring

• Elasticsearch
  • Overview
  • Nodes
  • Indices
  • Logs
• Kibana
  • Overview
  • Instances
• Beats
  • Overview
  • Beats
• Logstash
  • Overview
  • Nodes
  • Pipelines
• APM
  • Overview
  • APM servers

Stack Management

• Ingest
  • Ingest node pipelines
  • Logstash pipelines
  • Beats Central Management
• Data
  • Index Management
    • Indices
    • Data streams
    • Index templates
    • Component templates
  • Index Lifecycle Policies
  • Snapshot and Restore
    • Snapshots
    • Repositories
    • Policies
    • Restore status
  • Rollup Jobs
  • Transforms
  • Cross-Cluster Replication
    • Follower indices
    • Auto-follow patterns
  • Remote Clusters
• Alerts and Insights
  • Alerts and Actions
    • Alerts
    • Connectors
  • Reporting
  • Machine Learning Jobs
    • Anomaly detection
    • Analytics
  • Watcher
• Security
  • Users
  • Roles
  • API Keys
  • Role Mappings
• Kibana
  • Index Patterns
  • Saved Objects
  • Spaces
  • Advanced Settings
• Stack
  • License Management
  • 9.0 Upgrade Assistant

Open questions

• How granular do we want this feature results provider to be? Do we want to make the search results "actionable" navigating directly to CRUD views. For example, rather than simply navigation to cases we could navigate to "Create new case". It definitely streamlines navigation, but unsure if that level of granularity is useful. For those trying to reduce as many clicks as possible - it might be
• If we don't have feature controls for a number of these items, are they worth showing in search? I don't know if we want to streamline navigation to an error page
• Is there a programmatic way to get most of these features / sub-features or do teams need to manually register new ones? If we're adding a description to each, I'd imagine it's manual

[elasticmachine]

Pinging @elastic/kibana-core-ui (Team:Core UI)

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[alexfrancoeur]

I updated the original description to include mappings of in-app features that might be useful to return as part of Kibana's navigational search. This is basically a manual mapping of what's available today in 7.x and would love some feedback from the different teams responsible for these areas. When we're ready to start working on this one, I think a good next step will be to engage with the different solution and management teams to make sure this is a good starting point.

[ryankeairns]

While it doesn't belong to a specific category, I think it would be useful to add the Home page as well (I'll add to the description)

[joshdover]

To answer the "where should we capture this data" question, I think it makes sense at this point to consolidate the feature catalog registry with app registration. They're intrinsically linked and it would allow the application GS provider to use the same data source for both sets of items.

One tricky aspect is that for applications like Stack Management and Dev Tools which allow other plugins to register sections dynamically, not all sub-features will be known at setup. This may require an Observable-based API like:

core.application.register({
  id: 'management',
  features$, // management plugin would update this as new management apps are registered
  async mount() { ... },
});

The ApplicationService's applications$ Observable should be able to hide this detail by unwrapping this Observable and producing a single Observable of a static structure.

Later, we can adapt the feature directory page to use this data as well and then do away with the old feature catalog registry. The feature catalog registry has confused many a Kibana developer, so that seems like an additional win to me.