Схема базы данных, для системы мониторинга

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

Какие функциональные требования относятся к системе мониторинга? Вот некоторая часть этих требований:

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

data_modelУчаствующие сущности:

  • time_intervals таблица 15 минутных временных интервалов. Определяет период за который производилось наблюдение и за который поступили данные в систему;
  • qosraw.data_snmp таблица соответствующая способу получения измерений или по типу измерений. В данном случае SNMP, но может быть Netflow, CLI(Command Line Interface), ADSL и т.д. Еще это мастер таблица в терминах PostgreSQL;
  • qosraw.data_snmp_yyyy_MM_dd подчиненная таблица в терминах PostgreSQL.

time_intevals

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

Что дает нам такая связь? Имея ссылочную целостность в СУБД удалив временной интервал, мы удаляем все измерения и рассчитанные показатели за этот период времени.

qosraw.data_snmp

Таблицы с именем qosraw.data_XXX предназначены для хранения измерений по их происхождениям. В data_snmp хранятся метрики получаемые путем опроса объектов наблюдения по SNMP.

Описание полей:

  • time_id идентификатор временного интервала;
  • mid — measurement id идентификатор измерения: количество переданных пакетов, ошибок, нагрузка процессора, температура лазера и т.д.;
  • critid идентификатор критерия. Когда мы хотим отслеживать какую-то характеристику конкретного объекта, мы вешаем критерий и связываем его с типом измерения. К примеру ошибки на сетевом интерфейсе является типом измерения, может измерятся в пакетах или в % от обработанных пактов. В данном типу измерению «ошибки», соответствуют два измерения: ошибки в пакетах и ошибки в %;
  • value само значение.

Эта таблица в PostgreSQL(именно эту СУБД мы используем) является мастер таблицей при реализации партицирования таблиц и поэтому не содержит самих данных.

Партиционирование (partitioning) — это разбиение больших таблиц на логические части по выбранным критериям. Партиционированные или секционированные таблицы призваны улучшить производительность и управляемость базами данных.

qosraw.data_snmp_yyyy_MM_dd

Подчиненная таблица. Собственно она и содержит сами данные. Сделано это для повышение производительности. В одной тестовой зоне у заказчика происходит мониторинг 130 сетевых устройств, каждые 15 минут кладутся порядка 46 000 измерений, в такой дневной таблице получается порядка 4-5 миллионов измерений. Так что если все держать в одной таблице, что через месяц система начнет проседать.

Заключение

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

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

Обновление PostgreSQL с 8.4 до 9.3

За неимением DBA в штате, настройкой и оптимизацией PostgreSQL приходится заниматься самому.

После прочтения книги Работа с PostgreSQL, настройка и масштабирование, заинтересовался что и в каком объеме находится в буферах постгреса. Взял запрос из книги, запустил, и получил ошибки, что нет какой-то функции. Тут я понял, что пришло время, для перехода с не поддерживаемой версии 8.4, до последней 9.3.

Версию 9.3 для Debian 6 была взята с репозитория postgresql.org.

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

Прежде чем заливать дамп, следует не забыть следующее:

  • если использовались расширения(pg_buffercache, pgperl и т.д.) для версии 8.4, следует установить эти же расширения для 9.3, т.к. в дампе присутствуют инструкции по использование этих расширений;
  • если используются триггеры или функции написанные на С/С++, то их следует обновить.