Номер сергея трейсера: 22 апреля — Wikiwand

Аналогичные преобразования ожидаются, когда система трассировки преобразует другие распределенные форматы распространения контекста трассировки в W3C Trace Context. короче идентификаторы ДОЛЖНЫ быть оставлены заполненными нулями при преобразовании в 16 байтов идентификатор трассировки и крайняя правая часть trace-id СЛЕДУЕТ использовать как более короткий идентификатор.

Обратите внимание, что многие существующие системы не способны распространять всю trace-id также не будет распространять заголовок tracestate . Однако такая система может по-прежнему использовать заголовок tracestate для распространения дополнительных данных, которые известны эта система. Например, в некоторых системах используются два флага, указывающие, распределенная трассировка должна быть записана или нет. В этом случае можно отправить один флаг как выборка Флаг traceparent заголовка и tracestate можно использовать для отправки и получите дополнительный флаг. Совместимые системы будут распространять этот флаг все остальные пары ключ/значение. Существующие системы, не способные tracestate распространение урежет все дополнительные значения из tracestate и пройти только по этому флагу.

Спасибо Adrian Cole, Christoph Neumüller, Daniel Khan, Erika Arnold, Fabian Lange, Matthew Wear, Reiley Yang, Ted Young, Tyler Benson, Victor Soares за их вклад в эту работу.

Этот раздел не является нормативным.

Распределенная трассировка

Распределенная трассировка — это набор событий, инициированных в результате одной логической операции, объединенной в различные компоненты приложения. Распределенная трассировка содержит события, выходящие за границы процесса, сети и безопасности. Распределенная трассировка может быть инициирована, когда кто-то нажимает кнопку кнопку, чтобы начать действие на веб-сайте — в этом примере кнопка трассировка будет представлять вызовы, сделанные между нижестоящими службами который обрабатывал цепочку запросов, инициированных этой кнопкой нажимается.

[БИТ-ПОЛЕ]

8-битное поле . Википедия. URL-адрес: https://en.wikipedia.org/wiki/Bit_field

[FETCH]

Fetch Standard . Энн ван Кестерен. WHATWG. Уровень жизни. URL: https://fetch.spec.whatwg.org/

[RFC0020]

Формат ASCII для сетевого обмена . В.Г. Серф. IETF. Октябрь 1969 г. Интернет-стандарт. URL-адрес: https://www.rfc-editor.org/rfc/rfc20

[RFC2119]

Ключевые слова для использования в RFC для обозначения уровней требований . С. Браднер. IETF. Март 1997 г. Передовая современная практика. URL: https://www.rfc-editor.org/rfc/rfc2119

[RFC5234]

Расширенный BNF для спецификаций синтаксиса: ABNF . Д. Крокер, изд.; П. Оверелл. IETF. Январь 2008 г. Интернет-стандарт. URL: https://www.rfc-editor.org/rfc/rfc5234

[RFC7230]

Протокол передачи гипертекста (HTTP/1.1): синтаксис и маршрутизация сообщений . Р. Филдинг, изд.; Дж. Решке, изд. IETF. Июнь 2014 г. Предлагаемый стандарт. URL: https://httpwg.org/specs/rfc7230.html

[RFC8174]

Неоднозначность прописных и строчных букв в ключевых словах RFC 2119 . Б. Лейба. IETF. Май 2017 г. Передовая современная практика. URL-адрес: https://www.rfc-editor.org/rfc/rfc8174

[trace-context-protocols-registry]

Реестр протоколов контекста трассировки . Сергей Канжелев; Филипп Ле Эгаре. W3C. 19 ноября 2019 г. Примечание рабочей группы W3C. URL: https://www. w3.org/TR/trace-context-protocols-registry/

Контекст трассировки

Abstract

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

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

Чтобы сопоставить события между компонентами, эти компоненты должны обмениваться и хранить часть информации, называемую контекстом. Обычно контекст состоит из идентификатора исходящего события, идентификатора исходного компонента и других свойств события. Контекст состоит из двух частей. Первая часть — это контекст трассировки. Контекст трассировки состоит из свойств, важных для корреляции событий. Вторая часть — корреляционный контекст. Контекст корреляции несет определяемые пользователем свойства. Эти свойства могут быть полезны для сценариев корреляции. Но они не требуются, и компоненты могут отказаться от их переноски или хранения.

Унификация формата распределенного контекста трассировки, а также согласование семантического значения значений — основная цель этой рабочей группы. Цель состоит в том, чтобы поделиться этим с сообществом, чтобы различные продукты для отслеживания и диагностики могли работать вместе.

Статус этого документа

В этом разделе описывается статус этого документа на момент его публикации. Этот документ может быть заменен другими документами. Список текущих публикаций W3C и последнюю редакцию этого технического отчета можно найти в Указатель технических отчетов W3C на https://www. w3.org/TR/.

Это первый общедоступный рабочий проект (ФПВД). Есть доступно несколько реализаций этого протокола. Экспериментальная совместимость сценарии были запущены и продемонстрировали многообещающие результаты. Спецификация будет после этого перешел в стадию кандидата-рекомендации, проекты для двоичного кода, AMQP и Протоколы MQTT будут написаны, чтобы убедиться, что концепции и структура определены в этой спецификации могут быть перенесены на другие протоколы.

Этот документ был опубликован Рабочей группы по распределенной трассировке в качестве Рабочий проект. Этот документ должен стать Рекомендацией W3C .

Гитхаб Проблемы предпочтительны для обсуждение этого Спецификация. Альтернативно, ты можешь Отправить Комментарии нашим почтовое отправление список. Пожалуйста, пришлите их к общественный-след-контекст@w3.org (архивы) с контекст трассировки в начало твой электронная почта предмет .

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

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

Настоящий документ регулируется 1 февраля 2018 г. Технологический документ W3C .

1. Обзор

Контекст трассировки состоит из набора свойств, важных для корреляции событий в распределенных приложениях. Контекст трассировки размещает запросы в распределенной трассировке. Если вы посмотрите на распределенную трассировку как на график коррелированных запросов, то один запрос может быть частью нескольких графиков. Например, пусть компонент A вызывает компонент B , который, в свою очередь, вызывает C . Одна распределенная система трассировки может видеть компонент A , вызывающий компонент B . Другой может видеть, что все три компонента обмениваются данными. Таким образом, вызов с B на C будет нести контекст трассировки об услуге A , а также информацию о ее прямом восходящем соединении с B .

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

Контекст трассировки обеспечивает расширяемость для всех распределенных систем трассировки. Это требует от них соблюдения контекста, установленного другими системами.

Контекст трассировки представлен набором пар имя/значение, описывающих идентификатор каждого HTTP-запроса. Два поля распространения несут общие и специфичные для поставщика свойства, составляющие контекст трассировки.

• traceparent описывает позицию входящего запроса в графе трассировки в переносимом формате фиксированной длины. Его дизайн ориентирован на быстрый синтаксический анализ.
• tracestate сопоставляет все графы, частью которых является входящий родитель, в форматах, потенциально зависящих от поставщика. Например, если запрос пересекает системы трассировки, в tracestate будет одна запись для каждой системы.

Примечательно, что поле tracestate не зависит от данных в traceparent .

Библиотеки и платформы ДОЛЖНЫ распространять заголовки traceparent и tracestate , чтобы гарантировать, что трассировка не будет нарушена.

3. Конфиденциальность

Требования по распространению заголовков нижестоящим службам, а также сохранение значений этих заголовков открывают потенциальные проблемы с конфиденциальностью. Поставщики трассировки НЕ ДОЛЖНЫ использовать поля traceparent и tracestate для любой личной или иной конфиденциальной информации. Единственная цель этих полей — включить корреляцию телеметрии.

Поставщики трассировки ДОЛЖНЫ оценить риск злоупотребления заголовком. В этом разделе представлены некоторые соображения и первоначальная оценка риска, связанного с хранением и распространением этих заголовков. Поставщики трассировки могут выбрать проверку и удаление конфиденциальной информации из полей, прежде чем позволить платформе или системе трассировки выполнять код, который потенциально может распространять или хранить эти поля. Однако все мутации должны соответствовать списку мутаций, определенному в данной спецификации.

3.1 Конфиденциальность поля traceparent

поле traceparent имеет предопределенный набор значений. Эти значения являются случайно сгенерированными числами. Если у генератора случайных чисел есть какая-либо логика использования идентифицирующей пользователя информации, такой как IP-адрес, эта информация может быть раскрыта. Генераторы случайных чисел НЕ ДОЛЖНЫ полагаться на любую информацию, которая потенциально может быть идентифицируема пользователем.

Еще одна угроза конфиденциальности поля traceparent — это способность сопоставлять вызовы, сделанные как часть одной транзакции. Нисходящая служба может отслеживать и сопоставлять два или более вызовов, сделанных в одной транзакции, и делать предположения об идентичности вызывающего абонента одного вызова на основе информации из другого вызова. Услуга инициирования звонков МАЙ решил перезапустить трассировку при совершении вызовов, которые могут идентифицировать вызывающего абонента в нижестоящей службе.

Обратите внимание, что обе проблемы конфиденциальности поля traceparent носят скорее теоретический, чем практический характер.

3.2 Конфиденциальность поля tracestate

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

Платформы и системы отслеживания НЕ ДОЛЖНЫ включать какую-либо личную информацию в заголовок tracestate .

Платформы и системы слежения, чрезвычайно чувствительные к раскрытию личной информации МАЯ реализуют выборочное удаление значений, соответствующих неизвестным ключам. Эта мутация поля tracestate не запрещена, но крайне нежелательна. Поскольку это противоречит цели этого поля для обеспечения совместной работы нескольких систем отслеживания.

4. Безопасность

Существует два типа потенциальных угроз безопасности, связанных с этой спецификацией: раскрытие информации и атаки типа «отказ в обслуживании» против системы отслеживания.

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

4.1 Раскрытие информации

Как упоминалось в разделе о конфиденциальности, информация в заголовках traceparent и tracestate может содержать информацию, которая может быть считается чувствительным. Например, traceparent может позволить сопоставить один вызов с данными, отправленными с другим вызовом. tracestate может подразумевать версию программного обеспечения для мониторинга, используемого вызывающим абонентом. Эта информация потенциально может быть использована для создать большую атаку.

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

4.2 Отказ в обслуживании

Когда распределенная трассировка включена в службе с общедоступным API и наивно продолжает любую трассировку с установленным флагом записано , злоумышленник может перегрузить приложение трассировкой накладных расходов, подделать идентификатор трассировки коллизий которые делают данные мониторинга непригодными для использования или увеличивают ваш счет за отслеживание с помощью вашего SaaS отслеживание продавца.

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