Re: [Ganglia-general] localhost verses actual hostname
Hi Jonathan, IIRC, when ganglia first receives metrics from a new host, it does a reverse lookup on that IP. If your DNS is correctly configured, then that should resolve to the real hostname. I have encountered this type of issue before, and ended up fixing DNS, stopping ganglia, deleting the directories of the old metrics for the offending host, and then restarting, causing ganglia to re-check the hostname. Loses the historical data for that host, but fixes the issue. Possibly someone will have a neater solution for you. Cheers, Michael. On 23 July 2014 08:13, Silver, Jonathan wrote: > If I look at all of the metrics that we collect and get reported, some get > reported with the actual hostname of the collecting machine and some get > reported as coming from localhost on that collecting machine. > So the dropdown node selection has both hostname and localhost. > > Any idea how localhost is set? I'd like all of the metrics just to be > under the hostname selection and not split across. > > I thought that some of our nodes were using gmetric to report collected > metrics and I know that we removed any spoofing parameters that were being > used, so I'm not sure why this is happening. Any ideas? > > But is there any way from the gmetad (ganglia server) that we could use > hostname only? Can we fix this on the server and not on each of the agent > machines? > > Thanks in advance, > Jonathan > > > > -- > Want fast and easy access to all the code in your enterprise? Index and > search up to 200,000 lines of code with a free copy of Black Duck > Code Sight - the same software that powers the world's largest code > search on Ohloh, the Black Duck Open Hub! Try it now. > http://p.sf.net/sfu/bds > ___ > Ganglia-general mailing list > Ganglia-general@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-general > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
[Ganglia-general] localhost verses actual hostname
If I look at all of the metrics that we collect and get reported, some get reported with the actual hostname of the collecting machine and some get reported as coming from localhost on that collecting machine. So the dropdown node selection has both hostname and localhost. Any idea how localhost is set? I'd like all of the metrics just to be under the hostname selection and not split across. I thought that some of our nodes were using gmetric to report collected metrics and I know that we removed any spoofing parameters that were being used, so I'm not sure why this is happening. Any ideas? But is there any way from the gmetad (ganglia server) that we could use hostname only? Can we fix this on the server and not on each of the agent machines? Thanks in advance, Jonathan -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Grid of grids
Errr, my mistake. I need to forward the XML port, not the interactive port. After forwarding 8651 all works fine! Regards, Erich Am 22.07.2014 15:44, schrieb Erich Focht: > Hello, > > I am having similar issues. > > A gmetad is running on another host, monitoring a cluster. Its grid name > is "GangliaGrid". I created a gmetad.conf on my laptop, with a tunnel to > the remote host, forwarding its XML port (8652) to the localhost:8666. > Telnet to localhost 8666 shows that the remote gmetad answers fine to > queries like "/"... > > The local gmetad (on the laptop) uses in its conf: > > debug_level 1 > setuid off > gridname "LocalGrid" > data_source "GangliaGrid" localhost:8666 > trusted_hosts 127.0.0.1 > xml_port 18651 > interactive_port 18652 > rrd_rootdir rrds > > Unfortunately I see only timeouts. > > Sources are ... > Source: [GangliaGrid, step 15] has 1 sources > 127.0.0.1 > Data thread 140659923203840 is monitoring [GangliaGrid] data source > 127.0.0.1 > poll() timeout from source 0 for [GangliaGrid] data source after 0 bytes > read > > > If I use the same ganglia grid name in both gmetad's, gmetad dies > immediately. > > > Any idea what's going on? > > Best regards, > Erich > > > > > > > Am 23.06.2014 19:13, schrieb Rushton Martin: >> I've just updated to ganglia 3.6.0 and am trying to get a "grid of >> grids" configuration working. I started with the original grid which is >> visible through gweb. I built a new gmetad.conf for the new grid and >> that works fine when viewed from a new instance of gweb. The new grid >> uses port 8655 for XML and 8656 for queries. Using telnet to dump the >> XML also works fine and there are no obvious structural differences >> between it and the output from the original gmetad. However, when I add >> the line: >> >> data_source "Management" localhost:8655 >> >> to the master gmetad, not only do I see no output but I see repeated >> error messages in /var/log/messages: >> >> Process XML (Management): XML_ParseBuffer() error at line 1: no >> element found >> >> I tried scanning the archives and saw similar (but not identical) errors >> reported from a few years ago. I gather there was a known bug in gmetad >> that caused inputs from other gmetads to be rejected. So: >> >> 1) Is the bug still there? >> 2) Is there a work around? >> 3) Have I misconfigured it? >> >> Any advice gratefully received. > -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
Re: [Ganglia-general] Grid of grids
Hello, I am having similar issues. A gmetad is running on another host, monitoring a cluster. Its grid name is "GangliaGrid". I created a gmetad.conf on my laptop, with a tunnel to the remote host, forwarding its XML port (8652) to the localhost:8666. Telnet to localhost 8666 shows that the remote gmetad answers fine to queries like "/"... The local gmetad (on the laptop) uses in its conf: debug_level 1 setuid off gridname "LocalGrid" data_source "GangliaGrid" localhost:8666 trusted_hosts 127.0.0.1 xml_port 18651 interactive_port 18652 rrd_rootdir rrds Unfortunately I see only timeouts. Sources are ... Source: [GangliaGrid, step 15] has 1 sources 127.0.0.1 Data thread 140659923203840 is monitoring [GangliaGrid] data source 127.0.0.1 poll() timeout from source 0 for [GangliaGrid] data source after 0 bytes read If I use the same ganglia grid name in both gmetad's, gmetad dies immediately. Any idea what's going on? Best regards, Erich Am 23.06.2014 19:13, schrieb Rushton Martin: > I've just updated to ganglia 3.6.0 and am trying to get a "grid of > grids" configuration working. I started with the original grid which is > visible through gweb. I built a new gmetad.conf for the new grid and > that works fine when viewed from a new instance of gweb. The new grid > uses port 8655 for XML and 8656 for queries. Using telnet to dump the > XML also works fine and there are no obvious structural differences > between it and the output from the original gmetad. However, when I add > the line: > > data_source "Management" localhost:8655 > > to the master gmetad, not only do I see no output but I see repeated > error messages in /var/log/messages: > > Process XML (Management): XML_ParseBuffer() error at line 1: no > element found > > I tried scanning the archives and saw similar (but not identical) errors > reported from a few years ago. I gather there was a known bug in gmetad > that caused inputs from other gmetads to be rejected. So: > > 1)Is the bug still there? > 2)Is there a work around? > 3)Have I misconfigured it? > > Any advice gratefully received. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general
