5 Replies Latest reply on Dec 4, 2009 2:33 PM by byrona

    Syslog Processing & Potential Load Balancing


      I have been thinking about the possibility of load balancing my syslogs between my primary NPM poller and my secondary polling engine.  By doing this if either one of those systems had to fail back to my hot-standby system all of the log would be automatically re-directed to the still functioning polling system.

      I realize to do this I would need to turn on the syslog function on the secondary poller.  Aside from that, what other things would I have to do in order to get this to work?  Has anybody else done this before?

      Also, are the syslog alerting rules stored and processed on the system that receives them?  In this case would I need to replicate all of my alerting and escalation rues for syslog on both systems?

      I would really like to hear from somebody to find out if and how this may be possible, thanks in advance for any help on this!

      Summary of my Questions:

      • Has this been done before and is it possible?
      • Where are the syslog alerting and escalation rules stored and processed?
        • Would I need to replicate these rules on both systems receiving syslogs?
      • Also, if this is possible with syslogs would this same concept also be possible for snmp traps?
        • Re: Syslog Processing & Potential Load Balancing

          Just wanted to post back, we are not ignoring you, we have the Dev team checking into this to ensure we provide you the proper answer.  Stayed tuned for a more complete response

          • Re: Syslog Processing & Potential Load Balancing

            Syslog rules are stored in the database. All polling engines (including hot-standby) will get the same set of rules from the database. Trap rules work the same way. Since all polling engines will be accessing the same database, there is no need for you to take any extra steps to replicate this configuration.

            So I think what you would need to do is set up something that can be the target of syslog and traps from all your devices and forward incoming syslog/traps on to the regular polling engine and the hot-standby. Orion can do this, but you may not want to set up a whole extra Orion instance just for this purpose. Our Kiwi Syslog Server product can do this for free for syslog messages. There's probably something out there lighter than Orion that can do it for traps, but I don't know of anything off the top of my head.

            1 of 1 people found this helpful