Today, Steven Wagner wrote forth saying... > 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.
You should only have to compile the rrd library 32-bit right? What happens when you compile the monitor-core 64-bit and link the 32-bit rrd library. Does that not work? If it worked, then you would only need to deal with this headache whenever you upgraded rrdtool. To be honest though, I don't know about 32-bit 64-bit linking issues so this could a completely useless sentence to write (except maybe this last sentence). > 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 this is an error that i don't completely understand but i'm going to squash this bug today (assuming it is a bug.. it might just be a too-generic error message problem which might read "unable to contact data source to get XML in the first place). i'll find out. > ---[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] i know what is causing this bug. in order to play nice, the new gmetad doesn't require a 2.5.0 gmond. this makes it impossible on pre-2.5.0 systems to know the SLOPE attribute. this means that some non-numerical metrics slip through.. i bet one of your non-numeric metrics on a pre-2.5.0 gmond had a ':' in it? please check your colon and get back with us. > 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? yes. you need to check out the latest gmetad-webfrontend from CVS. the databases for the hosts are the same BUT the summary information is stored in a more generic and flexible manner so that we can get both the average and sum on demand. something to watch for.. the web frontend assume rrdtool is installed in /usr/bin/rrdtool. check your conf.php and make sure it all looks good. > 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... an easier way to check the data in a database is # rrdtool fetch proc_total.rrd AVERAGE it'll just print the timestamp and the values. -matt
