On Fri, Oct 9, 2009 at 15:52, Spike Spiegel <fsm...@gmail.com> wrote: > On Fri, Oct 2, 2009 at 9:59 PM, Jesse Becker <haw...@gmail.com> wrote: >> On Fri, Oct 2, 2009 at 10:35, Brad Nicholes <bnicho...@novell.com> wrote: >>> How well does this fit into the previous discussions of using a GUID to >>> identify a box rather than an IP or FQDN? Are aliasing and GUID >>> identifiers related or are they two separate issues? >> >> I think that is a separate, but related, discussion. Perhaps I'm >> wrong, but there doesn't seem to be a clear consensus about using >> GUIDs vs. FQDN vs. IPs vs. something else (again, someone correct me >> if I'm wrong). Maybe we should open that discussion again? > > why a separate discussion? You're adding a config option which you're > free to set to whatever you think and that to me covers all cases, you > could set it to the hostname, an ip or a GUID. Personally I find that > in large infrastructure naming machines meaningfully is a lost game, > the host itself is more or less irrelevant and what matters is the > service associated to it, so I'd assign a GUID myself and maintain the > association with the service somewhere else, maybe as a metric itself. > On the other hand for the small shop host names are a pretty decent > approach to map your infrastructure so they would prolly want to use > that as an identifier. Either way having it as an option is a safe way > of handling it and avoids surprises at the gmetad end (I don't like > this thing that the received resolves the ip of the sender to decide > its name).
The "GUID discussion" I refered to was if gmond/gmetad should be rewritten, top-to-bottom, to use GUIDs instead of relying on DNS/IP addresses. My understanding is that everything would have use them, including the .rrd files underneath. That is, IMO, a big overhaul. Adding aliasing is theoretically a smaller change, that I think works within the existing code. This is what I'm proposing to add--something simple, and inexpensive to implement, but hopefully useful to many people. Thus, I see it as separate, but perhaps complementary/related. -- Jesse Becker ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
