[rrd-developers] rrdcached daemonize failed, exiting

[Florian Forster]

Hi,

sorry for tuning in so late, I didn't get to read your mails until just
now..

On Wed, Sep 24, 2008 at 02:41:43PM -0500, kevin brintnall wrote:
> I see two main install types for rrdcached..  This is what I would target:
> 
> (I1) as a local service
>      - purpose is largely to ease disk burden
>      - cannot expect users to know cached is present
>      - optimize for the use cases that work today
>        - i.e. refer to file by any valid path

This is clearly the use case I had in mind when implementing the daemon.
I disagree with ``cannot expect users to know cached is present'', but I
guess you really meant the program that's writing the values - the
setupts we're talking about here aren't updated ``per hand''.. ;)

> (I2) large collection systems
>      - purpose is to distribute polling load
>      - users on the polling systems need to handle path discrepancy
>        between pollers and storage
>         - likely to be common administration
>         - we can expect them to do it themselves if we provide the switches
>      - users on the rrdcached system work just like "local service" above

I take it you mean `distributed' systems, because centralized systems
can get ``big'' without the need for network communication in rrdcached.
Polling is not the limiting factor in my experience, but I see the need
for having multiple instances nonetheless - we have customers using the
same (private) IP-address-range we use for certain tasks. It's not
related to statistics collection but it shows what messed up setups such
a solution needs to cope with.

While in the local setup resolving relative paths to absolute paths
before communicating with the daemon makes some sense, in the
distributed environment it doesn't or at least produces a lot of
unnecessary administrative work.

What about abstracting from the file layer some more? Much of the
problems (permissions, paths) result from the daemon writing to file
that are read by other processes. It's worth a though to restrict file
access *only* to the daemon. We'd need to add a `FETCH' command as a
first step, so that graphing can be done using information provided by
the daemon, too[1]. `rrdcached' would be more of a database layer over
the actual storage and neither client (updating or graphing) needs to
know the exact location of the data on disk.

This could solve another problem: Having graph generation on the same
machine that's writing the data is often not desirable. I'd make much
more sense if the webserver(s) could do this. Mounting the partition on
the webservers has worked so far, but can't send the `Flush' command.
Simply retrieving the data via the daemon would make for a nice
solution, imho.

Regards,
-octo

[1] Other commands are mostly administrative. They can be added to the
    daemon, too, but I'd target one issue at a time..
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080926/ed8b1d80/attachment.bin