Open for Voting
over 1 year ago

Replace NPM Syslog & Trap system with Kiwi Syslog

For many years now the Sylsog and Trap system have been due to an overhaul.  At this point they are nothing more than an ugly scar on NPM which is an otherwise fantastic product.  Years ago SolarWinds squired Kiwi Syslog Server which handles both Sylsogs and Traps and is also a fantastic product.

I think the Syslog & Trap system that are currently in NPM should be permanently removed and replaced by Kiwi.  SolarWinds should just provide a free copy of Kiwi with every polling engine.  Of course then it would make sense to provide some out-of-the-box integration between Kiwi and NPM.

It seems to me this is a much easier way to solve the legacy Syslog and Trap system issue in NPM versus completely rebuilding it; no need to reinvent the wheel when you already have a perfectly good wheel!

  • I have two Kiwi server and 4 orion npm pollers.

      All syslogs and traps go to one of the kiwi servers then:

       A. all syslogs and traps are saved to a file for each node on the kiwi server. so we have a record of all syslogs and traps

       B. then if the syslog or trap matches a rule (is an major issue) it is forwarded to the orion system.

       Then at the Orion NPM server

          A. will use its rules to Tag the syslog or trap for a type(power, link, fault).

          B. if the syslog or trap is something that needs to have an alert it will run a script that will set or remove an alertcode in the custom property (alertcode) for the node.

                   The alertcode is in the format of XXXX:T

                          where XXXX is a code for the event. i.e. A000,A001

                              and :T  will be a time to live for this event. i.e. A001:10

                          So some events will have a code like A000 (this event will not have a time to live )

                            and some will have a code like A000:60 (this event will have a time to live of 60min )

                          And you can have more then one code by using a ,  i.e A000:33,A001:67

           C. The Orion system can set an Alert for the node by looking to see if the custom property (alertcode) contains the alertcode for this alert.

           D. And there is an alert in the orion system that will look for a , in the alertcode, and then run a script to do a down count of all codes that have a time to live.

    So with this set up I have:

       1. a log of all traps and syslog from a device.

       2. all syslogs and traps of significant are sent to the orion system so they can be seen on the orion web page.

       3. syslogs and traps that are critical can trigger a orion alert via the alertcode.

       4. if the alertcode has no time to live. it will be active unto it is cleared  by someone or a trap or syslog clears it.

       5. if the alertcode has a time to live the alert will be active unto the time to live expires, but each now trap or syslog for this event will reset the time to live.


    Here is what I would like to see.

    Have an action added to the kiwi syslog server to "Log to the orion Database".

    This way I could have some of the traps and syslogs be displayed in the orion system just like I have it now.

    And all the rules could be on the kiwi system, some traps and syslog would be just logged to a file, some would be displayed in orion and some would generate an orion alert ( via a script run on the kiwi server to set the alertcode.

    This would remove the syslog and trap load from the orion servers.

    I would only have one set of rules for syslogs and traps, where I have two sets now.


    And I think Solarwinds could easily do this by making this new action to Kiwi Syslog server.

  • Hi

    is it possible to see the part of the script that update Orion?

Comment Children
No Data