On Mon, Dec 14, 2009 at 10:28 AM, Carlo Marcelo Arenas Belon
<care...@sajinet.com.pe> wrote:
>> a) you are only concerned with redundancy and not looking for
>> scalability - when I say scalability, I refer to the idea of maybe 3 or
>> more gmetads running in parallel collecting data from huge numbers of agents
> what is the bottleneck here?, CPUs for polling or IO?, if IO using memory
> would be most likely all you really need (specially considering RAM is really
> cheap and RRDs are very small), if CPUs then there might be somethings we
> can do to help with that, but vertical scalability is what gmetad has, and
> for that usually means going to a bigger box if you hit the limit on the
> current one.

Ime cpu isnt' really a problem, the big load is I/O and indeed moving
the rrds to a ramdisk is the most common solution with pretty decent

>> b) you can afford to have duplicate storage - if your storage
>> requirements are huge (retaining a lot of historic data or lot's of data
>> at short polling intervals), you may not want to duplicate everything
> if you are planning to store a lot of historic data then you should be
> using instead some sort of database, not RRDs and so I think this shouldn't
> be an issue unless you explode the RRAs and try to abuse the RRDs as a RDBMs

I think there's a middle ground here that'd be interesting to explore,
altho that's a different thread, but for kicks this is the gist: the
common pattern for rrd storage is hour/day/month/year and I've always
found it bogus. In many cases I've needed higher resolution (down to
the second) for the last 5-20 minutes, then intervals of an hr to a
couple hrs, then a day to three days and then a week to 3 weeks etc
etc, which increases your storage requirements, but  is imho not an
abuse of rrd and still retains the many advantages of rrd over having
to maintain a RDBMs.

> Carlo
> PS. I like the ideas on this thread, don't get me wrong, just that I agree
>    with Vladimir that gmetad and RRDtool are probably not the sweet spot
>    (cost wise) for scalability work even if I also agree that the vertical
>    scalability of gmetad is suboptimal to say the least.

sort of. If you're looking at where your resources go to compute and
deal with large amount of data, I agree. If you look at what it costs
you or if it's even possible to create a fully scalable and resilient
ganglia based monitoring infrastructure, I disagree.

"Behind every great man there's a great backpack" - B.

This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
Ganglia-developers mailing list

Reply via email to