Деревья

Вместе с метаданными, OpenTSDB 2.0 вводит понятие деревьев, иерархического метода организации временных рядов в легко навигационную структуру, которую можно просматривать, как файловую систему на компьютере. Пользователи могут определить несколько деревьев с различными наборами правил, которые организуют объекты TSMeta в структуру дерева. Затем пользователи могут просматривать полученное дерево через конечную точку HTTP API. Подробности см. в /api/tree.

Терминология деревьев

• Ветвь - Каждая ветвь — это один узел дерева. Она содержит список дочерних ветвей и листьев, а также список родительских ветвей.
• Лист - Конец ветви и представляет собой уникальный временной ряд. Лист будет содержать значение TSUID, которое можно использовать для генерации запроса TSD. Ветвь может, и скорее всего будет, иметь несколько листьев.
• Корень - Корневая ветвь — начало дерева, и все ветви расходятся от этого корня. Ее глубина равна 0.
• Глубина - Каждый раз, когда ветвь добавляется к другой ветви, глубина увеличивается.
• Строгое соответствие - При включенном режиме, временной ряд должен соответствовать правилу на каждом уровне набора правил. Если один или несколько уровней не соответствуют, временной ряд не будет включен в дерево.
• Путь - Название и уровень каждой ветви над текущей ветвью в иерархии.

Ветвь

Каждый узел дерева записывается как объект ветвь. Каждая ветвь содержит информацию, такую как:

• Идентификатор ветви - Идентификатор ветви. Это шестнадцатеричное значение, описанное ниже.
• Отображаемое имя - Имя ветви, полученное из объекта TSMeta набором правил дерева.
• Глубина - Насколько глубоко в иерархии находится ветвь.
• Путь - Глубина и имя каждой родительской ветви (включает локальную ветвь).
• Ветви - Дочерние ветви на один уровень ниже этой ветви.
• Листья - Листья, принадлежащие этой ветви.

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

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

Листья

Уникальный временной ряд представлен как лист на дереве. Лист может появляться на любой ветви структуры, включая корень. Но они обычно появляются в конце серии ветвей в ветви, которая имеет один или несколько листьев, но не имеет дочерних ветвей. Каждый лист содержит TSUID для временного ряда, который будет использоваться в запросе, а также имя и значения метрики и тега. Он также содержит отображаемое имя, полученное из набора правил, но может не совпадать ни с одним из имен метрики, имен тегов или значений тегов.

В идеале временной ряд будет появляться только один раз в дереве. Но если объект TSMeta для временного ряда, ИЛИ UIDMeta для метрики или тега изменены, он может быть обработан второй раз, и будет добавлен второй лист. Это может происходить особенно в ситуациях, когда дерево имеет пользовательское правило для метрики, имени тега или значения тега, где TSMeta был обработан, а затем пользователь добавляет пользовательское поле, которое соответствует набору правил. В таких ситуациях рекомендуется включить строгое соответствие для дерева, чтобы временной ряд не отображался до тех пор, пока пользовательские данные не будут добавлены.

Правила

Каждое дерево динамически строится из набора правил, определенных пользователем. Набор правил должен содержать как минимум одно правило и обычно содержит больше одного. Каждый набор имеет несколько уровней, определяющих порядок обработки правил. Правила, расположенные на уровне 0, обрабатываются первыми, затем правила на уровне 1 и так далее, пока все правила не будут применены к данному временному ряду. Каждый уровень в наборе правил может иметь несколько правил для обработки ситуаций, когда метрики и теги могут не быть спланированы заранее или могут случайно попасть какие-то произвольные данные. Если на уровне хранятся несколько правил, будет применено первое правило, которое успешно соответствует, а остальные будут проигнорированы. Эти правила также упорядочены по полю order, так что правило с порядком 0 обрабатывается первым, затем правило с порядком 1 и так далее. В логах и при использовании тестовой конечной точки правилам обычно присваиваются идентификаторы в формате "[<treeId>:<level>:<order>:<type>]", например, "[1:0:1:0]" указывает правило для дерева 1, на уровне 0, порядке 1 типа METRIC.

Построение дерева

Сначала необходимо создать таблицу tsdb-tree в HBase, если вы этого еще не сделали. Если вы включите обработку дерева, а таблица не существует, TSD не будут запускаться.

Дерево можно построить двумя способами. Настройка tsd.core.tree.enable_processing позволяет создавать дерево в реальном времени. Всякий раз, когда пользователь создает или редактирует новый объект TSMeta, объект TSMeta будет передан через каждое настроенное и включенное дерево. Результирующая ветвь будет записана в хранилище. Если произойдет конфликт или TSUID не совпадет с правилами, будет зарегистрировано предупреждение, и, если настроены параметры дерева, может быть записано в хранилище.

В качестве альтернативы вы можете периодически синхронизировать все объекты TSMeta через инструмент командной строки uid. Это позволит сканировать таблицу tsdb-uid и передавать каждый обнаруженный объект TSMeta через настроенные и включенные деревья. Подробности см. в uid.

Общая процедура создания и построения дерева следующая:

1. Создайте новое дерево через API HTTP
2. Назначьте одно или несколько правил дереву через API HTTP
3. Протестируйте правила с некоторыми объектами TSMeta через API HTTP
4. После проверки правильности отображения ветвей установите флаг enable дерева в true
5. Запустите инструмент uid с подкомандой treesync для синхронизации существующих объектов TSMeta в дереве

Коллизии

Из-за гибкости наборов правил и широкого разнообразия имён метрик, тегов и значений почти неизбежно, что две разные записи TSMeta будут пытаться создать один и тот же лист в дереве. Каждая ветвь может содержать только один лист с заданным отображаемым именем. Например, если ветвь содержит лист с именем user с TSUID 010101, но дерево пытается добавить новый лист с именем user с TSUID 020202, новый лист не будет добавлен в дерево. Вместо этого будет записана запись коллизии для дерева, указывающая, что TSUID 0202020 столкнулся с существующим листом для TSUID 010101. API HTTP можно использовать для запроса списка коллизий, чтобы проверить, не появился ли конкретный TSUID в дереве из-за коллизии.

Несовпадения

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

Примеры

Предположим, что наш TSD хранит следующие временные ряды:

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

Теперь давайте настроим дерево с отключенным strictMatching и следующими правилами:

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

В наших примерах данных у нас были некоторые старые временные ряды, у которых не было тега dc. Однако тег host содержит полное доменное имя с именем центра обработки данных. Таким образом, первый уровень нашего набора правил содержит два правила. Первое будет искать тег dc, а если найдено, оно будет использовать значение этого тега, а второе правило пропустит. Если тег dc не существует, то второе правило будет сканировать значение тега host и попытаться извлечь имя центра обработки данных из полного доменного имени. Второй уровень имеет одно правило, и оно используется для группировки по значению тега host, чтобы все метрики, относящиеся к этому хосту, отображались в ветвях под ним. На последнем уровне есть правило метрики, которое включает разделитель для дальнейшей группировки временных рядов по содержанию. Поскольку у нас есть множество метрик CPU и приложений, все разделенные точкой, имеет смысл добавить разделитель на данном этапе.