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

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

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-часовой точности с точностью до 1 часа

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

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

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

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

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

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

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

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