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

Specifying a controlLevelSwitch when no API key is in use forces all logs to Verbose #49

Closed
quooston opened this issue Nov 25, 2016 · 6 comments

Comments

@quooston
Copy link

If a client specifies no api key, but specifies a control level switch, the log level on the client is forced to Verbose.

The reason this can has been an issue for us is because we have an internal library which multiple projects use for things like logging and other infrastructure. Not all projects will necessarily have an API key for example and the code in the lib essentially wires up Seq with whatever is passed along:

  // ... 

  public static LoggingLevelSwitch LogLevelSwitch { get; set; }

  public static void ConfigureLogger(ConfigurationParams configParams)   //ConfigurationParams is an object we pass along with a bunch of config for differnet sinks etc.
  {
    LogLevelSwitch.MinimumLevel = LogEventLevel.Information;

    var config = new LoggerConfiguration()
         .MinimumLevel.ControlledBy(LogLevelSwitch)
         .WriteTo.Seq(configParams.SeqLocation, apiKey: configParams.apiKey, controlLevelSwitch: LogLevelSwitch);

    Log.Logger = config.CreateLogger();
  }

  // other config removed for brevity

configParams.apiKey may be null, as the client may not have one configured.

The LogLevelSwitch above will now be Verbose, regardless of the log level initially applied (Information, in this case).

We have updated our internal lib to be more careful about how it configures the Seq sink, but I feel that the sink should ignore the controlLevelSwitch if no APIKey is supplied.

@nblumhardt
Copy link
Member

Hi, thanks for the report!

#41 should have fixed this, released in version 3.1.0 of the package. Could you please confirm which version you're using?

@quooston
Copy link
Author

Thanks Nick, I'll take a look. Apologies for the duplicate!

@quooston
Copy link
Author

quooston commented Nov 25, 2016

Yep, we're on 3.0.1! So we'll update and test to confirm that it's all good.

Thanks again,
Q

@nblumhardt
Copy link
Member

Great, thanks for looping back 👍

@quooston
Copy link
Author

Yep, it's working perfectly. PEBKAC!

Q

@nblumhardt
Copy link
Member

Awesome :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants