DX Infrastructure Manager

Expand all | Collapse all

Nimsoft Scripting Agent (NSA) is no longer being developed!

  • 1.  Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 10-14-2013 03:38 PM

    Hi Lua fans,

     

    as far as I know from the Nimsoft support the Nimsoft Scripting Agent is no longer being developed.

     

    All existing Lua probes will never support the Nimsoft TNT2 database structure.

    Therefore no QoS metrics or alarm-messages were linked in the USM properly.

     

    I create an idea: https://na4.salesforce.com/ideas/viewIdea.apexp?id=08760000000CiM2

     

    Please vote for it.

     

    Thanks



  • 2.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 10-14-2013 04:59 PM

    It seems to have escaped the attention of product management just how much Lua code is created & used by Nimsoft users. I see way more Lua on the forum than any other language. It is by far the simplest SDK to get started with on Windows.



  • 3.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 04-22-2014 06:40 PM
    What?!
    We do so much with Lua, I'd hate to lose it!!!


  • 4.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 04-22-2014 06:57 PM

    Just spotted this posted by one of the Nimsoft product managers under the idea (link above) within the past month:

     

    The future of probe architecture, starting with NMS 6.5, is based off a new and extensible probe framework and topology description language.  Probes available in the admin console are either natively coded to this new architecture, or are adapted to be compatible.  The strategy for multiple per-language SDKs is not the future direction for Nimsoft - there will be new tools and interfaces for probe development.  It's understood that many customers and developers have created many custom probes for Nimsoft via the various existing SDKs (including NSA/LUA).   For existing probes, built with existing SDKs, conversion and/or compatability capablities are currently under review

     

    Sounds a bit scary, not only for Lua. I was thinking maybe I should start coding more Perl again rather than Lua, but I guess even the Perl SDK is going away in its current form. I am a bit puzzled about what is replacing the SDKs. Hopefully it will be easy to use with scripting languages, although recent events with the snmptoolkit and snmpcollector make me nervous.



  • 5.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 04-22-2014 09:47 PM

    I was trying to think what this architecture could be.. and at the same time I've been worried about the amount of new Java-based probes.. so I hope it's not going to be something "Java only" kind of stuff..

     

    -jon



  • 6.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 04-22-2014 10:08 PM

    Oh, I guess I missed the part about description language.. doesn't make it sound much better, though.



  • 7.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 05-08-2014 05:24 PM

    Sad!

     

    Do not have a good feeling 'bout that, bye bye simple probedevelopment, "descriptive" could be nearly everything.

     



  • 8.  Re: Nimsoft Scripting Agent (NSA) is no longer being developed!

    Posted 05-08-2014 10:07 PM

    It sounds like it might be a good thing in theory, but it makes me think of web services. Web services are great and make a lot of sense in many situations, but they can add a lot of complexity compared to a native API/SDK for a given language. They are often still appealing because they can be used with many languages without having to mantain lots of SDKs. But work in each individual language is often more painful. There is a lot of support for web services out there, but often that support requires additional libraries and such. Then when you are working with something like Lua inside the NAS, which is not quite the same as native Lua, adding libraries might not work. (This is the most concrete example I have of how web services can be a bit of a wall. If we want our NAS to open tickets in a system that only offers a web service API, I doubt we could do that easily.)