128-битный идентификатор следа Sleuth на PCF
Я пытаюсь использовать 128-битный TraceId, сгенерированный Sleuth, в качестве уникального идентификатора для запроса, попадающего в мой контроллер. Я понимаю, что значение traceId по умолчанию - 64, и чтобы его изменить, мне нужно добавить в application.properties следующее:
spring.sleuth.trace-id128=true
Это работает на моем локальном компьютере, но когда я развертываю его в PCF, идентификатор трассировки составляет 64 бита. Я создал образец проекта, в котором есть только простой контроллер, чтобы продемонстрировать это.
@RestController
public class Controller {
private Logger logger = LoggerFactory.getLogger(Controller.class);
@Autowired
private Tracer tracer;
@GetMapping("/")
public void test(){
logger.info("LOGGED +["+tracer.currentSpan().context().traceIdString()+"]");
}
}
В моем локальном он напечатает:
com.example.demo.Controller: LOGGED + [5bfcb33c9d564481479f2c212ec08143]
В PCF он печатает:
om.example.demo.Controller : LOGGED + [97a1168857dc7088]
PCF перезаписывает эту конфигурацию?
Обновления
В мой запрос включены «X-B3-TraceId» и «X-B3-SpanId», и теперь значение traceId составляет 128 бит, но это не та же строка, что была передана в заголовке запроса.
Ответы 1
Возможно, что PCF, а точнее Gorouter, создает идентификатор трассировки, и это распространяется на ваше приложение, которое вместо создания нового 128-битного идентификатора трассировки повторно использует существующий 64-битный идентификатор трассировки.
PCF поддерживает трассировку Zipkin, и она включена по умолчанию, поэтому она включена в большинстве сред.
https://docs.pivotal.io/pivotalcf/2-3/adminguide/zipkin_tracing.html
Согласно документации, Gorouter будет проверять наличие заголовков Zipkin во входящих запросах и, если они отсутствуют, создаст их.
If the X-B3-TraceId and X-B3-SpanId HTTP headers are not present in the request, the Gorouter generates values for these and inserts the headers into the request forwarded to an application.
и
If the X-B3-TraceId and X-B3-SpanId HTTP headers are present in the request, the Gorouter forwards them unmodified.
https://docs.pivotal.io/pivotalcf/2-3/concepts/http-routing.html#zipkin-headers
Вы можете видеть здесь, что он создает 64-битный идентификатор трассировки.
https://github.com/cloudfoundry/gorouter/blob/master/handlers/zipkin.go#L49-L57
Вы можете подтвердить, отправив запрос с установленными заголовками X-B3-TraceId и X-B3-SpanId. В этом случае Горутер должен переслать их без изменений.
Пример: curl -v -H 'X-B3-TraceId: 5bfcb33c9d564481479f2c212ec08143' -H X-B3-SpanId: 5bfcb33c9d564481479f2c212ec08143' https://your-cool-app.com/test.
Я не уверен, почему это так. Как вы это отслеживаете? Если вы устанавливаете эти заголовки, они просто проходят через Gorouter, поэтому он не собирается их изменять. Если вы посмотрите на cf logs, там должна быть запись в журнале [RTR], созданная Gorouter. У него будет значение заголовка, можете ли вы попробовать запустить его, чтобы убедиться, что он, по крайней мере, получает указанное вами значение заголовка? Оттуда, возможно, попробуйте зарегистрировать заголовки, которые входят в запрос в вашем приложении. Вы можете попытаться разобрать, где меняется значение.
Привет, @Daniel, еще раз спасибо за ответ. Я отслеживал журналы из диспетчера приложений PCF и включил ссылку в обновленный вопрос на снимок экрана журнала. Моя ошибка в комментарии о том, что traceId всегда принимает определенное значение, не соответствует действительности. Однако я заметил, что в 128-битном traceId первые 3 шестнадцатеричных значения не меняются. Всегда 5c0. Кажется, это связано с отметками времени?
Я не уверен. Идентификатор трассировки, который вы регистрируете в LOGGED +[..], создается Sleuth. Я не знаю точного метода, который он использует для создания идентификаторов трассировки / диапазона. Вам нужно будет посмотреть код или, возможно, задать другой вопрос, если вы хотите узнать об этом больше.
Это должен быть тот же traceId, который передается в TraceContext, если я не ошибаюсь. Хорошо, конечно! Спасибо за помощь, Даниэль!
Спасибо за ответ. Я пробовал то, что вы упомянули, и кажется, что когда я включаю 128-битный идентификатор трассировки и диапазона в заголовок моего запроса, идентификатор трассировки и диапазона в моем приложении действительно становится 128-битным, но он отличается от того, что я указал в моем запросе. Фактически, независимо от указанного мной значения, распространяемые traceId и spanId всегда равны «5c05f313f7d726cd1509f63585df7a7c».