audit-viewer performance

LC Bruzenak lenny at magitekltd.com
Sat Dec 19 18:20:20 UTC 2009


On Sat, Dec 19, 2009 at 7:34 AM, Steve Grubb <sgrubb at redhat.com> wrote:
> On Friday 18 December 2009 08:42:51 pm LC Bruzenak wrote:
>> What is the plan for this tool? As I said, I think it is very nice
>> feature-wise in general but in practice it isn't living up to
>> expectations.
>> I can try to help but will take a while to get python-proficient. Or
>> is the trouble in the parse library?
>
> The audit parsing library has not been optimized for handling large data sets.
> I don't think its the entire problem you are seeing, but I'm sure its a
> contributor to the problem. I was planning to look at performance issues in a
> future release.

I should be able to help out testing, debugging, etc. since we really
use the aggregation capability on high-volume systems and therefore
have a big data store to use in testing.

> But you could test the native C library against the python version to see if
> python itself is adding delay.

I'll try to take a look at this.

I was thinking that it seems to me a relational DB would be a help on
this point. Rather than parsing the entire log structure every time,
perhaps the audit-viewer could just query for the desired data and try
to leverage the DB's optimization.
But I guess if you went to such a big change there you might also
consider making it network-capable similar in form and function to the
prewikka viewer. This one handles large amounts of data pretty well.

>
> -Steve
>
> PS - I keep a TODO file up to date that will always let you know what the
> immediate plans are: https://fedorahosted.org/audit/browser/trunk/TODO
>

Very good. Thanks Steve, and Happy Holidays!

LCB.


-- 
LC (Lenny) Bruzenak




More information about the Linux-audit mailing list