It's three different servers running the same application (dev, test, prod). What I'm looking to do - and it does do by the way - is rotate the application log based on "Shutdown complete" showing in the logs. I just wanted to make sure I wasn't overlooking the "correct" way to do it
-----Original Message----- From: John P. Rouillard [mailto:[email protected]] Sent: Monday, March 25, 2013 1:39 PM To: Fontenot, Ward P. Cc: [email protected] Subject: Re: [Simple-evcorr-users] log / sec question In message <d1d7356b80a8f64c89977a9b0c496118025...@msgexsil1115.ent.wfb.bank.co rp>, [email protected] 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.
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ Own the Future-Intel® Level Up Game Demo Contest 2013 Rise to greatness in Intel's independent game demo contest. Compete for recognition, cash, and the chance to get your game on Steam. $5K grand prize plus 10 genre and skill prizes. Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d
_______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
