В прошлом году мы выпустили TSL как инструмент с открытым исходным кодом для выполнения запросов к Деформация 10 платформы, и выдвижением, OVHcloud Метрики Платформа данных .



Но как она развивалась с тех пор? Готов ли TSL запрашивать другие базы данных временных рядов ? Что насчет состояний TSL в экосистеме Warp10 ?

TSL для запроса многих баз данных временных рядов

Мы хотели, чтобы TSL можно было использовать перед несколькими базами данных временных рядов . Вот почему мы также выпустили генератор запросов PromQL .

Год спустя мы теперь знаем, что это был не лучший путь. Исходя из того, что мы узнали, тот TSL-адаптер проект был открытым исходным кодом, как доказательство концепции , как TSL может быть использован для запроса не-Деформация 10 базы данных. Проще говоря, TSL-адаптер позволяет TSL запрашивать InfluxDB .

Что такое TSL-адаптер?

TSL-адаптер — это API Quarkus JAVA REST, который можно использовать для запроса серверной части. TSL-адаптер анализирует запрос TSL, идентифицирует операцию выборки и загружает исходные необработанные данные из серверной части. Затем он вычисляет операции TSL с данными, прежде чем вернуть результат пользователю. Основная цель TSL-Adapter - сделать TSL доступным поверх других TSDB .



Говоря конкретно, мы запускаем JAVA REST API, который интегрирует библиотеку WarpScript в среду выполнения. Затем TSL используется для компиляции запроса в действительный запрос WarpScript. Это полностью прозрачно и касается только запросов TSL на стороне пользователя.


Чтобы загрузить необработанные данные из InfluxDB, мы создали расширение WarpScript. Это расширение объединяет абстрактный класс, 

LOADSOURCERAW

который необходимо реализовать для создания источника данных TSL-Adapter. Для этого требуется всего два метода: 

find

и 

fetch

. 

Find

собирает все селекторы серий, соответствующие запросу (имена классов, теги или метки), при этом 

fetch

фактически извлекает необработанные данные за определенный промежуток времени.

Приток запросов с TSL-адаптером

Для начала просто запустите InfluxDB локально на порту 8086. Затем давайте запустим агент Telegraf притока и запишем данные Telegraf на локальном экземпляре притока.

Затем убедитесь, что вы локально установили TSL-адаптер и обновили его конфигурацию, указав путь к tsl.soбиблиотеке.

Чтобы указать собственный адрес притока или базы данных, обновите файл конфигурации TSL-адаптера соответствующим образом.

Вы можете запустить TSL-адаптер с помощью следующего примера команды:

java -XX:TieredStopAtLevel=1 -Xverify:none -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar build/tsl-adaptor-0.0.1-SNAPSHOT-runner.jar

И это все! Теперь вы можете запрашивать свою базу данных притока с помощью TSL и TSL-адаптера.

Начнем с восстановления временного ряда, относящегося к измерениям диска.

curl --request POST \
  --url http://u:p@0.0.0.0:8080/api/v0/tsl \
  --data 'select("disk")'

Теперь давайте воспользуемся возможностями аналитики TSL!

Во-первых, мы хотели бы получить только данные, содержащие установленный режим rw.

curl --request POST \
  --url http://u:p@0.0.0.0:8080/api/v0/tsl \
  --data 'select("disk").where("mode=rw")'

Мы хотели бы получать максимальное значение через каждые пятиминутные интервалы за последние 20 минут. Таким образом, запрос TSL будет:

curl --request POST \
  --url http://u:p@0.0.0.0:8080/api/v0/tsl \
  --data 'select("disk").where("mode=rw").last(20m).sampleBy(5m,max)'

Теперь ваша очередь повеселиться с TSL и InfluxDB. Вы можете найти подробную информацию обо всех реализованных функциях в документации TSL. Наслаждайтесь исследованием!

Что нового в TSL с Warp10?

Изначально мы создавали TSL как прокси GO перед Warp10. TSL теперь интегрировал экосистему Warp 10 как расширение Warp10 или как библиотеку WASM ! Мы также добавили несколько новых собственных функций TSL, чтобы сделать язык еще богаче!

TSL как функция WarpScript

Чтобы TSL работал как функция Warp10, вам необходимо, чтобы tsl.soбиблиотека была доступна локально. Эту библиотеку можно найти в репозитории TSL на github. Мы также сделали расширение TSL WarpScript доступным в WarpFleet, репозитории расширений сообщества Warp 10.

Чтобы настроить расширение TSL на Warp 10, просто загрузите JAR, указанный в WarpFleet. Затем вы можете настроить расширение в файле конфигурации Warp 10:

warpscript.extensions = io.ovh.metrics.warp10.script.ext.tsl.TSLWarpScriptExtension
warpscript.tsl.libso.path = <PATH_TO_THE_tsl.so_FILE>

После перезагрузки Warp 10 все готово. Вы можете проверить, работает ли он, выполнив следующий запрос:

// You will need to put here a valid Warp10 token when computing a TSL select statement
// '<A_VALID_WARP_10_TOKEN>' 

// A valid TOKEN isn't needed on the create series statement in this example
// You can simply put an empty string
''

// Native TSL create series statement
 <'
    create(series('test').setValues("now", [-5m, 2], [0, 1])) 
'>
TSL

С помощью функции WarpScript TSL вы можете использовать собственные переменные WarpScript в своем скрипте, как показано в примере ниже:

// Set a Warp10 variable

NOW 'test' STORE

'' 

// A Warp10 variable can be reused in TSL script as a native TSL variable
 <'
    create(series('test').setValues("now", [-5m, 2], [0, 1])).add(test)
'>
TSL

TSL WASM

Чтобы расширить возможности использования TSL, мы также экспортировали его как библиотеку Wasm, так что вы можете использовать ее прямо в браузере! Версия библиотеки Wasm анализирует запросы TSL локально и генерирует WarpScript. Затем результат можно использовать для запроса к бэкэнду Warp 10. Более подробную информацию вы найдете на github TSL.

Новые возможности TSL

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

Мы добавили setLabelFromNameметод, чтобы установить новую метку для серии на основе ее имени. Эта метка может быть точным названием серии или результатом регулярного выражения.

Мы также доработали sortметод, позволяющий пользователям сортировать набор серий на основе метаданных серии (т. Е. Селектора, имени или меток).

Наконец, мы добавили filterWithoutLabels, чтобы отфильтровать набор серий и удалить все серии, не содержащие конкретных меток.

Спасибо за прочтение! Я надеюсь, что вы попробуете TSL, так как я хотел бы услышать ваши отзывы.

Встреча в Париже Time Series

Мы рады провести в парижском офисе OVHcloud третью встречу Paris Time Series, организованную Николасом Штайнметцем. Во время этой встречи мы поговорим о TSL, а также познакомимся с платформой Redis Times Series.

Если вы свободны, мы будем рады встретить вас там!

В команде Metrics мы работаем над временными рядами уже несколько лет. По нашему опыту, возможности аналитики данных платформы базы данных временных рядов (TSDB) являются ключевым фактором в  создании ценности из ваших показателей. Эти возможности аналитики в основном определяются поддерживаемыми ими языками запросов . 

TSL означает язык временных рядов . Проще говоря, TSL  — это абстрактный способ генерации запросов для различных бэкэндов TSDB в форме HTTP-прокси. В настоящее время он поддерживает языки запросов WarpScript 10 и Prometheus PromQL, но мы стремимся расширить поддержку и на другие основные TSDB.



Чтобы предоставить некоторый контекст вокруг того, почему мы создали TSL, он начался с обзора некоторых языков запросов TSDB, поддерживаемых  платформой данных метрик OVH . Реализуя их, мы узнали хорошее, плохое и уродливое в каждом из них. В конце концов, мы решили создать TSL, чтобы упростить выполнение запросов на нашей платформе, прежде чем открывать его для использования в любом решении TSDB. 

Так почему мы решили потратить время на разработку такого прокси? Что ж, позвольте мне рассказать вам историю протокола OVH Metrics !

Из OpenTSDB…

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

sys.cpu.0

 метрики в 

test

центре обработки данных, суммируя их между 

start

 и 

end

датами:

{
    "start": 1356998400,
    "end": 1356998460,
    "queries": [
        {
            "aggregator": "sum",
            "metric": "sys.cpu.0",
            "tags": {
                "host": "*",
                "dc": "test"
            }
        }
    ]
}

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

OpenTSDB был первым протоколом, поддерживаемым командой Metrics, и до сих пор широко используется. Внутренняя статистика показывает, что 30-40% нашего трафика основано на запросах OpenTSDB. Многие внутренние сценарии использования все еще могут быть полностью решены с помощью этого протокола, а запросы легко писать и понимать.

Например, запрос с OpenTSDB для получения максимального значения 

usage_system

для диапазона от 

cpu

0 до 9, взятого за 2-минутный интервал по среднему их значению, выглядит следующим образом:

{
    "start": 1535797890,
    "end": 1535818770,
    "queries":  [{
        "metric":"cpu.usage_system",
        "aggregator":"max",
        "downsample":"2m-avg",
        "filters": [{
            "type":"regexp",
            "tagk":"cpu",
            "filter":"cpu[0–9]+",
            "groupBy":false
            }]
        }]
}

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

Одна из основных областей, в которых отсутствует OpenTSDB (версия 2.3), — это несколько операторов набора временных рядов, которые позволяют выполнять такие действия, как разделение ряда. Эти операторы могут быть полезным способом вычисления времени отдельного запроса для каждого запроса, когда у вас есть (например) набор общего времени, затраченного на запросы, и набор рядов общего количества запросов. Это одна из причин, почему платформа данных метрик OVH поддерживает другие протоколы.

… В PromQL

Вторым протоколом, над которым мы работали, был PromQL , язык запросов к базе данных временных рядов Prometheus . Когда мы сделали этот выбор в 2015 году, Prometheus набирал обороты, и у него по-прежнему впечатляющие темпы внедрения. Но если Prometheus добился успеха, дело не в его языке запросов, PromQL. Этот язык так и не получил широкого распространения внутри компании, хотя в последнее время он начал получать некоторое распространение, в основном благодаря приходу людей, которые работали с Prometheus в своих предыдущих компаниях. На внутреннем уровне запросы PromQL составляют около 1-2%нашего ежедневного трафика. Основные причины заключаются в том, что многие простые варианты использования могут быть решены быстро и с большим контролем необработанных данных с помощью запросов OpenTSDB, в то время как многие более сложные варианты использования не могут быть решены с помощью PromQL. Запрос, аналогичный тому, что определен в OpenTSDB, будет выглядеть так:

api/v1/query_range?
query=max(cpu. usage_system{cpu=~"cpu[0–9]%2B"})
start=1535797890&
end=1535818770&
step=2m

Используя PromQL, вы теряете контроль над выборкой данных , поскольку единственный оператор остается последним . Это означает, что если (например) вы хотите уменьшить частоту дискретизации своей серии до 5-минутной продолжительности, вы можете сохранить только последнее значение каждого 5-минутного диапазона. Напротив, у всех конкурентов есть ряд операторов. Например, с OpenTSDB вы можете выбирать между несколькими операторами, включая среднее значение, счетчик, стандартное отклонение, первое, последнее, процентили, минимальное, максимальное или суммирование всех значений в пределах определенного диапазона.

В конце концов, многие люди предпочитают использовать гораздо более сложный метод: WarpScript, который работает на движке Warp10 Analytics Engine, который мы используем за кулисами.

Наше внутреннее принятие WarpScript

WarpScript  — это текущий язык временных рядов Warp 10 ® , нашего базового интерфейса. WarpScript поможет в любом сложном случае использования временных рядов и решит множество реальных проблем, так как вы полностью контролируете все свои операции. У вас есть специальные функциональные рамки для выборки необработанных данных и заполнения недостающих значений. У вас также есть платформы для применения операций к однозначным или оконным операциям. Вы можете применять операции к нескольким наборам временных рядов и иметь специальные функции для управления временем временных рядов, статистикой и т. Д.

Он работает с обратной польской нотацией (например, старый добрый HP48, для тех, у кого он есть!), И простые варианты использования могут быть легко описаны. Но когда дело доходит до аналитики, хотя она, безусловно, решает проблемы, ей все еще сложно научиться. В частности, варианты использования временных рядов сложны и требуют модели мышления, поэтому WarpScript помог решить множество сложных задач.

Вот почему он по-прежнему является основным запросом, используемым в OVH на платформе OVH Metrics, при этом почти 60% внутренних запросов используют его. Тот же запрос, который мы только что вычислили в OpenTSDB и PromQL, в WarpScript будет выглядеть следующим образом:

[ "token" "cpu.average" { "cpu" "~cpu[0–9]+" } NOW 2 h ] FETCH
[ SWAP bucketizer.mean 0 2 m 0 ] BUCKETIZE
[ SWAP [ "host" ] reducer.max ] REDUCE

Многим пользователям сначала сложно изучить WarpScript, но после решения их первоначальных проблем с некоторой (иногда большой) поддержкой это становится первым шагом в их приключении с временными рядами. Позже они придумывают новые идеи о том, как они могут получить знания из своих показателей. Затем они возвращаются с многочисленными требованиями и вопросами о повседневных проблемах, некоторые из которых можно быстро решить с их собственными знаниями и опытом.

Что мы узнали из WarpScript, так это то, что это фантастический инструмент для построения аналитики наших данных Metrics. Мы продвинули множество сложных вариантов использования с помощью передовых алгоритмов обработки сигналов, таких как LTTB , обнаружение выбросов или шаблонов , а также сглаживание ядра, где это оказалось реальным инструментом. Однако поддержка основных требований оказалась довольно дорогой, и отзывы показали, что синтаксис и общая сложность вызывают большие опасения.

WarpScript может включать в себя десятки (или даже сотни) строк, и успешное выполнение часто является достижением с особым чувством, которое возникает от использования в полной мере своих умственных способностей. Фактически, внутренняя шутка среди нашей команды — это способность написать WarpScript за один день или заработать значок WarpScript Pro Gamer! Вот почему мы раздали футболки Metrics пользователям, добившимся значительных успехов с платформой Metrics Data Platform.

Нам понравилась семантика WarpScript, но мы хотели, чтобы она оказала значительное влияние на более широкий спектр вариантов использования. Вот почему мы начали писать TSL с несколькими простыми целями:

• Предложите четкую семантику аналитики временных рядов
• Упростите написание и сделайте его удобным для разработчиков
• Поддержка запросов потока данных и простота отладки сложных запросов
• Не пытайтесь быть лучшим ящиком для инструментов. Будь проще.

Мы знаем, что пользователям, вероятно, придется время от времени возвращаться к WarpScript. Однако мы надеемся, что использование TSL упростит их обучение. TSL — это просто новый шаг в приключении временных рядов!

Путь к TSL

TSL является результатом трехлетней поддержки аналитики временных рядов и предлагает функциональный язык временных рядов. Целью TSL является построение потока данных временных рядов в виде кода.

В TSL существуют собственные методы, такие как 

select

и 

where

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

from

и 

last

. Подавляющее большинство других методов TSL принимают наборы временных рядов в качестве входных данных и предоставляют наборы временных рядов в качестве результата. Например, у вас есть методы, которые выбирают только значения выше определенного порога, скорости вычислений и т. Д. Мы также включили определенные операции для применения к нескольким подмножествам наборов временных рядов в виде сложения или умножения.

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

Numbers

, 

Strings

, 

Time durations

, 

Lists

и 

Time Series

(конечно же !).

Наконец, тот же запрос, который используется в этой статье, будет выглядеть в TSL следующим образом:

select("cpu.usage_system")
.where("cpu~cpu[0–9]+")
.last(12h)
.sampleBy(2m,mean)
.groupBy(max)

Вы также можете писать более сложные запросы. Например, мы собрали наш практический опыт WarpScript, предназначенный для обнаружения экзопланет по необработанным данным НАСА, в один запрос TSL:

sample = select('sap.flux')
 .where('KEPLERID=6541920')
 .from("2009–05–02T00:56:10.000000Z", to="2013–05–11T12:02:06.000000Z")
 .timesplit(6h,100,"record")
 .filterByLabels('record~[2–5]')
 .sampleBy(2h, min, false, "none")

trend = sample.window(mean, 5, 5)

sub(sample,trend)
 .on('KEPLERID','record')
 .lessThan(-20.0)

Итак, что мы здесь сделали? Сначала мы создали образец переменной, в которую загрузили необработанные данные sap.flux одной звезды, 6541920. Затем мы очистили серию, используя функцию временного разделения (чтобы разделить серию звезд, когда в данных есть дыра с длина больше 6h), сохраняя только четыре записи. Наконец, мы сделали выборку результата, сохранив минимальное значение каждого двухчасового периода.

Затем мы использовали этот результат для вычисления тренда ряда, используя скользящее среднее за 10 часов.

В заключение, запрос возвращает только точки меньше 20 из результата вычитания тренда и выборки.

TSL с открытым исходным кодом

Даже если наше первое сообщество пользователей было в основном внутри OVH, мы вполне уверены, что TSL можно использовать для решения множества вариантов использования временных рядов.

В настоящее время мы проводим бета-тестирование TSL на нашей публичной платформе OVH Metrics. Кроме того, исходный код TSL на Github открыт , поэтому вы также можете протестировать его на своих собственных платформах.

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