Support Startup & Shutdown Log Levels#85967
Conversation
|
Workflow [PR], commit [7e4d800] Summary: ❌
|
|
Example log (from running locally) with: |
717b939 to
2046590
Compare
|
Could you please write an integration test for this feature? See |
880d26b to
4b62bf3
Compare
|
The test seems flaky although I haven't yet figured out why. @kssenii do you have any suggestions for debugging? I can't see the Clickhouse logs from the test results. It could be shutdown is too fast and the test is unable to get the shutdown logs. |
|
|
|
@kssenii I meant the logs of the Clickhouse binary itself. Indeed the tests logs are clear on why it failed. I'll take a look at the tests today. |
|
Logs of clickhouse server are also there, inside integration_run_flaky0_0.tar.zst |
074f289 to
42f8635
Compare
|
Ok the issue was indeed the cluster.shutdown call killing clickhouse. I now trigger a SIGTERM instead so there is time to wait for the shutdown. Last test failed due to [UPDATE] |
42f8635 to
a4d7019
Compare
Alter the log levels on startup & shutdown if the respective values are set. This allows for a higher log level during startup & shutdown of clickhouse. Fixes: ClickHouse#85958
a4d7019 to
315ade5
Compare
|
@kssenii I decided to remove the shutdown check, it caused stability issues with the test. The test still checks startup + revert of log level to configured log level after startup. Let me know if you want me to add anything else to the PR. Otherwise this PR is ready for review. |
e.g. the test was flaky? |
Yeah with the shutdown it became flaky. And I suspect it was more related to the shutdown & restart of CH inside of the container rather then the test case per-se. I got connection errors on the previous PR run. |
As it was force-pushed, I cannot see what you tried to use, but I do not see why would it not work. Also I personally do not like to use |
Ah that is a good point, it would have been better to separate the commits. I wasn't aware wait_for_log_line would wait for calls after the call is made, that probably explains why the check was flaky in the first place. I have pushed a change with
No it shouldn't |
| instance.exec_in_container( | ||
| ["bash", "-c", "pkill -{} clickhouse".format(signal)], user="root" | ||
| ) |
There was a problem hiding this comment.
Yes, that is probably cleaner.
|
@kssenii the tests now pass 🎉 I just a fuzzer failure (probably not related to this PR based on what I could see) & a failure in the Finish Workflow: Do you know where I can add the relevant docs? Or are the comments in config.xml sufficient? |
programs/server/Server.cpp
Outdated
| { | ||
| /// Set the root logger level to the shutdown level. | ||
| /// This is useful for debugging shutdown issues. | ||
| /// The root logger level will be reset to the default level after the server is fully initialized. |
There was a problem hiding this comment.
nit: this comment doesn't make sense here
Head branch was pushed to by a user without write access
|
@kssenii I guess the push I did to update the comment disabled the auto-merge? |
19c8bb4
| <clickhouse> | ||
| <logger> | ||
| <level>none</level> | ||
| <startupLevel>trace</startupLevel> |
There was a problem hiding this comment.
@Blokje5 , configuration keys should be snake_cased, not camelCased. Please update this
| | `async` | When `true` (default) logging will happen asynchronously (one background thread per output channel). Otherwise it will log inside the thread calling LOG | | ||
| | `async_queue_max_size` | When using async logging, the max amount of messages that will be kept in the the queue waiting for flushing. Extra messages will be dropped | | ||
| | `startupLevel` | Startup level is used to set the root logger level at server startup. After startup log level is reverted to the `level` setting | | ||
| | `shutdownLevel` | Shutdown level is used to set the root logger level at server Shutdown. | |

Alter the log levels on startup & shutdown if the respective values are set. This allows for a higher log level during startup & shutdown of clickhouse.
Fixes: #85958
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes into CHANGELOG.md):
New configuration options:
logger.startupLevel&logger.shutdownLevelallow for overriding the log level during the startup & shutdown of Clickhouse respectively.This can be useful to help investigate startup & shutdown issues.
Documentation entry for user-facing changes