подробно…

Создание системы мониторинга Scheduled_jobs в Oracle
Базы данных Oracle являются широко распространённым инструментом СУБД в
ЦЕРНе. Это очень мощный инструмент хранения и обработки данных. Ответственность за
тонкую настройку и администрирование этих баз данных лежит на особых специалистах —
DBA (Database Administrators), потому что это требует внушительного багажа знаний и
опыта.
База данных Oracle используется в Dashboard для хранения сырых данных
мониторинга, их периодической обработки (агрегации) и хранения агрегированных данных.
Все результаты мониторинга, что можно увидеть на сайте Dashboard, проходят
стандартный путь. Сначала коллектор, специальная программа, извлекает сырые данные из
очереди сообщений и записывает их в базе данных в том же виде. Это может быть
информация об открытии файла, закрытии, начале передачи, конце передачи и др. Подобных
сообщений слишком много, чтобы эффективно ими оперировать.
Каждые десять минут, используя механизм DBMS_Scheduler (планировщик заданий
СУБД Oracle), запускается серия процедур(scheduled_jobs), призванных агрегировать сырые
данные, появившиеся после последнего успешного выполнения процедур и собранные
коллектором. Эти процедуры агрегируют информацию по некоторым полям и
десятиминутным интервалам. Поэтому процедура должна работать не более 10-ти минут,
иначе следующий её запуск должен будет обработать объём информации, пришедший со
времени предыдущего запуска, что может ещё более увеличить задержку выполнения
агрегации, что, в свою очередь, вызовет задержки на пользовательском интерфейсе. После
агрегации данные доступны для пользовательского интерфейса.
Следует отметить, что существует несколько схем (независимых наборов таблиц):
CMS_PRODUCTION, ATLAS_PRODUCTION, CMS_INTEGRATION и др. В каждой из этих
схем выполняются свои процедуры, которые не зависят друг от друга. На данный момент, для
некоторых схем механизм планировщика заданий Oracle работает на пределе, что требует
особой тщательности при добавлении новых процедур или модификации старых. Чтобы
обеспечить надёжную работу Dashboard во время выполнения каких-то обновлений, помочь
разработчикам идентифицировать задержку по причине увеличения потоков данных и
понять, насколько велики задержки, была создана система мониторинга выполнения
процедур в Oracle.
Вся информация о работающих процедурах, а также о процедурах, закончивших своё
выполнение, находится в Oracle в соответствующих таблицах. Это информация о дате и
времени начала и конца выполнения процедуры, о количестве успешных запусков и запусков,
закончившихся ошибкой. Доступ к этой информации даст возможность программистам
усовершенствовать существующие процедуры или оптимизировать новые разработки.
Основной проблемой при предоставлении информации о работе процедур является задача
визуализации, потому что записей в базе данных очень много, и простой вывод их на экран
не принесёт большой пользы. В связи с этим информация о процедурах была определенным
образом структурирована, а для предоставления доступа к хорошо структурированной
информации о процедурах был разработан веб-сервис.
Созданный веб-интерфейс предоставляет доступ к двум видам информации: общая
информация о процедурах и детальная информация о процедуре. Общая информация (Рис.1)
- это несколько таблиц, каждая из которых посвящена отдельной схеме базы данных. Каждая
строка таблицы — это процедура, которая либо работает, либо уже закончила свою работу,
либо выключена (подсвечивается серым в таблице). В случае если процедура превысила
отведённое для неё время, то она подсвечивается оранжевым, красным текстом
отображаются: текущее время работы, время старта, ожидаемое время окончания работы.
Рис.1. Общая информация о процедурах.
При необходимости, кликнув на процедуру, можно увидеть детализированную
информацию (Рис.2) о ней: длительности выполнения процедуры за последний месяц и
информацию о количестве сообщений, которые она агрегировала. Таким образом, на графике
сразу отображаются две метрики: время выполнения и количество пришедших сообщений.
Это помогает определить причину задержки: интенсивный поток сообщений или
недостаточно хорошо оптимизированная процедура.
Рис.2. Детализированная информация об отдельной процедуре.
Чтобы упростить навигацию по большому графику, была создана его не
масштабируемая малая копия (Рис.3), на которой можно выбрать интересующую область,
которая будет отображена. Чтобы упростить оценку скорости выполнения процедуры, части
графика, находящиеся выше отметки в 10 минут, окрашиваются в красный цвет. Чтобы
реализовать данный проект, в качестве веб-фреймворка был выбран Django, как стандартный
инструмент для создания веб-сервисов в группе Dashboard. Все таблицы созданы при
помощи datatables.js, эта библиотека упрощает поиск в таблице и позволяет сортировать
строки. Графики построены при помощи библиотеки flot.js.
Рис.3 Отображение информации об отдельной процедуре за указанный интервал времени.
Благодаря системе мониторинга Scheduled_jobs Oracle стало возможно следить за
временем выполнения процедур и упростить процесс их разработки и модификации.
Оказалось, что очень сложно выявить корреляцию между количеством новых сообщений и
временем выполнения процедур. Судя по всему, из-за особенностей внутреннего
планировщика Oracle, а также принципов кэширования, задержка может появиться даже
тогда, когда для неё не было видимых причин.