Всем привет. Сегодня я хочу рассказать немного о мониторинге СУБД на примере SAP HANA и заодно о своём инструменте RybaFish Charts который для этого и сделан.

Нелирическое отступление

В СУБД SAP HANA изначально заложена функция сбора телеметрии о собственном состоянии. Ведётся порядка 40 показателей которые характеризуют положение дел в системе. Кроме основных метрик (они же KPI) типа памяти, CPU, диска, сети и прочих, собираются и всякие специфические для ханы: количество открытых транзакций, блокировок, время отклика и прочее.

Занимается этим nameserver, который раз в 10 секунд записывает эту информацию на диск в csv-файл, но читать его можно и при помощи SQL-интерфейса. Кстати, в случае совсем уж страшных проблем можно прочитать именно CSV-файл даже при выключенной базе. На всякий случай: архитектура СУБД, вид из космоса.

Чем-то напоминает бортовые самописцы самолёта (“чёрный ящик”) я даже думаю что именно им вдохновлялись разработчики.

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

Дело в том, что nameserver довольно консервативная штука и новые метрики в нём появляются прямо редко. Да и нет необходимости каждые 10 секунд фиксировать подробную информацию обо всём подряд. Для более глубокого анализа в SAP HANA есть отдельная служба “statistics service”, который собирает кучу дополнительной диагностической информации. У него есть свой scheduler и разные данные записываются с разной периодичностью: что-то раз в минуту, что-то вообще раз в час.

То есть получается, есть как минимум два источника информации с разной степенью гранулярности.

Всё это тихо записывается в базу пока система работает нормально, а в случае отказов эта информация оказывается чрезвычайно полезной для post-mortum анализа.

К делу

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

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

Вот эту простую (казалось бы) задачу и решает RybaFish, который я уже какое-то время разрабатываю в качестве хобби.

Потребление основных ресурсов: память, ЦПУ.

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

Как я упоминал, для отрисовки изначально предназначены те самые ~40 метрик которые собирает nameserver, и их отрисовка и была реализована в первую очередь. Это уже дало очень неплохое представление о поведении системы... но остановиться уже было сложно.

Пользовательские метрики (Custom KPIs)

Довольно быстро (ах, жаль что не сразу!) я понял что на ось времени можно наносить не только 40 фиксированных метрик, но и любые другие значения. Лишь бы можно было достать их из базы и привязать ко времени. Это тут же сразу увеличило количество (и качество!) наблюдаемых показателей и, что важнее, инструмент из детерменированного постепенно становится довольно гибким.

Так появилась функция которую я назвал “Custom KPIs”, то есть какие-то свои нестандартные метрики. Если есть какие-то измерения и у них есть время - их можно нарисовать. В основном эта функция использовалась как раз для отображения всяких экзотических штук основанных на запросах к данным Statistics Service. Например, суммарный размер таблиц на диске или потребление памяти на определённые цели (какие-нибудь кэши, например). Выглядит это приблизительно так же как стандартные метрики, но я приложу картинку в конце.

Здорово разрабатывать что-то самому: придумал какую-то фичу - просто берёшь и делаешь, даже время на уговоры тратить не надо. Именно так я в какой-то момент придумал что график может отображать не только линии, но ещё и диаграммы ганта.

Самое очевидное - это отображать выполнение длинных SQL (expensive statements):

Диаграммы ганта и потребление ресурсов: память, ЦПУ.

Никогда ещё мониторинг БД не был настолько информативным!

Сразу видно, что пики CPU есть результат не одного, а нескольких SQL. Причём выполняются они разными пользователями, а когда Tim и Lucia берутся за дело вместе - то потребление CPU складывается и доходит до 50%. Понять что именно происходит в системе без диаграмм гантта конечно можно, но очень трудозатратно.

Прелесть, напомню, в том что эти диаграммы - просто часть настроек утилиты. Любой процесс у которого есть начало и конец может быть отображён в виде диаграммы ганта: какие-нибудь загрузки, бэкапы, системные процессы, что угодно... Expensive statements - просто частный пример, хотя, пожалуй, один из самых востребованных.

В зависимости от профиля нагрузки и особенностей конкретной системы можно подобрать ключевые метрики которые можно отображать на диаграмме чтоб�� держать руку на пульсе.

Здесь, пожалуй, не время и не место вдаваться в подробности анализа непосредственно SAP HANA, но поверьте, видя перед собой ключевые показатели производительности инстанции гораздо проще понимать насколько хорошо чувствует себя система. А после добавления диаграмм ганта СУБД вообще превращается из “чёрного ящика” в открытую книгу.

Вот и всё, в 90% случаев идентифицировать проблемный процесс можно быстро повключав интересующие метрики (стандартные или собственные), а ценное время администратора потратить на кружечку кофе и чтение хабра.

Пример более сложного варианта KPI, т.н. "multiline": как бы метрика с разбивкой на компоненты:

Разбивка потребления памяти по компонентам (multiline)

А вот так выглядит основной интерфейс:

Вместо заключения

Потом я подумал: ”а раз у меня уже есть соединение к БД, почему бы мне не сделать простенькую SQL-консоль?” и вот это была реально самонадеянная мысль. Я и представить не мог сколько разных интересных проблем таит в себе простенький SQL редактор. От номеров строк и подсветки скобок до обязательной многопоточности: SQL то может и минуту и десять работать, нельзя при этом блокировать единственный UI-thread. Но это уже совсем друга�� история...

Пару слов о технологиях:
- Python + Qt
- Pyinstaller для создания portable версии (+ splash screen при запуске!)

Со времён института я интересовался машинной графикой, поэтому рисованием графиков я занялся сам, без использования каких-то библиотек, кроме самого Qt. Конечно, немножко пришлось повозиться, зато я с точностью до пикселя уверен что у меня где находится, как именно формируются подписи по оси времени и прочие приятные мелочи. Ну и в случае возникновения проблем - просто берёшь и исправляешь, удобно.

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

Проект изначально ведётся как open-source, почти сразу я завёл его на github, стал записывать баги/фичи и в зависимости от наличия времени и сил - потихоньку их решать: всякие мелочи по вечерам, что-то сложное большое - обычно на выходных.

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

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

Буду рад, если кто-то нашёл для себя что-то полезное или не знал, а теперь узнал про рыбу, кстати, четверг ведь - рыбный день.

Мониторинг HANA DB