Логирование при микросервисной архитектуре?

Question

[ТёмнаяМатерия]

Если части системы отделены друг от друга и общаются по API как эффективно проследить взаимодействие между ними. Например одна часть передала другой данные на обработку и залогировала это. Вторая часть должна сразу дать ответ о том что данные приняты, либо первая загологирует отказ. При выполнении работы второй частью надо наверное тоже логировать сам факт выполнения. Вопрос как сопоставить это с логами от первой части системы, например если было передано 10 тыс. задач а выполнено 9,9 тыс. надо их сопоставить и выявить id которые не выполнены. Такое логирование можно только с БД сделать? На файлах такую задачу не решить?

Answer 1

[Сергей Протько]

Каждый микросервис живет своей жизнью. Если мы отправили запрос от микросервиса A к микросервису B, а тот отправил запрос на C, микросервису A глубоко плевать что пошло не так. Он не знает ничего о C и знать ничего не должен.

Логирование тут можно организовать точно так же как и в случае с исключениями. Каждый сервис в случае ошибки может отправить вызывающей стороне подробности что произошло, тот завернет это в свой ответ с указанием что было причиной ну и т.д.

Но в логи сообщения будут ложиться каждым сервисом независимо. Возможность трекать цепочки ошибок есть, а далее можно агрегатором логов просто слать сообщения той команде, которая занимается тем или иным сервисом.

Answer 2

[Immortal_pony]

Вопрос как сопоставить это с логами от первой части системы, например если было передано 10 тыс. задач а выполнено 9,9 тыс.

А при чем тут первая система? Вторая система файлы приняла и вторая же система их обработала. Это все внутренняя логика второй системы.
В общем виде, указанные вами сверки производятся по логам только в крайних случаях - если нормальная логика работы системы была нарушена. А все данные о том, что, куда и как отправилось и в каких статусах лежит, хранятся в первую очередь в БД.

В приведенном вами примере у второй системы должна быть приблизительно следующая логика:

1. Получили данные, записали в лог.
2. Закинули данные в БД, записали в лог.
3. Отправили первой системе квиток о принятии данных. Записали в лог.
4. Начали обработку единицы данных. Поменяли ей статус в БД на "Обрабатывается". Записали в лог.
5. Обработали данные. Поменяли статус в БД на "Успешно" или "Провалено". Записали в лог.
...

Comments

[Сергей Протько]

При микросервисах БД у каждого сервиса своя, если что. Ваша схема будет работать если все микросервисы завязаны на каком-то одном микросервисе для агрегации логов, или для проверки статусов задач. В целом для последнего проще и удобнее использовать очереди (RabbitMQ например, там это есть из коробки, хоть это и далеко не самая эффективная шина данных выйдет).

[Immortal_pony]

Сергей Протько, все правильно, БД своя, сущности свои, статусы свои.

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

Это зависит от архитектуры системы в целом.