I get nothing when I attempt to get any of the Services discovered or metrics within them.
My guess at present is that some name matching has to be done , but I don't know which and where. This is not like the SMTP example process where everything comes from some the named system server.
I have changed the name of the logfile for confidentiality. This example SHOULD be able to discover stuff and does not. Simplifying it so that it has a unique service for each queue would quadruple the runtime for the script. Not that it runs a long time... I could refactor slightly so as to parse 4 separate logfiles for answers, but that would be IMHO, an abuse of the programmer who coded the queue monitor in the first place.
OK... it looks like it is "hard" to get at the service underneath a server... and "hard" to get at multiple metrics on the server. Whether it works in a full install yet I don't know. It is not being kind in terms of command line testing.
Kicking down the size before log rollover will control the runtime for the scripts well enough. If I could trust Windows to effectively "tail" my file I'd use that. Separate logs because If I have 4 separate scripts running each will be re-examining data from 3 queues it is completely un-interested in. Triple the waste.
I can rewrite the scripts and monitor to go to separate logs.
The only sensible availability metric is the server which, if it is running, is connected to the WAS and getting data.
This version of the xml does work. However, the results of running it indicate that there is no method of using a single collective run even when it would make sense to get a collection of metrics in one go. Bless the fact that I did the collection in the monitoring java code and ignored the methods being used here. The perl script runs at about 0.1 seconds against a megabyte file.
Longer than I like if it is getting run 8 times ( 2 metrics from each of 4 queues). This will be controlled by reducing the log sizes to 20k or so. More than enough to be sure of having a run. I still don't know why I can't see the Services when I wrap them in a server and run the Java test, but it doesn't matter. This looks almost perfect. Hard to be certain about the availability. No idea about autodiscovery but... it does about what I expect it to do now and I am ready to take it to the Server and see if it all can connect.
The script measurement plugin does cache the results, normally you wouldn't see the script called more than once per metric collection interval. Try adding: -Dexec.interval=5 or more, the default is 1 with on the command-line, but would be 60 in the agent.
OK.... This version works, connects to the UI and displays services. The version with the Server removed didn't appear in the UI that I could find but could test each of the services. This is working.
I am going to work on the WSMQ and form a group now, as the plumbing for the project I am monitoring contains both sorts of queues. The pojo spring adminclient monitor is extensible to monitoring anything in the WAS with a little more java magic, right now specialized for queues. The WAS is a PITA to monitor (without getting strings back through the system) as the things to monitor are named quite arbitrarily. With the queue naming configured in Spring and in the script I think I am in business.
With the java tests in debug that was not apparent but I am glad that it will cache the results.
With the log size limited it is fine even if it did not. Using Perl gives me portability that an sh or ksh script wouldn't and the timing tests show it is quick enough. The java monitor itself has a timing associated to its updates and needs to be same as the hyperic frequency. I am a little concerned with the prospect that I will get simultaneity problems on the log file access.
It takes whole seconds to collect the information from the WAS itself and much more to get it set up in the first place. It has to store each queue ObjectName and request it specifically in order to keep it from being tens of seconds.
For someone like me that would be torture. Before moving here I worked at NASA JPL on embedded real-time signal chains and regarded a millisecond as a very long time indeed 🙂