Logger 3.1.0: Deprecate Levels Timing, APEX, and Sys Context

To help minimize confusion around the various logging levels, Logger will no longer support setting the level for logger.g_timing, logger.g_sys_context, and logger.g_apex. Instead of setting the level to these values, it is recommended to use logger.g_debug when calling logger.set_level.

These levels will still be used/referenced by their appropriate procedures in logger_logs.logger_level.

Logger 3.1.0: Adding Level to Additional Procedures

Prior to Logger 3.1.0, the following procedures would only log data when the Logger level was set to DEBUG:

  • log_apex_items
  • log_userenv
  • log_cgi_env
  • log_character_codes

This introduced an additional issue. What happens when I want to call these functions when the Logger level was set to ERROR? For example, suppose in a production environment you set the Logger level to ERROR (this is a pretty standard case). When an error occurs you call the usual logger.log_error call in the exception block. What if you wanted to also log all the APEX item values? If you called logger.log_apex_items it would not run since it had a hard coded validation to only log in DEBUG mode.

Each of the above functions now take in a new optional parameter called p_level. If defined, it will always log up to the defined level and store the entry in LOGGER_LOGS as that level. The best way to think of this paramater is if it is defined you're calling the equivialnt of logger.log_apex_items_error (if p_level => logger.g_error). If it is not defined, it will continue to only log in DEBUG mode and use the associated value for logger_level in LOGGER_LOGS.

Example:

-- Dev environment where Logger level is "DEBUG"
exec logger.set_level(p_level => logger.g_debug);

exec logger.log_userenv;

select id, logger_level, substr(text, 1, 45) text
from logger_logs_5_min
order by id desc;

-- Note: The "64" refers to the "SYS_CONTEXT" level. See the API docs for more info
        ID LOGGER_LEVEL TEXT
---------- ------------ ---------------------------------------------
    890647           64 USERENV values stored in the EXTRA column


-- Production: Logger level is set to "ERROR"
exec logger.set_level(p_level => logger.g_error);
exec logger.log_userenv;

-- No rows will be returned since Logger level is "ERROR"
select id, logger_level, substr(text, 1, 45) text
from logger_logs_5_min
order by id desc;

no rows selected


-- Using new parameter, store log_userenv even when Logger level is "ERROR"
exec logger.log_userenv(p_level => logger.g_error);

select id, logger_level, substr(text, 1, 45) text
from logger_logs_5_min
order by 1 desc;

-- Note: The "2" refers to the "ERROR" level. This happens since it uses the value stored in p_level
        ID LOGGER_LEVEL TEXT
---------- ------------ ---------------------------------------------
    890648            2 USERENV values stored in the EXTRA column

Logger 3.1.0: Beta

Logger 3.1.0 beta is now available for download in the releases folder (3.1.0_beta.zip).

This release is primarily focused around bug fixes, documentation, and some minor changes (i.e. it's not the most splashiest release we've had to date). We must thank the community for submitting all the bugs and suggestions.

As usual with each beta release of Logger, there will be a series of blog posts highlighting the changes:

You can review a complete list of changes for this release here.

Restrict Logger's Access to Your Data

Some DBAs and organizations may have issues with installing Logger in a schema with their existing data. The reason being that they don't want 3rd party code sitting alongside their data. The good news is that this concern can easily be resolved. Logger doesn't need to see your data/schema. Rather, your schema needs to see Logger.

Update 1: I've created a new issue for this so that these scripts will be available as part of Logger 3.1.0 onwards.

Update 2: This is now in Logger 3.1.0. Documentation here.

Here's how to setup Logger so that it can't see your data:

  1. Create a new user (for this example logger_user) with the appropriate permissions. You can review this in the Installation documentation. There's already a script to create a user in the install folder.

  2. Install Logger in the newly created schema.

  3. Grant execute and select permissions from logger_user to your schema:

-- Run as logger_user
grant execute on logger to my_user;
grant select on logger_logs to my_user;
grant select on logger_logs_apex_items to my_user;
grant select on logger_logs_5_min to my_user;
-- Add any additional grants to other Logger views
  1. In your schema, create the appropriate synonyms:
-- Run as my_user
create or replace synonym logger for logger_user.logger;
create or replace synonym logger_logs for logger_user.logger_logs;
create or replace synonym logger_logs_apex_items for logger_user.logger_logs_apex_items;
create or replace synonym logger_logs_5_min for logger_user.logger_logs_5_min;

After doing these steps your schema can see Logger's tables and views, and run the logger package. Assuming you don't grant public access to your tables/packages then Logger can't see your data.

Logger 3.0.0 Now Available!

We're please to announce that Logger 3.0.0 is now available! You can download the zip file from the releases folder on Github.

Logger 3.0.0 has many new features, the one we're most excited about is the concept of Plugins. A complete list of blog posts about this release can be found here (scroll down to the bottom for the list).

As always, if you find any bugs or have feature requests please be sure to submit them to the issues page.