После дальнейшего исследования я нашел ответ. На моих клиентах я добавил следующее к gmond.conf:
udp_send_channel {
host = monitoring-host
port = 8666
ttl = 1
}
udp_send_channel {
host = monitoring-host-backup
port = 8666
ttl = 1
}
Это отправляет данные через одноадресную передачу UDP к контролирующему хосту и резервному копированию каждая 1 секунда.
Затем на контролирующем хосте, я добавил это:
udp_recv_channel {
port = 8666
}
Ключ должен избавиться от многоадресной записи, которая является там по умолчанию.
Это работает, но проблема состоит в том, что все узлы закончатся в том же источнике данных по умолчанию, таким образом, их Кластерная информация будет потеряна, который не так хорош для мультикластерных сред.
Я еще не попробовал, но возможное обходное решение для этого должно было бы создать канал UDP для каждого кластера, который не так хорош, если у Вас есть многие из них.
Более позднее редактирование:
Моя текущая установка использует одноадресную передачу на кластерном уровне из-за сетевых ограничений, и все данные становятся отправленными в узел от каждого кластера. Затем я связываюсь с каждым из тех, которые используют распределенный для получения всех данных относительно того кластера.
Таким образом, кластеры будут присвоены своим собственным источникам данных, и их полная информация будет там.
Конфигурация была бы похожа на это:
# on each node in the cluster
udp_send_channel {
host = 1.2.3.4 # this is a member of the cluster, not a metad server
port = 8650
}
Затем на распределенном:
data_source "My Cluster" 1.2.3.4
Для дублирования у Вас может быть несколько udp_send_channel записей и несколько, дюйм/с перечислил в data_source. Я лично использую два для каждого кластера.
Для федерации я использую что-то вроде этого:
data_source "My Grid" 1.2.3.5:8651
Это допустимо, только если у Вас есть распределенное слушание на порте 8651 там.
Столкнулся с той же проблемой с режимом многоадресной рассылки при настройке Ganglia в облаке Amazon EC2, что предотвращает использование многоадресной рассылки в его сети. Возможное решение - переключиться в режим одноадресной рассылки, который, к счастью, работает.
Чтобы быть очень кратким, ниже приведены простые шаги, чтобы избавиться от режима многоадресной рассылки.
Пример: есть 10 узлов, на которых запущен демон gmond. Выберите любой узел из 10 и сделайте тот Мастер, который будет получать все данные даже с 10 узлов, также должен быть самим ведомым.
# Define the cluster.
cluster {
name = "Yellow"
owner = "Your Company"
latlong = "N34.02 W118.45"
url = "http://yourcompany.com/"
}
# Disable multicast and define the host, the yellow master, where nodes in the cluster send data.
udp_send_channel {
# mcast_join = 239.2.11.71 (No need to join as mcast is not being used)
host = master.among10node.com (put the IP/Hostname of server from any 10 nodes to ack as master)
port = 8649
ttl = 1
}
udp_recv_channel {
# mcast_join = 239.2.11.71 (Disabled mcast as it is not being used)
port = 8649
# bind = 239.2.11.71 (No need to bind as mcast is not being used)
}
Примечание: скопируйте одну и ту же конфигурацию на все 10 узлов, на которых работает демон gmond. Сначала перезапустите Мастер, затем все остальные. Надеюсь, что это сработает, и главный узел будет получать все данные с других узлов. Мохд Мозаммил Хан
See also:
https://github.com/ganglia/monitor-core/tree/feature/cloud
I installed it today and got it working on EC2 which doesn't allow multicast.