HP StoreOnce plugins - general description, incl. 1 or other bug

This forum was archived to /woltlab and is now in read-only mode.
  • To contribute something - and not only always ask or report bugs: We have begun setting up some specific checks/services for a customer's HP StoreOnce backup server - it's an "HPE StoreOnce 3540". Some basic SNMP checks like check_snmp_sysuptime.sh work, but you get (a lot) more infos with HP's own "HPE StoreOnce Monitoring Plug-in for Nagios Core", vn. 1.0.0. (The singular seems misleading, since there are 5 separate Python scripts in there, i.e. leading to 5 separate service rows in the services status page later under Nagios/Icinga...)

    A ZIP file is downloaded, containing i.a. a pretty detailed User Guide PDF, mainly about installing the plugins on a Nagios client server in an NRPE environment. No syntax descriptions of the Python script call-ups here, since all 5 scripts work according to the same call-up principle (there are no options of any kind!):

    script.py hostaddress username pword # latter 2 arguments are admin. access to the StoreOnce!

    Two of the 5 scripts only work if VTL libraries are installed, not the case on our customer's machine, so I can't say much about them as yet, except that they do seem to offer performance data (which the other 3 do not!): vtlStorageReport.py + vtlThroughputReport.py

    Three other scripts work fine if you have set up your StoreOnce to use English outputs:

    1. hardwareCompStatus.py
    2. serviceSetHealth.py
    3. systemHealthCapacity.py

    The first one produces oodles of output on the basic status of all hardware devices. (E.g. for physical disks, their capacity & whether they are currently okay. Not their fill state!) The third one briefly states whether the system is generally healthy and the total disk capacity.

    It's the 2nd one - health status of service sets (of the latter we have only 1) - that causes problems as released by HP in this (cf. 1st paragraph above) version. Our customer set up his StoreOnce to do outputs in German, so an important output line might look like this:


    ServiceSet Status : Läuft

    I found that the offending line in the serviceSetHealth.py script is this one:

    1. if "Running" not in line:

    I.e. HP coded the script to only look for an English word "Running" in such an output line from the StoreOnce. What is needed is either a reg. ex. search fn. call on the "line" string, e.g. with a search pattern containing German & English variants (perhaps using the "or" pipe symbol of extended regular expressions)... or a more general NLS-supportive solution, I feel!

    Other than that, so far, the (3 status) plugins work great... :thumbsup:

    The post was edited 6 times, last by bkai ().

  • Thankyou for that idea! I checked just now - the std. LANG setting currently in the monitoring server's root shell is "en_US.UTF-8"; it's also in the env list that way by default, so all child processes should inherit it. I just tried calling the service set health plugin from the command line with "LANG= " prefixed, and it still came out in German.

    When I looked through the Python code in recent days, I saw that the real embedded call-ups to the backup server are curl command lines using a long HTTPS URL with argument settings (after a "?" in the URL). I guess If one is going to affect the output at all, it's with one of those arguments. But I have no spec's on the backup server, and feel that is something HP should fix, anyway... If they allow the backup server to have other-than-English modes (which I approve of), the product-specific plugins should be able to handle that, too.

  • so all child processes should inherit it

    The monitoring process has its own environment which normally doesn't include any login script settings during startup so I'd try to trace/debug the actual plugin call.

    Changing / extending the curl call to alter the header might work.

  • All my initial tests with the plugin were done directly from the shell command line; so there was no monitoring process involved at those times. The latter just showed the same behaviour with the plugin as before in "raw" mode on the command line.

    I tried the curl command as indicated in the script (if you grep 'curl -s' on it, you will see the full command HP uses), with options "-H 'Accept-language: en' -v" added, but the output in the end is still in German. Extract of the initial verbose output ahead of that, followed by the 1st 14 lines of regular output (I scrambled the serial no.) :

    So that's how it seems to be. Short of changing the plugin script, I will probably notify HP of this bug some time in the next 10 days or so.

    Thanks a stack, Wolfgang, for your willingness to assist!

  • Perhaps. If so, I will be doing it with a colleague who has dealt with HP in the past. Not that urgent at the moment, anyhow. I wanted to contribute a description & possible solution to the community here...