[emstar-design] Adding logfile snapshot feature

[Lewis Girod]

On 8/5/05, Karen Weeks <karenyc at lecs.cs.ucla.edu> wrote:
> 
> So just to summarise what I think the consensus seems to be here...
> 
> I think the idea of having a new EmStar process which gets launched at
> statup sounds like the right idea.  This process can then be activated and
> deactivated via the web interface.  While the process is active, it logs
> the contents of selected log files.  When the process is deactivated, it
> closes the files, tars and zips them for later perusal by the user.

yes, i think this was the consensus. 

> A secondary request is to have some way to record 'events of interest'
> into a seperate file.  Nithya and I had discussed this a little as
> something we were interested in being able to implement.  We were looking
> at it as more of a list of alerts - whenever some event which we denoted
> as important occurred, it would be logged into a special file (which
> doesn't currently exist ;-)).  Events which may be considered important
> could be:
> - Sympathy detects a node is no longer in the network
> - Sympathy detects a new node has been added to the network
> - An EmStar process crashed
> 
> And I am sure there could be others added too.
>
> The contents of this file could be displayed in a very obvious way on the
> web interface, so the user could be made aware of interesting network
> events.

one trivial way to log these kinds of events (separate from the
sometimes noisy and arcane emlogs) is to just run "simple_logring"..
an example program in libdev, passing it a name like /dev/emlog/alerts

if you write something to that file, it will be appended to the log;
if you cat the log you'll see all the events.  different components
can all write to this log and the writes will be interleaved (as whole
writes).

a slicker solution would be to add this extra code to emrun and have a
command mechanism that took in an alert message, added the process
name and date stamp, and piped it into the log.

in either case you can display the contents of the event log as you
would any other, snapshot it via this proposed new logdumper module,
etc.

info on processes that crashed is already available from /dev/emrun/last_msg

> 
> Does thar sound fair to everyone?
> 
> Karen
> 
> >> so these were extracted from the emlog logs or from specialized
> >> devices (or written to regular files?).
> >>
> >> when you mentioned state changes it occurred to me that sometimes it's
> >> easier to just create an extra status device (or for that matter a log
> >> device) to log specific subsets of the info like state changes.  this
> >> can make it easier to extract more specific info.  you can also create
> >> a separate process hosting a log device  that allows multiple apps to
> >> write to an event log.  this is pretty easy to do.. it would make a
> >> good sample program
> >>
> >> of course, when you don't know what you're looking for or didn't plan
> >> ahead this way, the regular logs sometimes are the only option.  but
> >> this log snapshot mechanism we're thinking about could easily collect
> >> info from any set of devices, log or otherwise.
> >
> > These were extracted from the emlog logs. Extracting a subset of info
> > from the log into a state device is a good idea.
> >
> >> actually, this is very new... it has only been implemented in the last
> >> few weeks.. so you don't need to feel bad :)
> > Oh, then I mistakened it for another protocol. Now I feel better :-)
> >
> > - Vinayak
> >
> > _______________________________________________
> > emstar-design mailing list
> > emstar-design at cens.ucla.edu
> > http://www.cens.ucla.edu/mailman/listinfo/emstar-design
> >
>