Hi Thanks the health mbean looks good.
However I wonder if using a date is the right type for "interval" https://github.com/lburgazzoli/apache-camel/blob/CAMEL-10026-hc/camel-core/src/main/java/org/apache/camel/api/management/mbean/CamelOpenMBeanTypes.java#L251 Is interval a specific date, eg 2017-1-1 12:59:55 or is it not a number like 2000 for every 2000 milli seconds? On Tue, Sep 19, 2017 at 2:50 PM, Luca Burgazzoli <lburgazz...@gmail.com> wrote: > Hi Claus, > the branch is still [1] and the management parts is in api/management [2]. > > [1] https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc > [2] > https://github.com/lburgazzoli/apache-camel/tree/CAMEL-10026-hc/camel-core/src/main/java/org/apache/camel/api/management > > --- > Luca Burgazzoli > > > On Tue, Sep 19, 2017 at 2:26 PM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> On Tue, Sep 19, 2017 at 2:22 PM, Luca Burgazzoli <lburgazz...@gmail.com> >> wrote: >>> Hello, >>> >>> I've added some info through JMX, would you mind review it before merging ? >>> >> >> Can you post the link to the branch where those latest code changes are >> >>> 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 >> >> >> >> -- >> 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
