Tim Uckun wrote: >It's looking like rrd is not the right tool for this job >after all. I can't predict how frequently the different fields in the >database will be updated. I just wanted to keep track of the changes >but in a round robin fashion so I can see if they are going up, down, >or staying still and if they are moving try and get a sense of >"velocity". Some items might never change, some might change once a >week or day, others might change every ten minutes or so. What's worse >field X for one record might change rarely but for another record >change all the time.
From your description I thin you are right, RRD isn't the right tool. It's not designed to deal with arbitrary and changing number of data sources, or for data sources that change on an indefinite schedule. If you had a fixed number of records then it might work - you'd just update all of them in RRD even if the value hadn't changed. But I assume you've got a varying number of records as well, which means you'd have to be dynamically creating/removing RRD databases as well. The other thing to remember is that RRD wont store arbitrary timestamp:value pairs - all data is normalised to fit fixed period buckets whose length and number are fixed at the time of database creation. To be honest, since you already have the database, I think you would be better using that to track historical values (add a trigger to create a timestamp:key:value record in a history table when a field changes perhaps ?), but it does mean you'll have to roll your own programs to analyse the data. -- Simon Hobson Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed author Gladys Hobson. Novels - poetry - short stories - ideal as Christmas stocking fillers. Some available as e-books. _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users