feat(#5534): composite health and details

[SteKoe]

This pull request introduces a new sample for composite health contributors on the backend and refactors the frontend health panel for improved structure, styling, and accessibility. The main changes are grouped into backend additions for health contributors and frontend UI/UX improvements for health display.

Backend: Composite Health Contributor Sample

• Added new sample health indicators and a composite health contributor (ExternalApiHealthIndicator, MessageBrokerHealthIndicator, and ExternalServicesHealthContributor) to demonstrate grouping multiple health checks under a single /actuator/health/externalServices endpoint. These are registered via a new configuration class (HealthContributorConfig). [1] [2] [3] [4]

Frontend: Health Panel Refactor and Improvements

• Refactored the health panel in details-health.vue to introduce new layout and styling, including clear separation of component and group health checks, improved status color tokens, and a more accessible structure. [1] [2]
• Updated the health-details.vue component to support composite contributors, collapsible sections, and improved detail rendering with new CSS classes for better readability and maintainability. [1] [2]
• Improved computed properties and methods for handling health groups, component entries, and toggling group details, making the codebase more robust and maintainable. [1] [2] [3] [4] [5]
• Minor UI tweaks and bugfixes, such as updating class names for detail values and removing unused or redundant code. [1] [2]

These changes collectively provide a better developer and user experience for monitoring and displaying composite health checks in Spring Boot Admin.

[cdprete]

Nice @SteKoe.
Finally the Instance entry is gone and the status is on the accordion itself.

How does it look when a composite entry gets expanded?

[SteKoe]

Expanded entries look like this:

Completely collapsed health card like this, as already known:

[cdprete]

Expanded entries look like this:

Completely collapsed health card like this, as already known:

Mmm while I understand the reasoning behind that internal indentation I would try to keep the status "bar" aligned with the rest and only indent from the indicator name.
Also, if possible (I can bet it's difficult :D), I would try to keep the status badges aligned.

Regarding Discovery client not initialized, is there no key in the JSON?
I'm just asking because I think that the details there can still be a Map<String, Object>, so I wonder how things would be rendered if there is more than one entry.

Edit: ignore the comment above about the nesting. externalServices shows how they will be already and they look fine.

[SteKoe]

I will dig into it further. This PR is just a first draft of a possible and better solution for displaying health information.

Mmm while I understand the reasoning behind that internal indentation I would try to keep the status "bar" aligned with the rest and only indent from the indicator name.

Yeah, I tried out both variants, too, and for now sticked to this approach. But UI is still in flux. I am not yet happy, either.

Also, if possible (I can bet it's difficult :D), I would try to keep the status badges aligned.

This already took some time, I will have to rethink how the UI may look like.

[cdprete]

Sounds good from my side.
Just make sure to revert or address #5540 (comment) please ;)
From my side, for example, I'm using OFFLINE as status for expected downtime windows, so having that red now would be quite confusing.

[SteKoe]

Current state:

[cdprete]

Current state:

Looks good to me, apart that I'm questoning the utility of that left bar (it's a nice touch but brings no added value since the badge is already there).
Maybe I would just switch the font size between normal indicators and composite ones.

At least to me, the composite indicators with a smaller font than the normal ones give the impression they're somehow less important.
On the other end, for health groups which are basically kind of the same, we add a complete separate section with a header making them, visually at least, somehow important.
Unless you changed the health groups here as well to this new style (there are none in the screenshot), I would personally try to uniform the 2 concepts under the same rendering rules given that, as said, they're (almost) identical.
The only real difference between the 2 is that health groups have their status shown on demand - because it needs to be explicitly fetched - while composite indicators can show it right away because it's already available.

Also, why is Discovery client not initialized in italic? What's the idea behind?

[OFF-TOPIC IDEA]

Maybe, given that health groups don't participate to the overall health status, a better idea would be to separate them from the Health section/accordion into their own section/accordion which would:

• go directly under the Health one, adding therefore the necessary gaps below to keep the grid aligned
• being displayed only if health groups are available
• start as initially closed
• fetch the groups when it gets open and fetch them on demand on every status update, but only if their accordion is open

The assumption above is that, if the health group(s) accordion is closed, then clients are not interested in its status since, anyway, health groups are just an aggregate over some statuses already available above in the normal Health accordion.
As clients of SBA we should know our own applications and, therefore, what's configured as indicators for each health group. Therefore, some overhead in the UI - as well as on the end systems - may be avoided if it's actually not needed.

[/OFF-TOPIC IDEA]

[cdprete]

Wouldn't make more sense here to just call componentEntries() and assert its length?

Given that both are computed properties, there should be no overhead (to my understanding) with the benefit that the logic is not getting duplicated.
Especially about while health sub-entry to pick (details vs components).

[cdprete]

Shouldn't this go together with .status-unknown?