[cl-ppcre-devel] Byte vectors instead of strings

[Jim Prewett]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> I'm responsible for all of the network management systems for a VoIP
> telecom company.  Part of our architecture is the real-time monitoring
> of various logs such as the syslog messages generated by about 1000+
> Cisco devices as well as various application log files.  Currently, I
> use my own Python software called LogWrap[1] for this purpose.  Another
> part of our architecture is the post processing of log files for trend
> analysis, intrusion detection analysis, etc ...  This analysis is done
> with a whole bunch of Python scripts.

sounds familular ;)

I'm a sys-admin for several HPC (cluster) systems... 

> Over the past year, I've been learning CL in my free time and have been
> trying to slowly introduce CL at work in both of the above areas.  My
> first attempt was to write some of the post processing tools in CL
> because I thought that CL coupled with cl-ppcre would be much faster
> than my existing Python tools.  This was not the case because the
> open-source CL implementations were slow due to the IO processing.  Now
> I am now trying to use byte vectors with cl-ppcre to see if this will
> significantly speed up the processing.

hmmm... I thought the IO was a little on the slow side too :)

However, I found that most of my competition (SEC, Logsurfer, SWATCH, etc) 
have some pretty silly (and inefficient) notions built in like "flat" 
rulesets... Lisp is, IMO, part of the reason I was able to take advantage 
of better ideas to get more speed (not that a tree shaped structure is 
profound :)

> I'm reading about it now and it sounds very interesting and familiar as
> my Python LogWrap does some of the same, rules, actions, suppression,
> generic handlers, etc.  Its time for me to go to bed now, but I will
> read more about this tomorrow as it may help me with the real-time part
> of my architecture.  I was going to write LogWrap in Lisp, but it sounds
> like you've saved me the trouble. 

Well, I've done at least some of the work; I'm always interested in 
collaborators too :)

LoGS is my project to teach myself some Common Lisp.  We chose lisp 
because we felt s-expressions would be a good way to express rules that 
write rules ... that write rules; that was my original turn-off from 
Logsurfer (yes, you can do it, but after about 4 levels deep, the escaping 
is too much of a nightmare! :)  s-expressions are free with Lisp :)

> Perhaps, but it seems at first glance that LoGS has everything I need.

Wow!  Really?  ;)

> After I go through the documentation more thoroughly, I'll be able to

Oh, my apoligies for the current state of the documentation :)  I think 
its /mostly/ accurate although a little lacking :)  I'm hoping to do some 
serious documentation fix-ups for 0.1.0 (which should be coming out 
shortly after 0.0.4, which I'm hoping to release very very soon!  Maybe 
late August for 0.1.0?)

Anyway, please feel free to shoot me any questions!  there's also a 
mailing list, but the membership is quite small.

> determine if there are any missing pieces of functionality I might want
> to add and contribute if wanted.

oh yeah, definantly!  I'm very happy to accept patches (as long as I can 
see them being remotely useful).  

If you dig LoGS, maybe you could share some of your rulesets with me?

I think CL & Log analysis are a (surprisingly?) good match!  I'm also very 
interested in exploring what is possible with log analysis; I'm not very 
happy with any of the available tools, including LoGS, LoGS is just the 
best thing going (IMO).

Anyway, I'd love to add you to my (mental) short list of users... I think 
I've got 7-ish right now (including myself :)

> [1] http://www.kazmier.com/computer/logwrap

I'll check that out!  thanks!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQFC2zIOv/zdxjGBbZMRAsiBAKCX80mksWIYijx3zgykCXrlN2O76gCffQDc
CPwFWSpI3lc43MOfb9d0ZrA=
=pQEa
-----END PGP SIGNATURE-----