Imagine you are someone who has played with performance co-pilot and its web applications. You've grown beyond the default dashboards, and want something more.
You've come to the right place: the Custom Metrics Web Emporium!
step 0: log the metrics
Let's presume you already have basic PCP up and running on a Fedora/RHEL-like system. If you need a non-default PMDA, you may need to:
# yum install pcp-pmda-FOOBAR
# cd /var/lib/pcp/pmdas/FOOBAR
# ./Install < /dev/null
If the PMDA is self-configuring, that's enough to fetch live data from it. If you also want
the data archived, which you do, you may need to edit the appropriate pmlogger
configuration.
You could run pmlogconf
against a config.pmlogger
file you're already using, or edit it,
assuming you know where to find it. If you're avant-garde enough to let pmmgr run your
logging, and you want it to simply work for your whole network dammit,
# cd /var/lib/pcp/config/pmlogconf
# cat > MY_FAIR_METRICS.conf
ident MY FAIR METRICS
probe FOOBAR.ONE exists ? include : exclude
FOOBAR.ONE
FOOBAR.TWO
FOOBAR.THREE
^D
# /sbin/service pmmgr restart
The FOOBAR.ONE
metric is any metric you know is contained in the PMDA, if it's working
correctly; the other FOOBAR.*
ones are metrics or whole hierarchy prefixes of metrics
that you want future pmlogger
s to archive. You can confirm that any new archives get
the FOOBAR
metrics stored in them via pmdumplog /var/log/pcp/.../archive*.meta
,
or by looking at the pmlogger.log
files.
If you agree that this is rather too many steps, consider adding your voice to this enhancement request.
step 2: find the metrics in graphite
Once your fancy new metrics start being logged to a file, it's time to check them out on
the web. You'll need to run a pmwebd
server and have its pcp-webapps
package(s)
installed, so that its web page http://localhost:44323/ pops up.
Then comes finding the metrics. Since there are approximately one gazillion of them, and
possibly stored over one mazillion separate pcp archive files, pmwebd
needs a notation
to identify the one(s) of interest. It does this via the graphite webapi subset
it implements. The gist of it is that metrics get named something like archive.met.ric
, where the
first component identifies the archive file or host name, the middle components identify the
pcp metric names, and the optional last component identifies the instance within that metric.
It's harder to explain than to show, so go and hit the graphite top level link.
Hit the little plus sign beside the "Graphite" folder, wait for the first level (archive-file/host-name) of the metric hierarchy to be populated. Find the most recent archive for your host, and keep clickin on the little pluses until you get to a real live FOOBAR metric.
If you click on the "Graph Data" button in the little composer/graph
subwindow, you will see the full graphite name for your FOOBAR metric.
Note it down. The you will probably want to replace the first component
with one with a wildcard such as *HOSTNAME*
, in order to let pmwebd
search for all archives for the same host. You may want to replace the
last component with *
too, if it's a metric with an instance domain,
in order to draw all instances.
If you click on the graph image itself, and get your web browser to spit out its URL, you will see something like
http://localhost:44323/graphite/render/?width=249&height=98&_salt=1497559426.608&target=vm-rhel7q64.network.ip.fragfails
If you play around with the time interval buttons at the top of the subwindow, extra fields will appear in the URL querystring:
?from=1497473484&until=1497559884
to specify the time interval. In this example, these are UNIX-style
epoch-seconds, but other syntaxes such as -2day
for "two days ago"
or now
for now, or HH:MM_YYYYMMDD
for, well, it's obvious. All
times/dates are interpreted in UTC.
Other parameters are available to specify rendering parameters like colors, to add or subtract a legend, add other metrics. Experiment with the graphite compose window's interactive options to see their behaviour.
step 3: construct dashboard
OK, now that you have a URL for an image, you can keep it, pass it around. But that's not good enough, is it? Otherwise you wouldn't still be reading this.
But you are. So let's get to making a dashboard. There are at least two basic
approaches: roll-your-own HTML, or grafana. In the roll-your-own HTML case,
you already have everything you need: make an HTML file with a set of IMG
tags,
with each SRC
pointing to one of the above graphite image URLs. Format it as
you like, publish it, done!
Grafana is another way. This is another webapp we bundle with pcp, and it is oriented toward building sets of related graphs. Normal grafana includes a dashboard storage/management server, which pcp's version doesn't, so we have to work a little harder. See this blog post for details about how the grafana dashboards may be constructed as explicit JSON files, or synthesized on the fly from a URL that includes metric/host names as querystring elements. Just use the compound graphite metric names you found for your FOOBAR metrics. Add any others of interest. Use wildcards liberally.
step 4: profit!
(warning - results not guaranteed)