Tuesday, April 28, 2009

Managing Resources That Have A CLI

Sometimes, you may find yourself wanting to manage a resource for which there is no current Jopr plugin or, perhaps, the resource doesn't even have a management API or interface.

I have developed a new "Script plugin" that may help manage these "unmanageable" resources. You can watch a demo that shows the Script plugin in action.

This plugin will assume there is a command line executable or script that can be used to interface with the managed resource. What you do is manually add your "Script" resource to the Jopr inventory - defining where the command line executable or script is, and how its results/output should be used to determine the state of the managed resource. To be clear, the "CLI" executable/script is not really the managed resource - it is only used to interface with the real managed resource. The typical example I give people is: "apachectl" is the script, Apache Web Server is the real managed resource.

There is the ability to show RED or GREEN availability for any Script resource. For example, I can configure the Script plugin to assume the resource is UP (aka GREEN) if:
  • the executable merely exists on the file system, or...
  • the executable was able to run or...
  • the executable ran and returns a certain exit code and/or...
  • the executable ran and output a certain text string

The idea is that I have a command line executable or script that needs to get executed with a certain set of arguments. A successful execution would be determined by a regular expression that needs to match the exit code or output from that CLI.

You can also use the same type of mechanism to define how to invoke the executable to obtain a certain set of metrics. You can define arguments and a regular expression and based on what the executable returns (and what the regex captures) would be the value of the metric data.

This plugin should be useful because it is very generic - you can use it as-is for your own generic resources that have command line interfaces, a developer could extend the plugin classes, or a developer could just write their own plugin descriptor and have it pick up the Script plugin's ability to execute any executable and get the results. I think we'll be able to extend this to build a Nagios plugin, for example.

If you have any thoughts or ideas on what features such a Script plugin should have, feel free to comment. I would be interested to know what kinds of CLIs people run that manage their resources.

If you are interested in helping out develop a Nagios plugin, let me know - I'm very desparate in getting help on that. :)

[note: this blog post was updated July 2009 to reflect the new name of the plugin. This plugin was previously called the "CLI" plugin, but in order to avoid confusion with Jopr's new remote client/CLI, it was renamed to "Script" plugin.]


  1. How are you defining the metrics as metadata?

  2. Look at the metric comment in the CLI plugin descriptor:

    http://svn.rhq-project.org/repos/rhq/trunk/modules/plugins/cli/src/main/resources/META-INF/rhq-plugin.xmlThe generic CLI plugin does not define any metrics. What you would do it write your own custom plugin that extended this CLI plugin (which could mean just a simple plugin .jar with a single .xml descriptor in it). Your custom descriptor would define the metrics your CLI can support - in the metric definition, you define the CLI arguments and any regular expression needed to extract the metric data from the CLI output.

    See the javadoc in the CliServerComponent.getValues() method for some examples.

  3. This could very well help me with the Red Hat Cluster Status tool. By executing a Clustat with the XML option, I can get a list of all the cluster name of the node, the member nodes in the cluster, as well as which services are running on which servers.

    This is very useful information particularly for historical purposes as services can dynamically fail over to other nodes.

  4. The "CLI" plugin has been renamed to "Script" plugin to avoid confusion with the new client/CLI (they are not related).

    The previous links to the plugin descriptor and source are now this:



    I'll edit my blog post with a new link to the new demo after I finish it. I'll probably also demo an extension plugin that shows a metric.

  5. and once again, fedorahosted changed the syntax of the git links. here's the newest link: