Thanks for the input Michael, I hadn't considered syslog-ng. On Monday, June 24, 2013 4:43:51 PM UTC-5, Michael Starks wrote: > > On 24.06.2013 11:37, Blake Johnson wrote: > > > I was hoping the OSSEC server would have a way to differentiate based > > on an agent property whether to apply the <logall> option. With > > logall > > enabled I understand that the full log messages will be retained in > > /var/ossec/logs/archives. I could then have the Splunk agent monitor > > that directory to address retention requirements. > > Understand that all logs are sent to the manager for analysis > regardless of whether the logall option is enabled. What logall does is > to retain those events rather than throwing away the ones that don't > escalate into alerts. This is by design, since the agent doesn't have > any concept of what rules exist on the manager and the manager needs all > events because it doesn't know what local rules will be written. > > If I am understanding you correctly, for profile one, I would have > something like syslog-ng read the archives.log and parse that using > logic you determine. Rewrite the message to be a standard syslog > message. Set the destination to be the Splunk server. This will send raw > logs. for profile two, configure ossec to send alerts with the client > syslog functionality to the Splunk server, or have the Splunk server > read the alerts.log directly. > > > Since <logall> is a global option, it appears I may be forced into a > > two manager architecture, where the agents are associated with a > > manager based on my retention needs. > > I would try to avoid this if I were you. All the data is already there > on one manager. Do the parsing and analysis there. >
-- --- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
