Getting started

This is a 5 minutes guide to getting started with log4db2.

Downloading

You can download log4db2 from Releases.

Once you have downloaded the file, you need to extract it. In Linux:

tar -xvf log4db2.tar.gz

For more information about installing, you can visit:

Install section.
Install from sources section.

Preparing

There is nothing to prepare to install log4db2. You just need a small space in the database and the necessary rights. There are no other tools as prerequisites.

Installing

First, you need to connect to your database:

db2 connect to mydb

The output is:

   Database Connection Information

 Database server        = DB2/LINUXX8664 11.5.0
 SQL authorization ID   = ANGOCA
 Local database alias   = MYDB

You just need to call the installer. Make sure you use the dot (source) command.

cd log4db2
. ./install

The output is something like:

Installing utility for v10.1
/home/ext/angoca/workspace/install/log4db2/sql-pl/Tables.sql
DB20000I  The SQL command completed successfully.

DB20000I  The SQL command completed successfully.

...

DB20000I  The SQL command completed successfully.

DB20000I  The SQL command completed successfully.

log4db2 was installed successfully`

For more information about how to install log4db2 you can visit:

Install section.
FAQs section.

Calling from code

The basic way to create a log message with log4db2 is with an anonymous block:

db2 -td@

BEGIN
 -- Variable to keep the logger Id.
 DECLARE logger_id INTEGER;
 -- Generates the logger Id depending on the hierarchy of the name.
 CALL logger.get_logger('com.github.angoca.log4db2', logger_id);
 -- Creates a log message, with a WARN level.
 CALL logger.warn(logger_id, 'First test of log4db2');
END@

For more information about how to develop code with log4db2 you can visit:

API section.
Examples section.
Explanatory video.

Dealing with logs

Viewing the logs

With the default configuration, the logs are written in a table called LOGS (The schema is not mandatory because the table is aliased as public).

SELECT level_id, logger_id, CHAR(message, 64) message
  FROM logs ;

Also, you can view the logs with the following stored procedure:

CALL logadmin.logs() ;

Real time

To continuously monitor what is happening in the table, you can use this stored procedure:

CALL logadmin.next_logs() ;

Each time this procedure is called, it will show you the new messages. By default, it will show you up to 50 new messages. However, you can customize the value and size of the messages.

To monitor the LOGS table, there is a script called tail_logs that continuously calls this stored procedure.

tail_logs

This is the equivalent of tail -f on a file.

Deleting the logs

Because the default logs are written in a table, the logs are deleted as normal rows:

DELETE FROM logs ;

Changing the log levels

You can change a specific logger by providing its name and its new level. You can change it by providing the level name or the level id:

CALL logadmin.register_logger_name('com.github.angoca.log4db2', 'debug');
CALL logadmin.register_logger('com.github.angoca.log4db2', 5);

These changes are not taken immediately. Instead, there is a mechanism that takes the new configuration into account periodically (Cache). By default, it pools the configuration every 30 seconds.

There are different levels to log an event, and this status is kept in the following tables:

SELECT *
  FROM logdata.conf_loggers ;
SELECT *
  FROM logdata.conf_loggers_effective;

The CONF_LOGGERS table keeps the configuration, and the CONF_LOGGERS_EFFECTIVE table specifies dynamically the value for each member of the hierarchy. The CONF_LOGGERS_EFFECTIVE table is changed each time the CONF_LOGGERS table is modified, via triggers. You do not need and you cannot modify this table directly.