<br>Thanks much J.C for detail information.<div id="yMail_cursorElementTracker_0.6115123966058416"><br></div><div id="yMail_cursorElementTracker_0.6115123966058416"><br><div id="ymail_android_signature"><a href="https://overview.mail.yahoo.com/mobile/?.src=Android">Sent from Yahoo Mail on Android</a></div> <br> <blockquote style="margin: 0 0 20px 0;"> <header style="font-family:Roboto, sans-serif; color:#6D00F6;"> <div>On Wed, Apr 6, 2016 at 16:04, J.C. Cleaver</div><div><cleaver@terabithia.org> wrote:</div> </header> <div style="padding: 10px 0 0 20px; margin: 10px 0 0 0; border-left: 1px solid #6D00F6;"> <div id="msgSandbox_ALjkimIAAC1cVwWH2BQCYWFs4uug_TEXT" class="msgSandbox" style="padding: 1.5em 0.5em 0.5em 1.2em; word-wrap: break-word;"><br clear="none"><div class="yQTDBase yqt0354504414" id="yqtfd01006"><br clear="none">On Tue, April 5, 2016 10:59 am, eli wrote:<br clear="none">> I am planning to build secondary xymon server as backup, is there good<br clear="none">> method to sync between them and not both of them not to send alert same<br clear="none">> time. if any one implement already I would like to hear feedback.<br clear="none">> thanks,Eli</div><br clear="none"><br clear="none">There are a few different strategies one can use here, all depending on<br clear="none">what kind of internal SLA you're expecting, how much bandwidth you're able<br clear="none">to use, and whether you need identical systems or not.<br clear="none"><br clear="none"><br clear="none">The simplest solution (but most bandwidth intensive) is to run the two<br clear="none">servers as stacks in parallel and simply not alert on the secondary one.<br clear="none">You can use Linux-HA or any of the more advanced cluster software to<br clear="none">determine up/down status between the two boxes and take over when the<br clear="none">other isn't reachable. You can configure your clients to send reports to<br clear="none">both xymon servers at the same time ($XYMONSERVERS) and you've in effect<br clear="none">got two complete systems. (xymond_distribute can be used to pass<br clear="none">disable/enable messages over). The drawback is a) double the bandwidth<br clear="none">use, and b) losing your acknowledgements and alert suppression when the<br clear="none">failover occurs.<br clear="none"><br clear="none">Alternatively, you can keep the second server on a cold standby, regularly<br clear="none">getting rsync's from the primary one of the checkpoint files for both<br clear="none">xymond and xymond_alert. This has the advantage of the secondary system<br clear="none">not being in use when it doesn't need to be. When failover happens, you<br clear="none">start up xymond on the slave, it reads from the last checkpoint you'd<br clear="none">gotten (I'd advise increasing frequency to something like every few mins,<br clear="none">depending on your needs) and starts from there. The drawback there is that<br clear="none">you don't have graphing/history at all, and you're missing the last few<br clear="none">minutes of changes.<br clear="none"><br clear="none">If you have heavy network bw available to you, things like DRBD can be<br clear="none">used to perform a complete synchronization of *saved* data between the<br clear="none">servers.<br clear="none"><br clear="none"><br clear="none">Henrik had proposed a Xymon Swarm concept at<br clear="none"><a shape="rect" href="http://lists.xymon.com/pipermail/xymon/2015-November/042684.html " target="_blank">http://lists.xymon.com/pipermail/xymon/2015-November/042684.html </a>, which<br clear="none">may also help you evaluate your site's needs.<br clear="none"><br clear="none"><br clear="none">Really, there are lots of different ways to conceptualize "high<br clear="none">availability" for your monitoring system... I'd advise to keep things as<br clear="none">simple as possible so as to eliminate failure points. In our case, we've<br clear="none">had two live stacks running in parallel that (mostly) submit into a ticket<br clear="none">system, which can de-dupe incoming host+svc alerts automatically, which<br clear="none">mostly defines the problem out of existence. The things directly emailed<br clear="none">to us were of lower frequency, so we were fine with duplicate emails at<br clear="none">first. When that got to be too annoying, we left xymond_alert enabled on<br clear="none">the second system but used Linux-HA to simply disable Postfix when it<br clear="none">wasn't master. When a failover occurred, the startup script was modified<br clear="none">to clear out the local outbound queue before starting the service up.<br clear="none">Xymon thus never had to care about whether it was primary/secondary at<br clear="none">all.<br clear="none"><br clear="none"><br clear="none">Hope that helps a little bit.<br clear="none"><br clear="none"><br clear="none">Regards,<br clear="none">-jc<div class="yQTDBase yqt0354504414" id="yqtfd42729"><br clear="none"><br clear="none"></div></div> </div> </blockquote></div>