matt massie wrote:
steve-
does that mean that the C version of gmetad works on solaris if you
compile rrdtool 32-bit?
Well, at the time that I wrote that, I hadn't tried this yet*. But I did
just now, and it does work (despite the fact that my 32-bit compiler's a
bit old).
A bit of a pain in the butt to have to compile gmetad in a totally
different environment, though.
I'm now running it with debug output. And it seems to be storing RRD values.
Mostly.
---[ one log snippet from my 2.5.0-running Solaris boxen ]---
RRD_update: expected 1 data source readings (got 2) from N:1591.600000:22:...
save_to_rrd() couldn't parse the XML and data to RRD for [fs]
Updated rrd /www/gmetad/rrds/fileservers/SOME_SERVER/cpu_user.rrd with
value N:0.1
---[and one that includes errors from both, including my 2.4.1 Linux
cluster ]---
RRD_update: expected 1 data source readings (got 2) from N:1591.600000:22:...
save_to_rrd() couldn't parse the XML and data to RRD for [fs]
RRD_update: expected 1 data source readings (got 2) from N:1591.600000:22:...
RRD_update: expected 1 data source readings (got 2) from N:159.000000:91:...
save_to_rrd() couldn't parse the XML and data to RRD for [SOME_CLUSTER]
Of course there are screenloads of what appear to be real updates. But I'm
not seeing the graphs update on the frontend, which admittedly is running
on a hacked-up 0.1.0 codebase. My updated incarnation is having trouble
rendering graphs. Maybe the RRD layout has changed between versions?
When I run basic vanilla "rrdtool dump," though, I don't see any new
values. But the files *are* being written to (the timestamps are all
updating)... except for the summaries...
* - "Well, maybe I didn't say each and every syllable, but basically I said
'em, yeah ... basically..."
