Зачем объединять или зачем объединять из разных сервисов? На самом деле ответ один и очевиден - одним документом получить полный пакет информации.

Без относительно вашей идеи реализации, это называется tracing и весьма полезная штука

Боюсь что загуглить tracing по этой теме не получится, не подскажите более конкретный поисковый запрос?

opentracing, zipkin

istributed tracing system

только лучше OpenTelemetry, а не OpenTracing

Спасибо!

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

Это смотря как организовать. Кто то пишет вперемешку системные и бизнесовые события, кто то отделяет их, кто то обвешивает тэгами и кверяет только нужные. Жизненный цикл события - наверное имели ввиду жизненный цикл какого-нибудь бизнес процесса, а в нём уже цепочка событий. Разные подходы есть, зависит от требований, где то достаточно event sourcing с CQRS, где то просто трассировочный идентификатор (correlationId/traceId/requestId) передавать во все запросы и логировать указывая его. Логи собирать структурированое, скажем в единое хранилище ELK стек и по ид запроса получать всю цепочку обработки. Если пойти дальше, то будет тот же OpenTelemetry(тут будет больше инфы о дочерних подзапросах, метки времени,теги, путь обработки - детализация на ваше усмотрение). Альтернатива Event sourcing просто подписаться на события в системе, складировать их в какое нибудь хранилище и по ид доставать и смотреть что было, какие данные и тп

Большое спасибо, буду изучать тему.

Коллеги! Вероятно в процессе работы возникала необходимость гарантированного обмена сообщениями между различными сетевыми сегментами. Решение очевидно - MQ (IBM WebSphere MQ, Microsoft MQ, RabbitMQ... etc) Великолепная ИнфоБез (не в упрек будет сказано) хочет что бы обмен был контролируемым, то есть содержание передаваемой информации должно контролироваться и определяться набором правил. В лоб не нашел такой возможности в реализациях MQ. Может есть у кого опыт решения подобной задачи?

Что значит контролироваться?

Вероятно, имеется ввиду фиксация формата обмена и валидация сообщений на этот формат

также как и защита транспорта и валидация отправителей получателей

Часто ИБ считает MQ и ESB вообще вредными паттенами, потому что это для них "хаб данных", к которому подключено много сервисов и каждый может потенциально прочитать из "хаба" лишнюю информацию.

Но зато, ESB и MQ хорошо живут в сетях, с разделением зон. Где установка новых соединений разрешена только в одном направлении. Обычно это типа зона А имеет доступ в зону В, зона С имеет доступ в зону В, но зона А и С не могут общаться. Тогда MQ/ESB ставится в зону В.

тут надо понимать чёткие требования ИБ

если пробить подписи и шифр - это умеют все

если накатить валидацию, насыщение \ форматно логический контроль

бить набать и гнать ИБ

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

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