Hi Luca I will take a closer look tomorrow, I just peaked a bit today.
Just to be sure, the implementation of the logic that performs the actual health check is agnostic? i.e. its not tied to must be using Spring Boot. And that logic is if possible reusing the "ping check" (i.e. verifier extension). So the spring boot health check is currently for making it easier for end users to configure it via spring boot configuration? On Mon, Sep 4, 2017 at 4:01 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > Hello, > > I've been working a little on the Health Check API [1] implementation an > the code is available in my Apache Camel fork [2]. There is now a a new > package [3] that defines the following concepts: > > - HealthCheck > > this represent an health check and defines the some basic contract i.e > the response; > > - HealthCheckConfiguration > > this is a basic coonfiguration object that holds some basic settings > like the minimum delay between calls, the number of time a service may > be reported as unhealthy before meking the check as failed; beside > those simple options, is then responsability of the check impl. to > eventually implement further limitations; > > - HealthCheckRegistry > > this is just a registry, it doesn't have any method to trigger checks > and it has intentionally been kept simple as in the future it may be > superseeded by an internal camel registry [4]; > > - HealthCheckRepository > > this is a simple interface to define health check providers and by > default there is one that grabs all the checks available in the > registry so you can add your own check i.e. istantiating your bean > in spring/spring-boot; components can provide theirs own repository. > > - HealthCheckService > > this is a simple service that runs in the background and invokes the > checks according to a schedule. > > The default camel context sets-up a default implementation of the health > check registry which you can override by putting your own implementation > in the camel registry as usual. Check are not active by default so you > need to explicit enable/configure them. > > The current implementation has a number of limitations: > > - it is spring-boot oriented for demostration purpose so you can't > access health checks using JMX (but it is planned); > - it is focused on monitoring the status of external systems so there > are a few implementations based on the Component verifier extension: > > 1. a ServiceNow instance check to report if an instances is alive > 2. a simple undertow based http check that issue an http get to an > http endpoint > > There is also a simple consul repository that let you to reuse consul > checks [5] so i.e. you can have a single check to monitor the status > of twitter and reuse it in all your microservices. > > An example can be found in my fork [6] > > My next goals are: > > 1. define some core checks to monitor the health of the camel context > i.e. fail if there is an excessive number of errors, if the latency > is too high, etc. > 2. expose check through JMX. > 3. use health checks for ServiceCall EIP > 4. use health checks in Clustering/Superving route controller > > > Any feedback is very welcome, > Luca > > > [1] https://issues.apache.org/jira/browse/CAMEL-10026 > [2] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc > [3] > https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/camel-core/src/main/java/org/apache/camel/health > [4] https://issues.apache.org/jira/browse/CAMEL-10792 > [5] https://www.consul.io/docs/agent/checks.html > [6] > https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks > > > --- > Luca Burgazzoli -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
