[rrd-users] various questions on rrdcreate/rrd_create

[Rick Jones]

On Wed, 2011-04-20 at 15:54 -0700, Rick Jones wrote:
> On Wed, 2011-04-20 at 23:28 +0100, Simon Hobson wrote:
> > Rick Jones wrote:
> > Where there is a likelyhood of the number of datasets changing then 
> > you are better off with separate files. An example of that would be 
> > monitoring disk space where you may add or remove a filesystem. In 
> > that case you'd probably want one file per filesystem.
> > On the other hand, for an ethernet interface, I'd have combined those 
> > separate files into one since the set of values being logged isn't 
> > likely to change.
> > 
> > Another factor is whether all the data values are going to be 
> > available at the same time. You cannot do a partial update - so you 
> > cannot update one dataset at one point in time, and another at a 
> > different time, when they are in the same RRD file. If you can 
> > collect all the data values at once (which would be the case with an 
> > ethernet interface), then it's one call to update them all rather 
> > than updating each separate file individually.
> 
> Thanks.  I was wondering about ntop's decision there since with sflow
> counter samples one either gets all of the interface counters or none of
> them.

Having said that, as I'm getting farther in my own little "store away
the sFlow counters" program I've realized that I may not want the same
step value for each of the values returned for an interface.  for
example, out of the generic counters returned by sFlow:

typedef struct sflow_generic_counter {
    u_int32_t    ifindex;
    u_int32_t    iftype;
    u_int64_t    ifspeed;
    u_int32_t    ifdirection;
    u_int32_t    ifstatus;
    u_int64_t    ifinoctets;
    u_int32_t    ifinunicastpkts;
    u_int32_t    ifinmulticastpkts;
    u_int32_t    ifinbroadcastpkts;
    u_int32_t    ifindiscards;
    u_int32_t    ifinerrors;
    u_int32_t    ifinunknownprotos;
    u_int32_t    ifoutoctets;
    u_int32_t    ifoutunicastpkts;
    u_int32_t    ifoutmulticastpkts;
    u_int32_t    ifoutbroadcastpkts;
    u_int32_t    ifoutdiscards;
    u_int32_t    ifouterrors;
    u_int32_t    ifpromiscmode;
} sflow_generic_counter_t;

where I may desire a step value of one second for the octet, packet,
error and discard counters, I probably don't care for that small a
granularity for index, type, speed, direction and status.  not that ntop
makes distinctions there when it creates rrds, but then it doesn't
create rrds for those others anyway... and perhaps I won't as well.

rick jones