We're looking to perform REST API calls via a LUA script in the NAS using JSON objects.
In fact this has been singled out as a critical piece of work within the solution being implemented...
Has anyone in the community attempted to do this before?
I wanted to ask before I embark on this potentially complicated solution
Currently we're looking at installing OpenSSL and utilising LuaSocket, LuaSec and json.lua libraries...
This will allow UIM to potentially integrate with any other tool with a REST API.
Any advice welcome.
We attempted to do this and ended up abandoning the solution because nas and the implementation of lua is single threaded. So things in a busy environment can get bottle necked here and processing of alarms takes a hit since it has to wait for the thread as a whole to complete one at a time. I imagine it would take a heft rewrite of nas and how it implements scripting in order to correct this issue. We ended up with a in-house written application to handle integration and data enrichment of alarm data in UIM and outside sources for ticketing, CMDB, etc that processes in real-time. There is an alternative to nas scripting and that is EMS in UIM...depending on what you are trying to do you may run into the same issues as nas cause EMS is also single threaded I believe and more importantly does not have true fail-over capability last time I worked with the team that developed it.
Thank you for your reply juniorbink.
Initially we are only planning on using this mechanism to forward events to a MOM. I'm not expecting a vast quantity of events as there will only be appox 3,500 end points. However we are planning on sending every occurrence/count of the event.
I'm just trying to weigh-up if this is a viable option or for us or not.
I'd rather not use EMS at this point for a few reason including the lack of failover you mentioned.
It would be good to hear if anyone else in the community has had any experience around the question posed...
Else I'll have to look at other options such as SNMP, which is very straight forward, or an in-house application, time permitting.
you could implement this integration via API:
Alarm Calls - CA Unified Infrastructure Management Probes - CA Technologies Documentation
or you can script it by querying the DB and sending the alarms to a MOM.
Another option is to listen into the message bus...not sure what you MOM supports...
Thank you for your reply.
I don't think this is going to work for us as we don't want to ingest the events on an interval. We want them pushed in real-time.
NestorFalcon There are a couple of problems with using the UIM REST API, but the biggest is that it doesn't give you 'clear' events. Without these you have to write your own clearing logic in whatever integration you set up, or in the target system.
good point Steve.Mac. You can always check active alarms via API to compare it with your MOM and get the ones that have been cleared. But, again, this will require some "logic writing" as you mentioned.
nas is only single threaded when processing AO profiles and preprocessing rules.
If you are looking to run a long running LUA script off an AO profile, you need to do something that causes a second instance to be run via the nas scheduler for instance. As an example, you have the AO do something quick like create a file with the necessary information in it. The have a scheduled job that periodically checks for these files, reads their contents, does whatever long running thing you needed was, and cleans up. the scheduled job(s) will run concurrently with the nas AO profiles.
The sequential-ness of the AO profiles isn't a limitation of the nas - it's a protection because it saves you from having to code a mutex function if you have two AO profiles affecting the same underlying data.
You could also consider nas replication to replicate these "long running" jobs to another nas where they'd be processed separate from the first nas that was handling your time critical items.
Or you could use the nas "post message" to post to a message queue and the logmon probe to read that queue and execute a script on match.
Lots of ways to skin this proverbial cat.
like you plan to call for a high volume alarms the Rest call i would create a custom probe that listen to his own queue and executes the rest call. The advantage is that the queue can hold alarm storms if needed.
In the Nas you would create an action repost with an unique subject.
in your hub you create a new attach queue for that subject.
This seems like a sensible solution.
Also it will help handle persistent connections
Unfortunately, even though I've been in the UIM/Nimsoft arena for several years, I've not had the opportunity to write a custom probe.
Should be interesting.
A custom probe seem to be a right solution. The REST API stay limitated in a performance scenario where you have to bulk a lot of HTTP requests. (The average was one request every 500-1000ms when i created my custom probe alarms management).
I will advice you to use the Nimbus API when you can..
That make me sad (we are in the middle of the API Golden age ...).