On Thu, Dec 02, 2010 at 04:24:13PM +0100, Rainer Gerhards wrote: > sorry, I need to be a bit brief as I have a conference call upcoming later > today for which I need to prepare -- and I hope to fix some more thing. So > the most important facts first, more later (maybe monday...).
No problem.
> > I already have been spreading the word. Strangely, I mentioned
> > it to the OSSEC guys, and they didn't seem that interested in it.
> > That might change over time. I've talked about it on the Sagan mailing
> > list and people there seem to "get it".
>
> I think many people still think "we can normalize in any case, just let's use
> our regex approach". A very important point is speed. I will be very
> interested in practical rsyslog performance with that parser. But I think we
> can outperform most other normalizers by magnitudes.
Agreed. Regex isn't a practical approach for these types of
things. Speed is a must, and i agree. It'll probably out preform
other normalizers by quite a bit.
> > This is my dilemma.
>
> It is! And I am well aware of it. In rsyslog, I have the same issue. I think
> of something like a "common prefix" inside the sample db (maybe rulebase is a
> better name, btw :)). That would be common to all rules, and only the common
> prefix would need to be changed for different headers. It's not 100% sorted
> out, there is still enough work to do on the core engine (needs more parsers,
> parser priority, str optimizations).
That makes sense, if I understand correctly. Basically some
way you can "tell" the library, Ie - "I only have the 'message'
portion, so apply the rule base to it, but only using the 'message'
portion of the rule"? That sort of thing?
> rsyslog v6 will need libestr and libee in any case. There is also a volunteer
> who will package that. I try to keep dependencies as low as possible, but the
> alternative would be to copy the same code into different projects. I don't
> like that. I hope those folks who build packages will tie the right things
> together (and I am *very* grateful for their excellent work!).
Okay. That'd be great. Like you, I'm not a fan of adding to
many dependencies.
>
> > Oh.. on more thing. Do you think it's to early to start
> > writing liblognorm rules?
>
> Depends... You will probably want to revisit the rules in a few weeks, when
> we have more capabilities. But on the other hand, I need some experience with
> building them, so that I know what does not work out. The current parsers are
> extremely limited and some (word, char-to) are very generic. But if that
> works, it will continue to work with new version. Wehn the classifier is
> there (hopefully december), you will probably want to add classification tags
> for easy filtering (if that matters for Sagan).
Okay.. I understand. One more question, and this is more of a
future support sort of thing. I'm only asking because I'm wondering if
this was brought up with the CEE dictionary thing. You have things
like %ip:ipv4% and %port:number% . Do you have any idea if there will
eventually be something like a %ip:%ipv4:src% or %ip:ipv4:dst% type of
flags (same idea applying to %port:number%)? This might be useful,
for not only normalization, but XML and JSON output.
--
Champ Clark III | Softwink, Inc | 800-538-9357 x 101
http://www.softwink.com
GPG Key ID: 58A2A58F
Key fingerprint = 7734 2A1C 007D 581E BDF7 6AD5 0F1F 655F 58A2 A58F
If it wasn't for C, we'd be using BASI, PASAL and OBOL.
pgpyrtSI1zBFm.pgp
Description: PGP signature
_______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
