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

Customize PHP SDK logger

How to customize the log information about experiments coming from the Optimizely Feature Experimentation PHP 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 PHP SDK comes with a default Logger implementation. To configure the log level threshold, you can pass the log level as an argument to the DefaultLogger constructor.

use Monolog\Logger;
use Optimizely\Logger\DefaultLogger;

/**
 * To set a log level choose one of the following:
 * 
 * INFO: Logger.INFO
 * DEBUG: Logger.DEBUG
 * WARNING: Logger.WARNING
 * ERROR: Logger.ERROR
 * CRITICAL: Logger.CRITICAL
 *
 * To define a different minimum logging level pass it in during initialization
 * The example below shows a minimum logging level of WARNING and outputs
 * to standard out
 */

$optimizelyClient = new Optimizely($datafile, null, new
DefaultLogger(Logger::WARNING, "stdout"));

For finer control over your SDK configuration in a production environment, pass in a custom logger for your Optimizely client. A custom logger is an instance of a class that implements LoggerInterface

Log levels

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

Log LevelExplanation
CRITICALEvents that cause the app to crash are logged.
ERROREvents that prevent feature flags from functioning correctly (for example, invalid datafile in initialization and invalid feature flag keys) are logged. The user can take action to correct.
WARNINGEvents 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) are logged.
INFOEvents 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.
DEBUGAny 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 flag rule) are logged.