RFC 5424 Syslog Support in log4p

Overview

log4p now includes full support for RFC 5424 severity levels, making it compatible with standard syslog protocols and allowing seamless integration with syslog infrastructure.

RFC 5424 Severity Levels

RFC 5424 defines 8 severity levels (in descending order of severity):

Level	log4p Name	Priority	Description
0	emergency	Highest	System is unusable
1	alert		Action must be taken immediately
2	critical		Critical conditions
3	error		Error conditions
4	warning		Warning conditions
5	notice		Normal but significant conditions
6	informational		Informational messages
7	debug		Debug-level messages
N/A	trace	Lowest	Trace messages (more verbose than debug)

Log Level Mapping

log4p extends RFC 5424 with an additional trace level for finer-grained logging below the RFC standard. The level hierarchy in log4p is:

trace < debug < informational < notice < warning < error < critical < alert < emergency

Using RFC 5424 Levels

Direct Usage

Log using any RFC 5424 level directly:

?- use_module(log4p).

% Log at different severity levels
?- emergency('System failure detected').
?- alert('Immediate action required').
?- critical('Critical error condition').
?- error('An error occurred').
?- warning('Warning message').
?- notice('Routine notice').
?- informational('Information message').
?- debug('Debug information').
?- trace('Trace message').

With Formatting

Use the `/2` variants for formatted messages:

?- emergency('System ~w failed', [subsystem]).
emergency: System subsystem failed

?- error('Error ~d in module ~w', [42, auth]).
error: Error 42 in module auth

Legacy Aliases

For backward compatibility, log4p maintains legacy aliases that map to RFC 5424 levels:

Legacy	Maps To	RFC 5424
info/1,2	informational/1,2	Level 6
warn/1,2	warning/1,2	Level 4
fatal/1,2	emergency/1,2	Level 0

% These still work for backward compatibility
?- info('Information message').       % same as informational/1
?- warn('Warning message').            % same as warning/1
?- fatal('Fatal error').               % same as emergency/1

Setting Log Levels

Control which messages are emitted using the same level control predicates:

% Set global log level to warning (filters out informational and debug)
?- set_global_log_level(warning).

% Set local level for current thread
?- set_local_log_level(debug).

% Clear local level (reverts to global or default)
?- clear_local_log_level.

% Clear global level (reverts to default)
?- clear_global_log_level.

Default Log Level

The default log level is info (which is an alias for informational). This means:

• Messages at level informational and above are logged by default
• Messages at level notice, warning, error, critical, alert, and emergency are always logged unless overridden
• Messages at level debug and trace are filtered out by default

Filtering Behavior

Log filtering follows the RFC 5424 priority model:

% When level is set to 'warning':
?- set_global_log_level(warning).

% These are logged (warning or higher priority):
?- emergency('msg').      % Level 0 - logged
?- alert('msg').           % Level 1 - logged
?- critical('msg').        % Level 2 - logged
?- error('msg').           % Level 3 - logged
?- warning('msg').         % Level 4 - logged

% These are NOT logged (lower priority):
?- notice('msg').          % Level 5 - filtered
?- informational('msg').   % Level 6 - filtered
?- debug('msg').           % Level 7 - filtered
?- trace('msg').           % Level 8 - filtered

Integration with Syslog

While log4p doesn't include a built-in syslog handler in the core library, the RFC 5424 level names align perfectly with standard syslog severity codes. Custom handlers can easily map log4p levels to syslog facilities:

% Example: custom syslog-compatible handler
syslog_handler(Level, Message) :-
  level_to_severity(Level, Severity),
  format_syslog(Severity, Message),
  send_to_syslog(Message).

level_to_severity(emergency, 0).
level_to_severity(alert, 1).
level_to_severity(critical, 2).
level_to_severity(error, 3).
level_to_severity(warning, 4).
level_to_severity(notice, 5).
level_to_severity(informational, 6).
level_to_severity(debug, 7).

Backward Compatibility

Existing code using the old level names (trace, debug, info, warn, error, fatal) continues to work without modification:

% Old code still works
?- info('Using legacy alias').          % Maps to informational
?- warn('Using legacy alias').          % Maps to warning
?- error('Using legacy alias').         % No change, still error
?- fatal('Using legacy alias').         % Maps to emergency

However, the internal representation now uses RFC 5424 names, so introspection predicates like log_levels/1 will show the RFC 5424 names:

?- log_levels(Levels).
Levels = [trace, debug, informational, notice, warning, error, critical, alert, emergency].

Querying Available Levels

Get the complete list of supported log levels:

?- log_levels(Levels).
Levels = [trace, debug, informational, notice, warning, error, critical, alert, emergency].

% Get valid levels from current level upward
?- valid_log_levels(Valid).
Valid = [warning, error, critical, alert, emergency].  % if current level is warning

RFC 5424 Compliance

log4p's RFC 5424 implementation provides:

• ✅ All 8 standard severity levels (0-7)
• ✅ Correct priority ordering
• ✅ Level filtering based on severity
• ✅ Per-thread and global level configuration
• ✅ Message formatting with arguments
• ✅ Handler-based architecture for custom destinations For complete details about RFC 5424, see the IETF RFC 5424 specification.