Hello, I've just pushed some bits to my fork to cleanup the implementation and implement some basic checks for routes status. In addition, to make it suitable to be included in camel 2.20, I've reduced the scope of the implementation to be almost limited to core/internal health checks and to provide a good foundation for people to write their own advanced checks if needed (component checks such as those for undertow and servicenow has been removed).
Any feedback is really appreciated. --- Luca Burgazzoli On Tue, Sep 5, 2017 at 2:25 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > --- > Luca Burgazzoli > > > On Tue, Sep 5, 2017 at 2:17 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> Hi Luca >> >> Looks really good. >> >> There is a few typo's and the likes in the source code I looked at. >> Will try to do a github comment so you can see them as well later, or >> when the code is merged later. >> >> 1) >> For the doCall implementation when you implement a health check, then >> what would happen if that methods throws an runtime exception? I think >> we need to clarify on the javadoc what the contract is, and if an >> exception would then render the check to be status = DOWN or what? >> > > I'd expect the implementation to wrap it and decide if the service is > healthy or not so yeah, I'll make it clear. > >> >> 2) >> I think the spring boot auto configuration prefixes for the health >> checks for the components such as undertow, servicenow etc should all >> be under the same prefix as the component itself, eg >> >> eg >> camel.undertow.health.checks[spring-health].interval = 5s >> >> should be >> camel.component.undertow.health.checks[spring-health].interval = 5s >> >> Then everything you can configure in the undertow component is with >> the same prefix and its consistent. >> > > Agree. > >> >> 3) >> To implement a custom health check and have spring boot auto >> configuration, then you would have to write that configuration code >> yourself / manually? >> > > At the moment yes as the layout is not defined but it may be > eventually auto generated like the starters. > >> >> 4) >> I wonder in the servicenow health check where you configure the >> instance id, username etc again, whether you may want to be able to >> just refer to the existing configuration so you do not repeat >> yourself? >> >> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L66 >> > > Yeah, that was an example non properly cleaned up/explained but by > default the servicenow reuse component's configuration. > >> >> 5) >> In this example it is a bit confusing that the comment say the health >> check is enabled and then the value below is false >> https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/examples/camel-example-spring-boot-health-checks/application/src/main/resources/application.properties#L36 >> >> 6) >> ... and as well there is 2 indicator.enabled in that example. > > Yeah, it definitively need to be cleaned up. > >> >> >> >> On Mon, Sep 4, 2017 at 5:16 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: >>> 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 >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2: https://www.manning.com/ibsen2
