Сводка и предварительные агрегаты

Пример сводки

Учитывая серии выше, давайте сохраним sum и count с интервалом 1h.

Идентификатор серии	12:00	13:00
ts1 СУММА	10	5
ts1 КОЛИЧЕСТВО	4	4
ts2 СУММА	8	6
ts2 КОЛИЧЕСТВО	4	3
ts3 СУММА	9	19
ts3 КОЛИЧЕСТВО	4	4
ts4 СУММА	9	16
ts4 КОЛИЧЕСТВО	3	4

Обратите внимание, что все отметки времени выровнены по началу часа независимо от того, когда появляется первая точка данных в интервале «ведра». Также обратите внимание, что если данные отсутствуют для интервала, количество меньше.

В общем случае при хранении сводок следует вычислять и хранить MAX, MIN, SUM и COUNT.

Пример усреднения сводки

Когда сводки включены, и вы запрашиваете downsampler с функцией avg в OpenTSDB, TSD просматривает хранилище в поисках SUM и COUNT значений. Затем, при итерации по данным, он точно вычисляет среднее значение.

Отметки времени для значений count и sum должны совпадать. Однако, если ожидаемое значение count для суммы отсутствует, сумма будет исключена из результатов. Рассмотрим следующий пример набора из вышеуказанного, где у нас отсутствует значение count в ts2.

Идентификатор серии	12:00	13:00
ts1 СУММА	10	5
ts1 КОЛИЧЕСТВО	4	4
ts2 СУММА	8	6
ts2 КОЛИЧЕСТВО	4

Результирующая avg для запроса снижения частоты дискретизации 2h будет выглядеть так:

Идентификатор серии	12:00
ts1 СР.	1.875
ts2 СР.	2

Пример предварительной агрегации

Учитывая пример выше, мы можем захотеть посмотреть на общий трафик интерфейса по коло (дата-центру). В этом случае мы можем агрегировать по SUM и COUNT аналогично сводкам. Результатом будут четыре новые временные ряда с метаданными, такими как:

Идентификатор ряда	Метрика	Тег 1	Тег 2
ts1'	system.if.bytes.out	colo=lga	_aggregate=SUM
ts2'	system.if.bytes.out	colo=lga	_aggregate=COUNT
ts3'	system.if.bytes.out	colo=sjc	_aggregate=SUM
ts4'	system.if.bytes.out	colo=sjc	_aggregate=SUM

Обратите внимание, что эти временные ряды потеряли теги для host и interface. Это связано с тем, что во время агрегации несколько различных значений host и interface были объединены в этот новый ряд, поэтому их наличие в качестве тегов больше не имеет смысла. Также обратите внимание, что мы ввели новый тег _aggregate в сохранённые данные. Теперь запросы могут получить доступ к этим данным, указав значение _aggregate.

Теперь представленные данные:

Идентификатор ряда	12:00	12:15	12:30	12:45	13:00	13:15	13:30	13:45
ts1'	8	6	5	-1	6	-4	6	3
ts2'	2	2	2	2	2	1	2	2
ts3'	9	5	3	1	14	8	4	9
ts4'	1	2	2	2	2	2	2	2

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

Проблемы

Из-за (по сути) бессостоятельного характера TSD, они, вероятно, не будут иметь полного набора данных для выполнения предварительных агрегаций. Например, наши примерные данные ts1 могут быть записаны в TSD_A, в то время как ts2 записывается в TSD_B. Ни один из них не может выполнить правильную группировку без считывания данных из хранилища. Мы также не знаем, когда следует выполнить предварительную агрегацию. Мы можем подождать 1 минуту и агрегировать данные, но пропустить всё, что пришло после этой минуты. Или мы можем подождать час, и запросы к предварительным агрегатам не будут иметь данных за последний час. И что произойдёт, если данные поступят гораздо позже?

Кроме того, для сводок, в зависимости от того, как пользователи записывают данные в TSD, для ts1, мы можем получить данные 12:15 в TSD_A, но значение 12:30 приходит в TSD_B, поэтому ни у того, ни у другого нет данных, необходимых для целого часа. Ограничения по временным окнам также применяются к сводкам.

Решения

Использование сводок и предварительных агрегатов требует анализа и выбора между различными компромиссами. Поскольку некоторые пользователи OpenTSDB уже имеют средства для расчёта такого рода данных, мы просто предоставляем API для хранения и запроса. Однако вот несколько советов по тому, как вычислить их самостоятельно.

Обработка по частям

Один из методов, который обычно используется другими базами данных временных рядов, заключается в чтении данных из базы данных после некоторой задержки, вычислении предварительных агрегатов и сводок, а затем записи их. Это самый простой способ решения проблемы и хорошо работает при малых объёмах. Однако по-прежнему есть ряд проблем:

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

Некоторые методы улучшения обработки по частям включают:

• Чтение из реплицированных систем, например, если вы настроили репликацию HBase, вы можете позволить пользователям запросить главную систему, а агрегации читать из реплицированного хранилища.
• Чтение из альтернативных хранилищ. Одним примером является создание зеркала всех данных в другое хранилище, например, HDFS, и запуск задач по частям против этих данных.

Очереди в TSD

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

• Достаточно оперативной памяти или дискового пространства для хранения данных локально в каждом TSD.
• Если процесс TSD завершается, вы либо потеряете данные для агрегации, либо их нужно будет восстановить из хранилища.
• В любое время, когда выполняются вычисления агрегации, общая пропускная способность записи исходных данных может пострадать.
• У вас по-прежнему остаётся проблема с поздними/историческими данными.
• Поскольку TSDB основана на JVM, хранение всех этих данных в ОЗУ и последующий сбор мусора нанесут вред. Значительно. (хранение в диске лучше, но тогда у вас появятся проблемы с вводом/выводом)

В целом, создание очереди на писателе — плохая идея. Избегайте проблем.

Обработка потоков

Лучший способ обработки сводок и предварительных агрегатов — направить данные в систему обработки потоков, где их можно обрабатывать в режиме реального времени и записывать в TSD. Это похоже на вариант "Очереди в TSD", но с использованием одного из многочисленных фреймворков для обработки потоков (Storm, Flink, Spark и т.д.) для обработки маршрутизации сообщений и хранения в оперативной памяти. Затем вы просто пишете код для вычисления агрегатов и выдаёте данные после прохождения окна.

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

Хотя обработка потоков лучше, у вас всё ещё есть проблемы, с которыми нужно справиться:

• Достаточно ресурсов для работы потоковых рабочих процессов.
• Выход из строя потокового рабочего процесса требует восстановления из хранилища.
• Поздние/исторические данные должны обрабатываться.

Поделитесь

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