Как организовать журнал событий в распределённой системе правильно?
Обстановка:
Приложение, которое в автоматическом режиме совершает обзвон пользователей (миллионы абонентов в сутки), состоит из разных сервисов (интерфейсы настроек, всякие приблуды для телефонии, черные списки, управление юзерами и тд).
Появилась потребность в пользовательском интерфейсе (где всё настраивается пользователями, можно просматривать дашборды, отчёты и тд) - возможность смотреть "журнал событий" - раздел, где можно посмотреть, когда кто и где что-то сделал в системе. В том числе когда действия сделаны системой (например сервис определения автоответчиков определил автоответчик во время звонка) и пользователем (поменял настройки, добавил другого пользователя, сменил имя и тд).
Всё это живет в кубере. Вопрос - как бы реализовать такую функциональность лучшим образом? Пока что основная идея - добавить Кафку, туда кидать сообщения по каждому событию из каждого сервиса в едином формате (что-то своё придумать), и привязать к этому делу сервис-слушатель, который бы читал эту Кафку и писал в допустим, Кликхаус, эти самые сообщения в согласованном виде типа:
сервис / юзер / ip (где применимо) / тип операции (read/update/write/delete) / данные операции (json) / дата+время
Ну и потом из сервиса, который отвечает за фронт, получать эти данные по фильтрам какие нужны. Вроде бы звучит ок, но есть сомнения.
думал над этим вариантом, но это будет отдельная система, и не уверен что фильтров что предоставляет Кибана - хватит. Так что оно осталось за рамками изучения.
В данном задании непонятно насколько остро стоит необходимость именно в MQ системе.
Можно начать просто с централизованного сбора логов. Мне кажется это проще
чем строить кафку. Кроме того логгирование работает всегда, пока есть файловая
система. А Кафка может быть недоступна какое-то количество минут или секунд в году.
И вам надо будет думать что делать с событиями которые не ушли в Кафку. Блокировать.
Дропать события. Или искать резервное мето куда форварднуть.
Вроде бы Кафка кластер довольно стабилен. И слышал мнение, что можно самого кликхауса подключить к очереди слушателем и не писать для этого отдельный сервис.
Кафка - неплохое решение.
Для повышения надёжности можно правильно репликацию настроить.
А на случаи тех редчайших моментов, когда она вдруг будет недоступна, как раз и сделать сбор логов с помощью эластика, либо вообще писать их в файловую систему. А потом либо вручную, либо автоматически как-то обрабатывать эти дропнутые сообщения.
Средний
Средний
