[rrd-users] Sar data

[Ulf Zimmermann]

It can fork, but many of the modules are dynamic loaded modules.

> -----Original Message-----
> From: Mark Seger [mailto:Mark.Seger at hp.com]
> Sent: Monday, July 30, 2007 10:48
> To: Ulf Zimmermann
> Cc: Wes; rrd-users at lists.oetiker.ch
> Subject: Re: [rrd-users] Sar data
> 
> interesting.  I've never heard of collectd.  I will say it's
interesting
> to read that it's 'written in c' to make it faster but then forks
> script.  when I wrote collectl I found it work it to write my own
'cat'
> routine because it was much faster to open/read a file in perl than
exec
> cat.  go figure.  9-)
> -mark
> 
> Ulf Zimmermann wrote:
> >> From: rrd-users-bounces at lists.oetiker.ch [mailto:rrd-users-
> >> bounces at lists.oetiker.ch] On Behalf Of Mark Seger
> >> Wes wrote:
> >>
> >>> On 7/30/07 10:37 AM, "Mark Seger" <Mark.Seger at hp.com> wrote:
> >>>
> >>>
> >>>
> >>>> I've been thinking about adding rrd style output to collectl but
am
> >>>> waiting for someone to raise their hand and say they'd like to
work
> >>>>
> >> with
> >>
> >>>> me.  As for perl being too heavyweight, collectl uses less than
> >>>>
> > 0.1% of
> >
> >>>> the cpu reporting about 100 different variables.  If you want
less
> >>>> frequent samples as most rrd users do, you can probably get it
down
> >>>>
> > to
> >
> >> 0.01%
> >>
> >>> I figured programs collecting real-time sar data in RRD would be
all
> >>>
> >> over
> >>
> >>> the place.  I was very surprised to find such a thing so scarce.
> >>>
> >>> I am looking at colleting 5-10 second samples.  I may have to
resign
> >>>
> >> myself
> >>
> >>> to using perl for the sar data.  I have a number of other
> >>>
> > statistics,
> >
> >> some
> >>
> >>> of which have to be gathered by scanning very large log files in
> >>>
> > real
> >
> >> time.
> >>
> >>> By using C, I had hoped to save as many cycles as possible, and be
> >>>
> > able
> >
> >> to
> >>
> >>> use a common set of functions to transmit the data to the central
> >>>
> >> collection
> >>
> >>> system.  I guess I can always roll my own.  We have times when
every
> >>>
> >> cycle
> >>
> >>> we can save is crucial (can't just up and replace the systems with
> >>> faster...)
> >>>
> >>>
> >> 5-10 second samples is what collectl is all about and it can
collect a
> >> lot more data than sar so perhaps at least some of what you're
looking
> >> for it may already generate.  it's not unusual to have collectl
> >>
> > running
> >
> >> on systems sustaining >90% cpu loads
> >> -mark
> >>
> >>> Wes
> >>>
> >
> > I am using collectd on close to 100 nodes, specific per cpu stats,
load,
> > memory, swap, processes, interface, disk space used and disk IO (ops
and
> > bytes). It does other things too, but I am not interested in them,
so I
> > only load those plug ins. Choose collectd for the reason of 10
second
> > interval samples.
> >
> > I have written a grapher for our use but as collectd 4.x splitted
the
> > structure how RRDs are saved, it won't work for it. Currently
planning
> > on writing a new grapher soon, one which can hopefully also be
released
> > as opensource.
> >
> >