In many environments where multicast can't be used for one reason or another, and multiple clusters within ganglia need to be maintained, the need arises to have multiple ganglia target hosts specified.
For example, in gmond for one cluster, I might have two udp_send_client statements like:
And then define a cluster within gmetad with those two hosts as data_sources.
It currently seems impossible to mix jmxetric into an environment like this. I propose one of two ways to correct this:
1) Either in gmetric4j or jmxetric itself, we parse a limited set of configuration directives from gmond.conf, if present, particularly the udp_send_channel stanzas. This would closely mimic the behavior of the gmetric command line tool.
2) Allow multiple configuration elements to be specified. In this way, I could push out a jboss-jmxetric.xml file alongside gmond.conf, with the same set of hosts specified in both files.
In many environments where multicast can't be used for one reason or another, and multiple clusters within ganglia need to be maintained, the need arises to have multiple ganglia target hosts specified.
For example, in gmond for one cluster, I might have two udp_send_client statements like:
udp_send_channel { bind_hostname = yes host = 128.118.58.126 port = 8649 ttl = 1 }
udp_send_channel { bind_hostname = yes host = 128.118.58.163 port = 8649 ttl = 1 }
And then define a cluster within gmetad with those two hosts as data_sources.
It currently seems impossible to mix jmxetric into an environment like this. I propose one of two ways to correct this:
1) Either in gmetric4j or jmxetric itself, we parse a limited set of configuration directives from gmond.conf, if present, particularly the udp_send_channel stanzas. This would closely mimic the behavior of the gmetric command line tool.
2) Allow multiple configuration elements to be specified. In this way, I could push out a jboss-jmxetric.xml file alongside gmond.conf, with the same set of hosts specified in both files.