Графит перестает собирать данные случайным образом

8

У нас есть сервер Graphite для сбора данных с помощью collectd, statsd, JMXTrans ... Уже несколько дней у нас часто возникают дыры в наших данных. Перебирая данные, которые у нас еще есть, мы видим увеличение размера углеродного кэша (с 50К до 4М). Мы не видим увеличения количества собранных метрик (metricsReceived стабилен на отметке 300K). Мы имеем увеличение количества запросов в среднем с 1000 до 1500.

Как ни странно, cpuUsage немного уменьшается со 100% (у нас 4 процессора) до 50% при увеличении размера кеша.

Как ни странно, мы видим увеличение количества считанных октетов с диска и уменьшение количества записанных октетов.

У нас есть углеродная конфигурация в основном со значениями по умолчанию:

MAX_CACHE_SIZE = inf
MAX_UPDATES_PER_SECOND = 5000
MAX_CREATES_PER_MINUTE = 2000

Очевидно, что что-то изменилось в нашей системе, но мы не понимаем, что и как мы можем найти эту причину ...

Любая помощь ?

graphite metrics

— Гийом
источник

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

— Стефан

Мы проверили дисковое пространство и разрешение, ничего странного там нет. Без изменений в демоне, собирающем данные, возможно увеличение количества метрик, но не настолько большое. Мы смотрим на коррупцию WSP.

— Гийом

2

Это не ошибка графического стека, а скорее узкое место ввода-вывода, скорее всего потому, что в вашем хранилище недостаточно высоких IOPS. Из-за этого очередь продолжает накапливаться и переполняется в 4M. В этот момент вы теряете столько данных в очереди, что позже отражается в виде случайных «пробелов» в вашем графике. Ваша система не может следить за масштабом получения метрик. Это продолжает заполняться и переполняться .

Как ни странно, cpuUsage немного уменьшается со 100% (у нас 4 процессора) до 50% при увеличении размера кеша.

Это связано с тем, что ваша система начинает обмениваться, а процессоры много времени простаивают из-за ожидания ввода-вывода.

Чтобы добавить контекст, у меня есть 500 предоставленных IOPS в aws в системе, в которой я получаю приблизительно 40K метрик. Очередь стабильна на 50К.

— erbdex
источник

Я вижу точно такую же проблему, описанную в вопросе. Тем не менее, использование диска минимально (как сообщается, 0% -3% сверху), и я только проталкиваю ~ 80 метрик / с через StatsD. Поэтому кажется маловероятным, что у меня узкое место IO. Любая идея о том, что может быть причиной проблемы?

— Хейман

1

Другой отвечающий упомянул узкое место дискового ввода / вывода. Я расскажу о узких местах сети как о другой причине этого.

В моей среде мы запускаем кластер серверов интерфейса пользователя (httpd, memcached); другой кластер реле среднего уровня (carbon-c-relay, выполняющий пересылку и агрегацию); и внутренний уровень (httpd, memcached, carbon-c-relay и carbon-cache.) Каждый из этих кластеров состоит из нескольких экземпляров в EC2 и в общей сложности обрабатывает 15 миллионов метрик в минуту.

У нас была проблема, когда мы видели пробелы для метрик, сгенерированных агрегатной функцией «сумма», а также агрегированные значения были неверными (слишком низкими). Проблему можно было бы решить, перезапустив углерод-с-реле в среднем слое, но через несколько часов пробелы снова начали бы появляться.

Агрегирование происходило как на среднем уровне, так и на внутреннем уровне (внутренний уровень агрегировал агрегированные метрики, переданные ему из среднего уровня).

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

Точное место в сетевом стеке, где было узкое место? Я не мог тебе сказать. Это могло быть на хостах Linux; это могло быть на стороне Амазонки.

— Майкл Мартинес
источник