Ганглии без многоадресной передачи

Символы :) Симпсонов

5
задан 9 June 2009 в 03:03
4 ответа

После дальнейшего исследования я нашел ответ. На моих клиентах я добавил следующее к 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
}

Ключ должен избавиться от многоадресной записи, которая является там по умолчанию.

5
ответ дан 3 December 2019 в 01:17

Это работает, но проблема состоит в том, что все узлы закончатся в том же источнике данных по умолчанию, таким образом, их Кластерная информация будет потеряна, который не так хорош для мультикластерных сред.

Я еще не попробовал, но возможное обходное решение для этого должно было бы создать канал 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 там.

2
ответ дан 3 December 2019 в 01:17

Столкнулся с той же проблемой с режимом многоадресной рассылки при настройке Ganglia в облаке Amazon EC2, что предотвращает использование многоадресной рассылки в его сети. Возможное решение - переключиться в режим одноадресной рассылки, который, к счастью, работает.

Чтобы быть очень кратким, ниже приведены простые шаги, чтобы избавиться от режима многоадресной рассылки.

  1. Сделайте один из ваших узлов мастером, запустив gmond (сборщик данных ганглиев) демон.

Пример: есть 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. Сначала перезапустите Мастер, затем все остальные. Надеюсь, что это сработает, и главный узел будет получать все данные с других узлов. Мохд Мозаммил Хан

2
ответ дан 3 December 2019 в 01:17

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.

0
ответ дан 3 December 2019 в 01:17

Теги

Похожие вопросы