In message
<d1d7356b80a8f64c89977a9b0c496118025...@msgexsil1115.ent.wfb.bank.co
rp>, ward.p.fonte...@wellsfargo.com writes:
> I currently have three applications logging to the same log server -
> though the logs are in different locations for each, and I have a
> working configuration for one of the environments that I'd like to
> implement across all of them. Can I simply start three instances of
> sec with the configuration files specific to each application
> instance or is there a more correct way of doing this?
Am I correct in assuming you have three instances of the same
application logging to a single log server and the output for each
application is placed in a different log file?
If so you can certainly run three instances of SEC and change the
input option so each SEC instance is watching one log file.
Depending on your rules however you may be able to use just one
instance of SEC with three input arguments (one for each of the three
log files). This may be easier if you use the --nojointbuf option to
SEC as well.
However there are two issues with logging multiple instances of a
program into a single SEC instance.
1) lines from different program instances may trigger pair, threshold
and other correlation rules by accident.
2) conflicts in correlation descriptions or context names
Let's say you had a SingleWithThreshold rule set to trigger if more
that 4 "BADEVENT" lines were seen in the input in a minute.
Lets says that each of the three instances was emitting "BADEVENT"
lines at a rate of 2/minute. You would end up trigering your rule
despite each instance opetbrating acceptably. Now if your
SingleWithThreshold counted "<hostname> BADEVENT" lines[1] and each
instance ran on a separate host you would properly count 2
events/second for each of three different instances and you would not
trigger the rule.
[1] you would use a regexp to extract the hostname (or other instance
identifier) and put the hostname value in the description (desc)
of the SingleWithThrehold rule.
Similarly you can create/delete/check contexts that are missing the
instance information and end up looking at a context that was
extablished by a different instance.
If all you use are single, ignore etc statements that have only one
pattern and don't live for a period of time and don't use contexts you
should be ok regardless of how you wrote your rules. If you used pair,
*window*, *threshold* etc rules or use contexts and you didn't used
unique instance identifying info, I would go with running three SEC
processes.
If you set up your rules to handle multiple event streams, you can get
the advantages in monitoring (only one process to check) and setup
that comes with running one SEC process. You may find that one SEC
process is more efficient as well (fewer context switches, reduced
memory use ...) but running multiple processes can increase your
throughput if you have thousands of events/sec as SEC isn't threaded
so running multiple processes allows parallel processing of the event
streams.
Hopefully the above is useful to you.
Have a good day.
--
-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
_______________________________________________
Simple-evcorr-users mailing list
Simple-evcorr-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
