Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change log level on the fly without restart #12296

Open
szvincze opened this issue Sep 19, 2024 · 7 comments
Open

Change log level on the fly without restart #12296

szvincze opened this issue Sep 19, 2024 · 7 comments
Assignees
Labels
enhancement New feature or request

Comments

@szvincze
Copy link
Contributor

Overview

Currently the log level can be configured via environment variable NSM_LOG_LEVEL which means the process will use the configured value for its whole lifetime. It is fine in most of the cases, but when one would like to change the log level because closer monitoring is needed, it would be expected to be able to do the change without restarting the process that would be monitored. In the vast majority of the cases the restart makes impossible the immediate monitoring action, because after the configuration change we should initiate restart and then just wait for the issue to happen again.

For temporary setting it would be good if the log level could be changed via sending IPC signals to the process. For example, if we would like to monitor forwarder-vpp then we send SIGUSR1 to the process and it changes its log level to TRACE, when we captured the needed logs the original log level can be restored by sending signal SIGUSR2.

@arp-est
Copy link
Contributor

arp-est commented Sep 19, 2024

Hi,
We also ha a reference implementation, if this signalling approach is okay with you guys

networkservicemesh/cmd-forwarder-vpp#1171

@Ex4amp1e
Copy link
Contributor

Possible solution:

  1. Add term "NSM config"
  2. Move LOG_LEVEL configuring from ENV config to NSM config
  3. [Optional] In future - move other ENVs

Algorithm for LOG_LEVEL:

  1. Every cmd repo will contain structure, that we will read data from file
  2. On every request there will be check if the file has been modified, in positive case - read new value and update LOG_LEVEL in structure
  3. In scope k8s deployment - we will store data in configmap and mount it into each pod as file

@denis-tingaikin
Copy link
Member

cc @edwarnicke

This was referenced Oct 11, 2024
@denis-tingaikin
Copy link
Member

Hello @arp-est ,

Many thanks for doing this.

I have some problems with the prs below, the reference to the sdk is old there, how do you guys usually update the versions?

Yeah, we have faced a problem in SDK K8s, and those components were not updated. Now that the problem is resolved, could you please rebase these PRs?

@arp-est
Copy link
Contributor

arp-est commented Oct 14, 2024

Hello @arp-est ,

Many thanks for doing this.

I have some problems with the prs below, the reference to the sdk is old there, how do you guys usually update the versions?

Yeah, we have faced a problem in SDK K8s, and those components were not updated. Now that the problem is resolved, could you please rebase these PRs?

Right away

@arp-est
Copy link
Contributor

arp-est commented Oct 14, 2024

Hi, I rebased it but in those prs its not the sdk-k8s, but the regular sdk, that is missing the SetupLevelChangeOnSignal function, I see only the version of sdk-k8s was updated in the go.mod file.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: No status
Development

No branches or pull requests

4 participants