On 03/25/2013 11:30 PM, ward.p.fonte...@wellsfargo.com wrote: > 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 >
...are you actually looking for a way to trigger the input log rotation from SEC? kind regards, risto > -----Original Message----- > From: John P. Rouillard [mailto:rou...@cs.umb.edu] > Sent: Monday, March 25, 2013 1:39 PM > To: Fontenot, Ward P. > Cc: simple-evcorr-users@lists.sourceforge.net > Subject: Re: [Simple-evcorr-users] log / sec question > > > 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. > > > > ------------------------------------------------------------------------------ > 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 > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users ------------------------------------------------------------------------------ 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 Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
