#Планирование ёмкости компонента мониторинга

Компонент мониторинга отвечает за хранение данных метрик, собранных с одного или нескольких кластеров на платформе. Поэтому необходимо заранее оценить масштаб вашего мониторинга и спланировать ресурсы, необходимые для компонента мониторинга, согласно рекомендациям в этом документе.

#Предположения и методология

• Данные в этом документе получены из контролируемых лабораторных отчетов по производительности и предназначены в качестве базового ориентира для планирования в продакшене.
• В примерах для дискового пространства задан срок хранения 7 дней; для других сроков хранения корректируйте пропорционально.
• Базовые параметры хранения соответствуют приведённому выше предупреждению (SSD, ~6000 IOPS, ~250MB/s чтение/запись, отдельный монтируемый том).
• Тестовые нагрузки охватывали типичные страницы мониторинга, такие как "acp ns overview page" и "platform region detail page".

#Prometheus

Ниже приведены рекомендации по размеру для Prometheus и связанных компонентов (Thanos Query, Thanos Sidecar и др.) в зависимости от масштаба.

#Малый масштаб — 10 воркер-нод, 500 подов с двумя контейнерами

• Скорость приёма метрик: ~2800 сэмплов/секунду

#Средний масштаб — 50 воркер-нод, 2000 подов с двумя контейнерами

• Скорость приёма метрик: ~7294 сэмплов/секунду

#Большой масштаб — 500 воркер-нод, 10000 подов с двумя контейнерами

• Скорость приёма метрик: ~41575 сэмплов/секунду

#VictoriaMetrics

Ниже приведены рекомендации по размеру для компонентов VictoriaMetrics в зависимости от масштаба.

#Малый масштаб — 10 воркер-нод, 500 подов с двумя контейнерами

• Скорость приёма метрик: ~3274 сэмплов/секунду

#Средний масштаб — 50 воркер-нод, 2000 подов с двумя контейнерами

• Скорость приёма метрик: ~6940 сэмплов/секунду

#Большой масштаб — 500 воркер-нод, 10000 подов с двумя контейнерами

• Скорость приёма метрик: ~34300 сэмплов/секунду