On Fri, Mar 29, 2013 at 1:02 PM, Kat uncommon...@gmail.com wrote:
Ok, I am thinking off the cuff here -- but was starting to wonder how
OSSEC could scale more easily to large infrastructures. One of the primary
issues is analysisd being single threaded. BUT -- since analysisd does not
trap the port - 1514 for anything - that is left up to remoted - then why
couldn't you run multiple versions of analysisd but have them tied to a
specific keys file somehow?
In otherwords, have a way to mark the client.keys file with a field that
perhaps had a 1,2,3 or 4 or something like that, and it would indicate which
analysisd instance you are going to talk to?
I guess I need to go look at the code to see who is doing the evaluation on
the client.keys for processing. I am guessing it is remoted, so maybe this
would not work too easily if that is the case.
The whole point here is to NOT try to make analysisd multi-threaded, but
instead have some way to decide how many daemons you want to run and which
one processes which clients.
Thoughts/comments??
-K
I kind of thought this would be the easiest way of bettering the
performance. I figured remoted would do some load balancing by sending
all logs from agent001 to analysisd1 and agent002 to analysisd2.
Either that or use something like amqp to queue the data. I think the
hardest part will be correlating data between analysisd processes.
--
---
You received this message because you are subscribed to the Google Groups
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an
email to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
---
You received this message because you are subscribed to the Google Groups
ossec-list group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ossec-list+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
