![]() |
![]() |
Subject: | Notes on fetching RRD data from zenrender |
Author: | [Not Specified] |
Posted: | 2014-12-10 13:13 |
I hope it's ok to post some Zenoss administration experiences that aren't really support requests. I'm sure we have all "found things out" in our use of Zenoss that the documentation may not have addressed. Here's one I worked on today...
Ok, so I already knew there's a zenrender service running on each collector, port 8091, and one of its methods is "render", which serves up RRD graphs with URLS like this:
h_t_t_p://collector:8091/renderwidth=500&gopts=[RRD_OPTIONS]&drange=129600
Today I was hoping to obtain values from RRD files via the zenrender service. (Since I run distributed collectors, using a web interface was much more useful than hitting the rrd files directly.) The help page for the zenrender service (see: http://collector:8091/ ) suggests there is a method called currentValues which takes the path name of an RRD file in a parameter called "paths". So I would expect the URL for that to look like this:
h_t_t_p://collector:8091/currentValuespaths=/opt/zenoss/perf/devices/FOO/sysUpTime_sysUpTime.rrd
Under no circumstances could I get that to work. Even putting zenrender in debug mode showed that a URL like that was parsed strangely, each character of the path name handled individually.... If anyone knows how to make that work directly, I'd appreciate knowing. But pushing on to find a method that DID work, the Goog showed me there was a method called getRRDValue like this:
h_t_t_p://zenbase:8080/zport/dmd/Devices/Server/Windows/devices/FOO/getRRDValuedsname=sysUpTime_sysUpTime
tcpdump shows how that interacts with zenrender service. It posts to an XML-RPC interpreter, and uses the zenrender method "summary".
POST /RPC2 HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
Host: collector:8091
Accept: */*
Content-Type: text/xml
Content-Length: 575
So I have to ask... why does zenrender use XML and not Zenoss's more commonly used JSON Why doesn't summary work like render Turns out currentValues works the same way. Assemble your XML packet and shove it up into the RPC2 URL. You get back XML. There must be something I'm missing about this, but at least we got results.
< |
Previous Need to get alerts on DHCP scope capacity |
Next Notifications - blank fields and group field |
> |