Comments 4
Хочется заметить, что стандарт correlation-context W3C еще не принят. И судя по всему находится в стадии проработки.
по-моему, у вас не та ссылка закралась для MassTransit.SerilogIntegration
Пробрасывать CorrelationId через message не самое удачное решение.
CorrelationId вообще был придуман не для этого, не для логирования, не для того чтобы куски логов можно было связывать между собой. Но вы решили что чего зря его не заюзать.
Зачем вообще вмешиваться в формат ЦЕЛЕВОГО сообщения? Почему оно начинает знать по какой-то CorrelationId? Почему Консьюмеры начинают его знать?
Логирование это чисто инфраструктурная задача. Сообщения не знают, что из логируют. И уж тем более они не должны сообщать подсистеме логирования хитрое поле CorrelationId, которое можно изменить в любой части пайплайна (и тем самым поломать все).
Логирование, например, можно временно отключить. Но сообщения будут продолжать таскать CorrelationId зачем-то. Непонятно…
Почему бы не использовать «headers»: {}?
Ведь в Http запросах вы используете Headers для передачи «X-Correlation-ID».
Почему здесь вы отошли от этого принципа?
CorrelationId вообще был придуман не для этого, не для логирования, не для того чтобы куски логов можно было связывать между собой. Но вы решили что чего зря его не заюзать.
Зачем вообще вмешиваться в формат ЦЕЛЕВОГО сообщения? Почему оно начинает знать по какой-то CorrelationId? Почему Консьюмеры начинают его знать?
Логирование это чисто инфраструктурная задача. Сообщения не знают, что из логируют. И уж тем более они не должны сообщать подсистеме логирования хитрое поле CorrelationId, которое можно изменить в любой части пайплайна (и тем самым поломать все).
Логирование, например, можно временно отключить. Но сообщения будут продолжать таскать CorrelationId зачем-то. Непонятно…
Почему бы не использовать «headers»: {}?
Ведь в Http запросах вы используете Headers для передачи «X-Correlation-ID».
Почему здесь вы отошли от этого принципа?
Sign up to leave a comment.
Логирование в микросервисной среде .Net на практике