Назад | Перейти на главную страницу

Кластер графита / углерода, возвращающий неполные данные

Попытка настроить кластер Graphite / Carbon. У меня есть эластичный балансировщик нагрузки, который направляет трафик между двумя узлами в моем кластере, каждый из которых имеет одно веб-приложение, ретранслятор и кеш.

В этом примере я отправил в кластер 1000 отсчетов для Metric1.

Вот диаграмма:

Эта проблема

Как видно на диаграмме выше, на каждый сервер приходится примерно половина фактического количества метрик. При запросе через веб-приложение он возвращает только половину фактического количества. В соответствии с этот фантастический пост, это ожидаемое поведение, потому что веб-приложение возвращает первый увиденный результат. Это подразумевает (и задокументировано), что на узлах должны храниться только полные подсчеты (в моем примере один или оба узла должны иметь 1000.)

Таким образом, моя проблема заключается в неправильном сегментировании и репликации подсчета. В моем примере выше, когда новый счетчик приходит из Интернета, он может быть перенаправлен либо на NodeA, либо на NodeB. Я предполагал, что счетчики могут поступать в кластер через любое реле. Чтобы проверить это предположение, я удалил балансировщик нагрузки из кластера и направил все входящие подсчеты на реле NodeA. Это сработало: полный счет появился на одном узле, затем реплицировался на второй, и полный счет был правильно возвращен из веб-приложения.

Мой вопрос

В carbon-relay похоже, действует как балансировщик нагрузки на уровне приложения. Это нормально, однако меня беспокоит то, что, когда входящий трафик становится слишком большим, использование одного carbon-relay как балансировщик нагрузки станет узким местом и единственной точкой отказа. Я бы предпочел использовать настоящий балансировщик нагрузки, чтобы равномерно распределять входящий трафик между реле кластера. Тем не мение, carbon-relay не кажется, что играет хорошо, отсюда проблема, показанная выше.

Оказывается, моя конфигурация DESTINATIONS на самом деле указал на carbon-caches вместо другого carbon-relay, опечаткой порта #. Исправление конфигурации для реального представления схемы, изображенной в вопросе, похоже, решило проблему: теперь данные отображаются в полной форме на каждом узле (после репликации).

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

У вас проблема с авторитетом. Используя Whisper, каждая база данных временных рядов должна принадлежать одному-единственному демону углеродного кеша, иначе вы столкнетесь с проблемами согласованности, которые вы видите. Carbon-relay пытается решить эту проблему, последовательно отправляя один и тот же временной ряд в одну и ту же конечную точку. Это можно сделать либо с помощью механизма правил на основе регулярных выражений, либо с помощью согласованного хеширования.

Я бы порекомендовал не переусердствовать с проблемой, увеличивать масштаб до тех пор, пока вы больше не сможете, и только затем горизонтально. У нас есть одно углеродное реле, которое без проблем обрабатывает 350 000 показателей каждые 60 секунд на одном ядре Westmere EP, которому 5 лет. Если вы используете последовательное хеширование, это очень недорогая операция, чтобы выяснить, куда направить метрику вниз по течению. Если вы используете множество правил регулярных выражений, это требует большого количества сопоставлений строк, и вы можете намного быстрее попасть в стену производительности.

База данных Whisper не особенно эффективна. По всей вероятности, вы столкнетесь с узким местом в производительности ввода-вывода задолго до того, как реле начнет доставлять вам проблемы. Вы полностью переоцениваете свою архитектуру.

Если и когда вам действительно нужно масштабироваться за пределы того, что может дать вам один узел, вы можете либо маршрутизировать к конкретному реле на основе логики управления конфигурацией клиента, либо вы можете настроить ELB, который маршрутизирует несколько реле, которые каждый запускает. по одному и тому же набору правил и метрик маршрутизации к одним и тем же конечным точкам. Я считаю, что для этого потребуется использовать сопоставление на основе регулярных выражений, но согласованное хеширование также может работать, если ваши реле имеют ту же версию; Я никогда не тестировал этот подход.