Что нового в Glaber 3.1

Оптимизирован пайплайн обработки метрик

Упрощена архитектура основного пайплайна основного потока данных:

Унаследованная от Zabbix система пре-процессинга была несколько сложной:

https://www.zabbix.com/documentation/current/en/manual/config/items/preprocessing/preprocessing_details

В упрощенном виде старый пайплайн выглядел так:

До текущего момента в Glaber для решения вопросов производительности Preprocessing manager, можно было запускать более одного Preprocessing Manager.

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

Следующим узким местом был кеш истории: Он достаточно сложно устроен, и на рейтах более 150К метрик в секунду значительное время начинали занимать операции ожидания блокировок кеша истории.

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

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

Alt text

Новый внутренний механизм передачи metrics IPC

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

Простая реализация, около 200 строк на С
возможность передачи данных без сериализации
отсутствие необходимости копировать данные для обработки при получении
Количество операций блокировок пропорционально количеству операций получения данных, а не количеству данных. При увеличении нагрузки за одну операцию стороны посылают и принимают большее количество данных, то есть, есть отличные возможности масштабирования
Возможность формирование «статических» маршрутов прохождения метрик одних и тех же узлов: один и тот же хост проходит через одни и те-же процессы. Дает хорошие возможности по кешированию информации и оптимизации хранения некоторых кешей. Например, накопленные тренды более нет необходимости хранить в разделяемой памяти, а можно оставить в heap потоков процессинга.
Отсутствие необходимости выделять операций malloc/free на данных фиксированной длины
Алгоритмическая суть это заранее выделенный в памяти список элементов, формирующий односвязный список. Архитектурно - это FIFO буфер, с возможностью отправителем адресовать посылку конкретному получателю

Такой IPC использовался в Glaber начиная с версии 3.0 во вспомогательных функциях, например, для оповещения асинхронных процессов поллинга о смене конфигурации. Начиная с 3.1, он начал использоваться как основной способ внутренней пересылки метрик.

Опыт, упрощение

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

Alt text

А если «развернуть» схему с точки зрения шагов прохождения, то от такого пути прохождения метрики:

old flow

Пришли к такому: Alt text

Результаты

Затраты на передачу данных между субпроцессами снизились примерно в 30-50 раз.

Тесты на максимальную производительность пайплайна показали такие цифры: при обработке потока логов (60к NVPS, 200mBit/s ,1 шаг обработки):

preprocessing manager исчерпывал свою производительность и загружал один процессор на 100%, плюс суммарная нагрузка на воркеры составляла около 60% одного CPU, итого – 160%.
с такой же задачей один поток препроцессора справляется с затратами CPU около 11-13%.

При отключении шагов предобратоки цифры – соответственно 100%, и 3%.

Обработка зависимых данных в препроцессинге:

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

Тестирование шагов препроцессинга для UI делается в процессе траппера пересылка и ожидание результатов из пре-процессинга затратнее, чем локальное выполнение запросов.

Существенных отличий в результатах работы шагов пре-процессинга от предыдущей реализации нет, а вот реализация в коде стала очень лаконичной и простой:

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

Общая производительность

Glaber 3.1: тесты производительности

В настоящий момент узким звеном останется процессинг данных в процессе history syncer так как там активно используется работа с SQL для обработки метрик (работа с триггерами, вычисление макросов, функций и т.п.).

Внутренний мониторинг

Упрощены метрики:

zabbix[preprocessing_queue]
zabbix[tcache,*]
zabbix[wcache,*]

Новые метрики

Из соображений наглядности и удобства сделан синоним для внутренних метрик internal[...] Для новой системы IPC и очередей / буфферов в пре-процессинг и процессинг созданы метрики

internal[processing]
internal[preprocessing]

Метрики возвращают JSON с набором счетчиков, описывающих текущее состояние очередей. Создан отдельный шаблон для внутреннего мониторинга Glaber: glaber_template.yaml

Подробно описание: внутренний мониторинг

Изменения в конфигурации сервера:

Не поддерживаются более устаревшие опции:

    HistoryCacheSize
    HistoryIndexCacheSize
    TrendCacheSize
    TrendFunctionCacheSize

Появились опции размера буфера IPC и максимальной длины очередей:
```
    IPCBufferSize (512 Мb) 
    IPCProcMetricsPerPreprocessor (128k)  
    IPCProcMetricsPerSyncer (128k)
```

в большинстве инсталляций значения по умолчанию достаточны и опции можно не указывать

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

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

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

Например, нужна буферизация на 10 секунд. Нужно умножить ожидаемый рейт приходящих данных ( например, 10 тысяч метрик в секунду) на время буферизации, получим общее количество метрики:

10 * 10 000 = 100 000

Разделить это количество на - по процессам препроцессинга – например, 5, получим 20тысяч.

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

Общий размер памяти следует выбирать так: взять средний размер метрики, если в системе используются только числовые метрики, то использовать размер 72байта, если строковые – то добавить средний размер строки и еще 40 байт.

Зачастую такие цифры недоступны, поэтому можно брать с хорошим запасом, скажем, 500 байт на метрику. Далее умножить размер на суммарный размер очередей на этот размер и получится необходимый размер памяти. Следует делать запасы на пиковые нагрузки. Например 200 000 * 500 = 100 000 000 или примерно 100мбайт.

Изменения в прокси

Оптимизированы запросы на получение конфигурации для прокси, на больших конфигурациях ( более 200 тысяч метрик) время SQL запросов для подготовки конфигурации уменьшилось на 3-4 порядка.

Новые правила препроцессинга

Для решение вопросов производительности Discovery, обработки потоков данных создано несколько новых правил препроцессинга:

JSON Filter

Оставляет в запросе только объекты, чьи ключи указаны в параметрах

Local Dispatch

Переадресует элемент данных в рамках текущего хоста по значению поля в JSON

JSON Discovery aggregation

Агрегирует и через указанные промежутки времени отдает накопленные уникальные JSON объекты.

Нужно для эффективного пред-фильтра для формирования Discovery запроса на создание новых элементов. Позволяет автоматически создавать новые метрики из потока данных с большим входящим рейтом без ущерба для производительности LLD

Принимает на вход валидные JSON объекты или массивы объектов. В случае, если подается массив объектов,

Подробно описание и логика в препроцссинге