Collecting Information and Logging in the PHP SDK with Couchbase Server
- how-to
- UNDER CONSTRUCTION
Logging with the SDK using the default logger implementation in PHP.
Logging
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');
print_r($getResult->content());
…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:
$ 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 .
|