Блог

Есть ли способ определить связь между диапазонами без передачи идентификатора родительского диапазона дочерней службе на основе другой информации о транзакции?

Мы рассматриваем возможность использования opentracing для сбора информации о времени для сквозного потока команд / ответов на встроенные устройства. Насколько я понимаю, чтобы объединить несколько диапазонов в последовательную трассировку всей операции, span должен знать своего родителя, чтобы он мог сообщить, что у него есть «дочерняя часть» или «вытекающая из» связь с этим диапазоном. Для большей части нашей системы это не проблема, но в нашей системе есть одна служба, которая отправляет команды на устройство по SMS, и другая служба, которая получает ответы через UDP. В нашем бюджете SMS нет места для отправки контекста на устройство, хотя у нас есть уникальный идентификатор для устройства и увеличивающийся порядковый номер для команды.

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

Я думаю, чтобы действительно ответить на этот вопрос, нам нужно было бы больше знать об используемой вами реализации (Zipkin, Jaegar, Instana?), Но я попытаюсь ответить на это в общем виде, который, по крайней мере, обсуждает возможное решение.

Стандарт OpenTracing довольно ясно показывает, что они не выводят такого рода отношения специально: https://opentracing.io/docs/overview/inject-extract /

… существует компромисс между очевидным удобством этих подходов, основанных на выводе из черного ящика, и свежестью и качеством собранных трасс. Учитывая заботу о качестве, OpenTracing является явным стандартом распределенного инструментария трассировки…

Это все равно может повлечь за собой дополнительные расходы на SMS, но если бы вы были строги в отношении модели ввода / извлечения, вы могли бы создать пользовательский оператор: https://opentracing.io/docs/overview/inject-extract/#custom-carriers

Эта реализация будет зависеть от вашего решения для трассировки, поскольку OpenTracing на самом деле просто обращается к SDK, предоставляемому вашим трассировщиком.

Предполагая, что вы действительно можете гарантировать некоторый уровень уникальности в записях БД, чтобы не перепутывать трассировки, вы могли бы сохранить общий формат носителя (текстовая карта или dict, указывающий HTTP-заголовки) в БД, затем посмотреть и внедрить. Я бы все равно попытался отправить какой-нибудь UUID по проводу через SMS, потому что обе стороны, угадывающие уникальный идентификатор для этой трассировки, могут быть проблематичными.

В зависимости от объема ваших запросов, вы можете захотеть использовать хранилище ключ-значение, такое как redis. Это может быть более производительным вам не нужна большая часть функциональности, которую собирается предоставить вам RDBMS.

Что касается возврата UDP, вы должны придерживаться общего формата несущей, уже есть некоторые, которые подходят для такого рода вызовов по проводам.