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

[Support Technischer Verteiler]

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

[Anon Anon]

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.

[Anon Anon]

What?!
We do so much with Lua, I'd hate to lose it!!!

[Anon Anon]

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.

[Anon Anon]

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

[Anon Anon]

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

[Matthias Gruber]

Sad!

 

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

 

[Anon Anon]

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.)