Есть ли у кого-нибудь формулы или, может быть, некоторые образцы данных из их среды, которые могут помочь мне оценить, сколько дискового пространства будет использоваться графитом для каждой точки данных?
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 байт) целое число для его хранения:
При 8 байтах на выборку, что составляет около 173 КБ, плюс нормальные накладные расходы на индексацию хранилища и т.п. доводят его до 200 КБ для данных об использовании диска одним разделом (любая ошибка имеет тенденцию к завышению).
Исходя из базовых показателей, я могу определить средний размер «на машину» (10 разделов диска, пространство подкачки, оперативная память, средняя нагрузка, сетевая передача и некоторые другие параметры) - примерно 5 МБ на машину.
Я также добавляю здоровые 10% к окончательному числу и округляю его в большую сторону, поэтому я устанавливаю размер 6 МБ на машину.
Затем я смотрю на 1 ТБ пространства, которое у меня есть для хранения данных метрик для построения графиков, и говорю: «Да, вероятно, у меня не закончится хранилище за всю жизнь, если мы не вырастем очень сильно!» :-)
У меня 70 узлов, которые генерируют много данных. Используя Carbon / Whisper, один узел создал только 91 тыс. Файлов (узел генерирует несколько схем, каждая из которых имеет несколько счетчиков и переменных полей, которые необходимо выбирать. Например: (имя узла). (Схема). (Счетчик). (Вспомогательный счетчик). (И т. Д.) )....и так далее).
Это обеспечило детализацию, необходимую для построения любого графика, который мне нужен. После запуска сценария для заполнения оставшихся 69 узлов у меня на диске было 1,3 ТБ данных. И это всего лишь 6 часов данных на узел. Что меня понимает, так это то, что фактический плоский файл csv для данных на 6 часов составляет около 230 МБ / узел. 70 узлов - это ~ 16 ГБ данных. Моя схема хранения была 120 с: 365 дней.
Я относительно новичок в базах данных, поэтому могу делать что-то не так, но я предполагаю, что это все накладные расходы для каждого образца.
Это был забавный эксперимент, но я не думаю, что имеет смысл использовать шепот для тех данных, которые я храню. MongoDB кажется лучшим решением, но мне нужно выяснить, как использовать его в качестве бэкэнда для Grafana.