rdl on hold

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

rdl on hold

Vijay Lakshminarayanan
Jim,

I have temporarily put RDL on hold.  I am going to finally get my
hands dirty in plain LoGS before thinking of a solid RDL.

I'm going to write a complete set of rules/contexts/rulesets (I'll
explain my idea later), identify the patterns and abstract everything
out.

As I see it, we use only one file to describe the rules for a log
analysis.  And what I'd like is for our RDL to encompass that whole
file rather than just make rule description easy.  It must be able to
manipulate the ruleset, contexts and create other rules and a large
set of options to do stuff.  In short, a LoGS dialect.

Here is what I plan to write.  I will need a lot of help from your
side often.  I'll ask when I get stuck (after I start, that is).  I'm
no sysadmin and I don't know what kind of messages the kernel spits
out.  So I wrote a root-rule which reads a log-line and based on the
contents, creates a rule that scans for the regex that describes that
line.

Say the line is:

Jun  1 02:08:02 balrog kernel: [4294667.296000] BIOS-provided physical RAM map:

The regexp generated would be: "\\[\\d+\\.\\d\\] BIOS-provided physical RAM map"
I ignore the first few words until "kernel:" because I alreayd know
that all lines start with that and I ignore anything withing
parens/brackets/braces

With that regexp, I'd create a new rule which scans for this line,
saves the matched message into a context (this new context is also
created) and this rule has (:continuep 'NIL)

As a better example for the regexp/rule generator would be:

Jun  1 02:08:02 balrog kernel: [4294667.296000]  BIOS-e820:
000000003f7d3800 - 0000000040000000 (reserved)

\[\d+\.\d\]  BIOS-e\d+: \d+f\d+d\d+ - \d+ \([a-z]+\)

All numbers change to \d+ and all values within parens are generalized
and escaped.

After doing this whole thing for some time, the idea is that I dump
the rules and contexts out to one or many files (I haven't decided).

All this is just an idea I've had.  I think this can be quite easily
done with LoGS.  I know it has several flaws like similar messages
will probably end up in different contexts and so will messages that
are actually related and should be in a context together.  However, I
believe it does have its uses in finding a class of messages to later
look for in a log file or give me an idea.

Any thoughts?  Suggestions?  Comments?  I'll keep updating you with
how things go.

Thanks Jim
Vijay


_______________________________________________
LoGS-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/logs-devel