Планування ємності диска для шепіту / графіту

У когось є формули, чи, можливо, деякі зразкові дані з їх оточення, які можуть допомогти мені оцінити, скільки дискового простору буде використаний графіт на точку даних?

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

Однак це корисно лише для існуючих файлів шепіту.

Якщо ви хочете побачити прогностичний розмір схеми перед тим, як поставити її на місце, спробуйте Шепіт-калькулятор, наприклад, доступний за посиланням 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

Отже, ви в основному комбінуєте ваші хости на відповідність у відповідність за період зберігання на період на статистику, помножуючи на коефіцієнт систем, до яких ви також маєте намір застосувати це, на коефіцієнт кількості нових статистичних даних, які ви збираєтеся відстежувати. Тоді ви берете будь-який обсяг пам’яті, який є, і принаймні подвоюйте його (тому що ми купуємо сховище, і ми знаємо, що будемо використовувати його ...)

У документації для статистики вони наводять приклад політики збереження даних.

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

Якщо припустити лінійну залежність, це було б приблизно 12,2 байтів на точку даних .

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

Швидка відповідь - "Мабуть, не так багато місця, як ви думаєте, що вам знадобиться".

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

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

• Всього 21600 проб, розбиті на:
  • 8640 зразків для 30-денної точності 5 хвилин
  • 5760 зразків за 60-денну точність
  • 7200 зразків для одноденної точності 300 днів

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

З базових показників я можу розробити середній розмір "на машину" (10 дискових розділів, обмінні місця, оперативна пам'ять, середнє завантаження, передача в мережі та кілька інших речей) - працює приблизно до 5 Мб на машині.

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

Потім я дивлюсь на 1 ТБ простору, який я маю для зберігання даних метрики для графіків, і кажу: "Так, у мене, ймовірно, не вистачає місця для зберігання, якщо ми не виростимо багато!" :-)

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

Це забезпечило деталізацію, необхідну для побудови будь-якого графіка, який я хочу. Після запуску сценарію для заселення решти 69 вузлів у мене було 1,3 Тб даних на диску. І це лише 6 годин варті даних / вузла. Що мене отримує - це фактичний плоский файл csv за 6 годин даних, який становить приблизно 230 Мбіт / вузол. 70 вузлів - це ~ 16Gb даних. Моя схема зберігання була 120-х: 365d.

Я відносно новий в базах даних, тому я можу зробити щось не так, але гадаю, що це все накладні витрати для кожного зразка.

Тож це був цікавий експеримент, але я не думаю, що має сенс використовувати шепіт для типу даних, які я зберігаю. MongoDB здається кращим солютоном, але мені потрібно розібратися, як використовувати його як доповнення до Графани.