Kibana Health API: design phase

[lukeelmers]

@stacey-gammon has written an (internal) document the covers the overall definition for the Kibana Health API project.

From the document:

Is my Kibana server healthy, and if not, how do I repair it? Today those are tough questions to answer, and the goal of the Kibana Health API project is to make answering those questions more manageable.

We would like to introduce higher-level, more accurate, and more detailed health reporting to improve its operation in Cloud. We would like to make impact understandable for users and actionable, ensuring that users or orchestration can self-service.

We would like to expose a dozen (or less) high-level metrics, considering that ideally, we would want unhealthiness to be actionable by users. We would like to expose these metrics in an API to be consumed by UIs exposed to Cloud users.

The next step in the process will be to review Stacey's definition doc and kick off a proper design phase, with the goal of producing an RFC for the new API that can be circulated for feedback.

Key considerations this RFC will need to answer:

• What's the relationship between the new health API and the existing status API? (Do we get rid of status, attempt to combine them somehow, or keep both in place? If we get rid of status, what happens to the existing status UI page?)
• What will be the mechanism for plugins to report health to core? Goal is to use a push model for this.
• Are the health indicators highlighted in the definition doc the right ones? Do we need to add/subtract?
• How can the API work with little to no side effects? Performance is critical so we want to minimize ES queries, slow async operations, etc.
• How can we design this to be as consistent as possible with the Elasticsearch API, knowing Kibana is a fundamentally different product with a different architecture?

For a full list of requirements, please refer to Stacey's definition doc.

[elasticmachine]

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

[lukeelmers]

Also, just to disambiguate for anyone who stumbles across this issue, this API is not the same as the one proposed in #46984

That issue is focused on telling load balancers that Kibana is ready to receive traffic.

This project is focused on telling humans (and UIs) about the current health of key components in Kibana.