У меня есть настройка системы с шиной событий RabbitMQ и приложениями, использующими весенний облачный поток.Чтобы помочь отслеживать сообщения через систему, я также использую spring-cloud-sleuth.
У меня есть вопрос, касающийся потока / привязки errorChannel.Я не использую привязку error в моей конфигурации (имеется в виду this ).Вместо этого у меня есть настройка потока для прослушивания errorChannel, который добавляет дополнительный заголовок к сообщению, а затем отправляет его адресату с ошибкой.Это выглядит примерно так (написано на Groovy):
IntegrationFlows
.from('errorChannel')
.log()
.handle(MessagingException, {e, h ->
def message = MessageBuilder.withPayload(e).copyHeaders(h).setHeader('name', 'myApp').build()
errorSource.channel().send(message)
.channel('nullChannel')
.get()
Где канал errorSource объявлен как @Output.
В строке журнала выводится нечто похожее на:
INFO [myApp,1234,4321,false] LoggingHandler: ErrorMessage [...]
Когда я получаю сообщение от адресата с ошибкой, значение в заголовке X-B3-ParentSpanId не совпадает с идентификатором диапазона из сообщения в журнале выше (значение 4321)или любые другие идентификаторы диапазонов, зарегистрированные в исходном приложении.
Единственный способ увидеть совпадение - это увеличить запись в журнале от org.springframework.cloud до DEBUG, и даже тогда это строка журнала от TracingChannelInterceptor (хотя этот экземпляр выглядит так, как будто он принадлежит списку перехватчиков для errorChannel, поэтому я чувствую, что я рядом).Я бы предпочел не оставлять DEBUG включенным, поскольку он, очевидно, становится довольно шумным.
После всего этого вопрос заключается в том, есть ли какая-либо запись в журнал, которую я могу установить на канале ошибок или сама привязка, которая выдала бы некоторые строки журнала сидентификатор диапазона, который будет соответствовать тому, что указано в заголовке X-B3-ParentSpanId?Цель состоит в том, чтобы захватить этот идентификатор диапазона и сохранить его, чтобы позже его можно было использовать для перехода к исходному приложению при проверке журналов.
Мы также сохраняем идентификатор трассировки, и я вижу,которые проходят через штраф (и соответствуют идентификаторам трассировки исходного приложения), но было бы полезно иметь вместе и идентификаторы трассировки, и идентификаторы span.