dropwizard / dropwizard-health

Provides a health check implementation that performs ongoing monitoring of an application's dependencies and includes an endpoint that can be called by a load balancer to determine if the application is healthy and thus able to receive traffic.

Dropwizard

Dropwizard is a sneaky way of making fast Java web applications.

It's a little bit of opinionated glue code which bangs together a set of libraries which have historically not sucked:

• Jetty for HTTP servin'.
• Jersey for REST modelin'.
• Jackson for JSON parsin' and generatin'.
• Logback for loggin'.
• Hibernate Validator for validatin'.
• Metrics for figurin' out what your application is doin' in production.
• JDBI and Hibernate for databasin'.
• Liquibase for migratin'.

Read more at dropwizard.io.

Want to contribute to Dropwizard?

Before working on the code, if you plan to contribute changes, please read the following CONTRIBUTING document.

Need help or found an issue?

When reporting an issue through the issue tracker on GitHub or sending an email to the Dropwizard User Google Group mailing list, please use the following guidelines:

• Check existing issues to see if it has been addressed already
• The version of Dropwizard you are using
• A short description of the issue you are experiencing and the expected outcome
• Description of how someone else can reproduce the problem
• Paste error output or logs in your issue or in a Gist. If pasting them in the GitHub issue, wrap it in three backticks: ``` so that it renders nicely
• Write a unit test to show the issue!

Sponsors

Dropwizard is generously supported by some companies with licenses and free accounts for their products.

JetBrains

JetBrains supports our open source project by sponsoring some All Products Packs within their Free Open Source License program.

dropwizard-health's Issues

Allow to add customizable health check statuses

Up to now, we have only two possible health check statuses that are currently supported which are healthy and unhealthy. The idea behind this improvement would be to add more (customizable) heath check statuses, like for example:

• unknown when the application is not yet ready and can't provide its status.
• warn (like in the RFC HealthCheck) when for example a non critical dependency is unhealthy.
• maintenance when the application is down for maintenance
  ...

Within the context of this improvement, it could also be interesting to be able to configure for each health check status which http status code we would like to use as response of HealthCheckServlet#doGet.

Expose health check data to other modules

The ability to expose health check data to other modules (for instance, an Admin page may want to show historical health check results).

Create generally useful disk health checks

There are two health checks I have in mind for this:

• A disk space health check, that performs a check to determine if there is some configurable level of available disk space on the host the app is deployed to. This should be opt-in, if an app depends on some disk usage behavior. For inspiration: https://github.com/oracle/helidon/blob/master/health/health-checks/src/main/java/io/helidon/health/checks/DiskSpaceHealthCheck.java
• One that performs a write against the file system, to ensure that there isn't a read-only file system issue.

Add dropwizard-health to Dropwizard modules directory

Please consider adding this project to the list of official Dropwizard modules at https://modules.dropwizard.io/.

https://github.com/dropwizard/modules.dropwizard.io/blob/8724c877edb55517a62f1662b9063e373a8d821a/_data/modules/official.yaml

Register HealthCheckServlet to admin port

Hi Team, I recently noticed that HealthCheckServlet is added to application.
Assumption is anything related to state of application ( & not application itself) should be honoured at admin endpoints & not at application level.
This can be critical in the cases where application port is already heavily invoked & having health check there would put additional burden on application.
My ask is, can we register health check at admin port or at least provide way to configure it depending on user's input ?
Let me know if this sounds good & I can raise a PR.

Better support for Cloud-native liveness and readiness checks

Specifically zooming in on how Kubernetes liveness and readiness checks work, it will make sense to rethink how we mark an application healthy.

My current idea is that all critical dependencies must be checked and report healthy at least once at app startup time for the application to be marked healthy initially.

That way, we could mark an app live when it starts, and then we could mark an app ready only once it's dependencies are ready.

Minor threading bug in HealthCheckScheduler

I was doing a review of this library and noticed what I think is a minor threading bug in HealthCheckScheduler.

Specifically, the 'futures' member is declared to be a regular HashMap:

    private final Map<String, ScheduledFuture> futures = new HashMap<>();

But, the futures collection is modified by both the main thread:

HealthCheckRegistry.register() ->
   HealthCheckManager.onHealthCheckAdded() -> 
      HealthCheckScheduler.schedule() -> 
          modifies collection

as well as the health check threads created by the executor:

HealthCheckManger.onStateChanged() -> 
   HealthCheckScheduler.schedule() -> 
      HealthCheckScheduler.unschedule() ->
          modifies collection

Thus I think the futures member needs to be a synchronized collection (probably ConcurrentHashMap or Collections.synchronizedMap()) in order to ensure changes to the collection are published to other threads immediately. Otherwise you might not be able to remove an entry already in the collection due to the lack of the health check's thread's ability to see the addition made by the main thread.

Likely this is very minor.

Support for version 4

Will support for dropwizard 4 come any time soone ? Thanks

Set up artifact publishing to Maven Central

Publish a release

Planning on getting a first release published later this week/weekend.

Add support for configuring `Cache-Control` header for health check responses

In some scenarios, it is important to be able to have the health check responses include the Cache-Control header with directives indicating that the response should not be cached. For example, if if an app's health check is being consumed by a GSLB for failover purposes, the app may publicly be behind a cache, but the app's health check response should NOT be cached.

Minor threading bug in HealthCheckManager?

Similar to #21, I think I might have noticed another minor threading bug.

In HealthCheckManager,

Map<String, ScheduledHealthCheck> checks

is constructed via line 39:

this(configs, scheduler, metrics, new HashMap<>());

This is of course an unsynchronized collection. However, if you look at com.codahale.metrics.health.HealthCheckRegistry's implementation, it seems to be using synchronized collections for the list of health checks and its list of listeners. This seems to indicate that it would be valid behavior to add health checks to the HealthCheckRegistry instance from multiple threads. Thus, probably any listener to HealthCheckRegistry's callbacks must also be thread safe just in case someone decided to do this.

I might raise a PR later to fix this, but I just wanted to type up this issue report while it was fresh in my mind :-)

Health status change hooks

We should provide a way to hook into health status changes, to allow triggering of certain actions on status changes.

For instance, if an app is marked unhealthy, then one might want to trigger some sort of action, like an alert, and email, or whatever.

Whether this should be only at the application health level, or at the individual dependency health level as well, is somewhat up for discussion in my mind.

Support for Dropwizard 3.0

Would love to see Dropwizard 3.0 support added. In 3.0 Dropwizard has reorganized the classes into different packages. For example io.dropwizard.Configuration to io.dropwizard.core.Configuration.