Блог

Главная - Вопросы по программированию - Spring cloud Sleuth запускает новую трассировку вместо продолжения сегментов в одной трассировке

Spring cloud Sleuth запускает новую трассировку вместо продолжения сегментов в одной трассировке

#spring-boot #ibm-mq #spring-jms #spring-cloud-sleuth #zipkin

#spring-boot #ibm-mq #spring-jms #spring-cloud-sleuth #zipkin

Вопрос:

У меня есть 4 приложения с весенней загрузкой (A, B, C и D). Жизненный цикл транзакции выглядит следующим образом :

  1. Приложение A — это приложение kafka streams, и в конечном итоге оно приводит к теме, которая используется приложением B.
  2. Затем приложение B использует раздел с помощью @KafkaListener, выполняет некоторую обработку, а затем создает очередь IBMMQ с помощью JmsTemplate spring.
  3. Приложение C, которое является @JmsListener, использует указанную выше очередь и передает в другую очередь, используя JmsTemplate spring.
  4. Приложение D, которое снова является @JmsListener, использует указанную выше очередь, а затем создает раздел kafka, который снова используется приложением A

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

  1. Одна трассировка, начиная с приложения A и заканчивая приложением B (где она передается в IBM MQ)
  2. Одна трассировка, начинающаяся с приложения C и заканчивающаяся приложением A

Я бы загрузил изображения, чтобы показать сегменты zipkin, но по какой-то причине я не могу этого сделать.

Все вышеупомянутые приложения являются приложениями Spring boot и используют spring-cloud-sleuth для создания трассировок транзакций. Я полагаюсь на автоконфигурацию spring boot, и это свойства, которые я установил во всех приложениях:

   zipkin:
   enabled: ${ZIPKIN_ENABLED:false}
   sender:
    type: kafka
   baseUrl: ${ZIPKIN_URL:http://localhost:9411}
   service:
    name: ${spring.application.name}
 sleuth:
  messaging:
   kafka:
    enabled: true
   jms:
    enabled: true

Я не могу понять, что именно здесь происходит. Почему сегменты разбросаны по 2 трассам, а не по одной?

Я использую spring-boot 2.3.3 и spring-cloud-dependencies Hoxton.SR8.

Комментарии:

1. Скорее всего, это ошибка, связанная с интеграцией шаблона JMS. Для этого мы используем OpenZipkin Brave, так что либо это ошибка в Sleuth, либо Brave. Вам нужно будет отладить это, чтобы увидеть, установлены ли заголовки трассировки в исходящем сообщении или они не распространяются на стороне получателя.

2. Я вижу, что когда приложение B отправляет сообщение в IBMMQ, оно делает это с помощью свойства b3, что-то вроде b3=00d37562420424e5-b78b8a0a2b6eb173-1 , но когда приложение C использует его, оно отсутствует в сообщении. С другой стороны, когда ApplicationC выдает в IBMMQ, оно имеет аналогичное свойство в сообщении, и когда приложение D использует его, свойство все еще существует. Конфигурация абсолютно одинакова для всех компонентов spring JMS во всех приложениях. Кажется, что-то очень тонкое, что я где-то пропустил.

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

Ответ №1:

Итак, это было приложение B, которое не передавало заголовок вместе. Оказывается, что uri очереди имел свойство targetClient , для которого было установлено значение 1. URI выглядит примерно так

 queue:///DESTINATION_QUEUE?targetClient=1

Теперь я далеко не эксперт IBM MQ, но в документации указано, что установка этого свойства в 1 означает, что Messages do not contain an MQRFH2 header. я переключил его на 0 и вуаля, все сегменты встают на свои места.