author | oetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa> | |
Mon, 29 Mar 2010 17:03:57 +0000 (17:03 +0000) | ||
committer | oetiker <oetiker@a5681a0c-68f1-0310-ab6d-d61299d08faa> | |
Mon, 29 Mar 2010 17:03:57 +0000 (17:03 +0000) | ||
commit | 707fad9e415cfa2a55649c973c015bb44e19df45 | |
tree | d91af5b8a132630ae4d4cfe934f744ab5aecb994 | tree | snapshot |
parent | 978ca8ba881094bda9b493c40c44ae1932192bb0 | commit | diff |
Add a "FETCH" command to RRDCacheD which behaves like a (simplified
version of) rrdfetch(1).
This has advantages over calling "FLUSH" from within the "client",
especially if the daemon is accessed using a network socket. For one, it
makes it easy to separate collecting and storing of data on one side and
creating graphs on another, possibly more public server. Without this
command this is only possible using networked file systems and similar
techniques.
When talking to an instance of RRDCacheD via a network socket, only
relative pathnames are allowed. If the RRD file is to be accessed
afterwards (why else would one call "FLUSH"?), the client has to be in a
specific directory so the *same* relative path can be used. If the file
is on a share mounted via the network, the required CWD may differ from
the CWD of the server, making developing and deploying solutions using
separated storing and graphing unnecessarily hard.
The data can be accessed using "rrdc_fetch" which should be a drop-in
replacement for "rrd_fetch_r". This makes it easy for programs using the
RRDtool C API to use this new functionality. -- Florian Forster
git-svn-id: svn://svn.oetiker.ch/rrdtool/trunk@2059 a5681a0c-68f1-0310-ab6d-d61299d08faa
version of) rrdfetch(1).
This has advantages over calling "FLUSH" from within the "client",
especially if the daemon is accessed using a network socket. For one, it
makes it easy to separate collecting and storing of data on one side and
creating graphs on another, possibly more public server. Without this
command this is only possible using networked file systems and similar
techniques.
When talking to an instance of RRDCacheD via a network socket, only
relative pathnames are allowed. If the RRD file is to be accessed
afterwards (why else would one call "FLUSH"?), the client has to be in a
specific directory so the *same* relative path can be used. If the file
is on a share mounted via the network, the required CWD may differ from
the CWD of the server, making developing and deploying solutions using
separated storing and graphing unnecessarily hard.
The data can be accessed using "rrdc_fetch" which should be a drop-in
replacement for "rrd_fetch_r". This makes it easy for programs using the
RRDtool C API to use this new functionality. -- Florian Forster
git-svn-id: svn://svn.oetiker.ch/rrdtool/trunk@2059 a5681a0c-68f1-0310-ab6d-d61299d08faa
program/doc/rrdcached.pod | diff | blob | history | |
program/src/rrd_client.c | diff | blob | history | |
program/src/rrd_client.h | diff | blob | history | |
program/src/rrd_daemon.c | diff | blob | history |