TSL: удобный для разработчиков язык запросов временных рядов для всех наших показателей
В команде Metrics мы работаем над временными рядами уже несколько лет. По нашему опыту, возможности аналитики данных платформы базы данных временных рядов (TSDB) являются ключевым фактором в создании ценности из ваших показателей. Эти возможности аналитики в основном определяются поддерживаемыми ими языками запросов .
TSL означает язык временных рядов . Проще говоря, TSL — это абстрактный способ генерации запросов для различных бэкэндов TSDB в форме HTTP-прокси. В настоящее время он поддерживает языки запросов WarpScript 10 и Prometheus PromQL, но мы стремимся расширить поддержку и на другие основные TSDB.
Чтобы предоставить некоторый контекст вокруг того, почему мы создали TSL, он начался с обзора некоторых языков запросов TSDB, поддерживаемых платформой данных метрик OVH . Реализуя их, мы узнали хорошее, плохое и уродливое в каждом из них. В конце концов, мы решили создать TSL, чтобы упростить выполнение запросов на нашей платформе, прежде чем открывать его для использования в любом решении TSDB.
Так почему мы решили потратить время на разработку такого прокси? Что ж, позвольте мне рассказать вам историю протокола OVH Metrics !
Первая цель нашей платформы — обеспечить поддержку инфраструктуры OVH и мониторинга приложений. Когда этот проект стартовал, многие люди использовали OpenTSDB и были знакомы с его синтаксисом запросов. OpenTSDB — это масштабируемая база данных для временных рядов. Запрос OpenTSDB синтаксис легко читается, как вы отправить JSON документ , описывающий запрос. Ниже документ будет загружать все
Это позволяет быстро извлекать определенные данные в определенном временном диапазоне. В OVH это использовалось для целей графиков вместе с Grafana и помогало нам выявлять потенциальные проблемы в режиме реального времени, а также исследовать прошлые события. OpenTSDB объединяет простые запросы, в которых вы можете определить свою собственную выборку и работать с данными счетчиков, а также с отфильтрованными и агрегированными необработанными данными.
OpenTSDB был первым протоколом, поддерживаемым командой Metrics, и до сих пор широко используется. Внутренняя статистика показывает, что 30-40% нашего трафика основано на запросах OpenTSDB. Многие внутренние сценарии использования все еще могут быть полностью решены с помощью этого протокола, а запросы легко писать и понимать.
Например, запрос с OpenTSDB для получения максимального значения
Однако OpenTSDB быстро показывает свои ограничения, и некоторые конкретные случаи использования не могут быть решены с его помощью. Например, вы не можете применять какие-либо операции непосредственно на сервере. Вы должны загрузить данные во внешний инструмент и использовать его для применения любой аналитики.
Одна из основных областей, в которых отсутствует OpenTSDB (версия 2.3), — это несколько операторов набора временных рядов, которые позволяют выполнять такие действия, как разделение ряда. Эти операторы могут быть полезным способом вычисления времени отдельного запроса для каждого запроса, когда у вас есть (например) набор общего времени, затраченного на запросы, и набор рядов общего количества запросов. Это одна из причин, почему платформа данных метрик OVH поддерживает другие протоколы.
Вторым протоколом, над которым мы работали, был PromQL , язык запросов к базе данных временных рядов Prometheus . Когда мы сделали этот выбор в 2015 году, Prometheus набирал обороты, и у него по-прежнему впечатляющие темпы внедрения. Но если Prometheus добился успеха, дело не в его языке запросов, PromQL. Этот язык так и не получил широкого распространения внутри компании, хотя в последнее время он начал получать некоторое распространение, в основном благодаря приходу людей, которые работали с Prometheus в своих предыдущих компаниях. На внутреннем уровне запросы PromQL составляют около 1-2%нашего ежедневного трафика. Основные причины заключаются в том, что многие простые варианты использования могут быть решены быстро и с большим контролем необработанных данных с помощью запросов OpenTSDB, в то время как многие более сложные варианты использования не могут быть решены с помощью PromQL. Запрос, аналогичный тому, что определен в OpenTSDB, будет выглядеть так:
Используя PromQL, вы теряете контроль над выборкой данных , поскольку единственный оператор остается последним . Это означает, что если (например) вы хотите уменьшить частоту дискретизации своей серии до 5-минутной продолжительности, вы можете сохранить только последнее значение каждого 5-минутного диапазона. Напротив, у всех конкурентов есть ряд операторов. Например, с OpenTSDB вы можете выбирать между несколькими операторами, включая среднее значение, счетчик, стандартное отклонение, первое, последнее, процентили, минимальное, максимальное или суммирование всех значений в пределах определенного диапазона.
В конце концов, многие люди предпочитают использовать гораздо более сложный метод: WarpScript, который работает на движке Warp10 Analytics Engine, который мы используем за кулисами.
WarpScript — это текущий язык временных рядов Warp 10 ® , нашего базового интерфейса. WarpScript поможет в любом сложном случае использования временных рядов и решит множество реальных проблем, так как вы полностью контролируете все свои операции. У вас есть специальные функциональные рамки для выборки необработанных данных и заполнения недостающих значений. У вас также есть платформы для применения операций к однозначным или оконным операциям. Вы можете применять операции к нескольким наборам временных рядов и иметь специальные функции для управления временем временных рядов, статистикой и т. Д.
Он работает с обратной польской нотацией (например, старый добрый HP48, для тех, у кого он есть!), И простые варианты использования могут быть легко описаны. Но когда дело доходит до аналитики, хотя она, безусловно, решает проблемы, ей все еще сложно научиться. В частности, варианты использования временных рядов сложны и требуют модели мышления, поэтому WarpScript помог решить множество сложных задач.
Вот почему он по-прежнему является основным запросом, используемым в OVH на платформе OVH Metrics, при этом почти 60% внутренних запросов используют его. Тот же запрос, который мы только что вычислили в OpenTSDB и PromQL, в WarpScript будет выглядеть следующим образом:
Многим пользователям сначала сложно изучить WarpScript, но после решения их первоначальных проблем с некоторой (иногда большой) поддержкой это становится первым шагом в их приключении с временными рядами. Позже они придумывают новые идеи о том, как они могут получить знания из своих показателей. Затем они возвращаются с многочисленными требованиями и вопросами о повседневных проблемах, некоторые из которых можно быстро решить с их собственными знаниями и опытом.
Что мы узнали из WarpScript, так это то, что это фантастический инструмент для построения аналитики наших данных Metrics. Мы продвинули множество сложных вариантов использования с помощью передовых алгоритмов обработки сигналов, таких как LTTB , обнаружение выбросов или шаблонов , а также сглаживание ядра, где это оказалось реальным инструментом. Однако поддержка основных требований оказалась довольно дорогой, и отзывы показали, что синтаксис и общая сложность вызывают большие опасения.
WarpScript может включать в себя десятки (или даже сотни) строк, и успешное выполнение часто является достижением с особым чувством, которое возникает от использования в полной мере своих умственных способностей. Фактически, внутренняя шутка среди нашей команды — это способность написать WarpScript за один день или заработать значок WarpScript Pro Gamer! Вот почему мы раздали футболки Metrics пользователям, добившимся значительных успехов с платформой Metrics Data Platform.
Нам понравилась семантика WarpScript, но мы хотели, чтобы она оказала значительное влияние на более широкий спектр вариантов использования. Вот почему мы начали писать TSL с несколькими простыми целями:
Мы знаем, что пользователям, вероятно, придется время от времени возвращаться к WarpScript. Однако мы надеемся, что использование TSL упростит их обучение. TSL — это просто новый шаг в приключении временных рядов!
TSL является результатом трехлетней поддержки аналитики временных рядов и предлагает функциональный язык временных рядов. Целью TSL является построение потока данных временных рядов в виде кода.
В TSL существуют собственные методы, такие как
Наконец, для более удобочитаемого языка вы можете определить переменные для хранения запросов временных рядов и повторно использовать их в своем скрипте в любое время, когда захотите. На данный момент мы поддерживаем только несколько родных типов, таких как
Наконец, тот же запрос, который используется в этой статье, будет выглядеть в TSL следующим образом:
Вы также можете писать более сложные запросы. Например, мы собрали наш практический опыт WarpScript, предназначенный для обнаружения экзопланет по необработанным данным НАСА, в один запрос TSL:
Итак, что мы здесь сделали? Сначала мы создали образец переменной, в которую загрузили необработанные данные sap.flux одной звезды, 6541920. Затем мы очистили серию, используя функцию временного разделения (чтобы разделить серию звезд, когда в данных есть дыра с длина больше 6h), сохраняя только четыре записи. Наконец, мы сделали выборку результата, сохранив минимальное значение каждого двухчасового периода.
Затем мы использовали этот результат для вычисления тренда ряда, используя скользящее среднее за 10 часов.
В заключение, запрос возвращает только точки меньше 20 из результата вычитания тренда и выборки.
Даже если наше первое сообщество пользователей было в основном внутри OVH, мы вполне уверены, что TSL можно использовать для решения множества вариантов использования временных рядов.
В настоящее время мы проводим бета-тестирование TSL на нашей публичной платформе OVH Metrics. Кроме того, исходный код TSL на Github открыт , поэтому вы также можете протестировать его на своих собственных платформах.
Мы хотели бы получить ваши отзывы или комментарии о TSL или временных рядах в целом. Мы доступны в сетке метрик OVH, и вы можете узнать больше о TSL в нашей документации по бета-функциям .
TSL означает язык временных рядов . Проще говоря, TSL — это абстрактный способ генерации запросов для различных бэкэндов TSDB в форме HTTP-прокси. В настоящее время он поддерживает языки запросов WarpScript 10 и Prometheus PromQL, но мы стремимся расширить поддержку и на другие основные TSDB.
Чтобы предоставить некоторый контекст вокруг того, почему мы создали TSL, он начался с обзора некоторых языков запросов TSDB, поддерживаемых платформой данных метрик OVH . Реализуя их, мы узнали хорошее, плохое и уродливое в каждом из них. В конце концов, мы решили создать TSL, чтобы упростить выполнение запросов на нашей платформе, прежде чем открывать его для использования в любом решении TSDB.
Так почему мы решили потратить время на разработку такого прокси? Что ж, позвольте мне рассказать вам историю протокола OVH Metrics !
Из OpenTSDB…
Первая цель нашей платформы — обеспечить поддержку инфраструктуры OVH и мониторинга приложений. Когда этот проект стартовал, многие люди использовали OpenTSDB и были знакомы с его синтаксисом запросов. OpenTSDB — это масштабируемая база данных для временных рядов. Запрос OpenTSDB синтаксис легко читается, как вы отправить JSON документ , описывающий запрос. Ниже документ будет загружать все
sys.cpu.0teststartend{
"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_systemcpu{
"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 существуют собственные методы, такие как
selectwherefromlastНаконец, для более удобочитаемого языка вы можете определить переменные для хранения запросов временных рядов и повторно использовать их в своем скрипте в любое время, когда захотите. На данный момент мы поддерживаем только несколько родных типов, таких как
NumbersStringsTime durationsListsTime 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 в нашей документации по бета-функциям .
0 комментариев