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...
The MP Dev Kit heavily relies on OA perlA, too. I think doing a http request is something many monitors require (WS, REST..).
Perl is fantastic for quickly writing robust monitoring solutions.
That's why I post here.
Check out the Agent 12: it comes with more perl modules like HTTP, YAML, ... DateTime is unfortunately not included.
Which other perl modules would you need? DateTime? What else?
When you develop with the DevKit you can also include your own perl modules (or Strawberry Perl modules). Check out the chapter "ADDITIONAL PERL AND NON-PERL ARTIFACTS" in the DevGuide. But I agree, once you have compiled code as part of the perl module it gets a bit tricky (you could create a custom instrumentation with par files per OS).
Depending on the version of perl used by OA 12 some of the modules/funtions below may already be included (because they were added later in perl core).
1. strnptime: module Time::Piece (this should be already in perl core from 5.8) an altreative is DateTime (but it seems TimePiece was preffered for inclusion in core).. in short something to covert/manipulate dates and times. This comes handy when parsing different command outputs / logfiles, which include string dates.
2. Digest::SHA, Digest:MD5: also in core (not sure from which version onwards).
3. IO::Compress zip or bzip2
4. Some library to handle HTML, for example something to properly%20encode%20xml%20strings
5. Please also check the authentication schemes supported by LWP.
6. Build perl as multithreaded. In the end we did everything without it, though - so it's not really that much important.
That's all I can think about - those are the things I missed in the older OvPerlAs.
Maybe it wouldn't hurt to check what the default perl distributions install by default (for example on RH).
Don't remove previous modules (like XML Simple).
And if you can then backport the modules to OA 11... 😉 I know that XML Simple was added in a minor version.
Nearly forgot... this would also be veeery nice to have. opcmsg() and opcmon() in perl. Calling the commands if slow and you are limited by the command line length (esp. on Windows). On unix you already have a library and on windows a COM object - what is needed is to make those available to perl.
Win32:TieRegistry is included in OA 12, JSON (I think), too.
Also a simple HTTP client and a few others like YAML.
I haven't checked the others like MD5, yet.
I also checked OA 12 and I think we'll base our solution on it (require OA12) because of the perl goodies. It has a lot of stuff I mentioned - I just looked at the directory structure, though.
Another one that comes to mind: HTTPS - AFAIK LWP should be able to do HTTPS too.
Can you please check if opcmsg and opcmon are implemented using (lib)opcapi(.so) in perl? That perl is not calling the commands (bin/opcmsg[.exe], bin/opcmon[.exe]) but using the API?
Using the API is better becuse the commands are subject to CLI length limitations - the API is also faster than spawning binaries.
as far as I know you will have to use the CLI for sending events. Unfortunately there is no perl API you can use from external perl - only for embedded perl (inside of Measurement Threshold policies) you can generate events.
But hopefully you don't to generate so many events that running a CLI would cause bigger problems.
I don't know if HTTPS is supported - I never tried. There are modules for https, so maybe it works.