Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > alt.os.development > #8384

Re: System log and format of log entries

From "James Harris" <james.harris.1@gmail.com>
Newsgroups alt.os.development
Subject Re: System log and format of log entries
Date 2015-07-15 15:15 +0100
Organization A noiseless patient Spider
Message-ID <mo5ps3$mih$1@dont-email.me> (permalink)
References <mo2p03$kme$1@dont-email.me> <mo3eab$tca$1@speranza.aioe.org>

Show all headers | View raw


"Benjamin David Lunt" <zfysz@fysnet.net> wrote in message 
news:mo3eab$tca$1@speranza.aioe.org...
> "James Harris" <james.harris.1@gmail.com> wrote in message 
> news:mo2p03$kme$1@dont-email.me...

>> Anyone have a good approach to laying out entries in an OS system 
>> log?

...

>  tick: module: function: information
>
> Here is an example line of my SATA(AHCI) module output.
>
> 010187780423: SATA: sata_write_sectors:
>    lba = 1012097, count = 2, buf address = 0x031AE800

Thanks, Ben. That's useful to see. I have compared that with other 
sources: Peter's post and Rod's post here, Unix logs, Windows logs, and 
the following RFC about syslog.

  https://www.ietf.org/rfc/rfc3164.txt

As a consequence I have come up with the following contents for each log 
entry.

  64-bit   upcounter
  four octets   severity, classification, flags, and indicators
  text   datetime
  text   path (how the message got here, blank for local machine)
  text   source (program name, instance, sequence number)
  text   name of the userid under which the program was running
  text   entry text

It is a sort of superset as they all have things that I think are 
sensible to include but I have merged some elements in an effort to 
reduce the number of fields and and also added a few small elements. 
While each entry is quite wide not all fields would need to be printed 
when rendering a log to a display such as the screen, but they would be 
stored for examination.

Explanations of the fields are below for anyone who is interested.

* Upcounter. An unsigned upwards counter. Increasing at a constant 
real-time rate if possible such as a modern TSC or HPET, but otherwise 
increasing at a non-constant rate, such as an early TSC.

* Severity. One octet. Higher nibble value set to 1 more than the Unix 
"level" (e.g. Unix level ERR for error conditions has value 4 meaning 
the severity upper octet would be 5) partly so that there is no leading 
zero. Lower nibble a way to qualify the severity in a more fine-grained 
way. Default for the lower nibble 0x8 bit it can be higher or lower.

* Classification. One octet. Used for grouping reports by type of 
sender. No values assigned yet. Subsumes the Windows "Category" and the 
Unix "facility" indication.

* Flags. One octet. Various flags such as whether the upcounter value is 
fake or its source has changed.

* Indicators. One octet. Indicates the datetime's source and how long 
since it was last verified.

* Datetime. A human-readable but also program-parseable representation 
of the current date and time, with the timezone.

* Path. Blank if the log entry is from the local machine. Else, this 
field would be available to hold the path the log report took to get 
here. The origin machine adds its identification first. Each subsequent 
relaying machine can append its id. So, if present, the first part is 
always the originating machine.

* Source. The name of the program which sent the log entry and optional 
instance id and sequence number. The program name can have codes 
appended to indicate the version of the program and the type of the 
report - something that may be relevant only to that build of the 
program.

* Username. The textual name for the userid under which the program was 
running.

* Entry text. The log message (which could include the name of the 
function which issued the message and the sending machine's datetime etc 
as well as any specific message text).

I may change it but that's what I have so far.

James

Back to alt.os.development | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

System log and format of log entries "James Harris" <james.harris.1@gmail.com> - 2015-07-14 11:42 +0100
  Re: System log and format of log entries "James Harris" <james.harris.1@gmail.com> - 2015-07-14 11:59 +0100
  Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 03:23 -0400
    Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 22:46 -0400
  Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 03:33 -0400
    Re: System log and format of log entries Peter Cheung <mcheung63@gmail.com> - 2015-07-15 00:47 -0700
    Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-15 22:42 -0400
      Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-16 12:18 -0700
        Re: System log and format of log entries "Mike Gonta" <mikegonta@gmail.com> - 2015-07-16 15:50 -0400
          Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-16 13:24 -0700
            Re: System log and format of log entries "Rod Pemberton" <boo@fasdfrewar.cdm> - 2015-07-17 06:39 -0400
              Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-17 10:27 -0700
                Re: System log and format of log entries "Benjamin David Lunt" <zfysz@fysnet.net> - 2015-07-21 16:38 -0700
  Re: System log and format of log entries "James Harris" <james.harris.1@gmail.com> - 2015-07-15 15:15 +0100

csiph-web