В OVHcloud Metrics мы любим открытый исходный код! Наша цель — предоставить всем нашим пользователям полноценный опыт . Мы полагаемся на базу данных временных рядов Warp10, которая позволяет нам создавать инструменты с открытым исходным кодом для наших пользователей. Давайте взглянем на некоторые из них в этом блоге.

Инструмент для хранения

Наша инфраструктура основана на базе данных временных рядов с открытым исходным кодом: Warp10 . Эта база данных включает две версии: автономную и распределенную . Распределенный полагается на распределенные инструменты, такие как Apache Kafka, Apache Hadoop и Apache HBase .

Неудивительно, что наша команда вносит свой вклад в платформу Warp10 . Из-за наших уникальных требований мы даже вносим свой вклад в базовую базу данных с открытым исходным кодом HBase !

Прием данных метрик

Собственно говоря, мы были первыми, кто застрял в процессе приема ! Мы часто создаем адаптированные инструменты для сбора и отправки данных мониторинга на Warp10 — так появился noderig . Noderig является адаптированным инструментом , который способен собрать в простое ядро метрик с любого сервера или любой виртуальной машины . Также можно безопасно отправлять метрики на бэкэнд. Beamium , инструмент Rust, может передавать метрики Noderig одному или нескольким бэкэндам Warp 10 .



Что, если я хочу собирать собственные специальные показатели ? Во-первых, вам нужно будет разоблачить их по «модели Прометея». Beamium затем может подручных приложений на основе их файл конфигурации и вперед все данные в сконфигурированной Деформация 10 бэкэндом (ов)!

Если вы хотите отслеживать определенные приложения с помощью агента Influx Telegraf (чтобы предоставить необходимые вам метрики), мы также предоставили соединитель Warp10 Telegraf , который был недавно объединен!

Пока это выглядит великолепно, но что, если я обычно нажимаю метрики Graphite, Prometheus, Influx или OpenTSDB ; как я могу просто перейти на Warp10 ? Наш ответ - Catalyst : прокси-уровень, который может анализировать метрики в связанных форматах и ​​преобразовывать их в родной для Warp10.

Катализатор

Catalyst  — это HTTP-прокси Go, используемый для анализа нескольких записей в базе данных TimeSeries с открытым исходным кодом. На данный момент он поддерживает несколько операций записи в базу данных TimeSeries с открытым исходным кодом; такие как OpenTSDB, PromQL, Prometheus-remote_write, Influx и Graphite. Catalyst запускает HTTP-сервер, который прослушивает определенный путь ; начиная с имени временного ряда протокола, а затем с собственного запроса . Например, чтобы собрать данные о притоке, вы просто отправляете запрос на адрес 

influxdb/write

. Catalyst автоматически проанализирует 

influx

данные и преобразует их в собственный формат приема Warp 10 .

Запросы метрик

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

Теперь давайте возьмем пользователя, который использует Telegraf и отправляет данные в Warp10 с помощью Catalyst. Они захотят использовать встроенную панель управления Influx Grafana, но как? А как насчет пользователей, которые автоматизируют запросы с помощью протокола запросов OpenTSDB? Нашим ответом было разработать прокси: Эрленмейер

Эрленмейер

Erlenmeyer  — это HTTP-прокси Go, который позволяет пользователям запрашивать Warp 10 на основепротокола запросовс открытым исходным кодом . На данный момент он поддерживает несколько форматов TimeSeries с открытым исходным кодом; такие как PromQL, удаленное чтение Prometheus, InfluxQL, OpenTSDB или Graphite. Эрленмейер запускает HTTP-сервер, который прослушивает определенный путь ; начиная с имени временного ряда протокола, а затем с собственного запроса . Например, чтобы выполнить запрос promQL, пользователь отправляет запрос в

prometheus/api/v0/query

. Эрленмейер изначально проанализирует

promQL

запрос, а затем создаст собственный запрос WarpScript, который может поддерживатьлюбойбэкэнд Warp10 .

Продолжение следует

Сначала Erlenmeyer и Catalyst представили быструю реализацию собственных протоколов, призванную помочь внутренним группам выполнять миграцию, при этом используя знакомый инструмент . Теперь мы интегрировали множество встроенных функций каждого протокола и чувствуем, что они готовы к совместному использованию. Это время , чтобы сделать их доступными для Warp10 сообщества , поэтому мы можем получить обратную связь и продолжать работать в поддержке протоколов с открытым исходным кодом. Вы можете найти нас в игровой комнате OVHcloud Metrics !

Другим пользователям Warp10 может потребоваться нереализованный протокол. Они смогут использовать Erlenmeyer и Catalyst для поддержки их на собственном сервере Warp10.

Добро пожаловать, Erlenmeyer и Catalyst — Metrics Open Source проекты!

В OVHCloud мы открываем исходный код для нашего проекта «Agility Telemetry». Джерем , как наш сборщик данных, является основным компонентом этого проекта. Джерем регулярно очищает нашу JIRA и извлекает определенные показатели для каждого проекта. Затем он пересылает их в наше приложение для длительного хранения, платформу данных метрик OVHCloud .

Концепции Agility с точки зрения разработчика

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

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

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

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

Как работает Джерем

В OVH мы используем JIRA для отслеживания нашей активности. Наш Jerem бот обрывки наших проектов из JIRA и экспорта всех необходимых данных для нашей OVHCloud Метрики платформы данных . Джерем также может передавать данные в любую базу данных, совместимую с Warp 10. В Grafana вы просто запрашиваете платформу Metrics (используя источник данных Warp10 ), например, с помощью нашей панели управления программами . Все ваши KPI теперь доступны на красивой панели инструментов!

Откройте для себя показатели Jerem

Теперь, когда у нас есть обзор основных задействованных концепций Agility, давайте погрузимся в Джерема! Как преобразовать эти концепции гибкости в показатели? Прежде всего, мы извлечем все показатели, относящиеся к эпикам (т.е. новым функциям). Затем мы подробно рассмотрим метрики спринта.

Эпические данные

Чтобы объяснить эпические метрики Джерема, мы начнем с создания новой. В этом примере мы назвали это Agile Telemetry. Мы добавляем лейбл Q2-20, что означает, что мы планируем выпустить его во втором квартале. Чтобы записать эпопею с Джеремом, вам нужно установить четверть для окончательной доставки! Затем мы просто добавим четыре задачи, как показано ниже:



Чтобы получить метрики, нам нужно оценить каждую отдельную задачу. Мы сделаем это вместе на подготовительных сессиях. В этом примере у нас есть собственные очки истории для каждой задачи. Например, мы оценили write a BlogPost about Jeremзадачу на 3.



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

• jerem.jira.epic.storypoint

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

• jerem.jira.epic.storypoint.done

  : количество выполненных задач. В нашем примере мы уже выполнили 

  Write Jerem bot

  и 

  Deploy Jerem Bot

  , поэтому мы уже выполнили восемь пунктов истории.

• jerem.jira.epic.storypoint.inprogress

  : количество «выполняемых» задач, например 

  Write a BlogPost about Jerem

  .

• jerem.jira.epic.unestimated

  : количество неоцененных задач, как 

  Unestimated Task

  в нашем примере.

• jerem.jira.epic.dependency

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

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

Данные спринта

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

Итак, давайте откроем новый спринт в JIRA и начнем работать над нашей задачей. Это дает нам следующее представление JIRA:



Джерем собирает следующие показатели для каждого спринта:

• erem.jira.sprint.storypoint.total

  : общее количество очков истории, набранных в спринт.

• jerem.jira.sprint.storypoint.inprogress

  : сюжетные точки, которые в настоящее время выполняются в рамках спринта.

• jerem.jira.sprint.storypoint.done

  : количество очков истории, набранных на данный момент за спринт.

• jerem.jira.sprint.events

  : даты начала и окончания спринта, записанные как строковые значения Warp10.

Как вы можете видеть в представлении «Показатели» выше, мы будем записывать каждую метрику спринта дважды. Мы делаем это, чтобы быстро просмотреть активный спринт, поэтому мы используем метку «текущий». Это также позволяет нам запрашивать прошлые спринты, используя настоящее имя спринта. Конечно, активный спринт также можно запросить по его имени.

Данные о препятствиях

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

Мы можем добавить в JIRA специальные билеты, чтобы отслеживать выполнение этой задачи. Это то, что мы называем «препятствием». Они маркируются в соответствии с их природой. Если, например, постановка требует вашего внимания, то это препятствие «Инфра». Вы также получите метрики для «Всего» (все виды препятствий), «Избыточности» (незапланированные задачи), «Поддержка» (помощь товарищам по команде) и «Исправление ошибок или другое» (для всех других видов препятствий).

Каждое препятствие принадлежит активному спринту, в котором оно было закрыто. Чтобы закрыть препятствие, вам нужно только пометить его как «Готово» или «Закрыто».

Мы также получаем такие показатели, как:

• jerem.jira.impediment.TYPE.count

  : количество препятствий, возникших во время спринта.

• jerem.jira.impediment.TYPE.timespent

  : количество времени, затраченного на устранение препятствий во время спринта.

TYPE соответствует виду зафиксированного препятствия. Поскольку мы не обнаружили никаких реальных препятствий, Джерем собирает только totalметрики.



Чтобы начать запись препятствий, мы просто создаем новую задачу JIRA, в которую добавляем метку «препятствие». Мы также устанавливаем его характер и фактическое время, потраченное на это.



В качестве препятствия мы также извлекаем глобальные метрики, которые всегда записывает Джерем:

• jerem.jira.impediment.total.created: время, затраченное с даты создания на устранение препятствия. Это позволяет нам получить общее количество препятствий. Мы также можем записывать все действия с препятствиями, даже вне спринтов.

Для одного проекта Jira, как в нашем примере, вы можете ожидать около 300 показателей. Это может увеличиваться в зависимости от эпика, который вы создаете и помечаете в Jira, и того, который вы закрываете.

Панель управления Grafana

Нам нравится создавать информационные панели Grafana! Они дают команде и менеджеру много информации о ключевых показателях эффективности. Лучшее в этом для меня, как разработчика, — это то, что я понимаю, почему хорошо выполнять задачу JIRA!

На нашей первой панели управления Grafana вы найдете все лучшие KPI для управления программами. Начнем с глобального обзора:

Обзор квартальных данных



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

Данные активного спринта



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

Подробные данные



В последней части представлены более подробные данные. Используя переменную epic Grafana, мы можем проверять конкретные эпики, а также завершение более глобальных проектов. У вас также есть velocity chart, который отображает прошлый спринт и сравнивает ожидаемые баллы истории с фактически завершенными.

Панель управления Grafana доступна напрямую в проекте Jerem. Вы можете импортировать его прямо в Grafana, если у вас настроен действительный источник данных Warp 10.

Чтобы панель управления работала должным образом, вам необходимо настроить переменную проекта Grafana в виде списка WarpScript [ 'SAN' 'OTHER-PROJECT' ]. Если наш программный менеджер может это сделать, я уверен, вы сможете!

Настройка Jerem и автоматическая загрузка данных управления программами дают нам много полезного. Мне как разработчику это очень нравится, и я быстро привык отслеживать в JIRA гораздо больше событий, чем раньше. Вы можете напрямую видеть влияние ваших задач. Например, вы видите, как быстро продвигается дорожная карта, и можете определить любые узкие места, которые создают препятствия. Затем эти узкие места становятся эпопеями. Другими словами, как только мы начинаем использовать Jerem, мы просто заполняем его автоматически! Надеюсь, вам тоже понравится! Если у вас есть отзывы, мы будем рады их услышать.

В прошлом году мы выпустили 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 в нашей документации по бета-функциям .