We are creating a custom health indicator and would like the ability to turn off default or spring packaged indicators instead of using management.health.*.enabled=false. As we look forward it would require a properties file change the next time a new health indicator would be added in boot.
Thanks, Justin
If you want to shutdown everything, how about creating your own HealthEndpoint instead?
This works _right now_:
@Configuration
public class CustomHealthIndicatorConfiguration {
@Autowired(required = false)
private HealthAggregator healthAggregator = new OrderedHealthAggregator();
@Bean
public HealthEndpoint healthEndpoint() {
Map<String, HealthIndicator> healthIndicators = new HashMap<>();
healthIndicators.put("myHealthIndicator", new MyHealthIndicator());
return new HealthEndpoint(this.healthAggregator, healthIndicators);
}
}
How about this solution? (you basically build your map any way you want, ignoring the default behaviour of collecting the ones from the context).
That's a good solution for v1.2. I think we should add management.health.enabled for 1.3, similar to endpoints.enabled.
Isn't that different? That would disable the health management completely which isn't what is required here as far as I understand.
It would be the default when no specific override is specified (see http://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#production-ready-customizing-endpoints)
For some reason I can't get to the docs to re-read the docs, will try again in a few... What we are looking to do is create a custom health end point and have the ability to turn off pre-packaged health endpoints packaged with boot. What we want to prevent is boot adding another endpoint and then we have to update the properties files to disable it. Does that help?
That clarifies, yes. The code I pasted above can be used with the current release.
@justinmusgrove we had a server outage today. It should be back now. You can follow https://twitter.com/springops for notifications if you want.
@philwebb I have pushed a proposal on my fork. Basically configuring management.health.enabled to false disables standard indicators unless specified otherwise. I've added a few tests that demonstrate the intention.
I am not sure about that extra condition (albeit package private for now). Thoughts?
tuning @ConfigurationProperties to have multiple prefixes is not going to work since @ConfigurationProperties has also support for multiple names and the logic is that all names should apply.
While it would work for us with matchIfMissing=true, changing that flag to false with multiple prefixes and multiples names would be super weird.
Maybe a dedicated condition that triggers if something is enabled via a fallback would help?
I don't like management.health.enabled. IMO, the property name needs to reflect the fact that it only affects the default indicators. I.e. you can still register your own indicators and the /health endpoint will still be there. If I set management.health.enabled to false, I'd expect all the health infrastructure to be disabled and for the /health endpoint to disappear.
Agreed. how about management.health.enable-default-indicators?
Sounds good, although I also wonder about management.health.default-indicators.enabled. Seems more consistent with other properties and gives room to expand if we want any other properties for configuring the default indicators.
Andy I discussed this a bit further and we went ahead with management.health.defaults.enabled
I have management.health.defaults.enabled=false specified in my application.properties but still, somehow, this is the response that I get :
{
"status": {
"code": "UP",
"description": ""
},
"details": {
"diskSpace": {
"status": {
"code": "UP",
"description": ""
},
"details": {
"total": 71602487296,
"free": 34575777792,
"threshold": 10485760
}
},
"mongo": {
"status": {
"code": "UP",
"description": ""
},
"details": {
"version": "3.4.0"
}
}
}
}
Seems like management.health.defaults.enabled=false isn't working the way it should.
@khansuhel If that is the case, please open a new issue with a sample that reproduces the problem
Most helpful comment
I have
management.health.defaults.enabled=falsespecified in my application.properties but still, somehow, this is the response that I get :Seems like management.health.defaults.enabled=false isn't working the way it should.