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

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

Источник

4 ответа

Решение

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

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

Источник

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

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

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

Источник

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

Источник
Другие вопросы по тегам