[Logs Explorer][Discover] Move Logs Overview into Discover codebase

[tonyghiani]

📓 Summary

Closes #180024

This work aims to move the "Logs Overview" doc view created from the logs-explorer app into the unified-doc-viewer plugin, creating and registering this as a preset along the table and source doc views.

To keep control of whether this doc view should be displayed or not, an enabled configuration flag is supported for every doc view and will be used to determine whether a doc view should load or not in the view.
This enabled flag can be programmatically enabled/disabled by docView.id using the 2 new methods added to the DocViewsRegistry, the enableById and disableById ones.
The customization extension point does not register the content of the tab, but is limited to enable/disable a preset overview tab.

To allow this change, some shared utilities between the flyout logic and the smart fields feature have been copied into the @kbn/discover-utils package. The utils will still live in the logs_explorer plugin and are used by the smart fields feature until this is migrated too into Discover.

💡 Reviewer hints

Although it seems a large PR, most of the changes are on moved files from logs-explorer into unified-doc-viewer, which is logic already reviewed. With these changes, there will be a follow-up PR to optimize the shared parts with the other doc views.

🚶 Next steps

To keep the scope of this PR the smallest possible, here are some changes I'll work out in upcoming PRs built on top of this one.

• Implement a discover registry to enable registering external features, such as the ObservabilityAIAssistant.
• Integrate ObsAIAssistant with this work through the new discover features registry.
• Refactor the doc views to share duplicated logic.
• Port the existing e2e tests for the logs overview tab into the unified-doc-viewer plugin.

tonyghiani#1

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

• /oblt-deploy : Deploy a Kibana instance using the Observability test environments.
• /oblt-deploy-serverless : Deploy a serverless Kibana instance using the Observability test environments.
• run elasticsearch-ci/docs : Re-trigger the docs validation. (use unformatted text in the comment!)

[tonyghiani]

The reason behind the huge move of async bundle chunks from logs explorer into unified doc viewer is due to the ecs package that loads the fields descriptions.

[jughosta]

LGTM

[weltenwort]

Thanks for creating the smoke tests. And if it works out, I like the use of the flex grid!

I'm somehow struggling to deploy this to a cloud instance, so I wasn't able to check it visually yet.

I've seen several places where you removed intermediate <EuiFlexItem>s inside of <EuiFlexGroup>s. Was that intentional? Why do we need the groups in the first place if they don't contain flex items?

[davismcphee]

The code changes look good and it worked well when testing! I left a few questions, but otherwise this looks good on my end.

[tonyghiani]

cc. @weltenwort

I've seen several places where you removed intermediate s inside of s. Was that intentional?

I recently had an interesting discussion with the EUI team on an issue I created, and an off-topic comment (the first half of the comment is what matters) directly touched on the usage of EuiFlexGroup + EuiFlexItem.

The EuiFlexGroup + EuiFlexItem combo was in place to achieve the gap behaviour on flex layouts, which eliminated the requirement of using both in combination once the team switched to the native gap CSS property.
I agree with them it doesn't add benefits except when we need to control the content stretch of a flex layout, they also recommended removing extra div wrappers whether is possible.

Why do we need the groups in the first place if they don't contain flex items?

EuiFlexGroup might now be a bit misleading as the component name, as it's only applying CSS flex properties to a div element. The places where I left it are mostly for aligning and spacing between items.

[weltenwort]

Thanks for teaching me about that new flexbox gap semantic. It makes sense to avoid unnecessary divs.

[weltenwort]

I really like the thought of relying on flex grid to perform the column calculations for us 👍

During testing I found that it behaves differently from the previous implementation:

• It switches to two columns earlier when the screen is small
• It switches to more than three columns when the screen is large, while three was the upper limit previously

I think the new behavior doesn't feel any worse than the previous one. Just wanted to point this out in case there was an important reason for the previous behavior. Maybe @isaclfreire can double-check?

[davismcphee]

Thanks for addressing my comments and explaining the EuiFlexGroup situation! In that case great work on this and it LGTM 👍

[tonyghiani]

@weltenwort @isaclfreire I agree with Felix as it makes easier to tweak and maintain the columns layout using native CSS.
On the details, we can also use the auto-fill approach to keep columns aligned where there are less values filling the whole space:

auto-fill

auto-fit

@isaclfreire do you have any preference on the above options? Update: I turned it to auto-fill as IMO looks better aligned, but I'll wait on your check.

[isaclfreire]

@weltenwort @tonyghiani agreed that autofill looks way more tidy! all looking great btw, thanks :)

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 496d13a
• Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-180262-496d13ae97a7
• Observability Deployment

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
canvas	1211	1215	+4
cloudSecurityPosture	434	438	+4
dataVisualizer	667	671	+4
discover	789	793	+4
eventAnnotationListing	505	509	+4
lens	1407	1411	+4
logsExplorer	730	584	-146
ml	2026	2030	+4
savedSearch	48	52	+4
securitySolution	5459	5463	+4
slo	726	730	+4
unifiedDocViewer	120	171	+51
total			-55

Public APIs missing comments

Total count of every public API that lacks a comment. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats comments for more detailed information.

id	before	after	diff
@kbn/discover-utils	41	82	+41
@kbn/unified-doc-viewer	13	17	+4
total			+45

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
logsExplorer	1.1MB	317.9KB	-789.7KB
unifiedDocViewer	60.9KB	774.3KB	⚠️ +713.4KB
total			-76.3KB

Canvas Sharable Runtime

The Canvas "shareable runtime" is an bundle produced to enable running Canvas workpads outside of Kibana. This bundle is included in third-party webpages that embed canvas and therefor should be as slim as possible.

id	before	after	diff
module count	-	5874	+5874
total size	-	6.7MB	+6.7MB

Public APIs missing exports

Total count of every type that is part of your API that should be exported but is not. This will cause broken links in the API documentation system. Target amount is 0. Run node scripts/build_api_docs --plugin [yourplugin] --stats exports for more detailed information.

id	before	after	diff
@kbn/discover-utils	4	0	-4

Page load bundle

Size of the bundles that are downloaded on every page load. Target size is below 100kb

id	before	after	diff
logsExplorer	56.1KB	56.5KB	+464.0B
unifiedDocViewer	10.2KB	11.1KB	+925.0B
total			+1.4KB

Unknown metric groups

API count

id	before	after	diff
@kbn/discover-utils	63	110	+47
@kbn/unified-doc-viewer	14	18	+4
total			+51

async chunk count

id	before	after	diff
logsExplorer	12	10	-2
unifiedDocViewer	6	8	+2
total			-0

ESLint disabled in files

id	before	after	diff
logsExplorer	3	2	-1

ESLint disabled line counts

id	before	after	diff
logsExplorer	6	5	-1
unifiedDocViewer	7	9	+2
total			+1

Total ESLint disabled count

id	before	after	diff
logsExplorer	9	7	-2
unifiedDocViewer	7	9	+2
total			-0

History

• 💚 Build #206020 succeeded 29ef1f4
• 💚 Build #205986 succeeded 72f7460
• 💛 Build #205514 was flaky b7a5a32
• 💛 Build #205495 was flaky 88b6787
• 💚 Build #205274 succeeded 88ab78d

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream