Есть ли у кого-нибудь какие-нибудь формулы или, может быть, некоторые примеры данных из их среды, которые могут помочь мне оценить, сколько дискового пространства будет использовано графитом на точку данных?
monitoring
graphite
Кайл Брандт
источник
источник
Ответы:
whisper-info.py
дает вам глубокое понимание того, что и как агрегируется каждый файл, включая размер файла.Однако это полезно только для существующих файлов шепота.
Если вы хотите увидеть прогнозируемый размер схемы до ее установки, попробуйте калькулятор Whisper, например, доступный по адресу https://gist.github.com/jjmaestro/5774063.
РЕДАКТИРОВАТЬ:
Когда попросили пример ...
storage_schema:
Глядя на мой файл
applied-in-last-hour.wsp
,ls -l
выдаети
whisper-info.py ./applied-in-last-hour.wsp
даетТаким образом, в основном вы объединяете свои хосты по количеству сохраненных совпадений для каждого сегмента периода хранения по статистике, умножая их на коэффициент систем, для которых вы собираетесь применить это, с учетом количества новых статистических данных, которые вы собираетесь отслеживать. Затем вы берете любой объем хранилища и, по крайней мере, удваиваете его (потому что мы покупаем хранилище и знаем, что будем его использовать ...)
источник
ls -l
результатом, я принимаю это за байты. Когда я складываю размеры архивов в файле .wsp (как сообщаетсяwhisper-info.py
), они приближаются к общему размеру файла .wsp (остальное я предполагаю метаданными и т. Д. Это должен быть размер файла для всех время, когда данные снижаются до более низкого разрешения, а старые точки данных отбрасываютсяServerCount * MetricCount * 4.5MBytes
В документации для 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, один узел создал только 91k файлов (узел генерирует несколько схем, каждая из которых имеет несколько счетчиков и переменных полей, которые должны быть выбраны. Например: (имя узла). (Схема). (Счетчик). (Подсчетчик). (И т. Д.) )....и так далее).
Это обеспечило гранулярность, необходимую для построения любого графика, который я хочу. После запуска сценария для заполнения оставшихся 69 узлов у меня было 1,3 ТБ данных на диске. И это всего лишь 6 часов данных / узла. Что меня привлекает, так это фактический плоский CSV-файл для данных за 6 часов - около 230 МБ / узел. 70 узлов - это ~ 16 Гб данных. Моя схема хранения была 120s: 365d.
Я относительно новичок в базах данных, поэтому, возможно, я что-то делаю не так, но я предполагаю, что это все накладные расходы для каждого образца.
Так что это был забавный эксперимент, но я не думаю, что имеет смысл использовать шепот для данных, которые я храню. MongoDB кажется лучшим солютоном, но мне нужно выяснить, как использовать его в качестве бэкэнда для Grafana.
источник