Картина ясная: как мы визуализируем метрики Platform V DataGrid в Grafana

Источник: Хабр "Картина ясная: как мы визуализируем метрики Platform V DataGrid в Grafana"

Привет, Хабр! Меня зовут Илья Степанов, я работаю в СберТехе в команде продукта Platform V DataGrid — распределённой базы данных, основанной на Apache Ignite и доработанной до enterprise-уровня надёжности и безопасности. В статье расскажу, как мы обеспечиваем промышленный мониторинг критических систем и визуализируем метрики наших кластеров.

Периодически к нам обращаются пользователи и клиенты с вопросом: «Как лучше визуализировать то или иное состояние кластера?» В нашем продукте есть несколько способов получения метрик из кластера. В том числе «классические» для Java-приложений: можно прочитать метрики через JMX, экспортировать в формате Prometheus, сбрасывать в log-файл, получать в результате SQL-запроса или через вызов управляющего скрипта. То есть, с метриками может работать практически любая система мониторинга.

Для мониторинга Platform V DataGrid и других продуктов Platform V у нас есть специализированный продукт — Platform V Monitor, обеспечивающий сбор, хранение, визуализацию и анализ телеметрии. Помимо него, для сбора и хранения телеметрии доступны самые разные системы: Zabbix, Prometheus, InfluxDB, Victoriametrics и другие. Тогда для создания панелей чаще всего используется Grafana — распространённая платформа для мониторинга, визуализации и анализа данных. В поставке с Grafana идёт много плагинов для создания панелей, а ещё здесь можно установить дополнительные компоненты, которые расширяют возможности визуализации.

В простых случаях, например, когда вам нужно отобразить график с метрикой или нарисовать таблицу с данными, достаточно будет стандартных компонентов Grafana. Однако этого будет недостаточно, если потребуется модифицировать метрики перед визуализацией, составить более сложную логику работы с сырыми данными или отобразить нестандартные графики. Platform V Monitor, в свою очередь, позволяет это делать. А также обладает возможностями журналирования, трассировки, оповещения и прогнозирования значений метрик.

Я опишу наш опыт работы именно с Grafana, как с более известным и популярным решением.

Первое время для модификации данных мы использовали функции Transform в Grafana, но затем свели их применение к минимуму. Причин было две:

1. Многие функции на момент использования носили статус beta или alpha, что приводило к ошибкам в их работе.
2. После обновления Grafana до новой версии клиенты жаловались на ошибки в отображении данных. Как правило, причина была одна: изменение поведения функций Transform.

В итоге мы решили реализовать свой подход к модификации и визуализации данных в тех случаях, когда стандартных панелей недостаточно. Для этого выбрали плагин HTMLGraphics для Grafana. Благодаря связке JavaScript с HTML и CSS он позволяет реализовывать любую логику и визуализацию панелей. Код можно править прямо в настройках панели и без дополнительных манипуляций на стороне Grafana.

Примеры отображения метрик

Насколько быстро кластер выполняет операции над кешами

У базовых операций с кешем (например, GET, PUT, REMOVE) есть свой набор метрик. Скажем, метрика CacheGets отвечает за общее количество операций GET в определённом кеше, на конкретном узле кластера. Метрика CachePuts отвечает на вопрос, сколько было операций PUT, и т. д. Метрики увеличиваются каждый раз, когда узел кластера завершит ту или иную операцию.

Для оценки скорости выполнения операций мы используем гистограммы. Каждая операция имеет свою гистограмму с предустановленными временными интервалами. Так, для операции GET по умолчанию имеются следующие временные интервалы в метриках:

GetTime_0_1000000
GetTime_1000000_10000000
GetTime_10000000_100000000
GetTime_100000000_250000000
GetTime_250000000_1000000000
GetTime_1000000000_inf

Интервалы в именах метрик отображаются в наносекундах. Каждая такая метрика — это счётчик. Он увеличивается, если операция с кешем завершилась в его временных пределах. Нам остаётся только собрать все метрики гистограмм со всех узлов кластера по интересующему нас кешу.

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

С метриками транзакций ситуация похожая. Есть метрики количества успешных транзакций (txCommits) и гистограммы, которые отображают скорость выполнения транзакций. Гистограммы группируются по системному и пользовательскому времени исполнения (nodeSystemTimeHistogram и nodeUserTimeHistogram). Системное время — время, затраченное на получение блокировок, фиксации транзакции и т. д. Пользовательское время — время, затраченное на вычисления логики транзакции.

В отличие от метрик кеша, метрики транзакций создаются на узле без учёта количества кешей. Таким образом, метрик транзакций в разы меньше, чем метрик кешей. По умолчанию создаются следующие временные интервалы в метриках:

nodeUserTimeHistogram_0_1
nodeUserTimeHistogram_1_2
nodeUserTimeHistogram_2_4
nodeUserTimeHistogram_4_8
nodeUserTimeHistogram_8_16
nodeUserTimeHistogram_16_25
nodeUserTimeHistogram_25_50
nodeUserTimeHistogram_50_75
nodeUserTimeHistogram_75_100
nodeUserTimeHistogram_100_250
nodeUserTimeHistogram_250_500
nodeUserTimeHistogram_500_750
nodeUserTimeHistogram_750_1000
nodeUserTimeHistogram_1000_3000
nodeUserTimeHistogram_3000_5000
nodeUserTimeHistogram_5000_10000
nodeUserTimeHistogram_10000_25000
nodeUserTimeHistogram_25000_60000
nodeUserTimeHistogram_60000_inf

Интервалы в именах метрик отображаются в миллисекундах. С точки зрения отображения на панели мы рекомендуем тот же подход, что и для метрик кеша — график и суммирование.

Сколько времени осталось на ребалансировку данных в кластере

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

• RebalancingPartitionsLeft — общее количество оставшихся партиций к перемещению.
• RebalancingPartitionsTotal — общее количество партиций к перемещению.
• RebalancingStartTime — время начала операции по ребалансировке.
• RebalancingEndTime — время окончания операции по ребалансировке.

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

Сколько и каких узлов мы можем вывести из топологии без потери данных в кластере

По умолчанию кластер пытается разложить данные равномерно по всем узлам. Этот процесс можно контролировать, например, через BackupFilter. С помощью BackupFilter мы можем объединить узлы кластера в ячейки. Каждая Primary-партиция в такой ячейке будет иметь Backup-партицию в той же ячейке. В случае выхода узла из кластера можно узнать, сколько узлов осталось в ячейке и какие узлы нельзя потерять. Это важно в тех ситуациях, когда партиции находятся в единственном экземпляре.

Каждая кеш-группа публикует метрики партиций:

• AffinityPartitionsAssignmentMap — карта распределения партиций в кластере.
• OwningPartitionsAllocationMap — карта партиций в кластере в состоянии OWNING.

Если в AffinityPartitionsAssignmentMap есть партиция, которая хранится только на одном узле (0=[8dec8996-15f7-4846-a4fe-0121cb869cd3]), и на кластере не запущена ребалансировка, значит, такая партиция хранится в единственном экземпляре. Важно не терять узел с соответствующим идентификатором, так как это может привести к потере данных в кластере.

Осталось только собрать метрики, проанализировать количество идентификаторов для каждой партиции и вывести на экран:

Скорость работы пулов потоков кластера

На каждом узле кластера есть ряд системных пулов потоков. Каждый отвечает за свою функциональность. Например, Queries Pool — за работу SQL и Scan, Striped Pool — за базовые операции с кешами, Public Pool — за Compute, и т. д. У каждого пула — свои метрики узла:

• TotalQueueSize/QueueSize — размер очереди в пулах.
• TotalCompletedTasksCount/CompletedTaskCount — количество завершённых задач в потоках.

Также у каждого пула есть свой набор гистограмм:

TaskExecutionTime_0_10
TaskExecutionTime_10_50
TaskExecutionTime_50_100
TaskExecutionTime_100_500
TaskExecutionTime_500_1000
TaskExecutionTime_1000_inf

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

Отображаем проблемы в кластере

Пожалуй, один из самых сложных и спорных вопросов. Что считать проблемой? Конечно, есть ряд метрик, которые одинаково важны для всех пользователей, скажем, количество узлов в кластере. Но в остальных случаях у клиентов разные SLA: для кого-то повышенное потребление места на диске — это проблема, а для кого-то — нормальная ситуация.

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

Если у вас всего один кластер, то, скорее всего, вы захотите сделать визуализацию отдельно для каждого узла. А если кластеров 50, 100, 200? В таких случаях визуализацию нужно строить по кластерам, а не по узлам, предусмотрев сортировку и фильтрацию. Вот пример «дашборда здоровья», где каждый кластер — это отдельный круг с информацией о количестве найденных проблем: