Hello, I've added some info through JMX, would you mind review it before merging ?
Regards, Luca --- Luca Burgazzoli On Fri, Sep 8, 2017 at 4:20 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > 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
