Honour RRDCACHED_ADDRESS env var for Perl and Python bindings

[enigmapsi]

It would be nice for the Perl (python, etc) bindings to detect RRDCACHED_ADDRESS env variable and use rrdcached when updating/fetching/dumping/etc.

This way, tools like Torrus or Smokeping (and others that use RRDs::) can make use of rrdcached without patching their files, i.e. transparently.

Thanks.

[oetiker]

aehm ... don't they do that ?

[enigmapsi]

Hi,

I've checked/searched the code for the bindings (I'm only interested in Perl ones, TBH) and there's no RRDCACHED_ADDRESS anywhere.

Also, I've set up a Smokeping and Torrus test machine, compiled and installed the current commit (6890e9db8073e7850829f0b0b19fc85260a9042d), set up the RRDCACHED_ADDRESS to the local socket, and checked if any of the two tools use it transparently (using STATS rrdcached command), but nothing is sent to rrdcached, the rrd files are written directly.

Unless I'm missing something (different env var name?), it's probably not yet implemented.

Thanks

[oetiker]

I must admit, I am not using rrdcached myself, but looking at the source code, you can see that the checks for RRDCACHED_ADDRESS happen in the rrdtool source code itself ... independent of any language bindings ... see rrd_update.c and rrd_client.c

not sure why this does not work here.

[sshipway]

I believe this works, since I have a couple of Perl-based RRD web utilities (not counting Routers2) which were made to work with rrdcached simply by setting the RRDCACHED_ADDRESS environment variable. However I later coded it to add --daemon $RRDCACHED_ADDRESS as options to the RRDs library call. One issue that @enigmapsi may be experiencing is Apache (or whatever web server is being used) stripping entries fro mthe environment before calling the CGI. Using mod_env with SetEnv and PassEnv to set the RRDCACHED_ADDRESS variable before the CGI is called might be the solution.

[sshipway]

Another issue is that, of course, rrdcached does not support all of the RRDtool functions. In the case of MRTG, for example, the info and tune functions are called, which will silently fall back to local rather than using rrdcached, and so will fail if rrdcached is a remote TCP port. update and fetch are fine; graph prefers being told on the command line for specific DEFs; and info was only available in trunk last time I checked.

So, while setting RRDCACHED_ADDRESS might make some code work unaltered over rrdcached, if the code calls a function not supported by your perl module or rrdcached version, it will fail. I think you need to have a very recent version of rrdtool for info to work over rrdcached, for example.

[enigmapsi]

Given the info here, I will test again with both Torrus and Smokeping. The issue was not when viewing (graphing) the files, the issue was that rrdcached STATS command reported zero updates, like RRDCACHED_ADDRESS was totally ignored and the RRD files were updated directly. Will report the results back soon.

[enigmapsi]

Ok, found the culprit, this i not really an issue, thanks alot for the pointers above.

Please close the issue when you can.

RRDCACHED_ADDRESS was not transmitted to the Smokeping daemon, I had to use export RRDCACHED_ADDRESS=unix:/var/run/rrdcached.sock just before the daemon start command in the init script (Ubuntu 12.04).

In the meantime I discovered another issue, strictly rrdtool related, but I'll describe that separately.

Thanks a lot for your help!