Верна ли архитектура приложения сбора статистики онлайн пользователей используя Prometheus?

Question

[Даша Циклаури]

Коллеги, к вам вопрос, требующий идей/мнений/замечаний в виде ответов.

Моя идея: есть соц. сеть с кучей групп (пять тысяч и более), у группы есть две метрики: кол-во подписчиков и кол-во подписчиков онлайн, мне требуется дергать АПИ соц. сети (1 группа = 1 запрос = 1 ответ с обоими метриками) чтобы чекать эти две метрики и записывать к себе в базу, таким образом иметь статистику по цифрам за долгий период (максимум 1 месяц).
Период получения данных с АПИ = 5 минут
Кол-во запросов к АПИ за 5 минут = 5000+
Клиент моего продукта получает крайние справа данные за сутки/неделю/месяц по названию группы (group_name) в виде графика

Моменты реализации (в моем понимании):

• есть некоторая база данных со списком всех групп (mongodb)
  
• есть некоторый воркер, умеющий делать запросы к АПИ и класть данные в очередь
  
• есть некоторый потребитель данных, полученных от АПИ, из очереди, который проверяет - если данные новее предыдущих (просто обработка кейса когда более поздний запрос получил более ранний ответ чем предыдущий), то обновляет; обновление данных планируется производить в redis, таким образом redis умеет хранить словарь самых свежих данных, ключ=group_name значение=пара метрик (кол-во пользователей, кол-во онлайн)
  
• Prometheus для хранения двух метрик users_amount{group=} и users_online{group=}
  
• группы для мониторинга могут добавляться в режиме онлайн
  
• детали реализации АПИ/веб-интерфейса опустим
  

Открытые вопросы:

• Prometheus для такой задачи - это ок?
  
• тысячи лэйблов в Prometheus - это ок? учитывая что по ним независимые запросы, или лучше на кажду группу по две метрики заводить вида users_amount_, users_online_
  
• если в Prometheus настроена pull модель для двух метрик, то он меня будет пинать раз в 5 минут делая два запроса по каждой метрике и я ему отдаю пачкой данные для тысяч лэйблов, у меня верное понимание? или как-то нужно размазать нагрузку? на мой взгляд двумя запросами по трафику будет оптимальнее, чем для каждого лейбла
  
• желательно как можно ровнее размазать запросы уходящие в период пяти минут
  5k req/5min = 15-20 req/sec
  Какими средствами это лучше делать с заделом на масштабирование воркеров? понимаю, что раз в пять минут нужно класть в очередь пять тысяч элементов, верно ли тогда что тротлинг реализуем внутри воркера? тогда если воркеры не справляются, то очередь растет, то мы реагируем добавлением еще одного воркера
  

Answer 1

[Dimonchik]

Prometheus для такой задачи - это ок?

если речь о временнЫх рядах - это ок,

концептуально я запутался что там у вас - так как проскочило "если, то обновляет", а временные ряды на то и ряды, чтобы дописываться, а не обновлять, но +- стройте, а там сами увидите

вопросы по боттлнекам и рпсам теоретически, увы, нерешаемы, тот же Редис / Монго прекрасно работают на вставку при непрерысном потоке входящих до пока не придется скидывать на диск... хе-хе

поэтому все что вы надумали теоретически проверяется на тестовых данных, ваших тестовых данных, определяются боттлнеки и апдейтится конфинг

конечно, текущая со временем память - увы - только опыт, форумы и бессонные ночи админов

Comments

[Даша Циклаури]

обновляет имелось в виду в редис, так как он хранит свежайшие данные, а Прометеус с интервалом опрашивает его через посредника чтобы сохранить уже на диск
редис и был выбран так как не нужна работа с диском, ее делает прометеус

Answer 2

[d'Ivan]

Мне показалось, что архитектура переусложнена. Может, чего-то недопонял. Prometheus метрики забирает (scraping) со всех узлов самостоятельно через http: //apiendpoint/metrics .

То есть схема такова (data flow):
[api 1..N] => Prometheus scraper => Prometheus TSDB

Не понял зачем весь огород с очередями и воркерами. Какую задачу он призван решить?
Прометей не может обращаться напрямую к узлам? А даже если нет, то можно предоставить ему доступ через прокси-сервер.

Клиент моего продукта получает крайние справа данные за сутки/неделю/месяц по названию группы (group_name) в виде графика

Для получения данных есть язык запросов PromQL по API.

В конфигурации Prometheus можно переопределить интервал сбора метрик с узлов. Каждый узел должен уметь отдавать метрики в заданном формате. Благо, есть библиотеки. Средствами библиотеки пишем метрики (новый запрос к АПИ от клиента - делаем increment группе), которые автоматически агрегируются необходимым образом для Prometheus и выдаются по запросу скрэпера. Ответственность за тайминг сбора метрик лежит на Прометее.

Данные временных серий хранятся в БД Prometheus в оптимальном виде. Или в совместимой с ней VictoriaMetrics, если того мало.

Prometheus для хранения двух метрик users_amount{group=} и users_online{group=}

Вроде бы OK.

тысячи лэйблов в Prometheus - это ок?

А зачем тысячи меток? Из-за кол-ва групп?
Цититрую:

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

То есть не рекомендуют.

если в Prometheus настроена pull модель для двух метрик, то он меня будет пинать раз в 5 минут делая два запроса по каждой метрике и я ему отдаю пачкой данные для тысяч лэйблов, у меня верное понимание?

Метрики собираются одинажды для узла (endpoint), который должен представлять из себя отдельную группу со своими парами users_amount, users_online. Если так нельзя, то тогда Прометей тогда, наверное, не подходит. По крайней мере, я так себе представляю.

Если по каким-то причинам Прометей не устроит, тогда можете рассмотреть ClickHouse, куда данные нужно отправлять пачками (с воркеров или как хотите). Но тогда всю логику сами разгребать будете. Redis'ом или как хотите.

Comments

[Даша Циклаури]

по сути мой воркер это и есть одновременно прокси и скраппер АПИ соц сети, который раз в 5 минут собирает данные и обновляет кэш
соглашусь - возможно с воркерами переусложнение и стоит его заменить на одного воркера работающего через несколько прокси

групп тысячи, поэтому тут или меток тысячи или метрик тысячи*2 , вопрос что оптимальнее под запрос по имени группы?