Графит показывает «Нет» для всех точек данных, даже если я отправляю данные

8

Я установил Graphite через Puppet ( https://forge.puppetlabs.com/dwerder/graphite ) с nginx и PostgresSQL. Когда я отправляю ему данные вручную, он создает метрику, но все его точки данных имеют значение «Нет» (иначе говоря, ноль). Это также происходит, если я запускаю example-client.py, поставляемый с Graphite.

echo "jakub.test 42 $(date +%s)" | nc 0.0.0.0 2003 # Carbon listens at 2003
# A minute or so later:
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | head -n1
Sun May  4 12:19:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | tail -n1
Mon May  5 12:09:00 2014    None
$ whisper-fetch.py --pretty /opt/graphite/storage/whisper/jakub/test.wsp | grep -v None | wc -l
0

А также:

$ python /opt/graphite/examples/example-client.py 
# Wait until it sends two batches of data ...
$ whisper-fetch.py /opt/graphite/storage/whisper/system/loadavg_15min.wsp | grep -v None | wc -l
0

Согласно ngrep, это данные, поступающие в порт [из более поздней попытки] (строка 3):

####
T 127.0.0.1:34696 -> 127.0.0.1:2003 [AP]
  jakub.test  45 1399362193. 
####^Cexit
23 received, 0 dropped

Это соответствующая часть /opt/graphite/conf/storage-schemas.conf:

[default]
pattern = .*
retentions = 1s:30m,1m:1d,5m:2y

Есть идеи, что не так? Собственные показатели и данные Carbon отображаются в пользовательском интерфейсе. Спасибо!

Окружающая среда: Ubuntu 13.10 Saucy, графит 0.9.12 (через пипс).

PS: я написал о моих попытках устранения проблем здесь - Графит Показывает Метрики, но Нет Данных - Устранение проблем

ОБНОВЛЕНИЕ :

  1. Точки данных в шепотных файлах записываются только каждые 1 мин, даже если в политике хранения указана более высокая точность, например «1 с» или «10 с».
  2. Обходной путь для игнорируемых данных: либо используйте схему агрегирования с xFilesFactor = 0.1(вместо 0,5), либо установите наименьшую точность равной 1 м вместо <число между 1-49> с. - см. комментарии ниже принятого ответа или графического ответа. Согласно документам : « xFilesFactorдолжно быть числом с плавающей запятой от 0 до 1 и указывает, какая часть слотов предыдущего уровня хранения должна иметь ненулевые значения для агрегирования в ненулевое значение. По умолчанию 0,5 ». Таким образом, кажется, что без учета заданной точности 1 с, данные агрегируются за 1 минуту и ​​заканчиваются значением None, потому что менее 50% значений в минутном периоде не являются None.

РЕШЕНИЕ

Так @jlawrie приведет меня к решению. Получается, что данные на самом деле есть, но они сводятся к нулю, причина двойная:

  1. И пользовательский интерфейс, и шепотная выборка показывают данные, агрегированные с максимальной точностью, охватывающей весь период запроса, который по умолчанию равен 24 часам. Т.е. что-либо с сохранением <1d никогда не будет отображаться в пользовательском интерфейсе или при извлечении, если вы не выберете более короткий период. Так как мой период хранения в течение 1 с составлял 30 минут, мне нужно было выбрать период <= последние 30 минут, чтобы фактически увидеть необработанные данные с наивысшей точностью, которые собираются.
  2. При агрегировании данных (от 1 с до 1 мин в моем случае) Graphite по умолчанию требует, чтобы 50% (xFilesFactor = 0,5) точек данных в периоде имели значение. Если нет, он игнорирует существующие значения и объединяет их в None. Так что в моем случае мне нужно было бы отправлять данные как минимум 30 раз в минуту (30 означает 50% от 60 с = 1 мин), чтобы они отображались в агрегированном 1-минутном значении. Но мое приложение отправляет данные только каждые 10 секунд, поэтому у меня есть только 6 из 60 возможных значений.

=> решение состоит в том, чтобы изменить первую точность от 1 с до 10 с и не забудьте выбрать более короткий период, когда я хочу видеть необработанные данные (или увеличить его время хранения до 24 ч, чтобы показать его по умолчанию).

Якуб Холи
источник
Графит Ответы на вопрос Набор данных заполнен нулями? Интересно в этом контексте (упоминается добавление по умолчанию нуля каждые 60 секунд, только последние 24 часа) и b / c рекомендация ngrep для устранения неполадок.
Якуб Холи
Я попросил помочь также в Графитных ответах - answers.launchpad.net/graphite/+question/248242
Якуб Холи
Вы проверили логи? Если есть проблема с полученной метрикой (нет \ n или используйте \ r \ n вместо этого), вы должны увидеть что-то в console.log или create.log. Эти журналы хранятся в / opt / graphite / storage / log / carbon-cache / carbon-cache-a /, если вы использовали путь установки по умолчанию.
mattsn0w
Да, я проверил логи. Там не было ничего интересного. Журнал консоли содержал только «[..] ServerFactory, начиная с 7002 [..] Начальная фабрика <экземпляр twisted.internet.protocol.ServerFactory по адресу 0x1bc4248>», и имел записи о создании ожидаемых метрик, но без упоминания данных - f. ех. (для другой метрики без данных) "[..] создание файла базы данных /opt/graphite/storage/whisper/ring/handling-time/POST/15MinuteRate.wsp (archive = [(1, 1800), (60, 1440) ), (300, 210240)] xff = 0,5 агг = среднее) "
Якуб Холи
@ JakubHolý Не могли бы вы обновить ответ Джлаври или опубликовать другой ответ, так как вопрос содержит ответ сейчас
030

Ответы:

8

Я столкнулся с той же проблемой, используя тот же модуль кукол. Я не совсем уверен, почему, но изменение политики хранения по умолчанию, кажется, исправить это, например

class { 'graphite':
  gr_storage_schemas => [
    {
      name       => 'carbon',
      pattern    => '^carbon\.',
      retentions => '1m:90d'
    },
    {
      name       => 'default',
      pattern    => '.*',
      retentions => '1m:14d'
    }
  ],
}
jlawrie
источник
Большое спасибо! Это таинственное изменение действительно помогло. Интересно, что изменение удержания с «1с: 30м, 1м: 1д, 5м: 2г» на «1м: 14д» действительно «исправляет» это. Я постараюсь играть больше с этим. Может быть, есть какая-то проблема с гранулярностью 1s?
Якуб Холи
Это действительно кажется проблемой с периодом s - пока '1m:1d,5m:2yработает (данные записаны), 10s:30m,1m:1d,5m:2yнет. На самом деле, из файла .wsp кажется, что гранулярность <1m игнорируется, поскольку временные метки для 10s: ... все еще с интервалом в 1 минуту - «08:17:00, 08:18:00 и т. Д.»
Якуб Холи
Итак, проблема связана с политикой агрегации и xFilesFactor(по умолчанию), которая применяется здесь, является средней и xFilesFactor=0.5(см. /opt/graphite/conf/storage-aggregation.conf). Когда я меняю имя sumи изменяю 0.1имя, данные сохраняются (хотя точка все еще находится на частоте 1 м):echo -e "jakub.test.10s30m+1m1d+5m2y.count 42 $(date +%s)" | nc 0.0.0.0 2003
Якуб Холи
Я играл с разницей. AGGREG. Схемы, данные записываются (с интервалом 1 м), когда я установил xFilesFactor = 0.1, Agg. Метод не имеет значения (по крайней мере, все среднее, последнее, сумма работы).
Якуб Холи
В соответствии с этим схемы агрегации вступают в игру только с несколькими политиками хранения. Если у меня есть только одна политика хранения, даже с разрешением 10 секунд (то есть как часто я отправляю данные), она собирает каждую отдельную точку данных. При наличии нескольких политик хранения она выбирает ту, которая основана на временном интервале запроса, который по умолчанию с параметром whisper-fetch.py ​​по умолчанию используется до последнего дня, поэтому я думаю, что вы видите точки данных только каждую минуту. Все еще не уверен, почему они показывают None вместо агрегированной стоимости.
Джоулри
1

Есть много способов, которыми Graphite потеряет данные, поэтому я действительно стараюсь избегать их использования. Позвольте мне начать с простого - попробуйте подключить ваше приложение, подождите секунду (буквально одну секунду) и затем выведите данные с метками времени. Я обнаружил, что во многих случаях это решит эту проблему. Еще одна вещь, которую вы должны попробовать - это отправлять данные с частотой, которая намного выше, чем частота, с которой графит регистрирует данные. Я углублюсь в это немного больше. Еще одна частая ошибка - использование утилиты whisper-resize.py, которая на самом деле не работает для меня. Если ваши данные еще не важны, просто удалите шепотные файлы и дайте им создать новые параметры хранения.

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

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

Немного Linux Nerd
источник
Спасибо, я думаю, мне следует больше узнать о том, как работает поиск и агрегация данных, возможно, это действительно является причиной проблемы. Однако я думаю, что « отправка данных с частотой, которая была намного выше, чем частота, на которой графит хранил данные », является неоптимальным решением, поскольку записывается только последняя точка данных, полученная в каждом периоде графита, другие игнорируются - вот почему f.ex , statsD период промывки должен = период графита .
Якуб Холи
1
Кстати, данные «потери» графита / углерода могут быть связаны с настройками углерода, такими как MAX_UPDATES_PER_SECOND = 500, MAX_CREATES_PER_MINUTE = 50 (я думаю, что точки данных / показатели сверх лимита просто сбрасываются).
Якуб Холи
Кажется, я ошибся, в документации - если я правильно ее интерпретирую - говорится, что приведенные выше настройки ограничивают доступ к диску, но данные / метрики все еще хранятся в памяти (хотя я хотел бы действительно проверить это в первую очередь).
Якуб Холи
Некоторые из них могут определенно объяснить некоторые проблемы, которые у меня были с этим приложением.
Немного Linux Nerd