Update MicroProfile Health guide to MicroProfile Health 2.0 #3129
Conversation
There was a problem hiding this comment.
I have added a couple of comments and suggestions.
I'm not sure about the order of readiness and liveness. Readiness comes first in the lifetime of an application so I would have put it first but it kinda breaks how you present everything so feel free to ignore if it doesn't make sense.
| Importing the `smallrye-health` extension directly exposes three REST endpoints: | ||
|
|
||
| - `/health/live` - The application is up and running. | ||
| - `/health/ready` - The application is ready to serve requests. |
|
|
||
| - `/health/live` - The application is up and running. | ||
| - `/health/ready` - The application is ready to serve requests. | ||
| - `/health` - Accumulating all health check procedures in the application. |
There was a problem hiding this comment.
Someone told me it was deprecated? Should we talk about it?
There was a problem hiding this comment.
The qualifier is, not the endpoint, at least not in 2.0 up to my knowledge.
| - `/health/ready` - The application is ready to serve requests. | ||
| - `/health` - Accumulating all health check procedures in the application. | ||
|
|
||
| To check that smallrye-health extension is working as expected: |
There was a problem hiding this comment.
| To check that smallrye-health extension is working as expected: | |
| To check that the `smallrye-health` extension is working as expected: |
| following CDI qualifiers: | ||
|
|
||
| - `@Liveness` - the liveness check accessible at `/health/live` | ||
| - `@Readiness` - the readiness check accessible at `/health/ready` |
There was a problem hiding this comment.
Same here, I would put this one first.
|
|
||
| - `@Liveness` - the liveness check accessible at `/health/live` | ||
| - `@Readiness` - the readiness check accessible at `/health/ready` | ||
| - `@Health` - *deprecated* unspecified health procedure accessible at `/health` |
There was a problem hiding this comment.
I would remove this one: Quarkus is not 1.0 yet so let's not advertise deprecated features.
|
|
||
| == Negative health check procedure | ||
| NOTE: If you access `http://localhost:8080/health` you will get back both checks. |
There was a problem hiding this comment.
/health is still present in MP Health 2.0. There is a possibility that it will be extended in the future. I don't think it's deprecated so I would keep the note for now.
|
|
||
| In this section we create another health check procedure which simulates a connection to | ||
| an external service provider such as a database. For simplicity reasons, we only determine | ||
| More information about which health check procedures should be used when is detailed |
There was a problem hiding this comment.
| More information about which health check procedures should be used when is detailed | |
| More information about which health check procedures should be used in which situation is detailed |
| == Negative health check procedures | ||
|
|
||
| In this section, we extend our `Database connection health check` with the option of | ||
| stating that our application is not ready to process requests as underlying database |
There was a problem hiding this comment.
| stating that our application is not ready to process requests as underlying database | |
| stating that our application is not ready to process requests as the underlying database |
| it isn't influenced by the readiness checks. | ||
|
|
||
| As we shouldn't leave this application with a readiness check in a DOWN state and | ||
| because we are running Quarkus dev mode you can add `database.up=true` in |
There was a problem hiding this comment.
| because we are running Quarkus dev mode you can add `database.up=true` in | |
| because we are running Quarkus in dev mode you can add `database.up=true` in |
| done by using the `withData(key, value)` method of the health check response | ||
| builder API. | ||
|
|
||
| Let's create new health check procedure `org.acme.health.DataHealthCheck`: |
There was a problem hiding this comment.
| Let's create new health check procedure `org.acme.health.DataHealthCheck`: | |
| Let's create a new health check procedure `org.acme.health.DataHealthCheck`: |
|
@gsmet Thanks for the review. I've incorporated everything but the ordering suggestion. In my view:
In the end, for me, liveness and readiness are different use-cases so the order doesn't really matter to me. But for this PR, it would mean that I need to rewrite it again because it doesn't make sense to have a database connection (current Readiness example) as a liveness check. Does it make sense, please? |
|
@xstefank yes, thanks, merging! |
The associated quickstart PR is quarkusio/quarkus-quickstarts#238.