Collecting Information & Logging

how-to

Node.js SDK logging.

Library 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.

Note that customization of logging levels via console_log_level or LCB_LOGLEVEL will not take effect if a customer logging function has been provided in the sdk options argument. As of Node SDK 3.0.1, the connection library provides a logging function if one is not provided, so there will always be a provided logging function, and the DEBUG environment variable should be used to obtain logging output.

The Node.js SDK offers a basic logging facility through which its various subsystems can output debug and error information. This information provides details of the library’s internals and additional error information which may otherwise not be accessible via other APIs. Logging may be enabled via the debug library, an environment variable, or a connection string directive.

The most common way to enable logging is to set the DEBUG environment variable to couchnode*. Alternatively you can set the LCB_LOGLEVEL environment variable to a number between 1 and 5, with 5 being the most verbose and 1 being the least verbose. Also, the query parameter console_log_level can be used to set the log level. Note that these logs will go to stdout (standard output):

$ DEBUG=couchnode* node my_couchbase_app

$ DEBUG=couchnode:lcb:error,couchnode:lcb:warn node my_couchbase_app

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

1ms [I0] {14780} [DEBUG] (lcbio_mgr - L:383) <localhost:11210> (HE=0xe56760)
Creating new connection because none are available in the pool

The output format is subject to change. It is intended for human consumption and is not designed to be parseable. Different formats can be specified by providing a custom logging function in the 'options' argument.

The following table describes the components of the log entries:

Format Description

Format	Description
`nms`	The number of milliseconds elapsed since the loading of the library
`[In]`	The identifier of the `lcb_t` object associated with the current message. This allows you to determine the origin of the message in the case where the application contains multiple such `lcb_t` objects. The number is incremented for each call to `lcb_create()`
`{PID}`	The current thread/process identifier. On Linux this is also the process ID for single-threaded programs, further helping distinguish between multiple forks of an application.
`[LEVEL]`	A string representing the severity of the level
`(subsystem - L:line)`	The subsystem that produced this message, followed by the source code line at which this message was created. The subsystem will typically, but not always, resemble the source code file. It is a small string describing what the current line is doing.
`<host:port>`	The host and port, if any, associated with the message. This is supplied for messages that relate to the state of a particular connection.

nms

The number of milliseconds elapsed since the loading of the library

[In]

The identifier of the lcb_t object associated with the current message. This allows you to determine the origin of the message in the case where the application contains multiple such lcb_t objects. The number is incremented for each call to lcb_create()

{PID}

The current thread/process identifier. On Linux this is also the process ID for single-threaded programs, further helping distinguish between multiple forks of an application.

[LEVEL]

A string representing the severity of the level

(subsystem - L:line)

The subsystem that produced this message, followed by the source code line at which this message was created. The subsystem will typically, but not always, resemble the source code file. It is a small string describing what the current line is doing.

<host:port>

The host and port, if any, associated with the message. This is supplied for messages that relate to the state of a particular connection.

Additional Information

The Node.js SDK internally uses the libcouchbase API (since 4.0 implemented by the Couchbase++ library) to perform operations. If more in depth debug information is required such as Stack Traces or Memory Leak Detection, you can find more information on how to achieve this in the C SDK documentation.