Метрики? Метрики! Метрики...А есть ли жизнь за пределами Prometheus?
Обычно инженеры подразумевают одно и тоже когда говорят про метрики и Prometheus. Мы работаем с PromQL синтаксисом, устанавливаем экспортеры расположенные в Github организации Prometheus. Выглядит так что это одно и тоже. Но что если нет?
Краткая историческая справка
Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. Если упростить система мониторинга состоит из:
- Приложения экспортирующего метрики. Это может быть ваше приложение с метриками оформленными вами. Для их экспорта вам требуется специальный SDK. Альтернатива - взять готовый экспортер для сбора стандартных метрик (кафки, постгреса, или просто вирт. машины).
- Prometheus server. Отвечает за сбор метрик с целей. Экспорт метрик осуществляется за счет публикации HTTP ручки с набором метрик. И пром опрашивает раз в N секунд всё что оформлено в конфиге. Подсистема чтения данных и язык запросов встроены в Prometheus Server.
- TSBD. Система отвечающая за долговременное хранение собранных метрик. Важно отметить что эта система поддерживает только Local Disks.
Следствия такой архитектуры:
- Горизонтальное масштабирование за счет ручного шардирования. Чтобы собирать метрики с большего количества целей нужно добавлять больше инстансов Prometheus Server и делить нагрузку между ними. Упереться можем как в диск там и в CPU/RAM.Также нужно отметить что у Prometheus нет встроенного инструменте для объединения всех инстансов prometheus в единую PromQL View для чтения.
- Избыточность ресурсов. Диски дорогие, а данные на них устаревают. При этом возможна ситуация что данные хочется сохранить для редкого доступа. По Compute тоже все не так гладко, Prometheus это очень прожорливая штука.
Тут на сцену выходят конкуренты и альтернативы:
- Victoria Metrics. Написали все с нуля, добились лучших значений по сжатию данных, количеству метрик которые скрепятся в секунду, потребление RAM / CPU. Также был добавлен PUSH режим для того чтобы снять нагрузку с Prometheus Server (и не только). Также предоставляет vmselect - Query Engine для аггрегаций метрик с нескольких серверов хранящих метрики.
- Thanos. Добавляет в архитектуру Prometheus возможность экспорта данных в S3. Ставится как sidecar рядом с приложением. На самом деле это всё. Почему? Потому что Thanos это скорее набор плагинов в дополнение к Prometheus. А Виктория это прям полноценная независимая экосистема.
- Grafana Mimir. Узнал об этом звере когда готовил пост. Поддерживает S3. Целится в multi-tenant сценарии - когда у вас большой энтерпрайз, куча отделов и хочется выстроить правила игры для всех, с квотами и лимитами.
🔗 Заметка со сравнением 3х инструментов
Как видите каждый инструмент так или иначе помогает закрыть слабые места ванильного Prometheus. VM так вообще ушли далеко вперед и создали свой коммерческий продукт. Для меня их история развития прям канонический пример композиции - как сделать свой продукт. Ребята повторили API Prometheus для того чтобы все ранее созданные библиотеки и практики остались совместимы. Если вы компания и у вас Prometheus - можно мигрировать на VM и удешевить инфру. На больших объемах эффект будет пропорционален.
Делитесь в комментариях, что нового узнали, а также где хранятся метрики в вашей компании😊
Обычно инженеры подразумевают одно и тоже когда говорят про метрики и Prometheus. Мы работаем с PromQL синтаксисом, устанавливаем экспортеры расположенные в Github организации Prometheus. Выглядит так что это одно и тоже. Но что если нет?
Краткая историческая справка
Prometheus был создан на SoundCloud в 2012 году и с тех пор стал стандартом для мониторинга систем. Если упростить система мониторинга состоит из:
- Приложения экспортирующего метрики. Это может быть ваше приложение с метриками оформленными вами. Для их экспорта вам требуется специальный SDK. Альтернатива - взять готовый экспортер для сбора стандартных метрик (кафки, постгреса, или просто вирт. машины).
- Prometheus server. Отвечает за сбор метрик с целей. Экспорт метрик осуществляется за счет публикации HTTP ручки с набором метрик. И пром опрашивает раз в N секунд всё что оформлено в конфиге. Подсистема чтения данных и язык запросов встроены в Prometheus Server.
- TSBD. Система отвечающая за долговременное хранение собранных метрик. Важно отметить что эта система поддерживает только Local Disks.
Следствия такой архитектуры:
- Горизонтальное масштабирование за счет ручного шардирования. Чтобы собирать метрики с большего количества целей нужно добавлять больше инстансов Prometheus Server и делить нагрузку между ними. Упереться можем как в диск там и в CPU/RAM.Также нужно отметить что у Prometheus нет встроенного инструменте для объединения всех инстансов prometheus в единую PromQL View для чтения.
- Избыточность ресурсов. Диски дорогие, а данные на них устаревают. При этом возможна ситуация что данные хочется сохранить для редкого доступа. По Compute тоже все не так гладко, Prometheus это очень прожорливая штука.
Тут на сцену выходят конкуренты и альтернативы:
- Victoria Metrics. Написали все с нуля, добились лучших значений по сжатию данных, количеству метрик которые скрепятся в секунду, потребление RAM / CPU. Также был добавлен PUSH режим для того чтобы снять нагрузку с Prometheus Server (и не только). Также предоставляет vmselect - Query Engine для аггрегаций метрик с нескольких серверов хранящих метрики.
- Thanos. Добавляет в архитектуру Prometheus возможность экспорта данных в S3. Ставится как sidecar рядом с приложением. На самом деле это всё. Почему? Потому что Thanos это скорее набор плагинов в дополнение к Prometheus. А Виктория это прям полноценная независимая экосистема.
- Grafana Mimir. Узнал об этом звере когда готовил пост. Поддерживает S3. Целится в multi-tenant сценарии - когда у вас большой энтерпрайз, куча отделов и хочется выстроить правила игры для всех, с квотами и лимитами.
🔗 Заметка со сравнением 3х инструментов
Как видите каждый инструмент так или иначе помогает закрыть слабые места ванильного Prometheus. VM так вообще ушли далеко вперед и создали свой коммерческий продукт. Для меня их история развития прям канонический пример композиции - как сделать свой продукт. Ребята повторили API Prometheus для того чтобы все ранее созданные библиотеки и практики остались совместимы. Если вы компания и у вас Prometheus - можно мигрировать на VM и удешевить инфру. На больших объемах эффект будет пропорционален.
Делитесь в комментариях, что нового узнали, а также где хранятся метрики в вашей компании😊