OMi OA perl could include more modules by default
I'm seeing that perl is somewhat the best solution to write monitors.
The OMi Dev Kit relies on perl. It's an obious choice since you can write code that can run both on windows and unix.
I like perl, too... but at the same time I hate it 😉 Perl is fine until the functionality you need is in perl core or if the module you need is already packaged in the distribuiton you need (that would be perlA in our case).
In one of our previous solutions (for HPOM 9.x) we had to work miracles to make it work on both platforms and without requiring the user install additional perl modules (or requiring the customer to install Active perl).
This time I wanted to use it to monitor something via http and found that there's no way to do a http request with perlA (at least I could not find it, correct me if I'm wrong). I could of course use wget or curl, but this works only on Linux (or at least I have to provide the windows binaries, too).
And please don't say that PAR is solution. This also requires bundling .so's and can break depending on OS version.
So could someone push for adding some more modules (license permitting) into perlA?
I'll start with my list:
- DateTime (for strptime)
In hope of a more up-to-date perlA...
Well there is the case of 'proxy' monitoring... when one OA is responsible/monitors many ('external') resources. This is not theoretical, we have at least 2 such cases (I can priv. msg them). In such cases calling the API is faster, saves CPU cyccles for the monitored application. We have ratios of one agent to 1000 objects and more. [I'll ignore the issue with message storms such a configuration may generate]
Using the CLI has the following limititations:
- need to escape special carracters
- total length of command line beyond which truncation happens (esp. on Windows)
- limit on number of process' spawned per second (Windows)
Libopcapi.so is available in OMU/OML/OA for a very long time and it's probably not too complicated to create a perl module with it.
Our old SPI's are written in C/C++/Java/C# and that only because (at the time) we didn't have the required functionality available in perl. Looking at the code - 90% is parsing (of strings, xml, json) which can easily (and more robustly) be done in perl. The OMi Dev Kit is perl... What I want to say is that it makes sense to make OvPerl as powerfull as possible - this shortend development time and enables sysadmins with basic script knowledge to write their own monitoring solutions (or, license permitting, fix problems/extend existing solutions).
I did some preliminary testing with OA 12 perlA. Tested the following on Windows:
- JSON: works
- LWP HTTP: works
- LWP HTTPS: works with workaround - when started perl will complain that it can't find LIBEAY32.dll, SSLEAY32.dll. Those libraries are needed for HTTPS to work. The agent already has those libraries (for other purposes, I guess) - in hpcs\ssl. So if I cd to that directory and run the test again it works. I would suggest including the required libraries in the correct perl subdirectory.
Another issue with LWP HTTPS.
Error: 500 SSL_ca_file C:\Program Files\HP\HP BTO Software\nonOV\Perl\a\lib\5.16.0\MSWin32-AMD64-multi-thread\Mozilla\CA\cacert.pem does not exist
$ua->ssl_opts( SSL_ca_file => 'C:/Program Files/HP/HP BTO Software/nonOV/Perl/a/lib/5.16.0/Mozilla/CA/cacert.pem' );
I'm also having issues connecting to certain sites via https... I'll post back if I find some more info.