rgerhards at hq
Dec 3, 2011, 6:33 AM
Post #2 of 3
(170 views)
Permalink
|
|
Re: calling DBAs. need help replicating 'journal feature'
[In reply to]
|
|
> -----Original Message-----
> From: rsyslog-bounces [at] lists [mailto:rsyslog-
> bounces [at] lists] On Behalf Of david [at] lang
> Sent: Saturday, December 03, 2011 8:47 AM
> To: rsyslog-users
> Subject: [rsyslog] calling DBAs. need help replicating 'journal
> feature'
>
> On Fri, 2 Dec 2011, Rainer Gerhards wrote:
>
> >> From: rsyslog-bounces [at] lists [mailto:rsyslog-
> >> bounces [at] lists] On Behalf Of david [at] lang
> >
> > However, from the discussion I have learned that folks seem to find
> > log-hash-chaining useful, albeit it's limited security. Thus I have
> begun to
> > write a tool that handles this. It's an experiment outside of
> rsyslog, but
> > could be moved into omfile once it is sufficient mature. In the mean
> time
> > omprog can be used to call the tool directly. I'd like to mature it
> to a
> > point where it is cryptographically sound. I have a working hash
> > writer/verifier in my lab, but so far without append mode. I think
> I'll focus
> > on this work first.
>
> One other thing that would be useful, but requires DBA database SQL
> skills, would be to define the appropriate stored procedures, schema,
> etc
> to do the 'compression' (i.e. normalization) that the journal is
> claiming.
>
> basically, rsyslog should invoke the SQL command
> normalized_insert("$timestamp","$hostname","$fromhost-
> ip","$programname","$msg")
> and the database stored procedure should do the lookkup/addition work
> needed to replace hostname, fromhost-ip, programname with an int value
> (to
> be extended to additional values as we get trusted properties, etc in
> place)
>
> I'm enough of a DBA to modify a working example to extend it to more
> fields, and to know that this is doable, but implementing it would take
> a
> significant amount of time for me and I strongly suspect that a good
> DBA
> could make this pretty trivial
>
> ideally the command would be able to take multiple sets of log entries
> as
> a single transaction, but that's a further optimization after we get a
> single one added.
Just as a side-note I would suggest to have a look at systems like MongoDB.
That's on my todo list and it seems to have quite some potential for log
files, especially if enriched by structured data (or CEE).
Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
|
