Bosun HA и масштабируемость

Question

У меня есть небольшая настройка bosun и сбор метрик от многочисленных сервисов, и мы планируем масштабировать эти сервисы в облаке. Это будет означать, что в bosun поступает больше данных, и, следовательно, влияет нагрузка / эффективность / масштаб bosun.

Я боюсь потерять данные из-за перегрузки сети и в случае сбоев.

Я ищу отчеты о тестах производительности для bosun или какие-либо материалы по тестированию и тестированию bosun для масштаба и HA.

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

В настоящее время я думаю о том, чтобы запустить множество двоичных файлов bosun как кластер, поддерживаемый распределенной настройкой opentsdb. Кроме того, я думаю, стоит ли запускать некоторых исполнителей босунов в качестве простых "сборщиков" данных сколлектора (с bosun -n команда), а некоторые просто рассчитать оповещения.

Проблема этого подхода заключается в том, что одни и те же оповещения могут запускаться из нескольких экземпляров bosun (без опций -n). Есть ли лучший способ удалить дубликаты предупреждений?

Answer 1

Текущие лучшие практики:

1. Используйте https://godoc.org/bosun.org/cmd/tsdbrelay для пересылки метрик в opentsdb. Это выводит двоичный файл Босуна из "критического пути". Он также должен пересылать метрики в bosun для индексации и может дублировать поток метрик в несколько центров обработки данных для резервного копирования / восстановления.
2. Убедитесь, что ваш кластер hadoop / opentsdb имеет как минимум 5 узлов. Вы не можете выполнять оперативное обслуживание в кластере с 3 узлами, а hadoop обычно работает на дюжине или более узлов. Мы используем Cloudera Manager для управления кластером hadoop, а другие рекомендуют Apache Ambari.
3. Используйте балансировщик нагрузки, такой как HAProxy, чтобы разделить трафик записи / api / put на несколько экземпляров tsdbrelay в активном / пассивном режиме. Мы запускаем один экземпляр на каждом узле (с переадресацией tsdbrelay на локальный экземпляр opentsdb) и направляем весь трафик записи на первичный узел записи (с несколькими вторичными / резервными узлами).
4. Разделите трафик / api / query между оставшимися узлами, указанными непосредственно на opentsdb (нет необходимости проходить через ретранслятор) в активном / активном режиме (так называемая круговая схема или маршрутизация на основе хеша). Это повышает производительность запросов, балансируя их между узлами без записи.
5. Мы запускаем только один экземпляр bosun в каждом центре обработки данных, при этом сайт DR использует флаг только для чтения (любое аварийное переключение будет ручным). Он действительно не предназначен для HA, но в будущем может позволить двум узлам совместно использовать экземпляр redis и разрешить активный / активный или активный / пассивный HA.

Используя tsdbrelay для дублирования потоков метрик, вам не нужно иметь дело с репликацией opentsdb / hbase, и вместо этого вы можете настроить несколько изолированных систем мониторинга в каждом центре данных и дублировать метрики для любых подходящих сайтов. У нас есть основной сайт и сайт аварийного восстановления, и мы решили дублировать все показатели в обоих центрах обработки данных. Я фактически использую сайт DR ежедневно для запросов Grafana, так как он ближе к месту моего проживания.

Вы можете найти более подробную информацию о производственных настройках на http://bosun.org/resources включая копии всех файлов конфигурации haproxy/tsdbrelay/etc, которые мы используем в Stack Overflow.