Expose overall status to plugins

[joshdover]

Summary

Related to #41983

Exposes the API for reading Kibana's overall status to plugins in order to unblock @elastic/stack-monitoring-ui from deleting their legacy plugin. This API should only be used for data collection & reporting to external systems and should not drive application behavior.

Checklist

Delete any items that are not applicable to this PR.

• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

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

[chrisronline]

Thanks for doing this work!

I'm not sure the newly added response is compatible with the legacy response though.

The legacy response looks like (this is the object under the overall key):

{
  "state": "green",
  "title": "Green",
  "nickname": "Looking good",
  "icon": "success",
  "uiColor": "secondary",
  "since": "2020-08-20T14:49:06.720Z"
}

The new response from this PR looks like:

{
  "level": {},
  "summary": "All services are available"
}

All we technically need to report is the state field (which in the above example is Green).

Am I using the API wrong? Or is this an oversight?

[joshdover]

Thanks for doing this work!

I'm not sure the newly added response is compatible with the legacy response though.

The legacy response looks like (this is the object under the overall key):

{
  "state": "green",
  "title": "Green",
  "nickname": "Looking good",
  "icon": "success",
  "uiColor": "secondary",
  "since": "2020-08-20T14:49:06.720Z"
}

The new response from this PR looks like:

{
  "level": {},
  "summary": "All services are available"
}

All we technically need to report is the state field (which in the above example is Green).

Am I using the API wrong? Or is this an oversight?

My intention was to keep this legacy data out of the API exposed from Core. We're no longer going to use many of these fields moving forward but we will need to maintain some compatibility in some parts (the /api/status endpoint for example).

I see two options here:

1. Core could expose a core.status.legacy.overall$ API that has the same shape as the legacy status API
2. Monitoring can do the translation from the new format to the old one by copying most of the code in src/legacy/server/status/states.js and doing a simple mapping (unavailable -> red, degraded -> yellow, available -> green, etc.)

(1) may be simpler so that we only have this mapping logic in one place (since I'll need to this in Core already for the HTTP API). One question: how is this data ingested by monitoring and do we need all of the fields?

[joshdover]

The new response from this PR looks like:

{
  "level": {},
  "summary": "All services are available"
}

FYI I think this may just be being serialized strangely. The level field is an object that contains toString() and valueOf() functions to describe the level (but can also be directly compared to the ServiceStatusLevel.* objects from src/core/server).

[chrisronline]

how is this data ingested by monitoring and do we need all of the fields?

We just need the state field as a string

Core could expose a core.status.legacy.overall$ API that has the same shape as the legacy status API

This would work for us, but I could also the translation on our side. I'd defer to your judgement here as you are the maintainers of the API.

[joshdover]

This would work for us, but I could also the translation on our side. I'd defer to your judgement here as you are the maintainers of the API.

If all you need is the state string, let's just do that translation in Stack Monitoring. This will reduce the amount of breaking changes on the Core API for us to manage and think about. I will merge this PR as-is then.

[joshdover]

@elasticmachine merge upstream

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 199952b

Build metrics

✅ unchanged

History

• 💚 Build #69262 succeeded 373eee4
• 💔 Build #69229 failed 767bedf

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