Базу даных в целом можно разделить на три логические части:
Данная часть базы предназначена для хранения информации о проверяемых
сервисах, физическом местонахождении серверов на которых расположены проеряемые
сервисы и контактной информации о лицах, обслуживающих эти сервисы.
Сюда входят таблицы проверяемых сервисов (ping, http,
smtp,
whois,
mail,
dns1,
pop)
с обязательными атрибутами
putsection, host и первичным ключем key.
Набор необязательных атрибутов этих таблиц зависит от типа проверяемого
сервиса.
Логические взаимосвязи этих таблиц с остальными таблицами этой догической
части базы данных показаны на примере таблицы dns1. Кроме
этих таблиц существует еще две таблицы (square и rsquare)
в которых также присутствуют атрибуты putsection и host . Но
эти таблицы не используются соответствующими плагинами просмотра а находятся
в базе лишь из соображений целостности.
С помощью разрешаюших отношения многие-ко-многим таблиц person_host
и server_host таблицы проверяемых сервисов соединяются с таблицами
person
и
server . В таблице person лежит информация о персонах,
обслуживающих данный сервис. В таблице server
лежит информация о
физическом месторасположении сервера и его владельце.
Перечень запускаемых плагинов и их параметры определяются из таблиц
eye
и parametrs соответственно. В таблице parametrs находятся
и параметры используемые демоном eyed .
С другиой стороны на таблицу eye ссылается таблица rc. В
ней содержатся данные используемые при работе плагинами square и
rsquare.
Такие как соответствие цвета и информационного сообщения статусу ячейки
определенного тапа плагина. Стоит отметить что эти значения по умолчанию
прошиты в теле библиотеки view.
Данные таблицы служат для сбора статистической информации и заметок
операторов о случившихся событиях. Это наиболее быстрорастущая часть базы.
Для сбора информации служат две таблицы: stat и log.
В таблицу stat ложится статистическая информация от плагинов-сборщиков
информации. При каждом переключении статуса в ячейке туда записывается
строка. В таблицу log записываются комментарии операторов. В каждой
из таблиц присутствуют атрибуты времени и идентификатор ячейки. Таблицы
stat
и
log
соединяется
с таблицами проеряемых сервисов по их названиям и первичным ключам key.
Кроме того таблица log соединяется с таблицей
users.
Этот раздел бызы данных предназначен для разграничения прав доступа.
Он также служит для построения интерфейса. С его помощью, например, скрываются
суррогатные первичные ключи.
Структуры разделения доступа состоят из таблицы профилей rights
и таблицы соответствий пользователей этим профилям users. Таблица
профилей описывает права на просмотр/изменение/удаление записей из таблиц
сущностей. Просмотр и изменение регулируется для каждого атрибута таблиц
сущностей (например скрывается первичный ключ таблиц проверяемых сервисов).
Права на удаление определяются правами на первичный ключ (набор первичных
ключей) таблицы сущности. Практически каждый профиль должен иметь соответсвующего
пользователя базы с разрешенными на уровне SQL действиями над таблицами,
заявленными в rights. Кроме этих пользователей в базе данных заведены
пользователи eye - владелец схемы и parse - пользователь
с неограниченными правами на чтение.
Для определения прав конечного пользователя системы применяется следующая
процедура:
Пользователи базы данных
В этом разделе описаны пользователи базы данных, которые создаются при установке програмного пакета. Их назначение и првилегии в схеме eye.
Техническое исполнение
Первоначально конфигурация демона и плагинов лежала в отдельных файлах.
Затем эта конфигурация восстанавливалась в структуры описанные в секции
parse
описания демона eyed. В текущий версии
конфигурационная информация восстанавливается хоть и из базы данных, но
в те же структуры. Еще одна структура, формально соответствующая конфигурационной
секции одного плагина создается из таблицы rc с помощью функции
OpenRcFile().
Поскольку ее заполнение несколько отличается от заполнения структур
конфигурацинооых файлов, то опишем этот процесс поподробнее. NameOfCfg
структуры Plugin заполняется значением "Rc lines". Затем производится
следующая выборка:
select status,nameofexec,comment,color,loglevel from rc ORDER BY nameofexec,status;Поле ps_name структуры PutSection заполняется значениями из поля nameofexec таблицы rc. Это значит, что вся информация о сообщениях одного типа плагина содержится в пределах одной структуры PutSection. Поле key структуры Host заполняется значениями из поля key таблицы rc. Поле _h_addr структуры Host заполняется значениями из поля comment таблицы rc. А в полях h_adddata[0] и h_adddata[1] лежат значения взятые из полей color и loglevel таблицы rc соответственно.
В качестве СУБД был выбран Postgresql. Эта СУБД хорошо обрабатывает
большие объемы данных, которые накапливаются в статистических таблицах.
Имеет небольшой инсталляционный размер. Позволяет писать внутренние процедуры
на языках высокого уровня (C, PL/SQL). Позволяет удалять и переименовывать
атрибуты таблиц, что очень удобно для разработчика. Поддерживает инкапсуляцию
(т.е. выбранная ячейка в свою очередь может являеться записью).
Первоначально использовался Postgresql-6.1 с интерфейсом основанным
на библиотеке libpq.1. С переходом на Postgresql-6.3 , а
главное на интерфейсную библиотеку libpq.2, появилось возможность
использовать удаленную базу данных и определять пользователя схемы. В процессе
перехода с libpq.1 на libpq.2 был значительно переписан код
библиотеки db.c. В дальнейшем при переходе на 7 версию Postgresql
код библиотек eye работающих с СУБД не менялся. Стоит отметить,
что только версии Postgresql-7.x поддерживают ссылочную целостность.
Приложение: Схема базы данных.