On Tue, 2 Oct 2012, Joseph Guanzon wrote: > Hi David, > > Thanks very much for your response, do you know a good way to formulate > the required resources for a monitoring server that can handle a large > amount of server, polling server (network, CPU, memory, disk space, > logs, processes, etc).
sorry, I don't have a good rule of thumb to use for sizing. network: enough to handle logs without dropping them disk space: SEC doesn't need any > Also if I understand you correctly the number of > rules made would affect the memory use while the difficulty of the rules > may affect the cpu? not quite the more state you track, the more memory you need. That said, you can probably store a million pieces of state in a gig of memory, so it's not likely to be your limiting factor. the more complex your ruleset, the more CPU you need. This includes more rules, and more complex rules. Maintaining state costs CPU (especially state that will time out) David Lang > > > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > Sent: Tuesday, October 02, 2012 5:02 PM > To: Joseph Guanzon > Cc: [email protected] > Subject: Re: [Simple-evcorr-users] SEC system requirements and limitations on > servers and alerts > > On Tue, 2 Oct 2012, Joseph Guanzon wrote: > >> Is there known system requirement when using SEC to monitor large >> quantity of servers like how many cpu/memory would be needed for 300 >> to >> 500 servers and or 500 to 1000 servers monitored? > > The number of servers doesn't matter. > > What matters is the number of log messages, and how complex your ruleset is. > > the more state your rulesets keep (in contexts, thresholds, windows, etc), > the more memory they will need. However, overall it's surprisingly light on > memory requirements. When you consider how much space a Gig of memory > actually is, keeping track os these things really doesn't hurt much. > > CPU is eaten up by evaluating rules. > > The more rules that need to be evaluated before the log is processed, the > more CPU you need > > regex matches can be expensive, the more complex your regex, the more > expensive it will be. > > some types of matches are more expensive than alerts > > alert after X messages in Y seconds is more expensive than alert when you see > message Z > > > > All of this makes it really hard to say how much system you need to > process messages from X servers.. > > >> Can SEC be able to summarize log file alerts like instead of showing the >> 100 alerts it would state that there have been a 100 counts for this >> certain alert received. > > Yes, you can do this sort of thing. > > David Lang > Please consider the environment before printing this email. > > Visit our website at http://www.nyse.com > > **************************************************** > > Note: The information contained in this message and any attachment to it is > privileged, confidential and protected from disclosure. If the reader of > this message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify the sender immediately by replying to > the message, and please delete it from your system. Thank you. NYSE > Euronext. > > ------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev _______________________________________________ Simple-evcorr-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
