[Logs UI] Versioning for Logs related APIs

[tonyghiani]

📓 Summary

Closes #157324
Closes #159275
Closes #159303

This work converts the APIs related to the Logs UI feature into versioned APIs using the new Kibana versioned router.

The converted APIs are the following, where each endpoint now is set to version 1:

• log_views
• log_entries
• log_analysis
• log_alerts

The PR also includes moving the interfaces and runtime types relatives to each endpoint's group into the recommended practices for versioning interfaces.

🧪 Testing

• Navigate to the Logs UI settings page and verify the log view is correctly retrieved and can be successfully updated.
• Navigate to the Logs stream page and verify the stream entries are retrieved and rendered.
• Navigate to the Anomalies and Categories pages page and verify the anomalies entries are retrieved and rendered correctly.
• Create a Log threshold alert and verify the chart preview data are correctly retrieved and shown.

[apmmachine]

🤖 GitHub comments

Expand to view the GitHub comments

Just comment with:

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

[elasticmachine]

Pinging @elastic/infra-monitoring-ui (Team:Infra Monitoring UI)

[tonyghiani]

note: I'm not sure why GH see this as a file rename and changed, they were completely different files.

[mohamedhamed-ahmed]

LGTM! Clean work 🚀
Just out of curiosity, if we wanted to upgrade a route version now. What steps do we need to take?
Add a new version folder for the set of interfaces and expose them, then add a new version to the registered route? or something is missing

[mohamedhamed-ahmed]

Good Catch :)

[tonyghiani]

LGTM! Clean work 🚀 Just out of curiosity, if we wanted to upgrade a route version now. What steps do we need to take? Add a new version folder for the set of interfaces and expose them, then add a new version to the registered route? or something is missing

Hey there, the documentation for the Kibana versioned router and versioning interfaces explain step-by-step what the process of versioning a new API looks like, but basically it reduces to:

• Create in the common folder (in our case into the http_api sub-folder) a new folder with the new version, and re-export all the definitions made in the previous version folder + the new updated interfaces/types (this will override the existing definition from the previous version):

export * from './v1';

export type MyType = string

N.B. the documentation speaks about a single file for the version definition, but since we could have more endpoints under the same group and we could version them together, using a folder applies in the same way.

• Add a new version of the API endpoint, which consists of chaining a .addVersion call where the router registers the API versions and defines the handler function that applies the new logic and uses the new types/interfaces.
• Update in the client where the API invokes setting the correct version.

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 61507c8
• Storybooks Preview

Metrics [docs]

Async chunks

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

id	before	after	diff
infra	2.0MB	2.0MB	-53.5KB

Page load bundle

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

id	before	after	diff
infra	105.5KB	133.8KB	+28.2KB

Unknown metric groups

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
securitySolution	414	418	+4
total			+6

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
securitySolution	498	502	+4
total			+6

History

• 💔 Build #133636 failed 4556618
• 💔 Build #133616 failed 09c50cc
• 💔 Build #133584 failed 1ff02d1
• 💔 Build #133575 failed c34e3ac
• 💚 Build #131798 succeeded 104f1f1

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