Metrics and Health

[Roger Cundiff]

Hi,

The metrics proposal takes care to distinguish metrics from health checks and says the proposal does not cover health checks.  However, I've heard that Dropwizard is being considered for the metrics API, and Dropwizard does include a health check API (http://metrics.dropwizard.io/3.1.0/manual/healthchecks/) that covers similar territory to the health spec.  What are people's thoughts on this?  Is this a situation that needs to be reconciled?  If so, how should this be done?

-- Roger

[Heiko Rupp]

Rodger,

this is a good question and suggestion.

The page you cite seems to define how those health checks work inside of an application, but does not talk about exposing the results of the check.

The current health check proposal defines a http-access endpoint and also internal ways of how an application can expose its health.

Can you elaborate on what DWM is doing on the http-API side?

[donbo...@gmail.com]

I don't think that DWM addresses the HTTP-API side -- that exercise may be left to the user.  I think DWM is basically providing the healthcheck registry and a HealthCheck interface that people implement.  

I see an interesting article that shows how to use DWM healthchecks to provide a /health endpoint with JSON output at https://dzone.com/articles/monitoring-your-java-services-with-dropwizard-health-checks

[Emily Jiang]

I just found out zipkin also exposes the /health and /metrics. Do we need to worry about this kind of interaction?

Emily

[Heiko Rupp]

Am Donnerstag, 13. Juli 2017 17:56:55 UTC+2 schrieb Emily Jiang:

I just found out zipkin also exposes the /health and /metrics. Do we need to worry about this kind of interaction?

Do you mean, that those endpoints may already be in use when a user is using Zipkin with Microprofile?

I think in this case it should be left to the user to disable one or the other. I don't think MP should change its defaults, as those endpoints are "well known" and supporting them out of the box is the best user experience for the majority of our users.

[Emily Jiang]

yes, I meant the endpoint might already be in use when a user uses Zipkin. Not sure how easy to disable zipkin /health or /metrics. I think this things need to be considered and provide a solution or instruction on how to deal with it as MicroProfile potentially creates this conflicts. Maybe MicroProfile implements opentracing but disables /health or /metrics if zipkin is used as an implementation.

Emily

[Heiko Rupp]

Am Freitag, 14. Juli 2017 18:30:20 UTC+2 schrieb Emily Jiang:

yes, I meant the endpoint might already be in use when a user uses Zipkin. Not sure how easy to disable zipkin /health or /metrics. I think this things need to be considered and provide a solution or instruction on how to deal with it as MicroProfile potentially creates this conflicts. Maybe MicroProfile implements opentracing but disables /health or /metrics if zipkin is used as an implementation.

There may be several options

• In a scenarion like WF-Swarm, it would be possible to just not deploy the Metrics or Health Check fractions at all
• For other (more monolithic) servers it may be possible to set properties/config to disable the respective functionality 
  
• We may decide to add env-variables/properties to move the endpoints /metrics and /health to other locations

While I see the potential for conflict, I am also not sure how much we need/want to cater for all potential conflicts.

[Werner Keil]

Actually that /health endpoint has nothing to do with Zipkin, it's just bundled with Spring Boot in many cases: https://github.com/openzipkin/zipkin

If you need to use Zipkin with a MicroProfile container, don't use Spring Boot. Although there could be rare situations with e.g. some features being used in a Spring-based environment, I don't think it is very common, so I would ignore the likelyhood of MicroProfile Health being deployed with Spring Boot at the moment ;-)

Werner