LogAnalysis
RE: [logs] How to define Log, Event, and Alert? Jul 24 2008 04:43PM
Tina Bird (tbird precision-guesswork com) (1 replies)
RE: [logs] How to define Log, Event, and Alert? Jul 25 2008 02:23AM
Bill Scherr IV (bschnzl cotse net) (1 replies)
Re: [logs] How to define Log, Event, and Alert? Jul 25 2008 04:14AM
Anton Chuvakin (anton chuvakin org) (1 replies)
RE: [logs] How to define Log, Event, and Alert? Jul 25 2008 09:23AM
Rainer Gerhards (rgerhards hq adiscon com) (1 replies)
RE: [logs] How to define Log, Event, and Alert? Jul 26 2008 02:48AM
Bill Scherr IV (bschnzl cotse net) (1 replies)
RE: [logs] How to define Log, Event, and Alert? Jul 29 2008 03:31PM
Rainer Gerhards (rgerhards hq adiscon com) (1 replies)
RE: [logs] How to define Log, Event, and Alert? Jul 30 2008 07:41AM
Eric Fitzgerald (Eric Fitzgerald microsoft com) (1 replies)
Rainer,

I have really enjoyed reading your last few posts. I would invite you to join the CEE working group.

Your discussion of state was very similar to a private one that I sent offline in CEE. I think that from a developer standpoint, events are typically raised on internal state changes, but users of a system typically view it as a black box and don't focus on the state changes so much as the observable macroscopic occurrence, which might appear to have been a state change but might not appear to be so.

My working definition of "event" is:

"An observable occurrence in an IT system."
* observable - If we can't observe it, then we can't raise an event on it, so it's not interesting.
* occurrence - We raise an event about an instantaneous occurrence, not about something ongoing (the beginning, end, and perhaps state changes within a long duration process might be events).
* IT system - This restricts the problem domain to computer science, seemed like a reasonable restriction at the time. Perhaps there is a better term to restrict this to the realm of computers and software.

For completeness, I define the following:
Event record- a persistable data structure containing information about an event
Event log- an ordered database of event records (typically but not always a sequential access file) [this also captures your and Bill's [Scherr] point about the temporal aspect of events, but does not restrict us to any specific technology]

Now a few comments regarding sequence:

Sequence information in the log is also often insufficient for determining the actual order of events; I agree that it is better than timestamp for the reasons that you state but I also feel that most logs are significantly less useful (if not useless) without timestamps, being the primary correlator with any other observable or discoverable information in the IT environment.

Consider a multi-processor system where the log server is in a different process than the processes which are performing logged activities.

If multiple loggable activities occur at roughly the same time, then whichever process' inter-process call to the log server is serviced first, will get the lower sequence number. Since logging often involves allocating memory for and marshaling string data, etc., often the "smaller" event makes it to the log first, or in some cases, the "better prepared" event- if a process that logs frequently leaves allocated buffers then it might be able to call the log server without delay, while another process is still marshaling log data, even though the logged activities occurred simultaneously.

It gets worse. Process prioritization might influence the order in which the kernel services the calls to the log server, as will the time that the logged activity and the call to the logging service happened within the quantum of execution.

So an activity that occurred at an earlier time on a lower-priority process, or an activity that occurred at an earlier time, but near the end of the execution quantum for the process raising the event, will frequently be logged sequentially after events raised by higher-priority processes.

To an external observer, log ordering on a busy multiprocessor server might appear essentially random.

A group here at Microsoft did some research recently into reliable ordering of events. I am currently unable to locate a published paper on this but I am still looking. If I find it I will forward the link. In short it is possible, even across multiple systems, to be able to reliably reconstruct order in limited cases but there are severe constraints on the scenarios. I can't go into more detail until I determine the IP status of the work.

Sequence information IS useful for gap detection and for a rough idea of ordering. I'm not sure that high-precision timestamping on logs is very useful except perhaps on single-processor machines with cooperative rather than pre-emptive multitasking OS, or on real-time OS.

I do think that adding a "collection timestamp" at a log collection server is very useful as this solves almost all the problems of timestamp normalization, and it doesn't make ordering any worse than it already is.

Eric

________________________________
From: loganalysis-bounces (at) loganalysis (dot) org [email concealed] [loganalysis-bounces (at) loganalysis (dot) org [email concealed]] On Behalf Of Rainer Gerhards [rgerhards (at) hq.adiscon (dot) com [email concealed]]
Sent: Tuesday, July 29, 2008 8:31 AM
To: bschnzl (at) cotse (dot) net [email concealed]
Cc: loganalysis (at) loganalysis (dot) org [email concealed]
Subject: RE: [logs] How to define Log, Event, and Alert?

<inline...>

On Fri, 2008-07-25 at 22:48 -0400, Bill Scherr IV wrote:
> Wow! Comments interlaced!
>
> Circa 11:23, 25 Jul 2008, a note, claiming source Rainer Gerhards <rgerhards (at) hq.adiscon (dot) com [email concealed]>, was sent to me:
>
> Subject: RE: [logs] How to define Log, Event, and Alert?
> Date sent: Fri, 25 Jul 2008 11:23:40 +0200
> From: "Rainer Gerhards" <rgerhards (at) hq.adiscon (dot) com [email concealed]>
> To: "Anton Chuvakin" <anton (at) chuvakin (dot) org [email concealed]>, <bschnzl (at) cotse (dot) net [email concealed]>
> Copies to: <loganalysis (at) loganalysis (dot) org [email concealed]>
>
> > If I may generalize things a bit...
> >
> > I'd replace TIME by "sequence identifier", with sequence identifier
> > defined as being something that is monotonically increasing. A timestamp
> > is an object that we think to be a natural example of a monotonically
> > increasing function. HOWEVER, if we look at existing technology, this is
> > not always the case. In fact, it is more often NOT the case than it
> > is... If we have two systems a and b and these systems do not have time
> > synchronized, and have a system c which is the event collector (and
> > collects only events from a and b), then c may record time stamps inside
> > its log that do not monotonically increase. For example, it may record:
> >
> > 02:00:00 event a1
> > 01:00:00 event b1
> > 02:01:00 event a2
> > 01:01:00 event b2
> >
> If we keep the original log intact, the out of sync timestamps are information in themselves.

My point was just in relation to that log. You even do not know - with
only the information you see - if the log is out of sync. For example,
some time zone may be improperly configured. As many devices do not
convey timezone info, you need to reset to metadata to do that. So in
short: the timestamp alone is insufficient.

>
> > Of course, this is still a TIMED record of occurrences. However, in this
> > sense this is used, "TIMED" includes a sense of temporal order (at least
> > to me). In the above log, we may not have the correct temporal order.
> > We may be able to reconstruct it by sorting on the timestamp. That would
> > be a valid approach if the timestamps are indeed correct (compared to
> > universal time). But if a and/or b has incorrect time, we would create a
> > wrong temporal order. Indeed, in this sense the monotonically increasing
> > identity of the log in question would actually not be the timestamp but
> > rather the *sequence of recording*, kind of a meta-property not directly
> > contained in the property set of the individual event record (but rather
> > obtained by its relationship to its predecessor in the log file).
> >
> If a file is deleted before it is created, then we locate the shift in timestamps. Different context has different meaning. For
> instance, a timestamp shift coincident with the file deletion says real badness, while a timeshift occuring an odd time before
> (3hrs, 24mins, 5 secs) may just indicate that an admin noticed that ntpd had died. Rather than try to sync the time in the
> logs, what can we do with variations? Automatically?

I am not talking about a shift in timestamp. I am talking about
insufficient resolution. The system I describe is working fine, but it
emits only second-resolution timestamps. For a file delete and file
create, you can not differentiate any sequence without resorting to
meta-information (like sequence of records inside the event log).

>
> > Now let's assume a log without a timestamp. These things happens, e.g.
> > in debug logs (and all too often in others I have seen).
> >
> > If we define
> >
> > > Log = a TIMED record of the above occurence.
> >
> > such a "log" would obviously not be a log, because it does not fulfill
> > the requirement to be timed.
> >
> > If a log instead is "a record of events with a sequence identifier",
> > that problem does not exist. The sequence identifier in that case would
> > be the derived property I mentioned above.
> >
> The sequence is the order in which it appears in the log, plus or minus network latency. (wait for it)

What happens if the logs were queued for some time at an interim system?
Again, you need to have the meta-information, just the timestamp is
insufficient.

>
> > The question remains if such a definition is actually useful. The
> > sequence identifier is obviously something with very vague semantics.
> > They depend on the observer as well as the correctness of the "sequence
> > identifier generating function" on all systems in question.
> >
> > Let's get back to the simple case of timestamps: as outlined above, the
> > semantics of timestamps depend on time sync. Even if there is ntp
> > timesync, timestamps (with reasonable precision) are always
> > questionable. They are approximate, even on the same system. With
> > standard syslog timestamps (second precision!) the problem is easy to
> > see: one may receive hundreds of events within the same second. So even
> > if time is correct, an observer is unable to detect any order of events.
> > If looking just at the timestamps, one must conclude that all events
> > happened at once. If looking at the semantics of the messages, one most
> > often also can conclude this is impossible (e.g. how to delete a file
> > before it is created?). Obviously, the timestamp alone is never
> > sufficient to detect order of events, even on a single system. Granted,
> > for practical purposes a high resolution timestamp (with good time
> > synchronization) is most often a sufficiently well approximation of the
> > time an event happened. But do you really trust it? ...always? Have a
> > look at your own correlation engines: do they work on pure timestamps -
> > or do they include some other properties, like the order of event log
> > records inside the log?
> >
> Why are you looking at logs? Is the machine broke? There should be plenty of context to render a correct determination. Is
> the machine compromised? Then you must find an independent log that says roughly the same thing.

Of course. But, and this is my point, you can not just rely on the
timestamp (as you say).

>
> > Now let me try to define what I think a log actually is:
> >
> > An EVENT is a set of properties that describe a state change (in the
> > sense I have described state change yesterday). The contents of this set
> > is depending on the entity who's state changes as well as on the
> > observer. [so it may actually be a set of two sets: entity-related
> > properties and observer-related properties]
> >
> > An event is generated when a state changes.
> >
> "when" being the temporal aspect, recorded from the view of the program sensing the state change.

I fully agree. IMO a "state change" is also a temporal aspect. I think
"state *change*" implies that something has *now* state y while it had
state x a (maybe very) short while ago. So I think there is always a
temporal component inside a state change.

<snip>

>
> > There is no inherent order inside event logs. In practice we experience
> > a "natural order" (one record begins before another), but that actually
> > is a meta-property of the event record. So we can order event records
> > based on their meta-properties. It just happens that a text log is
> > physically ordered by the sequence meta property.
> >
<snip>

> > >
> > > On Thu, Jul 24, 2008 at 7:23 PM, Bill Scherr IV <bschnzl (at) cotse (dot) net [email concealed]>
> > > wrote:
> > > > So...
> > > >
> > > > I gather a temporal mention to be appropriate beyond the definition
> > > of the Log. Also, most systems break off their logs by
> > > > size, not time. Although there is a definite time to each log, they
> > > are not consistent, even with the same log gatherer. Right or
> > > > wrong, that is how I find them. Suggestions below (if I may be so
> > > bold):
> > > >
> > > > Circa 11:26, 23 Jul 2008, a note, claiming source Heinbockel, Bill
> > > <heinbockel (at) mitre (dot) org [email concealed]>, was sent to me:
> > > >
> > > > From: "Heinbockel, Bill" <heinbockel (at) mitre (dot) org [email concealed]>
> > > > To: <loganalysis (at) loganalysis (dot) org [email concealed]>
> > > > Subject: [logs] How to define Log, Event, and Alert?
> > > >
> > > >>
> > > >>
> > > >> Here is our initial shot at defining these terms:
> > > >>
> > > >>
> > > >> Event:
> > > >> A discrete, distinct, and discernible state change in an
> > > >> environment.
> > > >
> > > > A discrete, distinct, and discernible state change in an environment
> > > at a recorded (or given) time.
> > > >>
<HTML dir=ltr><HEAD>
<STYLE>.EmailQuote {
PADDING-LEFT: 4pt; MARGIN-LEFT: 1pt; BORDER-LEFT: #800000 2px solid
}
</STYLE>

<STYLE title=owaParaStyle>P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY ocsi="x">
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2>Rainer,</FONT></DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2><FONT face=tahoma>I have really enjoyed reading your last few posts.  I would invite you to join the CEE working group.</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2><FONT face=tahoma></FONT></FONT> </DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2><FONT face=tahoma>Your discussion of state was very similar to a private one that I sent offline in CEE.  I think that from a developer standpoint, events are typically raised on internal state changes, but users of a system typically view it as a black box and don't focus on the state changes so much as the observable macroscopic occurrence, which might appear to have been a state change but might not appear to be so.</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2><FONT face=tahoma></FONT></FONT> </DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2><FONT face=tahoma>My working definition of "event" is:</FONT></FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>"An observable occurrence in an IT system."</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2>* observable - If we can't observe it, then we can't raise an event on it, so it's not interesting.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2>* occurrence - We raise an event about an instantaneous occurrence, not about something ongoing (the beginning, end, and perhaps state changes within a long duration process might be events).</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2>* IT system - This restricts the problem domain to computer science, seemed like a reasonable restriction at the time.  Perhaps there is a better term to restrict this to the realm of computers and software.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>For completeness, I define the following:</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2>Event record- a persistable data structure containing information about an event</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2>Event log- an ordered database of event records (typically but not always a sequential access file) [this also captures your and Bill's [Scherr] point about the temporal aspect of events, but does not restrict us to any specific technology]</FONT></DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2>Now a few comments regarding sequence:</FONT></DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Tahoma color=#000000 size=2>Sequence information in the log is also often insufficient for determining the actual order of events; I agree that it is better than timestamp for the reasons that you state but I also feel that most logs are significantly less useful (if not useless) without timestamps, being the primary correlator with any other observable or discoverable information in the IT environment.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>Consider a multi-processor system where the log server is in a different process than the processes which are performing logged activities.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>If multiple loggable activities occur at roughly the same time, then whichever process' inter-process call to the log server is serviced first, will get the lower sequence number.  Since logging often involves allocating memory for and marshaling string data, etc., often the "smaller" event makes it to the log first, or in some cases, the "better prepared" event- if a process that logs frequently leaves allocated buffers then it might be able to call the log server without delay, while another process is still marshaling log data, even though the logged activities occurred simultaneously.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>It gets worse.  Process prioritization might influence the order in which the kernel services the calls to the log server, as will the time that the logged activity and the call to the logging service happened within the quantum of execution.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>So an activity that occurred at an earlier time on a lower-priority process, or an activity that occurred at an earlier time, but near the end of the execution quantum for the process raising the event, will frequently be logged sequentially after events raised by higher-priority processes.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>To an external observer, log ordering on a busy multiprocessor server might appear essentially random.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV><FONT face=tahoma size=2>
<DIV dir=ltr><FONT face=tahoma size=2>A group here at Microsoft did some research recently into reliable ordering of events.  I am currently unable to locate a published paper on this but I am still looking.  If I find it I will forward the link.  In short it is possible, even across multiple systems, to be able to reliably reconstruct order in limited cases but there are severe constraints on the scenarios.  I can't go into more detail until I determine the IP status of the work.</FONT></DIV>
<P><FONT face=tahoma></FONT> </P>
<DIV dir=ltr>Sequence information IS useful for gap detection and for a rough idea of ordering.  I'm not sure that high-precision timestamping on logs is very useful except perhaps on single-processor machines with cooperative rather than pre-emptive multitasking OS, or on real-time OS.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>I do think that adding a "collection timestamp" at a log collection server is very useful as this solves almost all the problems of timestamp normalization, and it doesn't make ordering any worse than it already is.</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=tahoma size=2>Eric</FONT></DIV>
<DIV dir=ltr><FONT face=tahoma size=2></FONT> </DIV>
<DIV id=divRpF936612 style="DIRECTION: ltr">
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> loganalysis-bounces (at) loganalysis (dot) org [email concealed] [loganalysis-bounces (at) loganalysis (dot) org [email concealed]] On Behalf Of Rainer Gerhards [rgerhards (at) hq.adiscon (dot) com [email concealed]]<BR><B>Sent:</B> Tuesday, July 29, 2008 8:31 AM<BR><B>To:</B> bschnzl (at) cotse (dot) net [email concealed]<BR><B>Cc:</B> loganalysis (at) loganalysis (dot) org [email concealed]<BR><B>Subject:</B> RE: [logs] How to define Log, Event, and Alert?<BR></FONT><BR></DIV>
<DIV></DIV><FONT size=2>
<DIV class=PlainText><inline...><BR><BR>On Fri, 2008-07-25 at 22:48 -0400, Bill Scherr IV wrote:<BR>> Wow!   Comments interlaced!<BR>><BR>> Circa 11:23, 25 Jul 2008, a note, claiming source Rainer Gerhards <rgerhards (at) hq.adiscon (dot) com [email concealed]>, was sent to me:<BR>><BR>> Subject:          &nbs
p;   RE: [logs] How to define Log, Event, and Alert?<BR>> Date sent:            Fri, 25 Jul 2008 11:23:40 +0200<BR>> From:           &
nbsp;     "Rainer Gerhards" <rgerhards (at) hq.adiscon (dot) com [email concealed]><BR>> To:           &nb
sp;       "Anton Chuvakin" <anton (at) chuvakin (dot) org [email concealed]>, <bschnzl (at) cotse (dot) net [email concealed]><BR>> Copies to:            <loganalysis (at) loganalysis (dot) org [email concealed]><BR>><BR>> > If I may generalize things a bit...<BR>> ><BR>> > I'd replace TIME by "sequence identifier", with sequence identifier<BR>> > defined as being something that is monotonically increasing. A timestamp<BR>> > is an object that we think to be a natural example of a monotonically<BR>> > increasing function. HOWEVER, if we look at existing technology, this is<BR>> > not always the case. In fact, it is more often NOT the case than it<BR>> > is... If we have two systems a and b and these systems do not have time<BR>> > synchronized, and have a system c which is the event collector (and<BR>> > collects only events from a and b), then c may record time stamps inside<BR>> > its log that do not monotonically increase. For example, it may record:<BR>> ><BR>> > 02:00:00 event a1<BR>> > 01:00:00 event b1<BR>> > 02:01:00 event a2<BR>> > 01:01:00 event b2<BR>> ><BR>> If we keep the original log intact, the out of sync timestamps are information in themselves.<BR><BR>My point was just in relation to that log. You even do not know - with<BR>only the information you see - if the log is out of sync. For example,<BR>some time zone may be improperly configured. As many devices do not<BR>convey timezone info, you need to reset to metadata to do that. So in<BR>short: the timestamp alone is insufficient.<BR><BR>><BR>> > Of course, this is still a TIMED record of occurrences. However, in this<BR>> > sense this is used, "TIMED" includes a sense of temporal order (at least<BR>> > to me).  In the above log, we may not have the correct temporal order.<BR>> > We may be able to reconstruct it by sorting on the timestamp. That would<BR>> > be a valid approach if the timestamps are indeed correct (compared to<BR>> > universal time). But if a and/or b has incorrect time, we would create a<BR>> > wrong temporal order. Indeed, in this sense the monotonically increasing<BR>> > identity of the log in question would actually not be the timestamp but<BR>> > rather the *sequence of recording*, kind of a meta-property not directly<BR>> > contained in the property set of the individual event record (but rather<BR>> > obtained by its relationship to its predecessor in the log file).<BR>> ><BR>> If a file is deleted before it is created, then we locate the shift in timestamps.  Different context has different meaning.  For<BR>> instance, a timestamp shift coincident with the file deletion says real badness, while a timeshift occuring an odd time before<BR>> (3hrs, 24mins, 5 secs) may just indicate that an admin noticed that ntpd had died.  Rather than try to sync the time in the<BR>> logs, what can we do with variations? Automatically?<BR><BR>I am not talking about a shift in timestamp. I am talking about<BR>insufficient resolution. The system I describe is working fine, but it<BR>emits only second-resolution timestamps. For a file delete and file<BR>create, you can not differentiate any sequence without resorting to<BR>meta-information (like sequence of records inside the event log).<BR><BR>><BR>> > Now let's assume a log without a timestamp. These things happens, e.g.<BR>> > in debug logs (and all too often in others I have seen).<BR>> ><BR>> > If we define<BR>> ><BR>> > > Log = a TIMED record of the above occurence.<BR>> ><BR>> > such a "log" would obviously not be a log, because it does not fulfill<BR>> > the requirement to be timed.<BR>> ><BR>> > If a log instead is "a record of events with a sequence identifier",<BR>> > that problem does not exist. The sequence identifier in that case would<BR>> > be the derived property I mentioned above.<BR>> ><BR>> The sequence is the order in which it appears in the log, plus or minus network latency.  (wait for it)<BR><BR>What happens if the logs were queued for some time at an interim system?<BR>Again, you need to have the meta-information, just the timestamp is<BR>insufficient.<BR><BR>><BR>> > The question remains if such a definition is actually useful. The<BR>> > sequence identifier is obviously something with very vague semantics.<BR>> > They depend on the observer as well as the correctness of the "sequence<BR>> > identifier generating function" on all systems in question.<BR>> ><BR>> > Let's get back to the simple case of timestamps: as outlined above, the<BR>> > semantics of timestamps depend on time sync. Even if there is ntp<BR>> > timesync, timestamps (with reasonable precision) are always<BR>> > questionable. They are approximate, even on the same system. With<BR>> > standard syslog timestamps (second precision!) the problem is easy to<BR>> > see: one may receive hundreds of events within the same second. So even<BR>> > if time is correct, an observer is unable to detect any order of events.<BR>> > If looking just at the timestamps, one must conclude that all events<BR>> > happened at once. If looking at the semantics of the messages, one most<BR>> > often also can conclude this is impossible (e.g. how to delete a file<BR>> > before it is created?). Obviously, the timestamp alone is never<BR>> > sufficient to detect order of events, even on a single system. Granted,<BR>> > for practical purposes a high resolution timestamp (with good time<BR>> > synchronization) is most often a sufficiently well approximation of the<BR>> > time an event happened. But do you really trust it? ...always? Have a<BR>> > look at your own correlation engines: do they work on pure timestamps -<BR>> > or do they include some other properties, like the order of event log<BR>> > records inside the log?<BR>> ><BR>> Why are you looking at logs?  Is the machine broke?  There should be plenty of context to render a correct determination.  Is<BR>> the machine compromised?  Then you must find an independent log that says roughly the same thing.<BR><BR>Of course. But, and this is my point, you can not just rely on the<BR>timestamp (as you say).<BR><BR>><BR>> > Now let me try to define what I think a log actually is:<BR>> ><BR>> > An EVENT is a set of properties that describe a state change (in the<BR>> > sense I have described state change yesterday). The contents of this set<BR>> > is depending on the entity who's state changes as well as on the<BR>> > observer. [so it may actually be a set of two sets: entity-related<BR>> > properties and observer-related properties]<BR>> ><BR>> > An event is generated when a state changes.<BR>> ><BR>> "when" being the temporal aspect, recorded from the view of the program sensing the state change.<BR><BR>I fully agree. IMO a "state change" is also a temporal aspect. I think<BR>"state *change*" implies that something has *now* state y while it had<BR>state x a (maybe very) short while ago. So I think there is always a<BR>temporal component inside a state change.<BR><BR><snip></DIV>
<DIV class=PlainText><FONT face="times new roman"></FONT><BR>><BR>> > There is no inherent order inside event logs. In practice we experience<BR>> > a "natural order" (one record begins before another), but that actually<BR>> > is a meta-property of the event record. So we can order event records<BR>> > based on their meta-properties. It just happens that a text log is<BR>> > physically ordered by the sequence meta property.<BR>> ><BR></DIV>
<DIV class=PlainText><FONT face="times new roman"><snip></FONT><BR><BR>> > ><BR>> > > On Thu, Jul 24, 2008 at 7:23 PM, Bill Scherr IV <bschnzl (at) cotse (dot) net [email concealed]><BR>> > > wrote:<BR>> > > > So...<BR>> > > ><BR>> > > > I gather a temporal mention to be appropriate beyond the definition<BR>> > > of the Log.  Also, most systems break off their logs by<BR>> > > > size, not time.  Although there is a definite time to each log, they<BR>> > > are not consistent, even with the same log gatherer.  Right or<BR>> > > > wrong, that is how I find them.  Suggestions below (if I may be so<BR>> > > bold):<BR>> > > ><BR>> > > > Circa 11:26, 23 Jul 2008, a note, claiming source Heinbockel, Bill<BR>> > > <heinbockel (at) mitre (dot) org [email concealed]>, was sent to me:<BR>> > > ><BR>> > > > From:           &
nbsp;       "Heinbockel, Bill" <heinbockel (at) mitre (dot) org [email concealed]><BR>> > > > To:           &nb
sp;         <loganalysis (at) loganalysis (dot) org [email concealed]><BR>> > > > Subject:          &nbs
p;     [logs] How to define Log, Event, and Alert?<BR>> > > ><BR>> > > >><BR>> > > >><BR>> > > >> Here is our initial shot at defining these terms:<BR>> > > >><BR>> > > >><BR>> > > >> Event:<BR>> > > >>       A discrete, distinct, and discernible state change in an<BR>> > > >> environment.<BR>> > > ><BR>> > > > A discrete, distinct, and discernible state change in an environment<BR>> > > at a recorded (or given) time.<BR>> > > >><BR></DIV></FONT></BODY></HTML>
_______________________________________________
LogAnalysis mailing list
LogAnalysis (at) loganalysis (dot) org [email concealed]
http://www.loganalysis.org/mailman/listinfo/loganalysis

[ reply ]
RE: [logs] How to define Log, Event, and Alert? Jul 30 2008 09:56AM
Rainer Gerhards (rgerhards hq adiscon com)


 

Privacy Statement
Copyright 2010, SecurityFocus