Logging Should Be Configurable

[jmcdale]

Is your feature request related to a problem? Please describe. Logging to Timber is based solely on the BuildConfig.DEBUG flag. SDK Users should be able to turn logging on and off via a configuration.

Describe the solution you'd like Expose the ability to enable/disable debug logging explicitly.

Describe alternatives you've considered Uproot all Timber trees and then add one that filters out logs from the Launch Darkly packages.

[jmcdale]

Something else to note is that LD could be logging in production for a lot of apps. The BuildConfig.DEBUG check only stops the LD debug tree from being planted. All of the Timber calls will still be logged to your clients' trees.

[gwhelanLD]

Hi @jmcdale,

Thanks for the suggestion. To clarify, would the desired change be a simple configuration value for enabling and disabling logging entirely, or more detailed control?

The current design is intended to be convenient in the usual cases. The expectation for production logging is that timber calls below a warn level would likely be silenced. Within the SDK logging at a warn level or above is reserved for messages we believe users would prefer to know about.

Thanks, -- @gwhelanLD

[jmcdale]

I could understand if someone wanted something more fine grained, but my use case is just the ability to enable/disable it to help clear up logs while developing and debugging.

[jmcdale]

We use Timber.e in a custom Tree to log to our paid crash monitoring service. We just started our first rollout with LD integration and are being heavily spammed by ConnectivityReceiver->LDClient.onNetworkConnectivityChangeInstances.

[JvmName]

we're also running into this issue -- there's no way to disable the LD SDK from heavily logging errors to our error monitoring service. I've gotten over 200+ useless errors from the SDK since Wednesday last week.

IMO logging shouldn't happen through Timber, it should happen through an interface. Y'all can optionally provide a Timber integration, but it should not be mandatory.

[elliemehrganrad]

Hi @gwhelanLD, We also have the same issue with launchdarkly-android-client-sdk . We get quite a lot of LD debug logs added to our log file. Is there a way to disable Logging? Thanks

[chrisr-ifit]

IMO logging shouldn't happen through Timber, it should happen through an interface. Y'all can optionally provide a Timber integration, but it should not be mandatory.

We would also like to have better control over the log verbosity and/or formatting of LaunchDarkly logs.

[chrisr-ifit]

@gwhelanLD

We're filtering out VERBOSE and DEBUG in our production Timber logging, but the logs from LaunchDarkly are still excessive in our opinion. The logs from LaunchDarkly are also missing the TAG, which further limits our ability to even filter the logs with additional tooling.

• This is going to cause our Users issues where our log files will grow unnecessarily large due to the excessive LaunchDarkly logging, also causing potential performance issues
• This is going to cause our Developer issues when reviewing Firebase logs, which additionally have size limitations, potentially pushing out relevant log lines due to the excessive LaunchDarkly logging
• This also causes development issues when reviewing DEBUG logs due to the excessive LaunchDarkly logging, slowing down Developer investigations

The LaunchDarkly SDK is the only 3rd party SDK we're using that is incorrectly using Timber and should provide a layer of abstraction over its internal logging to let the consumer control what they want logged.

[dmytroKarataiev]

This needs to be addressed, we are considering dropping launch darkly because of the noise that it generates and no ability to filter it out.

[JvmName]

@eli-darkly is it possible to stop the bleeding here by including a tag in stuff that the LD SDK logs? That way at least I can attempt to filter logs in application code?

[eli-darkly]

@JvmName Please see the latest comment on the similar issue https://github.com/launchdarkly/android-client-sdk/issues/. Updating to the latest patch release, 3.1.7, should give you a consistent tag of LaunchDarklySdk for all SDK log output. More options for log configuration will be coming in 3.2.0.

[JvmName]

hey, great to hear -- thanks for the update @eli-darkly; looking forward to the full configurator in 3.2.0 🙏🏾

[eli-darkly]

OK, we've released version 3.2.0. After updating to this version, here are some examples of ways to change the behavior:

• To stop the SDK from producing any log output at all: configBuilder.logAdapter(Logs.none()) (the Logs class is in com.launchdarkly.logging)
• To keep the default Timber behavior, but change the tag from "LaunchDarklySdk" to something else: configBuilder.loggerName("SomethingElse")
• To use the Android logging API directly without Timber, but suppress all log output below ERROR level: configBuilder.logAdapter(LDAndroidLogging.adapter()).logLevel(LDLogLevel.ERROR)

The com.launchdarkly.logging API (documented here) provides additional ways to redirect log output to other destinations or frameworks, or to write a custom adapter. It is a facade similar in principle to SLF4J, but much lighter-weight and with several built-in implementations.

[erawhctim]

This is great, thanks Eli!