Планирование емкости диска для Whisper / Graphite

14

Есть ли у кого-нибудь какие-нибудь формулы или, может быть, некоторые примеры данных из их среды, которые могут помочь мне оценить, сколько дискового пространства будет использовано графитом на точку данных?

Кайл Брандт
источник
2
Убедитесь, что вы также правильно планируете дисковый ввод-вывод, а не только емкость диска. За прошедшие годы rrdtool накопил много микрооптимизаций, которые делают его намного быстрее (в 2 раза быстрее?) при записи, чем формат базы данных Whisper в Graphite. Если вы планируете хранить все свои данные на приличном SSD, это поможет вам в этом, но я не планирую хранить целую тонну Whisper DB на вращающемся диске. В масштабе, это просто не рентабельно, что уровни дискового ввода / вывода, которые бросает Графит.
jgoldschrafe

Ответы:

7

whisper-info.py дает вам глубокое понимание того, что и как агрегируется каждый файл, включая размер файла.

Однако это полезно только для существующих файлов шепота.

Если вы хотите увидеть прогнозируемый размер схемы до ее установки, попробуйте калькулятор Whisper, например, доступный по адресу https://gist.github.com/jjmaestro/5774063.

РЕДАКТИРОВАТЬ:

Когда попросили пример ...

storage_schema:

{
    :catchall => {
      :priority   => "100",
      :pattern    => "^\.*",
      :retentions => "1m:31d,15m:1y,1h:5y"
    }
}

Глядя на мой файл applied-in-last-hour.wsp, ls -lвыдает

-rwxr-xr-x 1 root root 4415092 Sep 16 08:26 applied-in-last-hour.wsp

и whisper-info.py ./applied-in-last-hour.wspдает

maxRetention: 157680000
xFilesFactor: 0.300000011921
aggregationMethod: average
fileSize: 4415092

Archive 0
retention: 604800
secondsPerPoint: 10
points: 60480
size: 725760
offset: 52

Archive 1
retention: 2678400
secondsPerPoint: 60
points: 44640
size: 535680
offset: 725812

Archive 2
retention: 157680000
secondsPerPoint: 600
points: 262800
size: 3153600
offset: 1261492

Таким образом, в основном вы объединяете свои хосты по количеству сохраненных совпадений для каждого сегмента периода хранения по статистике, умножая их на коэффициент систем, для которых вы собираетесь применить это, с учетом количества новых статистических данных, которые вы собираетесь отслеживать. Затем вы берете любой объем хранилища и, по крайней мере, удваиваете его (потому что мы покупаем хранилище и знаем, что будем его использовать ...)

gWaldo
источник
Любой шанс, что у вас есть некоторые номера образцов из этого (в сочетании с настройками хранения). Прямо сейчас я думаю о различных хранилищах данных временных рядов с точки зрения использования диска - так что запуск графита для этого - немного непростая задача.
Кайл Брандт
@KyleBrandt Ответ обновлен.
gWaldo
Спасибо за это. Так что с размером файла, это то, что будет после часа сбора данных, или это то, что размер файла будет почти всегда? Итак, является ли 4415092 представителем данных за 5 лет такого хранения, или это является представителем данных за один час за 1 минуту? Кроме того, это байты или биты?
Кайл Брандт
Это новая реализация в этой компании, и у меня нет доступа к моей старой. Так как результат fileSize верхнего уровня совпадает с ls -lрезультатом, я принимаю это за байты. Когда я складываю размеры архивов в файле .wsp (как сообщается whisper-info.py), они приближаются к общему размеру файла .wsp (остальное я предполагаю метаданными и т. Д. Это должен быть размер файла для всех время, когда данные снижаются до более низкого разрешения, а старые точки данных отбрасываются
gWaldo
Ладно, так с этими настройками хранения. Примерно:ServerCount * MetricCount * 4.5MBytes
Кайл Брандт
2

В документации для statsd они приводят пример для политики хранения данных.

В ретенции есть 10s:6h,1min:7d,10min:5yчто 2160 + 10080 + 262800 = 275040 точек данных , и они дают размер архива из 3.2 МиБ .

Предполагая линейную зависимость, это будет приблизительно 12,2 байта на точку данных .

AndreKR
источник
Пары ops-school.readthedocs.org/en/latest/monitoring_201.html (timestamp, value) хранятся в виде длинного и двойного значения, занимающего 12 байтов на пару. Разница в 0.2, вероятно, из-за служебной информации метаданных файла ?!
user27465
1

Непосредственного опыта работы с Graphite, но я представляю ту же логику, которую мы использовали для Cacti или чего-либо еще, применяя RRD или управляемые с временным переключением (Graphite больше не использует RRD внутри, но логика хранения кажется сопоставимой)

Быстрый ответ: «Вероятно, не так много места, как вы думаете, вам нужно».


Длинный ответ включает в себя некоторую специфическую для сайта математику. Для нашей системы мониторинга (InterMapper) я выясняю периоды хранения, разрешения и размер точки данных, делаю умножение и добавляю накладные расходы.

В качестве примера я буду использовать дисковое пространство - мы храним цифры с 5-минутной точностью в течение 30 дней, 15-минутной точностью в течение еще 60 дней, а затем с часовой точностью в течение следующих 300 дней, и мы используем 64 -бит (8 байт) целое число, чтобы сохранить его:

  • Всего 21600 образцов в разбивке по:
    • 8640 образцов для 30-дневной 5-минутной точности
    • 5760 образцов для 60-дневной 15-минутной точности
    • 7200 образцов для 300-часовой точности с точностью до 1 часа

При 8 байтах на выборку это около 173 КБ, плюс полезные накладные расходы на индексацию хранилища и т. Д. Увеличивают его до 200 КБ для данных об использовании диска одним разделом (любая ошибка приводит к переоценке).

Исходя из базовых показателей, я могу рассчитать средний размер «на машину» (10 дисковых разделов, пространство подкачки, ОЗУ, средняя загрузка, передача по сети и некоторые другие вещи) - примерно до 5 МБ на машину.

Я также добавляю 10% к итоговому числу и округляю их, так что я оцениваю вещи по 6 МБ на машину.

Затем я смотрю на 1 ТБ места, которое у меня есть для хранения данных метрик для построения диаграмм, и говорю: «Да, у меня, вероятно, не хватит памяти в моей жизни, если мы не будем сильно расти!» :-)

voretaq7
источник
1
Если отбросить число из реальной практики, с моей политикой хранения продукции (9 месяцев по 5 минут; 1 год по часам; 5 лет ежедневно) и около 20 машин с ~ 20 8-байтовыми метриками в каждой, плюс предупреждение / аварийный сигнал / критические / истории отключений за 5 лет Я использую 1,5 ГБ дискового пространства. Это с InterMapper, вставляющим все в базу данных Postgres. Итак, еще раз - быстрый ответ: «Вероятно, не так много места, как вы думаете, вам нужно» :-)
voretaq7
Да, эта математика проста, на самом деле я просто больше смотрю на то, как Graphite хранит эти данные - может иметь большие различия в масштабе. Единственное, что я обнаружил, это то, что, согласно документам, он не очень экономит место (вероятно, потому, что рассчитывает на довольно агрессивные свертки).
Кайл Брандт
Whisper (серверная часть Graphite использует хранилище) имеет несколько встроенных элементов для жевания места - вы, вероятно, уже видели эту страницу. Раздел о «периодах перекрытия архивов» выделяется мной, потому что это означает, что архивы больше, чем мои примеры выше, потому что все они уходят в начало времен (60-дневный архив на самом деле составляет 90 дней; 300-дневный архив 390 дней) Whisper также сохраняет временную метку (4 или 8 байт) вместе с каждой точкой данных, которую также необходимо добавить. Не выглядит сложно, просто раздутый :)
voretaq7
0

У меня есть 70 узлов, которые генерируют много данных. Используя Carbon / Whisper, один узел создал только 91k файлов (узел генерирует несколько схем, каждая из которых имеет несколько счетчиков и переменных полей, которые должны быть выбраны. Например: (имя узла). (Схема). (Счетчик). (Подсчетчик). (И т. Д.) )....и так далее).

Это обеспечило гранулярность, необходимую для построения любого графика, который я хочу. После запуска сценария для заполнения оставшихся 69 узлов у меня было 1,3 ТБ данных на диске. И это всего лишь 6 часов данных / узла. Что меня привлекает, так это фактический плоский CSV-файл для данных за 6 часов - около 230 МБ / узел. 70 узлов - это ~ 16 Гб данных. Моя схема хранения была 120s: 365d.

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

Так что это был забавный эксперимент, но я не думаю, что имеет смысл использовать шепот для данных, которые я храню. MongoDB кажется лучшим солютоном, но мне нужно выяснить, как использовать его в качестве бэкэнда для Grafana.

musca999
источник