- Changes to Cruise Control logging configuration are not reflected.
- As a workaround, the users need to restart the Cruise Control pod after changing the logging configuration(about 5 minute later, to wait for the Cluster Operator recreate the log4j.properties).
- I am concerned that if we try to ask our customers to output the debug logs to resolve issues with Cruise Contorl. it will affect our technical support work and investigations.
- For example, to change the root logger level to debug as below, but debug logs were not output:
cruiseControl: ... logging: type: inline loggers: cruisecontrol.root.logger: "DEBUG"
- FYI, as far as I can see from my brief research:
- With the above changes (cruisecontrol.root.logger: "DEBUG"),
- The contents of log4j.properties in CruiseControl was *changed correctly*. However, Cruise Contorl didn't change the outputs of the logs. I think Cruise Contorl does not support changing log4j.properties dynamically as of now.
- And the Cruise Control pod did *NOT restart*.
- However, if changing tlsSidecar log level as below, the Cruise Control pod *restart* and the logging configuration will be reflected. I think in case of changing tlsSidecar logging level, the cluster operator change TLS_SIDECAR_LOG_LEVEL in the Cruise Control deployment, so the Cruise Control pod is restarted.
cruiseControl: ... tlsSidecar: ... logLevel: debug
- With the above changes (cruisecontrol.root.logger: "DEBUG"),
- is related to
-
ENTMQST-2695 [Docs] Update deprecation change cruisecontrol.root.logger -> rootLogger.level
-
- Closed
-