Зачем использовать statsd, если агрегатор углерода графита может выполнять ту же работу?

1. StatsD работает через UDP, что устраняет риск того, что carbon-aggregator.py будет медленно отвечать и вызвать задержку в вашем приложении. Другими словами, слабая связь.

2. StatsD поддерживает выборку входящих показателей, что полезно, когда вы не хотите, чтобы ваш агрегатор брал 100% всех точек данных для вычисления описательной статистики. Для участков кода большого объема обычно используется частота дискретизации 0,5% -1%, чтобы не перегружать StatsD.

3. StatsD имеет широкую клиентскую поддержку.

tldr: вам, вероятно, понадобится statsd (или carbon-c-relay), если вы когда-нибудь захотите посмотреть суммы или средние значения для конкретного сервера.

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

Пример statsd: предположим, что ваш файл graphite storage-schemas.conf имеет минимальное время хранения 10 секунд (по умолчанию) и ваше приложение отправляет примерно 100 точек данных каждые 10 секунд в services.login .server1.count со значением 1. без statsd графит будет хранить только последний полученный счет в каждой 10-секундной корзине. после получения 100-го сообщения остальные 99 точек данных были бы выброшены. однако, если вы поместите statsd между вашим приложением и графитом, тогда он суммирует все 100 точек данных перед отправкой общего количества в графит. Итак, без statsd ваш график показывает только , вход в систему в течение 10-секундного интервала. с statsd он указывает сколько входов в систему за этот интервал. (например)

Пример агрегатора углерода: предположим, что у вас есть 200 разных серверов, передающих 200 отдельных показателей (services.login.server1.response.time, services.login.server2.response. время и т. д.). на панели управления операциями вы показываете график среднего значения по всем серверам, используя этот графитовый запрос: weightedAverage (services.login.server * .response.time, services.login.server * .response.count, 2). К сожалению, рендеринг этого графика занимает 10 секунд. Чтобы решить эту проблему, вы можете добавить правило агрегатора углерода, чтобы предварительно вычислить среднее значение по всем вашим серверам и сохранить значение в новой метрике. теперь вы можете обновить свою панель управления, чтобы просто получить одну метрику (например, services.login.response.time). новая метрика отображается почти мгновенно.

боковые примечания:

1. правила агрегации в storage-aggregation.conf применяются ко всем интервалам хранения в storage-schemas.conf кроме первого (наименьшего) периода хранения для каждой строки хранения. можно использовать агрегатор углерода для агрегирования точек данных в рамках метрики для этого первого периода хранения. к сожалению, aggregation-rules.conf использует шаблоны "blob", а не шаблоны регулярных выражений. поэтому вам нужно добавить отдельную запись в файл aggregation-rules.conf для каждой глубины пути и типа агрегации. Преимущество statsd заключается в том, что клиент, отправляющий метрику, может указывать тип агрегирования, а не кодировать его в пути метрики. Это дает вам возможность добавлять новую метрику на лету независимо от глубины пути метрики. Если вы хотите настроить углеродный агрегатор на автоматическое агрегирование, подобное statsd, при добавлении новой метрики, ваш файл aggregation-rules.conf будет выглядеть примерно так:

   <n1>.avg (10)= avg <n1>.avg$
   <n1>.count (10)= sum <n1>.count$
   <n1>.<n2>.avg (10)= avg <n1>.<n2>.avg$
   <n1>.<n2>.count (10)= sum <n1>.<n2>.count$
   <n1>.<n2>.<n3>.avg (10)= avg <n1>.<n2>.<n3>.avg$
   <n1>.<n2>.<n3>.count (10)= sum <n1>.<n2>.<n3>.count$
   ...
   <n1>.<n2>.<n3> ... <n99>.count (10)= sum <n1>.<n2>.<n3> ... <n99>.count$
   

   примечания: завершающий символ "$" не нужен в графите 0.10+ (в настоящее время предварительная версия) здесь это соответствующий патч на github, а вот стандартная документация по правила агрегирования

2. функция weightedAverage является новой в графите 0.10, но обычно функция averageSeries дает очень похожее число, если ваша нагрузка равномерно сбалансирована. если у вас есть серверы, которые работают медленнее и обслуживают меньше запросов, или вы просто приверженец точности, то вы все равно можете рассчитать средневзвешенное значение с помощью графита 0,9. вам просто нужно построить более сложный запрос вроде этого:

   divideSeries(sumSeries(multiplySeries(a.time,a.count), multiplySeries(b.time,b.count)),sumSeries(a.count, b.count))
   

3. если statsd запускается на клиентском компьютере, это также снижает нагрузку на сеть. хотя теоретически вы можете запустить углеродный агрегатор и на стороне клиента. однако, если вы используете одну из клиентских библиотек statsd, вы также можете использовать выборку, чтобы снизить нагрузку на ЦП вашего компьютера приложения (например, создание пакетов udp с обратной связью). кроме того, statsd может автоматически выполнять несколько различных агрегатов для одной входной метрики (сумма, среднее, минимальное, максимальное и т. д.)

4. если вы используете statsd на каждом сервере приложений для агрегирования времени отклика, а затем повторно агрегируете эти значения на графитовом сервере с помощью агрегатора углерода, вы получаете среднее время отклика, взвешенное по серверу приложений, а не по запросу. очевидно, это имеет значение только для агрегирования с использованием правила агрегирования mean или top_90, но не min, max или sum. Кроме того, это имеет значение только для среднего, если ваша нагрузка неуравновешена. в качестве примера: предположим, что у вас есть кластер из 100 серверов, и внезапно на 1 сервер отправляется 99% трафика. как следствие, время отклика увеличивается в четыре раза на этом 1 сервере, но остается стабильным на остальных 99 серверах. если вы используете агрегацию на стороне клиента, ваш общий показатель вырастет только примерно на 3%. но если вы выполните всю агрегацию в одном агрегаторе углерода на стороне сервера, то общий показатель вырастет примерно на 300%.

5. carbon-c-relay, по сути, является заменой для углеродного агрегатора, написанного на c . в нем улучшена производительность и улучшены правила сопоставления на основе регулярных выражений. Результатом является то, что вы можете выполнять как агрегацию точек данных в стиле statsd, так и метрическую агрегацию в стиле углеродного реле, а также другие полезные вещи, такие как многоуровневое агрегирование, в одном и том же простом файле конфигурации на основе регулярных выражений.

6. если вы используете внутреннюю часть цианита вместо углеродного кеша, то цианит будет выполнять внутриметрическое усреднение за вас в память (начиная с версии 0.5.1) или во время чтения (в версии ‹0.1 .3 архитектура).

Если агрегатор Carbon предлагает все необходимое, нет причин не использовать его. У него есть две основные функции агрегирования (сумма и среднее), и действительно, они не охватываются StatsD. (Я не уверен насчет истории, но, возможно, агрегатор Carbon уже существовал, и авторы StatsD не хотели дублировать функции?) Прием данных через UDP также поддерживается Carbon, поэтому единственное, что вы могли бы пропустить, это выборка , что не имеет значения, если вы производите агрегирование путем усреднения.

StatsD поддерживает различные типы показателей, добавляя дополнительные агрегированные значения (например, для таймеров: средний, нижний, верхний и верхний X-й процентиль, ...). Они мне нравятся, но если они вам не нужны, агрегатор Carbon - тоже хороший вариант.

Я изучал исходный код агрегатора Carbon и StatsD (а также Bucky, реализацию StatsD в Python), и все они настолько просты, что я бы не стал беспокоиться об использовании ресурсов или производительности в любом случае.

Похоже, агрегатор углерода и statsd поддерживают несвязанный набор функций:

• statsd поддерживает расчет и суммирование ставок, но не поддерживает значения усреднения
• агрегатор углерода поддерживает усреднение, но не поддерживает расчет ставок.

Поскольку графит имеет минимальное разрешение, вы не можете сохранить два разных значения для одной и той же метрики в течение определенного интервала. StatsD решает эту проблему, предварительно объединяя их, и вместо того, чтобы говорить «1 пользователь зарегистрирован сейчас» и «1 пользователь зарегистрирован сейчас», он говорит «2 пользователя зарегистрированы».

Другая причина - производительность, потому что:

1. Вы отправляете данные в StatsD через UDP, который является протоколом «выстрелил и забыл», без сохранения состояния, намного быстрее
2. Реализация StatsD etsy находится в NodeJS, что также значительно увеличивает производительность.