HP-UX Workload Manager User's Guide

Advanced WLM usage: Using performance metrics
Supplying data to WLM
Appendix H484
Independent collectors Independent collectors use the wlmsend
command to communicate a metric value to WLM. For more information
on this command, see “What methods exist for sending data to WLM?” on
page 493.
They are called “independent” because they are not started by the WLM
daemon wlmd, and they are not required to run continuously.
This type of collector is ideal if you want to convey event information to
WLM, such as application startup or shutdown.
One caveat of using this type of collector is that on start-up, WLM has no
value for the metric until the collector provides one. For this reason, the
collector should be structured to report a value periodically, even if it has
not changed.
If your collector runs continuously, be careful if using pipes. The pipes
may have internal buffering that must either be defeated or flushed to
ensure the data is communicated in a timely manner.
To configure an independent collector for a metric called metricIC, place
the following tune structure in your configuration file:
tune metricIC {
coll_argv = wlmrcvdc;
}
Stream collectors Stream collectors convey their metric values to
WLM by writing them to stdout. WLM starts these data collectors when
activating a configuration, and expects them to continue to run and
provide metrics until notified of a WLM shutdown or restart.
Use this type of collector if the metric is available in a file or through a
command-line interface. In this case, the collector can simply be a script
containing a loop that reads the file or executes the command, extracts
the metric value, writes it on stdout, and sleeps for one WLM interval.
(The current WLM interval length is available through the
WLM_INTERVAL environment variable to data collectors started by WLM
through a coll_argv statement in the WLM configuration.)
Again, as with independent collectors, be careful if using pipes in the
data collector. These pipes may have internal buffering that must either
be defeated or flushed to ensure the data is communicated in a timely
manner.