Error Logging Requirements
Michel Fingerhut
mf at ircam.ircam.fr
Mon Nov 12 19:25:26 AEST 1990
By order of importance (to me):
Compatibility with other systems?
syslog is a *defacto* standard, esp. in a heterogeneous environment.
I'd say (for me) -- 4.3 syslog. The fact that currently ultrix 4.0
supports only 4.2 syslog is a major pain for us. Any other system
should be compatible with 4.3 syslog (at the same time extend it,
if at all possible). A one-line report is the best place to start
with... (but that should not be the only available info).
Insofar as LANs, the centralization of reports from different machines
in a common log may help resolve problems common to multiple machines
which otherwise wouldn't be noticed (e.g., due to security, network,
electrical problems, etc...)
How is the error log used?
An error logging mechanism should (a) alert (b) log info of help to
diagnose and repair a problem. It should present both a low-level,
nitty-gritty view of the problem, as well as a "high level
monitoring" of system's health. Ideally, it should accumulate
statistics and make them available to monitoring tools that would allow to
see changes in performance over time and alert in such cases
(e.g.: disk effective throughput going down over time; load average
constantly too high or rising; terminal lines getty's eating too
much of cpu time, ECC errors increasing, etc...)
How it is reported (alerts)
Alerts should be, somewhat like for syslog, either real-time alarm messages
to console and/or specific users, or else "trigger" a user-selectable
program (e.g., mail, if so selected, to send mail to the system manager;
but also other programs which could take site-specific action).
The extent of the "report" should be configurable, so that one could
configure the same event to be reported differently to different audiences
(= classes of users).
It should also be possible to do LAN-wide alerts.
With the standardisation of X11, it would be nice to have popup alert
windows too.
What information should the error log contain
See above. For "specific bit meaning" -- I think this *should* be
included. I.e., an error report of the type IEREG (say) = 0x1234
is useless unless you happen to know the meaning of all bits in all
registers of all your devices. Since hopefully the device driver
knows it, it might as well elucidate.
Error log could be a combination of a short plain ascii text report combined
with a detailed (binary) snapshot "somewhere else" with tools to decrypt that
info.
Michael Fingerhut
More information about the Comp.unix.ultrix
mailing list