[Serverless] Discover decisions for Observability projects #169964
Assignees
Labels
enhancement
New value added to drive a business result
Feature:LogsExplorer
Logs Explorer feature
impact:high
Addressing this issue will have a high level of impact on the quality/strength of our product.
Team:DataDiscovery
Discover App Team (Document Explorer, Saved Search, Surrounding documents, Data, DataViews)
Team:obs-ux-logs
Observability Logs User Experience Team
Comments
mwtyang
added
the
Team:DataDiscovery
|
Pinging @elastic/kibana-data-discovery (Team:DataDiscovery) |
mwtyang
removed
the
Team:DataDiscovery
mwtyang
added
Team:DataDiscovery
timductive
added
enhancement
gbamparop
added
Feature:LogsExplorer
|
Assigning @davismcphee for a time boxed exploration phase |
9 tasks
davismcphee
added a commit
that referenced
this issue
Dec 8, 2023
) ## Summary This PR adds tabs to navigate between Discover and Log Explorer in serverless O11y projects. The Discover top nav should remain unchanged in stateful deployments and all other serverless project types:  > [!IMPORTANT] > While writing tests for this, I encountered a few issues we'll probably want to discuss and make decisions for before merging this PR. 1. When there are no data views in Kibana and a user navigates to Discover, they are prevented from accessing it and shown a no data screen. So if a user navigates to Discover in a serverless O11y project in order to get to Log Explorer but there are no existing data views, they will be unable to access the tabs since they will be blocked by the no data screen. Is this a realistic scenario in serverless O11y that we need to solve for, or will there always be at least one data view by default? 2. When navigating from the Log Explorer tab to the Discover tab, we convert the current dataset to an ad hoc data view to use in Discover. This doesn't work in reverse since Log Explorer can't load an arbitrary data view that might be selected in Discover, so instead I'm using the "all logs" locator. I'll leave it to the O11y team to decide if this is ok or if we need to take another approach here. 3. Since we are passing state between Discover and Log Explorer when a user switches between tabs, the default columns in Log Explorer will be overwritten by the current Discover grid columns (even if it's just the Document column). I imagine the O11y team doesn't want this, but how should we solve it? Should we avoid passing columns (and any other state that might overwrite defaults) when navigating from Discover to Log Explorer, or take another approach? ## Notes - The sidebar navigation link has been changed from "Log Explorer" to "Discover" and defaults to the Discover tab. - "Log Explorer" has been renamed to "Logs Explorer" in the UI. - The mockups used "Data Views" for the Discover tab title, but this was later decided against, so the implementation uses "Discover". - All of the same state that used to be passed from Log Explorer to Discover through the top nav button is still being passed, but I also added support for passing `sort` as well (I can revert this if it's unwanted). - In order to add tabs to the left side of the Discover top nav in serverless, we had to stop relying on Unified Search for rendering the top nav (in serverless only, stateful still uses it). Instead we are now rendering the top nav directly in Discover in serverless, similar to what Log Explorer does. This also required access to some of the internal navigation plugin components we rely on for the Discover top nav, so I exported them from the plugin since I figured it was better than duplicating them. Part of #169964. **In order to fully resolve this issue, there is still a remaining task to remove the "Data Views" tab from the Log Explorer dataset selector.** Part of #171386. **In order to fully resolve this issue, it looks like there may be some documentation work to do (especially since "Log Explorer" has been named to "Logs Explorer" in the UI).** ### Checklist - [x] Any text added follows [EUI's writing guidelines](https://elastic.github.io/eui/#/guidelines/writing), uses sentence case text and includes [i18n support](https://github.com/elastic/kibana/blob/main/packages/kbn-i18n/README.md) - [ ] [Documentation](https://www.elastic.co/guide/en/kibana/master/development-documentation.html) was added for features that require explanation or tutorials - [x] [Unit or functional tests](https://www.elastic.co/guide/en/kibana/master/development-tests.html) were updated or added to match the most common scenarios - [x] Any UI touched in this PR is usable by keyboard only (learn more about [keyboard accessibility](https://webaim.org/techniques/keyboard/)) - [ ] Any UI touched in this PR does not create any new axe failures (run axe in browser: [FF](https://addons.mozilla.org/en-US/firefox/addon/axe-devtools/), [Chrome](https://chrome.google.com/webstore/detail/axe-web-accessibility-tes/lhdoppojpmngadmnindnejefpokejbdd?hl=en-US)) - [ ] If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the [docker list](https://github.com/elastic/kibana/blob/main/src/dev/build/tasks/os_packages/docker_generator/resources/base/bin/kibana-docker) - [ ] This renders correctly on smaller devices using a responsive layout. (You can test this [in your browser](https://www.browserstack.com/guide/responsive-testing-on-local-server)) - [x] This was checked for [cross-browser compatibility](https://www.elastic.co/support/matrix#matrix_browsers) ### For maintainers - [ ] This was checked for breaking API changes and was [labeled appropriately](https://www.elastic.co/guide/en/kibana/master/contributing.html#kibana-release-notes-process) --------- Co-authored-by: kibanamachine <42973632+kibanamachine@users.noreply.github.com>
|
@davismcphee since this PR was merged and we have an implementation issue for the remaining work needed for the tabs can we close this? |
|
@gbamparop Yes, I think that would make sense. Closing this issue now as completed since we've covered everything in it except what will be covered in #171386. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Background
This meta issue summarizes the decision between the Observability and Kibana teams on providing a consistent ad-hoc data exploration experience using Discover. Our users across solutions use Discover as a primary app for ad-hoc data explorations, and we're introducing ES|QL in the 8.11 release to enhance this experience for all Elastic users.
As we launch serverless, we aim for a uniform ad-hoc data exploration experience across all serverless project types using Discover. Discover is a top-level left navigation item for all serverless projects.
For stateful Elastic Stack, the global menu navigation with Discover and the Observability submenu navigation with Log Explore (starting in 8.11) will remain unchanged. We will optimize the unified Observability left navigation menu items once we start to provide a unified left navigation for each solution in the future.
In the near term, the below is the agreed-upon approach for implementing Discover for serverless Observability projects with a future plan for further user experience enhancements by the Platform and Observability teams.
Decisions
Add “Discover” to the serverless Observability project, similar to Search and Security serverless projects.
Discover will have two tabs.
The first tab will be a generic Discover view in stateful Kibana today and is the same across all serverless projects (the screen capture below is for illustration purposes only and more design and IA work are required).
Next steps
cc @abhiksingh @evin-elastic @chrisdistasio @ruflin @abatsakis @skearns64 @timductive @thomasneirynck @ninoslavmiskovic @ryankeairns @sophiec20
The text was updated successfully, but these errors were encountered: