• HOME
  • INTEGRATIONS
  • SDKS
  • GUIDES
  • API DOCS
No results for ""
EXPAND ALL
launchdarkly.com

EDIT ON GITHUB

Logging configuration

Read time: 6 minutes
Last edited: Jun 18, 2021

Overview

This topic explains how to configure the logging feature. Logging is available for both client-side and server-side SDKs.

Configuring logging

LaunchDarkly SDKs rely on built-in logging packages and libraries to track events. Depending on which language you use, you can configure logging behavior to be highly or minimally verbose.

  • Client-side SDKs
  • Server-side SDKs

Client-side SDKs

This feature is available in the following client-side SDKs:

Android

The Android SDK makes heavy use of Timber logging. Include Timber in your application to enable debug output or production logging. An example is shown below to enable debug output when the application is built with a debug configuration.

1if (BuildConfig.DEBUG) {
2 Timber.plant(new Timber.DebugTree());
3}

Electron

By default, the SDK uses the winston package. There are four logging levels: debug, info, warn, and error; by default, debug and info messages are hidden.

To change the logging configuration, you can set LDOptions.logger to either another Winston instance or any object that implements the LDLogger interface. The createConsoleLogger function creates a minimal logger.

Node.js (client-side)

By default, the SDK uses the winston package. There are four logging levels: debug, info, warn, and error; by default, debug and info messages are hidden.

To learn more, read the TypeScript definitions for LDLogger, LDOptions, and createConsoleLogger.

You can pass a custom logger to the SDK by the configurable logger property. Winston's syntax for instantiating and configuring loggers changed between versions 2.x and 3.x. If using the transitive dependency generates errors, declare a dependency on a specific Winston version.

1const logger =
2 new winston.Logger({
3 level: "debug",
4 transports: [
5 new winston.transports.Console()
6
7 ]
8 }
9);
10
11const user = {
12 key: "aa0ceb"
13};
14
15const ldClient = LaunchDarkly.initialize(
16 'YOUR_CLIENT_SIDE_ID',
17 user,
18 {"logger": logger}
19);

Roku

The Roku SDK's logging feature is configurable. You can set different log levels, or use a custom logging back end with one of the two supported custom loggers.

Those loggers are:

Log levels in the Roku SDK

You can configure the SDK log level. For example, to set the level to info:

1config.setLogLevel(LaunchDarklyLogLevels().info)

The SDK supports the following Levels:

1LaunchDarklyLogLevels().error
2LaunchDarklyLogLevels().warn
3LaunchDarklyLogLevels().info
4LaunchDarklyLogLevels().debug
5LaunchDarklyLogLevels().none

Legacy API custom logger for the Roku SDK

1function CustomLogger() as Object
2 return {
3 log: function(level as Integer, message as String)
4
5 print level message
6 end function
7 }
8end function
9
10config.setLogger(CustomLogger())

SceneGraph API custom logger for the Roku SDK

1<!-- /components/CustomLogger.xml -->
2
3<component name="CustomLogger" extends="Task">
4 <interface>
5 <field id="log" type="assocarray" alwaysNotify="true"/>
6 </interface>
7
8 <script type="text/brightscript" uri="pkg:/components/CustomLogger.brs"/>
9</component>
1REM /components/CustomLogger.brs
2
3function init()
4
5 m.messagePort = createObject("roMessagePort")
6
7
8 m.top.observeField("log", m.messagePort)
9
10end function
11
12function mainThread() as Void
13 while (true)
14
15 msg = wait(0, m.messagePort)
16
17
18 if type(msg) = "roSGNodeEvent" then
19 if field = "log" then
20 value = msg.getData()
21
22 print value.level value.message
23 end if
24 end if
25 end while
26end function

To use the logger, create the SceneGraph logger node, and then:

1config.setLoggerNode(myLoggerNode)

Xamarin

The Xamarin SDK uses the Common.Logging framework. For an example configuration, read the Common.Logging README.

Be aware of two considerations before you enable the DEBUG log level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

Server-side SDKs

This feature is available in the following server-side SDKs:

.NET

The .NET SDK has four logging levels: Debug, Info, Warn, and Error. By default, the lowest enabled level is Info, so Debug messages are hidden. Be aware of two considerations if you enable the Debug level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

The .NET SDK sends log output to Console.Error by default. The ConfigurationBuilder.Logging method and the LaunchDarkly.Logging API allow you to change the output destination and log level.

Here is an example:

1using LaunchDarkly.Logging;
2using LaunchDarkly.Sdk.Server;
3
4var config = Configuration.Builder("my-sdk-key")
5 .Logging(
6 Components.Logging(Logs.ToWriter(Console.Out)).Level(LogLevel.Debug)
7 )
8 .Build();

The destination could be another logging framework, such as the .NET Core Microsoft.Extensions.Logging API in this example:

1using LaunchDarkly.Logging;
2using LaunchDarkly.Sdk.Server;
3
4var config = Configuration.Builder("my-sdk-key")
5 .Logging(Logs.CoreLogging)
6 .Build();

To learn more about logging configuration and adapters for other logging frameworks, read the documentation for LaunchDarkly.Logging.

All log messages from the SDK are tagged with a logger name, indicating the category of messages. If you use a logging framework like Microsoft.Extensions.Logging or NLog, you can use these names to filter the output:

  • LaunchDarkly.Sdk: general messages about the operation of the SDK client.
  • LaunchDarkly.Sdk.DataSource: messages about how the SDK client receives feature flag data, such as if the connection to LaunchDarkly has been interrupted.
  • LaunchDarkly.Sdk.DataStore (or more specific names like LaunchDarkly.Sdk.DataStore.Redis): messages about how the SDK client stores feature flag data, such as if you are using a database integration.
  • LaunchDarkly.Sdk.Evaluation: messages about unusual conditions during feature flag evaluation, such as if a feature flag could not be evaluated because its configuration is invalid.
  • LaunchDarkly.Sdk.Events: messages about analytics events, such as if event data could not be sent to LaunchDarkly due to a network problem.

Before version 6.0, the .NET SDK had different logging behavior:

  • The mechanism for specifying a log destination was the Common.Logging framework.
  • If you did not specifically configure a log destination using Common.Logging, logging was disabled by default.
  • The main logger name was LaunchDarkly.Client.LdClient.

C/C++ (server-side)

By default, there is no log output, but we provide a default logger you can enable. The SDK does not lock on any logging. Ensure that your implementation is thread safe.

Whether you use a custom logger or the default one, you must call LDConfigureGlobalLogger before the client is initialized. You cannot modify logging while the client is running.

If you use the defeault logger, you can configure how verbose it should be.

For example, setting it to LD_LOG_TRACE produces the most verbose output, which may be useful in troubleshooting.

1LDConfigureGlobalLogger(LD_LOG_TRACE, LDBasicLogger);

You can also use your own custom log function:

1static void
2myCustomLogger(const LDLogLevel level, const char *const text)
3{
4 printf("[%s] %s\n", LDLogLevelToString(level), text);
5}
6
7LDConfigureGlobalLogger(LD_LOG_TRACE, myCustomLogger);

Go

The Go SDK uses a logging abstraction that can write to a log.Logger or anything with a compatible interface. This adds a system of log levels similar to logging frameworks on other platforms. There are four logging levels: Debug, Info, Warn, and Error.

By default, all levels of messages are enabled except Debug. You can tell the SDK to enable more or fewer levels, to send the output to a different destination, or to disable logging.

Here's how:

1import (
2 "log"
3 "os"
4 ldlog "gopkg.in/launchdarkly/go-sdk-common.v2"
5 ld "gopkg.in/launchdarkly/go-server-sdk.v5"
6 "gopkg.in/launchdarkly/go-server-sdk.v5/ldcomponents"
7)
8
9var config ld.Config
10
11// Send output to a file, and change minimum level to Warn (Debug and Info are disabled)
12file, _ := os.Create("app.log")
13config.Logging = ldcomponents.Logging().
14 BaseLogger(log.New(file, "", log.LstdFlags)).
15 MinLevel(ldlog.Warn)
16
17// Or, disable logging
18config.Logging = ldcomponents.NoLogging()

Be aware of two considerations if you enable the Debug log level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

Java

The Java SDK uses SLF4J. All loggers are namespaced under com.launchdarkly. For an example configuration, visit hello-java.

You can filter by logger name. Here are available logger names, starting with version 5.0:

  • com.launchdarkly.sdk.server.LDClient: This is for general messages that do not fall into any other categories.
  • com.launchdarkly.sdk.server.LDClient.DataSource: This is for messages related to how the SDK obtains feature flag data. Usually, this means messages about the streaming connection to LaunchDarkly, but if you use polling mode or file data instead, the SDK logs those messages under this name.
  • com.launchdarkly.sdk.server.LDClient.DataStore: This is for messages related to how feature flag data is stored. For example, database errors appear here if you are using a database integration.
  • com.launchdarkly.sdk.server.LDClient.Evaluation: This is for messages related to feature flag evaluation.
  • com.launchdarkly.sdk.server.LDClient.Events: This is for messages related to analytics event processing.

In versions of the SDK before 5.0, logger names were not standardized and were sometimes the names of Java classes that are not part of the public API, but they consistently had a package prefix of either com.launchdarkly.client. or com.launchdarkly.eventsource.

For an example SLF4J configuration, visit hello-java.

Be aware of two considerations when enabling the DEBUG log level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

Node.js (server-side)

The Node.js SDK offers several choices for logging.

In the default configuration, the SDK sends output to the console and enables all log levels except debug.

Versions 5.x and earlier of the SDK used the winston logging package for the default configuration. Versions 6.0 and later do not have a dependency on winston. Instead, they write directly to the console by default.

For full control over logging behavior, you can set the logger option to an object that implements the LDLogger interface. To learn more about the logger's requirements and methods, read LDLogger. The winston package is compatible with this interface, so if you are already using a winston logger, you can pass it directly to the SDK.

You can use basicLogger for simpler control over logging behavior. Versions 5.x and earlier of the SDK do not support basicLogger.

This example shows how to use basicLogger to enable debug-level logging in your SDK configuration:

1const LaunchDarkly = require('launchdarkly-node-server-sdk');
2
3const config = {
4 logger: LaunchDarkly.basicLogger({
5 level: 'debug',
6 }),
7};

Be aware of two considerations when enabling debug-level logging:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

PHP

The PHP SDK uses Monolog. All loggers are namespaced under LaunchDarkly.

Be aware of two considerations when enabling the DEBUG log level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

You can pass a custom logger to the SDK by using the configurable logger property:

1$client = new LaunchDarkly\LDClient("YOUR_SDK_KEY", array("logger" => new Logger("LaunchDarkly", [new ErrorLogHandler(0, Logger::DEBUG)])));

Python

The Python SDK uses Python's built-in logging library. All loggers are namespaced under ldclient.util. For an example configuration, visit hello-python.

Be aware of two considerations when enabling the DEBUG log level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

Ruby

The Ruby SDK uses Ruby's built-in Logger class. All loggers are namespaced under [LDClient].

Be aware of two considerations when enabling the DEBUG log level:

  1. Debug-level logs can be very verbose. We do not recommend using debug logging in high-volume environments.
  2. Debug-level logs include sensitive information, including LaunchDarkly users you create when you use this SDK.

You can pass a custom logger to the SDK by using the configurable logger property:

1log = ::Logger.new($stdout)
2log.level = ::Logger::DEBUG
3config = LaunchDarkly::Config.new({logger: log})
4client = LaunchDarkly::LDClient.new("YOUR_SDK_KEY", config)