Practical Cloud-Native Java Development with MicroProfile by Emily Jiang Andrew McCright John Alcorn David Chan Alasdair Nottingham

Author:Emily Jiang, Andrew McCright, John Alcorn, David Chan, Alasdair Nottingham
Language: eng
Format: epub
Publisher: Packt Publishing Pvt Ltd
Published: 2021-09-13T00:00:00+00:00

As we mentioned previously, we can view the data through the /health, /health/liveness, /health/readiness, and /health/started endpoints. Due to this, these health checks can be consumed by requests over HTTP/REST. Through an HTTP/REST call, the health check procedures are presented in JSON format. The root level contains the overall health status with a status field, and it is calculated from the conjunction of all health check procedures defined in the checks JSON list.

The overall status dictates the HTTP response code. An UP status returns HTTP 200, while a DOWN status returns HTTP 500. Any failures or errors that are encountered by the health check procedure will result in an HTTP 503 return code, which equates to a DOWN status. Remember that if any health check reports are down, then the overall status is DOWN. Each health check JSON object in the list displays the contents of HealthCheckReponse (that is, its name, status, and optional key-value map). If there a no health check procedures, then an automatic UP (that is, HTTP 200) is returned. The formatting structure and behaviors listed previously apply to all four endpoints. The use of response codes is important as this may be the method in which the external observer is determining the health of your application (that is, the cloud platform).

The following example output can be applied to any of the four health endpoints, so we will not define which endpoint it is from:

{

"status": "DOWN",

"checks": [

{

"name": "goodCheck",

"status": "UP"

},

{

"name": "questionableCheck",

"status": "DOWN",

"data": {

"application": "backend",

"locale": "en"

}

}

]

}

The output reports that we have a health check procedure named "goodCheck" that reports UP. We also have a procedure named "questionableCheck" that is reporting DOWN. This causes the overall status to report DOWN and will result in an HTTP 500 error being returned. As shown in the output, the "questionableCheck" procedure has incorporated the additional contextual map data; that is, "application": "backend" and "locale": "en".

Special Note About Default Readiness and Startup Procedures

The MicroProfile Health runtime provides a configuration value (through MicroProfile Config) called mp.health.default.readiness.empty.response. Its value can be either UP or DOWN. The default value is DOWN. This value is used to report the readiness of your microservice if the application is still starting up and the readiness procedures cannot be called yet. This is not applicable if no readiness health check procedures have been defined in the application code. If that is the case, then the default behavior for no health check procedures is to return an HTTP 200 response with an UP status on the /health/readiness endpoint.

There is also a configuration value that exists for the startup health check called mp.health.default.startup.empty.response. If there are no startup health checks at all, then the default UP status is returned on the /health/started endpoint.

Liveness checks, on the other hand, do not have configurable values. They follow the simple rule of returning an HTTP 200 response with an UP status if the application is still starting, and the liveness checks are not ready to be invoked yet.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.