Как RP C атрибуты диапазона клиентского доступа / дочерние диапазоны могут быть созданы сервером - PullRequest
Новая
       4

Как RP C атрибуты диапазона клиентского доступа / дочерние диапазоны могут быть созданы сервером

0 голосов
/ 23 января 2020

Я использую модуль Python opentracing с клиентом RP C (по HTTP).

В настоящее время я не заинтересован в отправке журналов трассировки в такое приложение, как Jaeger - Я просто хочу проверить промежуток (и дочерние промежутки) в клиенте, когда возвращается вызов RP C.

Пока у меня есть это: 

tracer = MockTracer()
with tracer.start_span('my-client') as span:
    span.set_tag(tags.HTTP_METHOD, 'GET')
    span.set_tag(tags.HTTP_URL, url)
    span.set_tag(tags.SPAN_KIND, tags.SPAN_KIND_RPC_CLIENT)
    opentracing.global_tracer().inject(span.context, Format.HTTP_HEADERS, headers)
    results = requests.request('GET', url, headers=headers, params=params, json=body)
# Extract from span any tags added by the server and/or any child spans created by the server???

Я обнаружил, что должен был используйте MockTracer(), чтобы получить что-либо вообще. Базовый класс Tracer(), по-видимому, не сделал общедоступной базовую c информацию (start_time, finish_time, tags et c) о диапазонах.

I в настоящее время не может выяснить, как извлечь обновленный диапазон (чтобы прочитать какие-либо теги, которые мог добавить сервер) и какие-либо дочерние диапазоны, созданные сервером, по результатам запроса. (Я также немного озадачен тем, как сервер узнает, какие дочерние диапазоны нужно создать - очевидно, они должны быть того же типа, что и диапазон, передаваемый через заголовки.)

В В двух словах, хотя отправка отчетов о трассировке на центральный сервер, например, Jaeger, полезна, моя цель здесь - заставить клиента RP C распечатать всю информацию о трассировке сервера. (Не сказать, что я не хочу, чтобы трассировки также были в Jaeger, но я разберусь с этим, как только сработает система отчетов о трассировке клиента.)

1 Ответ

0 голосов
/ 24 января 2020

Короткий ответ: «Вы не можете».

Мой вопрос был основан на очень фундаментальном недопонимании того, что делает opentracing.

Отслеживание контекста только распространяется вниз по течению, а не вверх по течению.

Из той же ветки обсуждения:

На проводном распространении подразумевается только "контекст контекста", который является небольшой набор полей для идентификации и возможный багаж. Возврат всей трассировки как части запроса не рассматривался как вариант использования.

и

Сбор трассировки должен быть асинхронным и вне процесса.

Итак, мое понимание теперь таково:

Каждый отдельный программный компонент создает свои собственные данные трассировки, связывает их и отправляет на сервер трассировки (например, Jaeger). Каждый программный компонент должен быть настроен на использование одного и того же поставщика трассировки и одного и того же сервера трассировки - клиент RP C не может сообщить серверу RP C, что для конкретной трассировки он должен использовать поставщика трассировки Jaeger и сервер Jaeger по такому-то адресу. (По крайней мере, в стандарте opentracing нет способа сделать это.) Информация трассировки, введенная клиентом в запрос RP C, позволяет серверу RP C встраивать поле родительского идентификатора в трассировку. информация.

Тогда трассировщик (например, Jaeger) должен выяснить отношения между различными трассировками, которые он получил от различных компонентов программного обеспечения, сопоставляя встроенные в них идентификационные коды.

Поэтому то, что я хотел сделать, - это не вариант использования, рассмотренный в процессе опроса, и это невозможно.

...