У нас есть сервер Graphite для сбора данных через collectd, statsd, JMXTrans ... Уже несколько дней в наших данных часто появляются дыры. Просматривая данные, которые у нас все еще есть, мы можем увидеть увеличение размера углеродного кеша (с 50 КБ до 4 МБ). Мы не видим увеличения количества собираемых метрик (metricsReceived стабильно составляет около 300 КБ). У нас количество запросов увеличилось в среднем с 1000 до 1500.
Как ни странно, cpuUsage немного уменьшается со 100% (у нас 4 ЦП) до 50% при увеличении размера кеша.
Как ни странно, мы видим увеличение количества октетов, считываемых с диска, и уменьшение количества записанных октетов.
У нас есть настройка углерода в основном со значениями по умолчанию:
Очевидно, что что-то изменилось в нашей системе, но мы не понимаем, что и как мы можем найти эту причину ...
Любая помощь ?
Это не ошибка графитового стека, а скорее узкое место ввода-вывода, скорее всего, из-за того, что ваше хранилище не имеет достаточно высокого IOPS. Из-за этого очередь продолжает расти и переполняется на 4M. В этот момент вы терять столько данных в очереди, которые позже отражаются в виде случайных «пробелов» на вашем графике. Ваша система не может успевать с масштабом, в котором он получает метрики. Он держит наполнение и переполнение.
Как ни странно, cpuUsage немного уменьшается со 100% (у нас 4 ЦП) до 50% при увеличении размера кеша.
Это связано с тем, что ваша система начинает заменять местами, а процессоры получают много «времени простоя» из-за ожидания ввода-вывода.
Чтобы добавить контекст, у меня есть 500 подготовленных операций ввода-вывода в секунду в aws в системе, на которой я получаю около 40 000 метрик. Очередь стабильная на 50К.
Другой ответчик упомянул узкое место ввода-вывода диска. Я расскажу об узких местах в сети как еще одной причине.
В моей среде мы запускаем кластер серверов пользовательского интерфейса переднего плана (httpd, memcached); другой кластер ретрансляторов среднего уровня (Carbon-c-relay, выполняющий пересылку и агрегацию); и внутренний уровень (httpd, memcached, carbon-c-relay и carbon-cache). Каждый из этих кластеров состоит из нескольких экземпляров в EC2 и в общей сложности обрабатывает 15 миллионов метрик в минуту.
У нас была проблема, когда мы видели пропуски для показателей, сгенерированных функцией агрегированной «суммы», а также агрегированные значения были неверными (слишком низкими). Проблему можно было бы решить, перезапустив углерод-с-реле в среднем слое, но через несколько часов снова начали появляться пробелы.
У нас была агрегация, происходящая как на среднем уровне, так и на внутреннем уровне (внутренний уровень агрегировал агрегированные метрики, переданные ему со среднего уровня).
Хосты среднего уровня не были привязаны к процессору, диску и не были ограничены по памяти. Это в сочетании с тем фактом, что проблема могла появиться только через несколько часов после перезапуска реле, означало, что возникло узкое место в сети. Нашим решением было просто добавить больше хостов на средний уровень. Это мгновенно привело к тому, что агрегированные метрики работали правильно и не испытывали пробелов.
Точное место в сетевом стеке, где было узкое место? Я не мог тебе сказать. Это могло быть на хостах linux; это могло быть со стороны Амазонки.