Created attachment 284267 [details] PNG graph of bad values The data for varnish-default-workers/total_threads-created.rrd and varnish-default-workers/total_requests-overflowed.rrd are way too large. Its always in the trillions or 0. Most of the other data sets look valid. The ones where I'm running at 0 on I can't tell if they are correct or not. We are running Gentoo 2010.0, Varnish 2.1.5 and collectd 5.0.0-r1. We are using an overlay with modified emerge file to allow the building of the varnish plugin so we can test it.
Hey, thanks for the bug report. Not sure what to do here since you're using an build outside our own tree, but let's collect more info so we can help upstream. We should also look at adding this support to the ebuild in gentoo-x86, so please post your ebuild as well. - what version of rrdtool? - can you perhaps attach the rrd-file? - do you have a custom types.db entry for this data source? - did you initialize this data source from collectd 5 or is this an upgrade from an older installation?
(In reply to comment #1) > Hey, > thanks for the bug report. > > Not sure what to do here since you're using an build outside our own tree, but > let's collect more info so we can help upstream. We should also look at adding > this support to the ebuild in gentoo-x86, so please post your ebuild as well. All I did was make a two line change. I removed "varnish" from the untested list and added it to the tested list. I'll post the emerge. Here's a diff: --- collectd-5.0.0-r1.ebuild-org 2011-07-25 14:01:01.000000000 -0700 +++ collectd-5.0.0-r1.ebuild-new 2011-08-16 11:54:07.000000000 -0700 @@ -21,7 +21,7 @@ COLLECTD_IMPOSSIBLE_PLUGINS="netapp pinba xmms" # Plugins that still need some work -COLLECTD_UNTESTED_PLUGINS="ipvs apple_sensors routeros tape zfs_arc modbus amqp genericjmx lpar redis threshold varnish write_redis v5upgrade" +COLLECTD_UNTESTED_PLUGINS="ipvs apple_sensors routeros tape zfs_arc modbus amqp genericjmx lpar redis threshold write_redis v5upgrade" # Plugins that have been (compile) tested and can be enabled via COLLECTD_PLUGINS COLLECTD_TESTED_PLUGINS="apache apcups ascent battery bind conntrack contextswitch @@ -33,7 +33,7 @@ tokyotyrant uptime users vmem vserver wireless csv exec logfile network notify_desktop notify_email oracle perl python rrdcached rrdtool syslog unixsock write_http match_empty_counter match_hashed match_regex match_timediff match_value - target_notification target_replace target_scale target_set uuid" + target_notification target_replace target_scale target_set uuid varnish" COLLECTD_DISABLED_PLUGINS="${COLLECTD_IMPOSSIBLE_PLUGINS} ${COLLECTD_UNTESTED_PLUGINS}" > - what version of rrdtool? v1.3.8 > - can you perhaps attach the rrd-file? Yes, I will attach one of the files. > - do you have a custom types.db entry for this data source? no > - did you initialize this data source from collectd 5 or is this an upgrade > from an older installation? It was initialized with collectd 5. We just started using it.
Created attachment 284383 [details] The ebuild file The patched ebuild file I used to test the varnish plugin.
Created attachment 284387 [details] A sample RRD file with invalid data.
OK, so I've discussed this with upstream. The issue is that the data type is DERIVE but plugin submits as gauge. It will be fixed shortly in upstream.
(In reply to comment #5) > OK, so I've discussed this with upstream. The issue is that the data type is > DERIVE but plugin submits as gauge. It will be fixed shortly in upstream. Thanks for looking into this. Maybe when the update is done and shown to work we can remove the varnish plugin from untested?
Created attachment 284719 [details, diff] varnishd-derive.patch Jon: Can you please test this patch and get back to me?
(In reply to comment #7) > [...] > > Jon: Can you please test this patch and get back to me? Patch installed. Data deleted and collecting data now.
The patch has corrected the data in those two data sets. Thank you!
Great. Will be merged upstream soon, which also should turn up here in short (with the addition of the varnished module)
Thanks to all involved. Fixed in 5.0.0-r2.
