Запись данных

Агрегация

Хотя система меток гибкая, могут возникнуть некоторые проблемы, если вы не понимаете сторону запросов в OpenTSDB, поэтому необходима предварительная проработка. Рассмотрим пример запроса выше: sum:sys.cpu.user{host=webserver01}. Мы записали 64 уникальных временных ряда для webserver01, по одному временной ряду для каждого ядра процессора. Когда мы выполнили этот запрос, были извлечены все временные ряды для метрики sys.cpu.user с меткой host=webserver01, усреднены и возвращены как один ряд чисел. Допустим, полученное среднее значение составило 50 для метки времени 1356998400. Мы мигрировали из другой системы в OpenTSDB и имели процесс, который предварительно агрегировал все 64 ядра, чтобы мы могли быстро получить среднее значение и просто записать новый временной ряд sys.cpu.user host=webserver01. Если мы выполним тот же запрос, мы получим значение 100 в 1356998400. Что случилось? OpenTSDB агрегировал все 64 временных ряда и предварительно агрегированный временной ряд, чтобы получить это 100. В хранилище у нас будет что-то вроде этого:

sys.cpu.user host=webserver01    1356998400  50
sys.cpu.user host=webserver01,cpu=0  1356998400  1
sys.cpu.user host=webserver01,cpu=1  1356998400  0
sys.cpu.user host=webserver01,cpu=2  1356998400  2
sys.cpu.user host=webserver01,cpu=3  1356998400  0
...
sys.cpu.user host=webserver01,cpu=63 1356998400  1

OpenTSDB автоматически агрегирует все временные ряды для метрики в запросе, если не заданы никакие метки. Если определены одна или несколько меток, агрегация будет «включать все» временные ряды, соответствующие этой метке, независимо от других меток. В запросе sum:sys.cpu.user{host=webserver01} мы бы включили sys.cpu.user host=webserver01,cpu=0, а также sys.cpu.user host=webserver01,cpu=0,manufacturer=Intel, sys.cpu.user host=webserver01,foo=bar и sys.cpu.user host=webserver01,cpu=0,datacenter=lax,department=ops. Мораль этого примера: будьте осторожны со схемой именования.

Мощность временных рядов

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

Ограниченные уникальные идентификаторы (UID)

Существует ограниченное количество уникальных идентификаторов для присвоения каждой метрике, имени метки и значению метки. По умолчанию доступно чуть более 16 миллионов возможных идентификаторов на тип. Например, если вы управляете очень популярной веб-службой и пытаетесь отслеживать IP-адреса клиентов в качестве метки, например, web.app.hits clientip=38.26.34.10, вы можете быстро столкнуться с лимитом присвоения UID, так как существует более 4 миллиардов возможных адресов IP версии 4. Кроме того, такой подход приведёт к созданию очень разреженного временного ряда, так как пользователь с адресом 38.26.34.10 может использовать ваше приложение спорадически или, возможно, никогда больше с этого конкретного адреса.

Однако ограничение по UID обычно не является проблемой. Значению метки присваивается UID, который полностью отделён от имени метки. Если вы используете числовые идентификаторы для значений меток, число присваивается UID один раз и может использоваться с многими именами меток. Например, если мы присвоим UID числу 2, мы можем сохранить временные ряды с парами меток cpu=2, interface=2, hdd=2 и fan=2, используя только 1 UID значения метки (2) и 4 UID имени метки (cpu, interface, hdd и fan).

Если вы думаете, что ограничение по UID может повлиять на вас, сначала подумайте о запросах, которые вы хотите выполнить. Если мы посмотрим на пример web.app.hits выше, вам, вероятно, важна только общее количество обращений к вашей службе, и редко нужно углубляться до конкретного IP-адреса. В этом случае вы можете сохранить IP-адрес как аннотацию. Таким образом, вы по-прежнему можете извлечь выгоду из низкой мощности, но если вам нужно, вы можете поискать результаты по этому конкретному IP-адресу с помощью внешних скриптов. (Примечание: поддержка запросов аннотаций ожидается в будущей версии OpenTSDB.)

Если вам действительно нужно больше, чем 16 миллионов значений, вы можете увеличить количество байтов, используемых OpenTSDB для кодирования UID, с 3 до максимального значения в 8 байт. Эта модификация потребует изменения значения в исходном коде, перекомпиляции, развертывания вашей настраиваемой версии кода на все TSD, которые будут получать доступ к этим данным, и поддержки этой настройки во всех будущих обновлениях и выпусках.

Скорость запросов

Мощность также существенно влияет на скорость запросов, поэтому рассмотрите запросы, которые вы будете выполнять часто, и оптимизируйте схему именования для них. OpenTSDB создаёт новую строку на каждый временной ряд в час. Если у нас есть временной ряд sys.cpu.user host=webserver01,cpu=0 с данными, записанными каждую секунду в течение 1 дня, это приведёт к 86 400 строкам данных. Однако, если у нас есть 8 возможных ядер процессора для этого хоста, теперь у нас будет 691 200 строк данных. Это выглядит хорошо, потому что мы можем легко получить сумму или среднее значение использования процессора по всем ядрам, выполнив запрос типа start=1d-ago&m=avg:sys.cpu.user{host=webserver01}.

Однако, что если у нас есть 20 000 хостов, каждый с 8 ядрами? Теперь у нас будет 3,8 миллиона строк данных в день из-за высокой мощности значений хостов. Запросы среднего использования ядра на хосте webserver01 будут медленнее, так как необходимо выбрать 691 200 строк из 3,8 миллиона.

Преимущества этой схемы заключаются в том, что у вас очень глубокая детализация в ваших данных, например, хранение метрик использования на основе каждого ядра. Вы также можете легко составить запрос, чтобы получить среднее значение по всем ядрам и всем хостам: start=1d-ago&m=avg:sys.cpu.user. Однако запросы к этой конкретной метрике будут занимать больше времени, так как существует больше строк для фильтрации.

Вот несколько распространённых способов решения проблем с мощностью:

Предварительная агрегация — в примере выше с sys.cpu.user, вы обычно интересуетесь средним значением использования на хосте, а не использованием по ядрам. Хотя сборщик данных может отправлять отдельное значение на ядро с помощью схемы меток выше, сборщик также может отправлять дополнительную точку данных, например, sys.cpu.user.avg host=webserver01. Теперь у вас есть совершенно отдельный временной ряд, который будет содержать только 24 строки в день и, при 20 000 хостах, всего 480 000 строк для фильтрации. Запросы среднего значения по хосту будут намного быстрее, и у вас по-прежнему будут данные по ядрам для детализации отдельно.

Перевод метрики — что если вам действительно нужны только метрики для определённого хоста и не нужно агрегировать по хостам? В этом случае вы можете переместить имя хоста в метрику. Наш предыдущий пример становится sys.cpu.user.websvr01 cpu=0. Запросы к этой схеме очень быстры, так как в день будет только 192 строки для метрики. Однако для агрегации по хостам вам придётся выполнять несколько запросов и агрегировать вне OpenTSDB. (В будущих работах будет добавлена эта функция).

Заключение по схеме именования

При разработке схемы именования имейте в виду следующие рекомендации:

• Сохраняйте согласованность в именовании, чтобы уменьшить дублирование. Всегда используйте один и тот же регистр для метрик, имён и значений меток.
• Используйте одинаковое количество и тип меток для каждой метрики. Например, не храните my.metric host=foo и my.metric datacenter=lga.
• Подумайте о наиболее часто используемых запросах и оптимизируйте схему для них.
• Подумайте о том, как вы можете углубиться при выполнении запросов.
• Не используйте слишком много меток, поддерживайте их количество достаточно небольшим, обычно до 4 или 5 меток (по умолчанию OpenTSDB поддерживает максимум 8 меток).

Временные метки

Данные могут записываться в OpenTSDB с разрешением в секунды или миллисекунды. Временные метки должны быть целыми числами и не превышать 13 цифр (см. первое [ПРИМЕЧАНИЕ] ниже). Временные метки в миллисекундах должны иметь формат 1364410924250, где последние три цифры представляют миллисекунды. Приложения, генерирующие временные метки с более чем 13 цифрами (т.е., с разрешением более чем в миллисекунды), должны быть округлены до максимальных 13 цифр перед отправкой, в противном случае будет сгенерирована ошибка.

Временные метки с разрешением в секунды хранятся в 2 байтах, а с разрешением в миллисекунды — в 4. Поэтому, если вам не нужно разрешение в миллисекунды или все ваши точки данных находятся на границах в 1 секунду, рекомендуется отправлять временные метки с 10 цифрами для разрешения в секунды, чтобы сэкономить место на диске. Также рекомендуется избегать смешивания временных меток с разрешением в секунды и миллисекунды для заданного временного ряда. Это замедлит запросы, так как итерация по смешанным временным меткам занимает больше времени, чем если вы записываете только один тип или другой. OpenTSDB будет хранить то, что вы ему дадите.

Метрики и теги

Следующие правила применяются к метрикам и значениям тегов:

• Строки чувствительны к регистру, т. е. «Sys.Cpu.User» будет храниться отдельно от «sys.cpu.user»
• Пробелы не допускаются
• Допускаются только следующие символы: a до z, A до Z, 0 до 9, -, _, ., / или буквы Юникода (согласно спецификации)

Длина метрик и тегов не ограничена, хотя следует стремиться к тому, чтобы значения были достаточно короткими.

Целочисленные значения

Если значение из команды put анализируется без десятичной точки (.), оно будет обрабатываться как целое число со знаком. Целые числа хранятся без знака с кодированием переменной длины, так что элемент данных может занимать от 1 байта до 8 байт. Это означает, что элемент данных может иметь минимальное значение -9 223 372 036 854 775 808 и максимальное значение 9 223 372 036 854 775 807 (включительно). Целые числа не могут содержать запятых или каких-либо символов, кроме цифр и тире (для отрицательных значений). Например, для хранения максимального значения оно должно быть представлено в форме 9223372036854775807.

Значения с плавающей точкой

Если значение из команды put анализируется с десятичной точкой (.), оно будет обрабатываться как значение с плавающей точкой. В настоящее время все значения с плавающей точкой хранятся в 4 байтах, одинарной точности, с поддержкой 8 байт, запланированной на будущие версии. Вещественные числа хранятся в формате с плавающей точкой IEEE 754 «одинарной точности» с поддержкой положительных и отрицательных значений. Бесконечные и нечисловые значения не поддерживаются и вызовут ошибку при вводе в TSD. Подробнее см. Wikipedia и Java Documentation.

Порядок

В отличие от других решений, OpenTSDB позволяет записывать данные для заданного временного ряда в любом порядке. Это обеспечивает значительную гибкость при записи данных в TSD, позволяя заполнять текущие данные из ваших систем, а затем импортировать исторические данные в более позднее время.

Дубликаты точек данных

Запись точек данных в OpenTSDB, как правило, идемпотентна в течение часа после первоначальной записи. Это означает, что вы можете записать значение 42 с временной меткой 1356998400 и затем снова записать 42 для того же времени, и ничего плохого не произойдет. Однако, если у вас включены уплотнения для уменьшения потребления памяти, и вы записываете одну и ту же точку данных после того, как строка данных была уплотнена, при запросе по этой строке может быть возвращена исключение. Если вы попытаетесь записать два разных значения с одной и той же временной меткой, во время запроса может быть выброшено исключение дублирования данных. Это связано с разницей в кодировании целых чисел на 1, 2, 4 или 8 байтах и ​​чисел с плавающей точкой. Если первое значение было целым числом, а второе — с плавающей точкой, ошибка дублирования всегда будет выброшена. Однако, если оба значения были числами с плавающей точкой или оба были целыми числами, которые можно было закодировать на одном длине, то исходное значение может быть перезаписано, если уплотнение не произошло в строке.

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

В OpenTSDB 2.1 вы можете включить «последнее значение — выигрывает» путем установки значения конфигурации tsd.storage.fix_duplicates в true. При включенном этом флаге во время запроса будет возвращено последнее записанное значение вместо выброса исключения. В файл журнала также будет записано предупреждение о том, что был найден дубликат. Если также включено уплотнение, исходное уплотненное значение будет перезаписано последним значением.

Telnet

Самый простой способ начать работу с OpenTSDB — открыть терминал или клиент telnet, подключиться к вашему TSD и выполнить команду put и нажать «ввод». Если вы пишете программу, просто откройте сокет, выведите строку команды с новой строкой и отправьте пакет. Формат команды telnet:

put <metric> <timestamp> <value> <tagk1=tagv1[ tagk2=tagv2 ...tagkN=tagvN]>

Например:

put sys.cpu.user 1356998400 42.5 host=webserver01 cpu=0

Каждый put может отправлять только одну точку данных. Не забудьте символ новой строки, например, \n в конце вашей команды.

Http API

Начиная с версии 2.0, данные могут отправляться по протоколу HTTP в форматах, поддерживаемых плагинами «Serializer». Несколько независимых точек данных могут быть отправлены в одном запросе HTTP POST для экономии пропускной способности. Подробности см. в ../api_http/put.

Пакетный импорт

Если вы импортируете данные из другой системы или вам нужно заполнить исторические данные, вы можете использовать утилиту командной строки import. Подробности см. в cli/import.

Присвоение UID

Первая проблема, с которой сталкиваются пользователи, — это «присвоение UID». Каждому строковому значению метрики, ключу тега и значению тега должен быть присвоен UID, прежде чем данные точки могут быть сохранены. Например, метрика sys.cpu.user может быть присвоена UID 000001 в первый раз, когда она встречается в TSD. Это присвоение занимает довольно много времени, так как необходимо получить доступный UID, записать сопоставление UID с именем и сопоставление имени с UID, а затем использовать UID для записи ключа строки данных. UID будет сохранен в кэше TSD, чтобы в следующий раз, когда встретится та же метрика, UID можно было найти очень быстро.

Поэтому мы рекомендуем «предварительно назначить» UID как можно большему количеству метрик, ключей тегов и значений тегов. Если вы разработали схему именования, как рекомендуется выше, вам будет известно большинство значений для назначения. Вы можете использовать инструменты командной строки cli/mkmetric, cli/uid или HTTP-API ../api_http/uid/index, чтобы выполнить предварительные назначения. Всякий раз, когда вы собираетесь отправить большой объем новых метрик или тегов в работающий кластер OpenTSDB, старайтесь выполнять предварительные назначения, иначе TSDs будут немного загружаться при получении новых данных.

Случайное присвоение UID метрикам

В версии 2.2 вы можете случайным образом назначать UIDs метрикам для лучшего распределения записи в серверах регионов. Поскольку UIDs метрик расположены в начале ключа строки, если создается новый набор загруженных метрик, все записи для этих метрик будут на одном сервере до тех пор, пока регион не разделится. При включенном случайном генерировании UID новые метрики будут распределены по всему пространству ключей и, скорее всего, окажутся в разных регионах на разных серверах.

Случайное генерирование метрик можно включать или отключать в любое время, изменив флаг tsd.core.uid.random_metrics, и данные будут обратно совместимы с OpenTSDB 1.0. Однако рекомендуется предварительно разделить таблицу данных TSDB в соответствии со всем пространством UID метрик. Например, если вы используете стандартный размер UID в OpenTSDB, UIDs имеют ширину 3 байта, поэтому у вас может быть 16 777 215 значений. Если в вашей таблице TSDB уже есть данные, и вы решите включить случайные UIDs, вам может потребоваться создать новые регионы.

При генерировании случайных идентификаторов TSDB будет пытаться присвоить UID без коллизии до 10 раз. Таким образом, по мере увеличения количества назначенных метрик будет увеличиваться и количество коллизий, а также вероятность того, что точка данных может быть пропущена из-за повторных попыток. Если вы включите случайные ID и продолжите добавлять больше метрик, вам может потребоваться увеличить количество байтов в UIDs метрик. Обратите внимание, что изменение UID не обратно совместимо, поэтому вам необходимо создать новую таблицу и мигрировать старые данные.

Добавление соли

В версии 2.2 поддерживается добавление соли, что значительно увеличивает распределение записи между серверами регионов. При включении соли заданное количество байтов добавляется в начало каждого ключа строки. Каждая метрика и комбинация тегов затем хешируются в один «ведро», ID которого записывается в байты соли. Распределение улучшается, особенно для метрик с высокой кардинальностью (метрик с большим количеством комбинаций тегов), так как временные ряды разбиваются на заданное количество ведер, тем самым перенаправляясь в разные регионы и на разные серверы. Например, без добавления соли метрика с 1 миллионом рядов будет записана в один регион на одном сервере. При включенной соли и размере ведра 20 ряды будут разделены на 20 регионов (и 20 серверов, если в кластере такое количество узлов), где каждый регион содержит 50 000 рядов.

Чтобы включить добавление соли, вам необходимо изменить параметр конфигурационного файла tsd.storage.salt.width и, по желанию, tsd.storage.salt.buckets. Мы рекомендуем установить ширину соли в 1 и определить количество ведер на основе коэффициента количества серверов регионов в вашем кластере. Обратите внимание, что во время запроса TSD запустит tsd.storage.salt.buckets сканера для извлечения данных. Правильное количество ведер с солью необходимо определить путем экспериментов, так как в какой-то момент производительность запросов может снизиться из-за слишком большого количества открытых сканеров и агрегирования результатов. В будущем ширина соли и количество ведер могут быть настраиваемыми, но мы не хотели, чтобы пользователи случайно изменяли настройки и теряли данные.

Добавление данных

Также в версии 2.2 теперь поддерживается запись в столбцы HBase с помощью добавления данных. Это может улучшить как производительность чтения, так и производительность записи, так как TSDs больше не будут поддерживать очередь строк для уплотнения в конце каждого часа, тем самым предотвращая массивную операцию чтения и перезаписи в HBase. Однако из-за того, как работают добавления в HBase, на серверах регионов произойдет увеличение использования ЦП, размер файла хранилища и трафика HDFS. Следите за вашими серверами HBase.

Во время чтения возвращается только один столбец на строку, подобно строкам после уплотнения TSD. Однако обратите внимание, что если включен tsd.storage.repair_appends, то при наличии дубликатов или данных в неправильном порядке столбец будет перезаписан в HBase. Кроме того, столбцы с множеством дубликатов или проблемами с упорядоченностью могут замедлить запросы, поскольку они должны быть разрешены перед ответом вызывающему лицу.

Добавление данных можно включать и отключать в любое время. Однако версии OpenTSDB, предшествующие версии 2.2, пропустят добавленные значения.

Предварительное разделение областей HBase

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

Простейший способ предварительного разделения областей таблицы tsdb — оценить количество уникальных имен метрик, которые вы будете регистрировать. Если вы разработали схему именования, у вас должно быть довольно хорошее представление. Предположим, что мы будем отслеживать 4000 метрик в нашей системе. Это не означает 4000 временных рядов, так как мы пока не учитываем теги, а только имена метрик, такие как «sys.cpu.user». Точки данных записываются в ключах строк, где UID метрики составляют первые байты, по умолчанию 3 байта. Первой метрике будет назначен UID 000001 в виде шестнадцатеричного кодированного значения. У 4000-й метрики будет UID 000FA0 в шестнадцатеричном виде. Вы можете использовать эти значения в качестве начального и конечного ключей в скрипте из книги HBase для разделения вашей таблицы на любое количество областей. 256 областей может быть хорошей отправной точкой в зависимости от того, сколько временных рядов используют каждую метрику.

TODO - включить скрипты для предварительного разделения.

Простой метод разделения, описанный выше, предполагает, что у вас примерно одинаковое количество временных рядов на метрику (то есть довольно постоянная кардинальность). Например, метрика с UID 000001 может иметь 200 временных рядов, а 000FA0 — около 150. Если у вас есть широкий диапазон временных рядов на метрику, например, 000001 имеет 10 000 временных рядов, а 000FA0 — только 2, вам может потребоваться разработать более сложный алгоритм разделения.

Но не беспокойтесь слишком сильно о разделении. Как указано выше, HBase автоматически разделит области, поэтому со временем данные будут распределены довольно равномерно.

Распределенный HBase

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

Однако, если вам нужна серьезная пропускная способность и масштабируемость, вам необходимо настроить кластер Hadoop и HBase с несколькими серверами. В распределенной настройке HDFS управляет файлами областей, автоматически распределяя копии по разным серверам для обеспечения отказоустойчивости. HBase назначает области разным серверам, а клиент OpenTSDB отправляет точки данных на конкретный сервер, где они будут сохранены. Теперь вы распределяете операции между несколькими серверами, увеличивая производительность и емкость хранения. Если вам нужна еще большая пропускная способность или емкость хранения, просто добавьте узлы или диски.

Существует множество способов настройки кластера Hadoop/HBase и множество различных настроек для настройки, поэтому поищите в Google и обратитесь в группы пользователей за советом. Некоторые общие рекомендации включают:

• Выделите пару серверов с большим объемом памяти и малым объемом диска для узла Name Node. Настройте их для высокой доступности с помощью чего-то вроде Heartbeat и Pacemaker.
• Настройте Zookeeper, по крайней мере, на 3 серверах для отказоустойчивости. Они должны иметь много оперативной памяти и достаточно быстрый диск для записи логов. В небольших кластерах их можно запустить на серверах Name Node.
• JBOD для узлов данных HDFS
• Серверы регионов HBase можно расположить совместно с узлами данных HDFS
• По крайней мере, 1 Гбит/с подключения между серверами, предпочтительно 10 Гбит/с.
• Убедитесь, что кластер находится в одном дата-центре.

Несколько TSD

Один TSD может обрабатывать тысячи записей в секунду. Но если у вас много источников, лучше масштабироваться, запустив несколько TSD и используя балансировщик нагрузки (например, Varnish или DNS round robin) для распределения записей. Многие пользователи размещают TSD на серверах регионов HBase, когда кластер посвящен OpenTSDB.

Постоянные подключения

Включите keep-alive в TSD и убедитесь, что любые приложения, которые вы используете для отправки временных рядов, поддерживают открытые подключения вместо открытия и закрытия для каждой записи. Подробности см. в configuration.

Отключить метаданные и публикацию в реальном времени

OpenTSDB 2.0 представил метаданные для отслеживания типов данных в системе. При включенном отслеживании счётчик увеличивается для каждой точки данных, записанной, и новые идентификаторы (UID) или временные ряды будут генерировать метаданные. Данные могут быть отправлены в поисковый движок или обработаны кодом генерации дерева. Эти процессы требуют больше памяти в TSD и могут повлиять на пропускную способность. Отслеживание отключено по умолчанию, поэтому протестируйте его перед включением функции.

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