A couple of clarifications. 1). Spoofing is achieved by creating a spoofing module and having that module discover the hosts that should be spoofed, in any way the module wants. The discovery could be done by querying the network for a specific type of device or appliance or by simply reading a .conf file that contains information about a spoofed host similar to what you suggested below. Once the spoofing module knows who it is spoofing for, it creates metric definitions which associate the spoofed metric with the spoofed host. An example of how this is done as a python module is in the spfexample.py module that is included in the python modules source code. Basically the only requirement is that a metric definition be returned to gmond that includes all of the basic metric information along with the special tags SPOOF_HOST and SPOOF_NAME. Anything else the spoofing module needs to do beyond this, it completely up to the module developer. Any or all of what you described below should just be module implementation details.
2). In reality there is only one module interface that gmond understands and that is the C interface. The python module interface is nothing more than implementing a C module (ie. mod_python.c) that is capable of acting as a proxy between the C interface and the python interface. The bottom line is that gmond can be expanded to understand any language interface by simply implementing a C module that does the translation between the C interface and the <whatever> language interface. In fact if the community believes that the current python module interface could be much more efficient or easier to use if it did <X>, is simply a matter of implementing an alternative to the current mod_python.c that does <X> and loading the alternative module as well. The whole idea is that the C module interface was introduced as a way to extend gmond. What that extension is, is completely up to the imaginations of the Ganglia community. And since the C module interface is really the only module interface that gmond knows about, anything that can be done with the python interface has to be done through the C interface meaning that the C interface has all of the same functionality and much more. Brad >>> On 2/4/2009 at 9:11 PM, in message <[email protected]>, Spike Spiegel <[email protected]> wrote: > Hi, > > while looking at taking advantage of host spoofing a few things came > up that I'd like to discuss. Assuming that host spoofing can be used > for: > > a) overriding host names because using PTRs can be a PITA depending on > the infrastructure (for example if you have tun/ethX prefixes) > b) streamlining appliances into ganglia > > I see a problem of how to manage this "spoofed hosts collection" and > would love to see some kind of standard emerging. > /etc/ganglia/conf.d/spoofing.cfg could be added containing definitions > like: > > spoofed_host { > hostname = spf1.example.org > ip = 10.0.0.0 > metrics = disk_spoof, cpu_spoof > } > > At this point metrics should read that file and figure out if they > should be doing any spoofing and if so for which hosts. Not sure about > C, but with the current python setup each module should include some > kind of lib to do that lookup, or maybe the approach should be changed > entirely. > > One problem I see is with a) is treating every host as a spoofed host, > which might end up being confusing. Furthermore it's arguable that the > concept of spoofing isn't itself misleading, take this example: > - an host named myhost with a public and private interface > - the public one resolves to task.domain.tld while the internal to > int.task.domain.tld > - monitoring traffic is kept on the internal network > - as a result data is recorded and shows up as int.host.domain.tld > > What I'm arguing here is that "int." could be considered spoofed since > the one the user is going to be thinking of is "task" and not int.task > or even that both are spoofed since the real host name is myhost. You > could blame it on poor naming and DNS practices, but I believe there > are legit examples where simply using the PTR to save data doesn't cut > it or whose result can be confusing. Imho much better would be to > allow the user to specify an arbitrary name, just use what hostname > unix command returns, and/or fallback on PTR. > > So I guess what I'm asking here is: should this be accomplished with > host spoofing, maybe allowing a hostname = something in gmond.conf and > hiding it from the user or do people feel that PTR is The Way and if > you want otherwise you deal with it yourself using spoofing.cfg or > something like that? > > On a related note, initially I believed the spoofing functionality to > be tied to the python modules, but then I noticed this in the STATUS > file: > > * Allow both a C and python module to create a metric that will spoof a > specific host. This provides the same spoofing functionality as gmetric > but through a metric module. It is done by adding SPOOF_HOST and > SPOOF_NAME as extra metadata to the metric description > > Based on that it should be possible to allow spoofing from the > standard C modules distributed with ganglia, correct? How would that > be done? I've looked at some of the existing metrics and noticed calls > to MMETRIC_ADD_METADATA, would that be it? > > thanks ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
