• how-to
    Logging with the SDK using the default logger implementation in PHP.


    The Logging implementation has changed substantially in 4.0 and is not currently fully documented. This will be resolved in a future 4.x release.

    The Couchbase PHP SDK has no hard dependency on a specific logger implementation. By default it uses built-in means to report events. The only thing you may change is the log level, which is controlled by couchbase.log_level in php.ini.

    You can increase the log level for greater verbosity (more information) in the logs:

    • off — disables all logging, which is normally set by default.

    • error — error messages.

    • warn — error notifications.

    • info — useful notices, not often.

    • debug — diagnostic information, required to investigate problems.

    • trace — the most verbose level.

    The PHP SDK is configured to send logs to standard output (when error_log is set to NULL). You can set it to syslog to redirect all logs (including the PHP SDK) to the syslog device. For example, the script below:

    $options = new ClusterOptions();
    $options->credentials("Administrator", "password");
    $cluster = new Cluster('couchbase://localhost', $options);
    $bucket = $cluster->bucket('travel-sample');
    $collection = $bucket->scope('inventory')->collection('airline');
    $getResult = $collection->get('airline_10');

    …​along with this php.ini snippet:

    error_log = syslog
    extension = couchbase.so
    couchbase.log_level = debug

    Alternatively, if you do not wish to make changes in your ini file, you can use the COUCHBASE_LOG_LEVEL variable as follows:

    GNU/Linux and Mac
    $ export COUCHBASE_LOG_LEVEL=<log-level>
    $ set COUCHBASE_LOG_LEVEL=<log-level>

    When logging is turned on, the SDK will output messages similar to this:

    [2022-05-25 11:51:20.180] [72937,15083872] [debug] 0ms, [3d1ad384-ca9b-4983-b701-ea6ef15909ee/725383a6-e68b-460a-d782-56ee249fba58/plain/-] <localhost:11210> attempt to establish MCBP connection
    [2022-05-25 11:51:20.182] [72937,15083872] [debug] 2ms, [3d1ad384-ca9b-4983-b701-ea6ef15909ee/725383a6-e68b-460a-d782-56ee249fba58/plain/-] <localhost:11210> connecting to ::1:11210, timeout=2000ms
    [2022-05-25 11:51:20.182] [72937,15083872] [debug] 0ms, [3d1ad384-ca9b-4983-b701-ea6ef15909ee/725383a6-e68b-460a-d782-56ee249fba58/plain/-] <localhost:11210> connected to ::1:11210
    [2022-05-25 11:51:20.182] [72937,15083872] [debug] 0ms, [3d1ad384-ca9b-4983-b701-ea6ef15909ee/725383a6-e68b-460a-d782-56ee249fba58/plain/-] <localhost/::1:11210> user_agent={"a":"cxx/1.0.0/","i":"3d1ad384-ca9b-4983-b701-ea6ef15909ee/725383a6-e68b-460a-d782-56ee249fba58"}, requested_features=[tcp_nodelay, mutation_seqno, xattr, xerror, select_bucket, json, duplex, alt_request_support, tracing, sync_replication, vattr, collections, subdoc_create_as_deleted, preserve_ttl, unordered_execution, clustermap_change_notification, snappy]
    By default, php-fpm redirects the standard output and error streams to /dev/null for performance and FastCGI conformance reasons. In order to capture the logs in this setup, you must explicitly configure catch_workers_output = yes.