Hello.
I found HealthAggregator was deprecated and documentation suggests to use StatusAggregator, but StatusAggregator getAggregateStatus accepts only statuses, there is no information about status source (indicator).
I mean information about status source is helpful, e.g. HZ is DOWN, but it is used only for caching and system continues to work, maybe worser, but... It seems immpossible to handle such cases.
Yes, I tried to find a advice on StackOverflow and other internet, unfortunetly without success.
Please provide a way or revert deprecation or give a piece of advice
Comment From: wilkinsona
Unfortunately, I'm not sure that I understand what you were doing with a custom HealthAggregator that you now cannot do with a StatusAggregator. Information about the health of the application, broken down by components, continues to be available from the health endpoint. This is the recommended way of seeing the health by component rather than a side-effect of aggregation.
Comment From: NLatyshev
I cannot get more information, only status, cannot get status source.
Comment From: NLatyshev
Please take a look at code of org.springframework.boot.actuate.autoconfigure.health.HealthAggregatorStatusAggregatorAdapter. It passes dummy Health to HealthAggregator and map keys (that must be name of sources) like health0. The contact was broken here.
Comment From: NLatyshev
@wilkinsona you offer to me stay aggregation as is. hm, do you think one of system broken component must move system to broken as well in all cases? I tried to give a example i nmy first post. If it is not clear please let me know and I'll find another one.
I am not against checking by component, moreover it is not connected with the deal. Imagine /health returns down because some component1 /health/component1 is down, but component1 can be optinal.
Or do you suggest me not to inculude such component (not to define such component as HealthIndicator)?
Comment From: philwebb
I wonder if we could move this code into a default method of the StatusAggregator interface?
Comment From: philwebb
We discussed this today on our team call and decided that we'd prefer not to extend the API of StatusAggregator. We feel it's better to keep it focused on only having a single job.
For your use-case, we'd recommend using health groups. If that won't work, you could consider using custom status responses. For example, rather than returning Status.DOWN you could return new Status("PARTIAL_DOWN") so that your StatusAggregator can handle that code differently.