Dev guideAPI Reference
Dev guideAPI ReferenceUser GuideGitHubNuGetDev CommunitySubmit a ticketLog In
GitHubNuGetDev CommunitySubmit a ticket

Customize the Ruby SDK logger

Hsow to customize the log information about experiments coming from the Optimizely Feature Experimentation Ruby SDK to help with debugging.

The logger logs information about your experiments to help you with debugging. You can customize where log information is sent and what kind of information is tracked.

The Ruby SDK does not have a logger enabled by default. You need to pass in a logger to the SDK to have basic logging functionality. The Ruby SDK provides a simple logger implementation that you can instantiate and pass in.

To improve your experience setting up the SDK and configuring your production environment, we recommend that you pass in a logger for your Optimizely client. See the code example below.

# Require the logger library in to get the log levels
require 'logger'
require 'optimizely'

# Instantiate an Optimizely logger with the default log level Logger::INFO
logger = 

# You can also instantiate with a custom log level
logger =

# Instantiate the Optimizely client with our logger
optimizely_client =
  datafile: datafile,
  logger: logger

Use your own logger

For finer control over your SDK configuration in a production environment, pass in a custom logger for your Optimizely client. A custom logger is a function that takes an argument, the level, and the message. See the code example below to create and set a custom logger.

# Define your own custom logger that inherits from the Optimizely base logger
class CustomLogger < Optimizely::BaseLogger
  def initialize
    @logger =$stdout)

  def log(level, message)
    # You can handle the message here in any way you'd like
    custom_message = "Custom logged: #{message}"
    @logger.add(level, custom_message)

Log levels

The table below lists the log levels for the Ruby SDK.

Log LevelExplanation that cause the app to crash are logged. that prevent feature flags from functioning correctly (for example, invalid datafile in initialization and invalid feature keys) are logged. The user can take action to correct. that don't prevent feature flags from functioning correctly, but can have unexpected outcomes (for example, future API deprecation, logger or error handler are not set properly, and nil values from getters) are logged. of significance (for example, decision started, decision succeeded, tracking started, and tracking succeeded) are logged. This is helpful in showing the lifecycle of an API call. information related to errors that can help us debug the issue (for example, the feature flag is not running, user is not included in the rollout) are logged.