Релиз Tempo 3.1: новые функции для Kafka, обновления метрик TraceQL, удаление данных из трассировок и многое другое

В Tempo 3.1 добавлено несколько улучшений, предложенных сообществом для приема данных на основе Kafka, включая новые опции для защиты соединений, снижения затрат на передачу данных и поддержки большего количества бэкендов, совместимых с Kafka.

TLS и дополнительные механизмы SASL

В Tempo 3.0 прием данных в режиме микросервисов был перенесен на Kafka, и клиент, поставляемый с ним, мог выполнять аутентификацию только через SASL PLAIN и только по незашифрованному соединению. В нем не было настроек TLS, поэтому брокер, требующий TLS, отклонял соединение. В Tempo 3.1 добавлены TLS и еще четыре механизма: SCRAM-SHA-256, SCRAM-SHA-512, OAUTHBEARER и AWS_MSK_IAM.

Используйте -config.expand-env=true для раскрытия переменных окружения.

Спасибо @heytrav за этот вклад. Чтобы узнать больше, см. PR и документацию по настройке аутентификации и TLS.

Выборка с учетом стойки (Rack-aware fetching)

Tempo всегда получал данные от лидера раздела, где бы он ни находился. Когда лидер находится в другой зоне доступности, каждая прочитанная трассировка пересекает границу зоны, и ваш облачный провайдер выставляет счет за передачу.

Новая опция client_rack помогает снизить эти расходы, включая выборку с учетом стойки (KIP-392), чтобы потребители могли читать данные из реплики в своей собственной зоне:

Это настройка на стороне чтения, поэтому она применяется к сборщикам блоков (block-builders), хранилищам в реальном времени (live-stores) и генераторам метрик, а не к дистрибьютору, записывающему записи в Kafka. Для того чтобы это заработало, ваши брокеры должны иметь настроенные идентификаторы стоек (rack IDs).

Спасибо @KyriosGN0 за этот вклад. Чтобы узнать больше, см. PR и документацию по настройке приема данных.

Настраиваемое сжатие данных производителем

Дистрибьютор Tempo сжимает каждый пакет, который он записывает в Kafka, и до версии 3.1 кодек нельзя было настроить. Это нормально, если ваш бэкенд принимает только один кодек: например, Azure Event Hubs поддерживает протокол Kafka, но принимает только gzip, что исключало его использование в качестве бэкенда для Tempo.

Новая опция producer_compression позволяет выбрать один из вариантов: none, gzip, snappy, lz4 или zstd:

Вместе с поддержкой TLS, упомянутой выше, эта опция делает Event Hubs пригодным бэкендом Kafka для Tempo. Если оставить producer_compression не заданным, клиент Kafka по умолчанию использует snappy. Если ваш бэкенд не поддерживает snappy, установите producer_compression на поддерживаемый алгоритм или установите значение none, чтобы отключить сжатие.

Спасибо @fleighton за этот вклад. Чтобы узнать больше, см. PR и документацию по настройке приема данных.

Защита конфиденциальных данных: удаление данных из трассировок с помощью запроса TraceQL

В Tempo 3.0 мы добавили функцию удаления данных из трассировок, позволяющую навсегда удалить конфиденциальную информацию, такую как адрес электронной почты, токен авторизации или номер счета, попавшие в атрибут спана, из ваших данных трассировки, не дожидаясь истечения срока хранения. Однако tempo-cli redact принимал только идентификаторы трассировок, поэтому вам приходилось перечислять каждую затронутую трассировку. Конфиденциальные данные обычно попадают в любой трафик, проходящий через определенный путь кода, что может означать гораздо больше трассировок, чем можно практически перечислить. Любая пропущенная трассировка — это данные, которые остаются в объектном хранилище и потенциально доступны для запросов.

Теперь, в Tempo 3.1, вы можете удалять данные с помощью запроса TraceQL:

Начните с --dry-run, как показано выше. Tempo выполнит запрос и подсчитает, что именно будет удалено, не изменяя никаких блоков. Команда выведет идентификатор пакета и количество созданных заданий. Количество заданий и объем найденных или удаленных трассировок — это метрики для каждого арендатора, которые можно увидеть в строке «Redaction» на панели мониторинга Backend Work, поставляемой с миксином мониторинга Tempo. Как только количество совпадет с ожидаемым, выполните ту же команду без --dry-run, чтобы перезаписать блоки. Это действие нельзя отменить.

Поскольку неверный запрос навсегда удаляет данные, которые вы не собирались удалять, мы намеренно ограничиваем поддерживаемый синтаксис: это один фильтр spanset со сравнением на равенство атрибутов resource.* и span.*, объединенных с помощью && и ||. Все, что выходит за рамки этого, отклоняется при отправке задания. Мы продолжаем улучшать эту функциональность.

Если вы знаете временной диапазон, в котором данные должны быть удалены, вы можете использовать его для более быстрого и эффективного выполнения задания. Это важно при установках с большим объемом данных, так как Tempo приостанавливает компакцию для арендатора во время выполнения удаления. Используйте --start и --end, которые принимают значение now, относительное смещение, например now-7d, или метку времени в формате RFC3339. Компакция возобновляется между запусками.

Примечание: Используйте --start и --end только тогда, когда каждый планировщик и рабочий процесс в вашей ячейке работает как минимум на версии Tempo 3.1. Более старый рабочий процесс проигнорирует окно и удалит все совпадения запроса в каждом блоке, который ему передан, независимо от метки времени, без ошибки и без возможности восстановления данных.

Чтобы узнать больше, см. селектор запросов PR, временной диапазон PR и документацию по удалению данных из трассировок (Redact traces) для получения полного синтаксиса запросов и ограничений.

Запрос метрик трассировки с большей точностью, гибкостью и скоростью: обновления метрик TraceQL

В Tempo 3.0 метрики TraceQL стали общедоступными, позволяя запрашивать специальные метрики непосредственно из данных трассировки. Это упрощает ответы на вопросы о производительности, частоте ошибок и поведении сервисов в распределенных системах.

В релизе 3.1 мы внедряем несколько обновлений, которые делают метрики TraceQL более гибкими и эффективными, а также более точными при работе с данными выборочной трассировки.

Метрические запросы с учетом выборки

Допустим, вы собираете 50% трассировок до того, как они попадут в Tempo. Если вы выполните запрос rate() для сервиса, вы получите половину трафика, который он фактически обслужил, потому что Tempo учитывает только те спаны, которые прошли через выборку.

Это особенно полезно при использовании Adaptive Traces и других настроек выборки в конце (tail sampling), где частота выборки может варьироваться в разных сервисах. Благодаря запросам с учетом выборки метрики TraceQL могут учитывать эти различия и более точно отражать реальный трафик.

В Tempo 3.1 вы можете скорректировать выборку во время выполнения запроса с помощью новой экспериментальной подсказки with(extrapolate=true):

Тот же запрос на трассировках с 50% выборкой: без подсказки слева и с ней справа. Графики имеют одинаковую форму, но ось Y заканчивается на 4 слева и на 8 справа.

Сэмплеры, реализующие спецификацию вероятностной выборки OpenTelemetry probability sampling specification, которая все еще находится в разработке и пока поддерживается не во всех языках, помечают частоту выборки на спане в поле tracestate. Подсказка считывает эту частоту и соответствующим образом масштабирует спан. При 50% выборке каждый сохраненный спан считается за два, поэтому запрос, который находит 1000 спанов, сообщает о 2000. Спаны, которые приходят без записанной частоты выборки, считаются за один, что означает безопасность частичного внедрения: если только два ваших сервиса используют выборку, показатели других сервисов не изменятся.

В ваши блоки ничего нового не записывается. tracestate уже хранится с каждым спаном, и запросы, которые не используют подсказку, не считывают его. Если вы уже корректируете выборку в генераторе метрик, установив enable_tracestate_span_multiplier, что мы added в Tempo 3.0, путь запроса считывает частоту таким же образом, поэтому специальный запрос и ваши предварительно агрегированные ряды tempo_spanmetrics_* будут совпадать.

Экстраполяция применяется к rate, count_over_time, sum_over_time, avg_over_time, histogram_over_time, quantile_over_time и compare. Она не применяется к min_over_time или max_over_time, поскольку выборка не меняет минимальное или максимальное значение, которое вы фактически наблюдали.

Примечание: эта подсказка является экспериментальной и требует использования блоков vParquet4 или более поздних версий.

Чтобы узнать больше, см. PR и документацию по метрическим функциям TraceQL.

Объединение метрических запросов с помощью арифметических операций

Многие метрики, которые вы хотите получить из трассировок, требуют объединения двух метрических запросов, а не выполнения только одного. Распространенным примером является частота ошибок. Раньше TraceQL мог измерять ошибки и общий трафик отдельно, но не мог делить одно на другое, поэтому вам приходилось выполнять два запроса и делить их с помощью математического выражения в Grafana.

В Tempo 3.1 вы можете записать деление непосредственно в TraceQL. Операторы +, -, * и / работают между двумя метрическими запросами, поэтому частота ошибок — это один запрос:

То же деление с by (resource.service.name) с обеих сторон, чтобы каждый сервис получал свою собственную частоту ошибок. В отличие от этого, при запросе ({status=error} | rate() by (resource.service.name)) / ({} | rate()) только числитель группируется по сервису, в то время как знаменатель рассчитывается по всем данным.

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

Вы можете комбинировать with(extrapolate=true) и арифметику. Одна подсказка в конце выражения применяется к обоим подзапросам:

Подсказка должна стоять в конце. Размещение with(...) внутри подзапроса является синтаксической ошибкой.

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

Более быстрые метрические запросы по умолчанию

Метрические запросы также стали быстрее: мы заметили, что простые запросы выполняются почти в два раза быстрее. Путь выборки только спанов (span-only fetch), который мы представили как экспериментальный в Tempo 3.0, теперь включен по умолчанию для блоков vParquet5, которые записывает Tempo 3.1.

Запросы, которым не нужна полная структура трассировки, теперь обрабатывают отдельные спаны вместо целых трассировок, что снижает задержку и использование памяти. В одном прогретом тесте { } | rate() с включенной выборкой только спанов завершился чуть более чем за половину времени, которое потребовалось с отключенной выборкой только спанов. Вам не нужно менять свои запросы, чтобы использовать это, и вы можете отказаться от этой функции для каждого арендатора или для каждого запроса, если это необходимо.

Чтобы узнать больше, см. PR и документацию по более быстрому пути чтения.

Улучшения в metrics-generator

Metrics-generator — это дополнительный компонент Tempo, который извлекает метрики из принятых спанов, предоставляя вам как RED-метрики (Rate/Error/Duration), так и графы сервисов, которые показывают взаимосвязи между вашими сервисами. Здесь мы рассмотрим несколько улучшений metrics-generator, включенных в Tempo 3.1, но, пожалуйста, обратитесь к changelog и примечаниям к выпуску для получения полного списка.

Узнайте, почему на вашей карте сервисов отсутствуют ребра

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

В Tempo 3.1 мы добавили метку unmatched_span_kind к счетчику истекших ребер, чтобы вы могли видеть, какая сторона пропала. Например, многие истекшие ребра с меткой SPAN_KIND_SERVER указывают на инструментарий «сервер-сервер», который никогда не разрешится в узел.

Чтобы узнать больше, см. PR, документацию по графам сервисов и документацию по устранению неполадок с истекшими ребрами.

Распознавание db.system.name из обновленных семантических соглашений OTel

OpenTelemetry семантические соглашения v1.30.0 переименовали атрибут db.system в db.system.name. Инструментарий, который выдает только новое имя, перестал распознаваться как вызов базы данных, поэтому эти узлы исчезли с вашей карты сервисов после обновления SDK без каких-либо ошибок.

Tempo 3.1 принимает оба атрибута для идентификации запросов к базе данных и для именования виртуальных узлов. Когда спан содержит оба, db.system имеет приоритет, поэтому обновление ваших SDK не переименует узлы, на которые уже указывают ваши дашборды и алерты.

Спасибо @iamrajiv за этот вклад. Чтобы узнать больше, см. PR и документацию по атрибутам имен баз данных.

Снижение затрат на metrics-generator для каждого спана

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

Процессоры span-metrics и service-graphs теперь заимствуют пулы буферов меток из реестра вместо того, чтобы каждый раз выделять новые, и наши тесты производительности service-graphs в установившемся режиме сообщают о нулевых выделениях памяти на операцию. Имена метрик, метки и значения остались прежними, поэтому вы не увидите разницы в своих дашбордах, только процессорное время и память генератора, которые вам больше не нужно выделять.

Чтобы узнать больше, см. PR по метрикам спанов и PR по графам сервисов.

Упрощение чтения больших трассировок с помощью обрезки спанов

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

В Tempo 3.1 конечная точка trace-by-ID v2 сворачивает каждую группу похожих листовых спанов в один сводный спан, который несет aggregation.span_count, а также минимальную, максимальную, среднюю и общую длительность спанов, которые он заменил. В приведенном выше примере вы получаете 2 спана вместо 101 в соответственно меньшем ответе. Спаны группируются только тогда, когда их имя, тип, статус и имя родителя совпадают, поэтому ошибка никогда не объединяется с успешными результатами. Это происходит во время чтения, поэтому ничего не покидает хранилище.

Запросите это для каждого запроса:

Установите span_pruning_enabled_by_default в значение true в вашей конфигурации Tempo, и вам не нужно будет передавать span_pruning в каждом запросе:

Это также охватывает пользовательский интерфейс Grafana и инструмент get-trace сервера Tempo MCP, ни один из которых пока не отправляет этот параметр. Явный span_pruning в запросе по-прежнему имеет приоритет, поэтому вызывающая сторона, которой нужна полная трассировка, всегда может ее запросить. Вы также можете установить это значение по умолчанию для каждого арендатора.

Мы также добавили поддержку фильтров TraceQL в конечную точку trace-by-ID v2. Она принимает один фильтр spanset в параметре q, поэтому вы можете получить одну трассировку и вернуть только те спаны, которые соответствуют критериям, вместо всех. По умолчанию эти спаны возвращаются сами по себе; добавьте keep_hierarchy=true, и вы также получите путь предков каждого совпадения до корня.

CLI gcx обновляется, чтобы предоставить оба параметра в gcx traces get: --prune для обрезки и --filter для запроса.

Примечание: обрезка спанов является экспериментальной. Параметры span_pruning, их поведение и формат ответа могут измениться в будущих выпусках.

Чтобы узнать больше, см. документацию по обрезке трассировокPR, фильтрам PR, API Query V2 для параметров запроса, документацию по конфигурации query-frontend и августовский звонок сообщества.

Сделайте сравнение трасс быстрее и эффективнее для ИИ

Иногда нужно сравнить две трассы: после развёртывания конечная точка стала отвечать медленнее, и у вас есть одна трасса до и одна после, либо один и тот же запрос успешно выполняется для одного клиента и завершается ошибкой для другого. В любом случае ручное сравнение означает прокрутку двух трасс в поисках span, который изменился, появился или исчез.

В Tempo 3.1 можно использовать traces diff, чтобы отправить два идентификатора трасс в query-frontend и получить ответ о том, что изменилось, вместо того чтобы загружать обе трассы и сравнивать их самостоятельно. Это также создаёт гораздо меньшее контекстное окно для LLM, что делает расследования на основе ИИ быстрее и дешевле:

По умолчанию вы получаете патч на уровне span, в котором перечислены все span, которые были добавлены, удалены или изменены. Частичные трассы отклоняются, поскольку span, отсутствующие в неполной трассе, будут выглядеть как удалённые span.

Вы также можете запросить сводку вместо патча. Она сообщает, увеличилась или уменьшилась задержка трассы, количество ошибок и число span, изменилась ли структура и какие сервисы были задействованы, а для тех, которые изменились, — дельта в миллисекундах. Она показывает направление изменения каждой метрики, а не является ли это регрессией. Трасса, которая стала быстрее, может просто завершаться ошибкой раньше.

Сводка также выявляет дрейф, который патч отфильтровывает. Если каждый span в сервисе стал немного медленнее, ни один отдельный span не превышает допустимое отклонение на span, но суммарная длительность span сервиса превышает его, поэтому сервис по-прежнему отображается как изменённый.

Существует несколько инструментов, которые можно использовать для получения traces diff. Средство gcx CLI оборачивает API в экспериментальную команду gcx traces diff, так что вы можете сравнить два идентификатора из терминала, не загружая ни одну из трасс самостоятельно:

Команда tempo-cli experimental traces-diff вместо этого сравнивает два локальных JSON-файла трасс, что удобно, если вы уже экспортировали их. По умолчанию она выводит патч, а сводку можно получить с помощью --format. Сервер Tempo MCP, добавленный в 2.9, теперь включает инструмент traces-diff, который сначала возвращает сводку, поэтому ИИ-ассистент, подключённый к Tempo, получает пригодный ответ, не всегда загружая большой патч.

Примечание: этот endpoint является экспериментальным. Форматы запроса и ответа могут измениться в будущих выпусках.

Чтобы узнать больше, см. PR API, PR CLI, PR MCP, документацию API traces diff, документацию экспериментальной команды traces diff в Tempo CLI, справочник gcx traces diff и документацию Compare traces в Tempo MCP.

Повышенная производительность запросов и меньшее потребление памяти: vParquet5 теперь является форматом блоков по умолчанию

Tempo хранит трассы в блочном столбчатом формате Apache Parquet и продолжает совершенствовать структуру для лучшей производительности и эффективности. Мы представили vParquet5 как формат по выбору в Tempo 2.10, а в 3.1 он становится форматом по умолчанию.

Более быстрый путь чтения метрик, упомянутый ранее в этой статье, — одно из преимуществ нового формата по умолчанию. Он реализован только для vParquet5, а для блоков в более старых форматах Tempo переключается на стандартный путь, поэтому запросы метрик становятся быстрее по мере накопления новых блоков. Ещё одно преимущество состоит в том, что новые блоки поддерживают встроенный атрибут span:childCount. Мы добавили его в 2.10, но поддерживает его только vParquet5, поэтому ранее для его использования нужно было включать vParquet5.

vParquet5 также предоставляет больше возможностей для настройки конфигурации столбцов Parquet. Теперь можно иметь вдвое больше выделенных столбцов для строк, поддержку целых чисел, а также поддержку очень длинных строк или строк с высокой кардинальностью (известных как «blobs») на каждом из уровней resource, span и event. Лучший способ воспользоваться этим — использовать новую команду tempo-cli suggest columns. Она проанализирует ваши данные и подскажет оптимальную структуру, а также позволит легко скопировать и вставить вывод в конфигурацию Tempo.

Чтобы узнать больше о возможностях, которые приносит vParquet5, см. документацию по выделенным столбцам и раздел vParquet5 в блоге о выпуске Tempo 2.10. Вы также можете посмотреть PR и документацию по блочному формату Apache Parquet.

Как узнать больше

Чтобы увидеть полный список улучшений, исправлений ошибок и несовместимых изменений в Tempo 3.1, обратитесь к заметкам о выпуске и . Перед обновлением ознакомьтесь с документом «Обновление установки Tempo» и учтите изменения, требующие действий.

Если вам интересно узнать больше о новостях Tempo, присоединяйтесь к нам в канале #tempo в Slack-сообществе Grafana Labs, задайте вопрос в наших форумах сообщества или присоединяйтесь к нашему ежемесячному созвону сообщества Tempo. До встречи там!