Reduce Debug Output messages

[RobLSDev]

While debugging locally there is an excessive amount of noise in the Debug Output logs. The following doesn't serve any purpose to the average developer on our team and just makes it harder to watch for the information they are interested in. It would be great if there was at least a way to set the debug level programatically in our applications\libraries so we wouldn't have to see this unless we were troubleshooting something:

Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Starting operation with location Primary per location mode PrimaryOnly. Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: This operation can only be executed against the primary storage location. Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Starting asynchronous request to http://127.0.0.1:10002/devstoreaccount1/CDSRequest(). Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Setting payload format for the request to 'Json'. Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Waiting for response. Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Response received. Status code = 204, Request ID = 2b665035-8889-4197-8e3d-5c162ec14d37, Content-MD5 = , ETag = W/"datetime'2020-01-02T16%3A49%3A19.05Z'". Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Response headers were processed successfully, proceeding with the rest of the operation. Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Processing response body. Microsoft.Azure.Cosmos.Table Information: 0 : ec30069c-8bce-45fe-a3f0-6339d3fbebff: Operation completed successfully.

We are continuously addressing and improving the SDK. Please describe your issue along with the following information:

SDK version Issue reproduce steps Whether the issue is consistent or sporadic Environment Summary ** Any other context, such as stack trace or log.

[pitscherer]

Glad I get to know that this behavior is problematic for others as well. I experience the same and was trying to find information on how to configure the debug level but no luck. Having a function to adjust the debug level could turn this nuisance into a great feature in case you need to dig deep or to understand how the very basics of the DLL work.

[aimerie]

Really happy to see this has been reported. I too have been looking for some way to disable this logging, or at least change the severity level so my output window isn't clogged up with Information messages.

[djj0809]

I'm also facing this issue, can we have a configuration to disable it?

[RobLSDev]

@donghexu - As the only person to do a commit to this repo can you weigh in on this? Or is there someone else that can be alerted to issues posted in this repo?

[IngarSaltvik]

Hi. I also faced the same issue. After studying the disassembly, I was able to figure out that the logging can be disabled with this app.config section:

  <system.diagnostics>
    <switches>
      <add name="ClientSwitch" value="Off" />
    </switches>
  </system.diagnostics>

[RobLSDev]

Hi. I also faced the same issue. After studying the disassembly, I was able to figure out that the logging can be disabled with this app.config section:

  <system.diagnostics>
    <switches>
      <add name="ClientSwitch" value="Off" />
    </switches>
  </system.diagnostics>

OH MY GOD. This really makes me happy to have a way to suppress these. I was going insane. I do think they need to fix this issue by changing it to opt-in instead of opt-out and provide proper documentation for it.

[aimerie]

Hi. I also faced the same issue. After studying the disassembly, I was able to figure out that the logging can be disabled with this app.config section:

  <system.diagnostics>
    <switches>
      <add name="ClientSwitch" value="Off" />
    </switches>
  </system.diagnostics>

THANK YOU! I agree with @RobLSDev, this should be documented (and opt-in), but nevertheless I am very happy there is a way to suppress these messages today.

[FlsZen]

I'm in the same boat with .NET Core. My appsettings.json is configured with a default logging level of "Warning", yet I still get a bunch of information-level log messages when accessing storage tables. I wasn't able to determine how switches would be configured for .NET Core projects since they lack .config XML files.

The below reflection hack changes the logging level to "Warning" for me.

var type = typeof(CloudTable).Assembly.GetType("Microsoft.Azure.Cosmos.Table.Logger");
var fieldInfo = type.GetField("TraceSourceInternal", BindingFlags.NonPublic | BindingFlags.Static) ?? throw new NullReferenceException("Hack isn't working (1)");
var traceSource = fieldInfo.GetValue(null) as TraceSource ?? throw new NullReferenceException("Hack isn't working (2)");
traceSource.Switch.Level = SourceLevels.Warning;

[sakash279]

thanks for your feedback here. the default here is Informational logging. We will address this issue in the next release of the Tables SDK by improving the documentation on logging, and how to disable/enable it, and set the various levels of logging based on the need.

[RobLSDev]

I would strongly recommend adjusting the default. The typical consumer of this API doesn't care at all about what is filling up their output, and would only be interested in exceptional cases.

[sakash279]

This has been fixed in 1.0.7 by adjusting the default logging to none.

[ddobric]

Just tried the new version 1.0.7. Can confirm that noisy Information logs do not appear anymore. However, now logs do not appear if I try to enable them. For example, the following configuration should make logs visible.

"Logging": {
    "IncludeScopes": false,
    "LogLevel": {
      "Default": "Debug",
      "System": "None",
      "Microsoft.Azure.Cosmos.Table": "Information"

    }