#48260 Add classification information to error logs and a way to process them in an automated fashion.
Closed: wontfix 5 years ago Opened 6 years ago by rmeggins.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1257459

Description of problem:
Without having an understanding of what each error message means it is not
clear for the common user to understand how critical the issues described are,
also this makes it more difficult and time consuming to create scripts to
process error logs for purposes such as monitoring.

It will be good if error logs have a severity level assigned to them such as
syslog(3) error classification scale:

       LOG_EMERG      system is unusable
       LOG_ALERT      action must be taken immediately
       LOG_CRIT       critical conditions
       LOG_ERR        error conditions
       LOG_WARNING    warning conditions
       LOG_NOTICE     normal, but significant, condition
       LOG_INFO       informational message
       LOG_DEBUG      debug-level message

and also if they could be identified by an numeric ID such as:
1234 - the service is shutting down.
4321 - the service is starting up

In this way it would be much easier to automate the processing of the logs to
better monitor the status of the service.
This ideally would come with an updated documentation so that normal users can
find the meaning of the error without much effort.

Version-Release number of selected component (if applicable):
All versions and releases until now.

How reproducible:
Not relevant.

Steps to Reproduce:
1. Look at the errors log (/var/log/dirsrv/... errors

Actual results:
Error logs are shown as sometimes descriptive strings without clear information
about the severity and in multiple lines.

Expected results:
Error logs are shown with an ID and a severity level assigned in a single line
together with a short descriptive message

Rich, are you proposing that we use a new error code for each severity level, or are you proposing, in addition to the severity levels, we also add error codes for particular conditions? Just checking, thanks.

Replying to [comment:6 mreynolds]:

Rich, are you proposing that we use a new error code for each severity level, or are you proposing, in addition to the severity levels, we also add error codes for particular conditions?

The latter - every error (except perhaps DEBUG/TRACE level) should have a unique code assigned to it - this is from the bz:

This is to aid migration from Sun/Oracle DS. We should see what else Sun/Oracle DS logs to see if there is additional information we can add.

There will need to be a doc component for this - whatever we do in the code, we should do it in such a way that we can generate the docs from the code.

The error code registry should also be in the source code, in a format that can be processed with doxygen.

We will need to make sure that we do not break the console which has an error log parser.

The error log message should have a unique code. For example, instead of
{{{
[08/Jun/2016:13:45:10 -0600] - 389-Directory/1.3.4.0 B2016.160.1456 starting up
[14/Jun/2016:12:10:53 -0600] - slapd stopped.
}}}
this
{{{
[08/Jun/2016:13:45:10 -0600] - 1 - 389-Directory/1.3.4.0 B2016.160.1456 starting up
[14/Jun/2016:12:10:53 -0600] - 42 - slapd stopped.
}}}
Then in the error code documentation:
{{{
1 - INFO - the slapd process has begun the startup process.
42 - INFO - the slapd process has exited cleanly.
}}}

That way, someone writing a logging system can know exactly what error log message number 1 and 42 mean, can route them to an alert system or not, etc.

I'm not sure if DEBUG or TRACE messages should be registered/numbered like this.

Metadata Update from @rmeggins:
- Issue set to the milestone: 1.3.6 backlog

5 years ago

I have suggested something like this before, where we have a unique code per error message. The hardest part is actually making all the codes so they can be routed.

Mark has done a lot of work here for log levels, so is this still relevant?

Metadata Update from @firstyear:
- Custom field reviewstatus adjusted to review
- Custom field version adjusted to 1.3.6
- Issue close_status updated to: None

5 years ago

Metadata Update from @mreynolds:
- Custom field reviewstatus adjusted to new (was: review)

5 years ago

This isa duplicate fo issue 48978

Metadata Update from @mreynolds:
- Custom field reviewstatus reset (from new)
- Issue close_status updated to: duplicate
- Issue status updated to: Closed (was: Open)

5 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1591

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: duplicate)

2 years ago

Login to comment on this ticket.

Metadata