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

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

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

• Данные в этом документе получены из контролируемых лабораторных отчетов о производительности и предназначены в качестве базового ориентира для планирования в продакшене.
• В примерах с дисковым хранением время хранения составляет 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 сэмплов/секунду