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.
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
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
Metadata Update from @mreynolds: - Custom field reviewstatus adjusted to new (was: review)
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)
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: duplicate)
Login to comment on this ticket.