Thanks for responding Mark,

To clarify I can change the logging level of the route to any level below and 
to the initial INFO level -  I can change between ERROR, WARN and INFO and see 
the requisite changes in the apps logging. This issue seems to arise whenever I 
want to raise it above INFO, for example updating the logs to DEBUG level, no 
DEBUG log lines are logged. This makes me think that there is a logger higher 
up in the hierarchy than the routes logger itself blocking it.

For clarity my package structure looks like this

- src
  - main
    - java
      - my.package
        - controllers
          TestLoggersController.java
        - routes
          TestLoggersRoute.java
        MyApplication.java

Kind Regards
Simon

From: Mark Nuttall <mknutt...@gmail.com>
Date: Tuesday, 18 May 2021 at 04:08
To: users@camel.apache.org <users@camel.apache.org>
Subject: Re: Update Logging Levels of Camel routes using Spring Boot Actuator
CAUTION: This email originated from outside of the organisation. Do not click 
links or open attachments unless you recognise the sender and know the content 
is safe.


It looks like your route Builder classes in the root package. That usually
is not good as if that's the case. I suggest moving it to the same package
as the controller. I don't know if that will make any difference but
sometimes having classes in the root package causes issues. Other than that
I can't see why things are not working. Other than Maybe because routes are
created initially on Startup it's not sensing the logging level change
which is weird. I'll have to confirm that tomorrow. Which is door today I
think.

On Mon, May 17, 2021, 1:08 PM Simon Loy <simon....@uktv.co.uk> wrote:

> Hi All,
>
> I’m currently working on a PoC to improve logging capabilities for our
> Spring Boot applications.
>
> The idea is that setting up spring boot actuator allows us to update our
> Camel routes logging levels without any downtime of manual config changes.
>
> As part of the PoC I have created a simple Spring Boot REST controller:
>
> @RestController
> public class TestLoggersController {
>
>   private Logger logger = LoggerFactory.getLogger(this.getClass());
>
>   @EndpointInject(value = "direct:TestLoggersRoute")
>   private ProducerTemplate producerTemplate;
>
>   @GetMapping("/testLogger")
>   public ResponseEntity publishReconciledChannelDayAsRuns(){
>     logger.trace("Controller TRACE");
>     logger.debug("Controller DEBUG");
>     logger.info("Controller INFO");
>     logger.warn("Controller WARN");
>     logger.error("Controller ERROR");
>
>     producerTemplate.sendBody("");
>
>     return ResponseEntity.ok().build();
>   }
> }
> and a Camel Route:
>
> @Component
> public class TestLoggersRoute extends RouteBuilder {
>   Logger logger = LoggerFactory.getLogger(this.getClass());
>
>   @Override
>   public void configure() throws Exception {
>     from("direct:TestLoggersRoute").routeId("TestLoggersRoute")
>         .log(LoggingLevel.TRACE, "Route TRACE!")
>         .log(LoggingLevel.DEBUG, "Route DEBUG!")
>         .log(LoggingLevel.INFO, "Route INFO!")
>         .log(LoggingLevel.WARN, "Route WARN!")
>         .log(LoggingLevel.ERROR, "Route ERROR!");
>   }
> }
> Nothing special going on, simple slf4j Logger for the REST Controller and
> a standard log() within my route both with a log line for each level so I
> had a decent range to test with
>
> After adding the relevant spring boot actuators dependencies
>
> <dependency>
>  <groupId>org.springframework.boot</groupId>
>  <artifactId>spring-boot-starter-actuator</artifactId>
> </dependency>
> and exposing/enabling the loggers endpoint
>
> management.endpoints.web.exposure.include=loggers
> management.endpoint.loggers.enabled=true
> I called my rest endpoint ‘0.0.0.0:80/testLogger’ to test connectivity
> and I hadn’t messed up the basics. As expected I seen three log lines
> printed for both the controller and routes; the ERROR, WARN and INFO log
> lines.
>
> I then bumped the log level for the REST Controller up to ‘TRACE’ via curl
>
> curl -X "POST" "
> http://localhost:80/actuator/loggers/my.package.TestLoggersController"; -H
> "Content-Type: application/json; charset=utf-8" -d $'{"configuredLevel":
> "TRACE"}'
>
> To confirm this worked I used the actuators GET method for loggers
>
> curl "
> 0.0.0.0:80/actuator/loggers/uk.co.uktv.gbt.asruns.controllers.TestLoggersController
> "
>
> which returned
> {
>     "configuredLevel": "TRACE",
>     "effectiveLevel": "TRACE"
> }
>
> Then, I called my REST controller and as expected I had eight log lines,
> five for the controller – a log line for each level on the test and the
> initial three log lines for the test route.
>
> I repeated the above curl statements but this time increasing the test
> routes logging level to ‘TRACE’ and checking that it had been updated in
> the actuator.
>
> curl -X "POST" "http://localhost:80/actuator/loggers/TestLoggersRoute"; -H
> "Content-Type: application/json; charset=utf-8" -d $'{"configuredLevel":
> "TRACE"}'
>
> curl http://localhost:80/actuator/loggers/TestLoggersRoute which as
> expected returned:
> {
>     "configuredLevel": "TRACE",
>     "effectiveLevel": "TRACE"
> }
>
> However this time instead of seeing the expected ten log lines (ERROR,
> WARN, INFO, DEBUG & TRACE for both the REST controller and the test route)
> I only seen the same eight from the previous test after only changing the
> controller’s logging level.
>
> After a little playing around with the curl command I noticed that  I
> could lower the logging level within the camel routes to INFO, WARN, &
> ERROR successfully and only see the requisite log output. I then upped the
> default log level for the route by adding this to my application.properties
> file:
>
> logging.level.TestLoggersRoute=TRACE
> This allowed me to set the log level to any level and see the expected
> outputs, however this is far from ideal as I do not want to have to set all
> my routes to ‘TRACE’ level then have to instantly lower it after I spin the
> app up.
>
> Ideally I’d want the default log level to be INFO but be able to raise it
> up to ‘TRACE’ or ‘DEBUG’ without doing anything hacky in the
> applications.properties and/or on start up.
>
> If anyone is able to shine light how to resolve this issue it would be
> greatly appreciated.
>
> Kind Regards
> Simon
> Simon Loy
> Solutions Developer
>
> simon....@uktv.co.uk
>
>
>
> [https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fs3-eu-west-1.amazonaws.com%2Fuktv%2FUKTVeMailSig.jpeg&amp;data=04%7C01%7CSimon.Loy%40uktv.co.uk%7C29ca28294c2c4d74110f08d919aa4142%7C8b02c9a29f0c481681a2c218d97745ea%7C0%7C1%7C637569041303971752%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=j3uVlon%2BfOy3kVYh2jPYaZwsvj5w%2FuChdnbcw3ymudo%3D&amp;reserved=0]
>  <
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.uktv.co.uk%2F&amp;data=04%7C01%7CSimon.Loy%40uktv.co.uk%7C29ca28294c2c4d74110f08d919aa4142%7C8b02c9a29f0c481681a2c218d97745ea%7C0%7C1%7C637569041303981710%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=akAZyM9eU8vGM2vkcMWa1vKp7ULgTFMXUriZ3%2BuXXrY%3D&amp;reserved=0>
>

Reply via email to