running "nc host_running_gmetad 8651” giving me "nc: getaddrinfo: Name or service not known"
I did get full set of metric from gmetad -d 5: Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: heartbeat host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: gexec host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: mem_free host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: mem_shared host:x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: mem_buffers host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: mem_cached host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: swap_free host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: cpu_user host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: cpu_system host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: cpu_idle host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: cpu_nice host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: cpu_aidle host: x.x.x.x Processing a metric metadata request message from x.x.x.x setting metadata request flag for metric: cpu_wio host: x.x.x.x Processing a metric metadata request message from x.x.x.x > On Jun 5, 2015, at 12:05 PM, Jesse Becker <haw...@gmail.com> wrote: > > Run "nc host_running_gmetad 8651". You should a large XML dump that > includes many metrics on a per-host basis (and possibly per-grid, if > you are using a federated configuration). > > The debugging output is incredibly verbose, and probably not helpful right > now. > > Also run "nc" against the gmond collector, to make sure it has the > metrics it should. > > On Fri, Jun 5, 2015 at 11:40 AM, Paul <p...@space.mit.edu > <mailto:p...@space.mit.edu>> wrote: >> Hi Jesse, >> >> Here are the output from gmod and gmetad. x.x.x.xs are all correct IPs. I >> know gmond works right. I ran tcpdump and got correct connections and ports. >> I am not sure the output from gmetad is normal or missing any piece. >> >> Thanks, >> paul >> >> >> # gmond -d 5 >> loaded module: core_metrics >> loaded module: cpu_module >> loaded module: disk_module >> loaded module: load_module >> loaded module: mem_module >> loaded module: net_module >> loaded module: proc_module >> loaded module: sys_module >> loaded module: multicpu_module >> loaded module: python_module >> udp_recv_channel mcast_join=NULL mcast_if=NULL port=8656 bind=NULL buffer=0 >> socket created, SO_RCVBUF = 124928 >> >> tcp_accept_channel bind=NULL port=8656 gzip_output=0 >> [tcp] Starting TCP listener thread... >> Processing a metric metadata request message from x.x.x.x >> setting metadata request flag for metric: heartbeat host: x.x.x.x >> Processing a metric metadata request message from x.x.x.x >> setting metadata request flag for metric: gexec host: x.x.x.x >> ……. >> >> >> # gmetad -d 10 >> Going to run as user nobody >> Sources are ... >> Source: [testhpc, step 15] has 1 sources >> x.x.x.x (IP1-correct) >> Source: [engaging, step 15] has 1 sources >> x.x.x.x (IP2-correct) >> Source: [c3ddb, step 15] has 1 sources >> x.x.x.x (IP3-correct) >> xml listening on port 8651 >> interactive xml listening on port 8652 >> Data thread 140100751070976 is monitoring [testhpc] data source >> x.x.x.x (IP1-correct) >> Data thread 140100740581120 is monitoring [engaging] data source >> x.x.x.x (IP2-correct) >> Data thread 140100730091264 is monitoring [c3ddb] data source >> x.x.x.x (IP3-correct) >> cleanup thread has been started >> [c3ddb] is a 2.5 or later data stream >> hash_create size = 1024 >> hash->size is 1024 >> hash_create size = 50 >> hash->size is 64 >> hash_create size = 50 >> hash->size is 64 >> hash_create size = 50 >> …… >> hash->size is 64 >> hash_create size = 50 >> hash->size is 64 >> hash_create size = 50 >> hash->size is 64 >> [cluster1] is a 2.5 or later data stream >> hash_create size = 1024 >> hash->size is 1024 >> hash_create size = 50 >> hash->size is 64 >> hash_create size = 50 >> hash->size is 64 >> …… >> hash->size is 64 >> hash_create size = 50 >> hash->size is 64 >> hash_create size = 50 >> hash->size is 64 >> [cluster1] is a 2.5 or later data stream >> [cluster2] is a 2.5 or later data stream >> [cluster3] is a 2.5 or later data stream >> …… >> >> >> >> On Jun 5, 2015, at 10:12 AM, Paul <p...@space.mit.edu> wrote: >> >> Hi Jesse, >> >> gmon got changed to goon by auto spell check. The little bunny foo foo was >> funny. :0) >> >> Anyway, I did double, triple check for rrd_rootdir and permission. I tried >> to set it wrong for testing and I would get error when I ran debug mode. I >> assume everything is running without error but maybe missing something I did >> not see. >> >> Thanks for the quick response. >> >> paul >> >> >> On Jun 5, 2015, at 9:58 AM, Jesse Becker <haw...@gmail.com> wrote: >> >> "goon?" >> >> Not familar with that, except in hockey and nursery rhymes[1]. >> >> Gmetad is responsible for creating the RRD files. Make sure the value >> for "rrd_rootdir" in gmetad.conf is correct, and that gmetad has >> proper permissions to write there (as defined by the >> setuid/setuid_username settings and/or startup scripts). Note that >> the webserver will also need read access to these files as well. >> >> >> [1] http://en.wikipedia.org/wiki/Little_Bunny_Foo_Foo >> >> >> On Fri, Jun 5, 2015 at 9:21 AM, Paul <p...@space.mit.edu> wrote: >> >> Hi, >> >> I am running ganglia-web 3.6.2 and ganglia 3.7.1. Everything seems working >> except I could not get rrd files. So I am getting blank charts on web page. >> Both gmetad -d 5 and goon -d 5 indicated that I am getting connected to the >> goon feed without any issue. log message did not show any error. Does anyone >> running into the same problem? >> >> Thanks, >> paul >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Ganglia-general mailing list >> Ganglia-general@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ganglia-general >> >> >> >> >> -- >> Jesse Becker >> >> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Ganglia-general mailing list >> Ganglia-general@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/ganglia-general >> >> > > > > -- > Jesse Becker
------------------------------------------------------------------------------
_______________________________________________ Ganglia-general mailing list Ganglia-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-general