powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Перепроектирование системы мониторинга о сбоях
7 сообщений из 7, страница 1 из 1
Перепроектирование системы мониторинга о сбоях
    #38926463
Nimua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Здравствуйте!

В БД есть таблица, куда накапливаются данные о мониторинге системы, ее анализирует программа и, в случае проблем, присылает сообщение "то-то и то-то сломалось". Таблица имеет следующую структуру:

№ п.п.Название поляТипОписание1id_tracking_parameterbigintСобственный идентификатор строки2row_statustinyintСтатус строки (0 – обычный статус)3dtsdatetimeШтамп времени модификации строки4id_partitiontinyintПризнак раздела размещения строки5Id_referencebigintСвязь со строкой группы параметров6group_typetinyintТип параметра (группа или ее элемент)7min_valueIntМинимально допустимое значение параметра8max_valueintМаксимально допустимое значение параметра9impact_factorintСобственный «вес» параметра10multiplication_factorintКоэффициент влияния параметра11id_unitbigintПоле связи. Связь со справочником единиц измерения 12procedure_nameNVarchar(256)Название процедуры ведущей расчет13parameter_nameNVarchar(256)Название параметра

Возникла необходимость указывать min_value, max_value разные в зависимости от времени суток.
Было предложено вот такое решение. Сделать таблицу, в которой можно перепрописать значения min_value и max_value в зависимости от времени, дня и вообще чего угодно. Вот структура такого справочника, в котором можно будет перепрописывать любое значение любого справочника системы.

№ п.п.Название поляТипОписание1id_profile_valuebigintСобственный идентификатор строки2row_statustinyintСтатус строки (0 – обычный статус)3dtsdatetimeШтамп времени модификации строки4id_partitiontinyintПризнак раздела размещения строки5id_ur_frs_linkbigintСвязь с универсальным справочником по названию таблицы FRS 6id_rowbigintСобственный идентификатор строки внешнего (перекрываемого) справочника7id_ur_param_groupbigintСвязь с универсальным справочником по названию группы параметров8id_ur_param_typebigintСвязь с универсальным справочником по типу параметра (индивидуальный элемент группы параметров)9param_value_mindecimalМинимальное значение параметра перекрытия10param_value_maxdecimalМаксимальное значение параметра перекрытия11value_override_mindecimalМинимальное значение величины перекрытия12value_override_maxdecimalМаксимальное значение величины перекрытия


Мне такое решение кажется избыточным, вот почему:

1. Решение увеличивает "неявность" системы
Настройка по сути делается в 2х таблицах, получается что нужно все время работать с view. Системой мониторинга управляют сами разработчики из БД. Интерфейса нет, то есть получается если вдруг кто-то забудет или не будет знать о возможности "перепрописать" значение в другом справочнике, то это возможные ошибки и сбои.

2. Решение сложное - вместо того чтобы вынести min_value, max_value в отдельную таблицу и там указывать время действия настройки, у нас эти величины задаются 2 раза, так более того еще и при задании во втором справочнике, данные из первого игнорируются.

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

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

Спасибо!
...
Рейтинг: 0 / 0
Перепроектирование системы мониторинга о сбоях
    #38926513
ScarferNV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Т.е. при одних и тех же общих данных, некоторые значения меняются с течением времени, и все эти изменения необходимо хранить, правильно я понимаю?
...
Рейтинг: 0 / 0
Перепроектирование системы мониторинга о сбоях
    #38926548
Nimua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Да!

Первая таблица используется как список параметров, которые мы собираем, например кол-во запросов от клиентов. Там нужно бить тревогу например, если запросов в течение нескольких часов совсем нет. Или другой параметр кол-во отказов за час - например max_value здесь 20, если больше 20то нужно отправлять оповещение, для этих целей первая таблица подходит полностью.
Но есть параметры - например кол-во продаж, которые очень сильно меняются в зависимости от времени. Если днем кол-во продаж меньше 100, то значит что-то не так. И надо прислать оповещение. А ночью оно и должно быть меньше 100 - это ок.
...
Рейтинг: 0 / 0
Перепроектирование системы мониторинга о сбоях
    #38926573
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Какой же фигнёй вы занимаетесь, Nimua, - просто поразительно. Отсутствие продаж - это сбой? Первого января народ массово просыхает - это тоже сбой? В номинации на самый идиотский вопрос года вы были бы минимум в призёрах.
...
Рейтинг: 0 / 0
Перепроектирование системы мониторинга о сбоях
    #38926906
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Nimua2. Решение сложное - вместо того чтобы вынести min_value, max_value в отдельную таблицу и там указывать время действия настройки, у нас эти величины задаются 2 раза, так более того еще и при задании во втором справочнике, данные из первого игнорируются.

И неправильное.
Граничные значения в любом случае должны храниться отдельно- даже для того, чтобы засунуть избыточно в вашу текущую таблицу.
Сделайте отдельную таблицу "Параметры" и вынесите туда название параметра, тип парметра, название процедуры (а лучше ссылку на процедуру), ед измерения, мин, макс. а тут уже просто ссылайтесь на нее.
В таблице значений не должно быть ничего кроме значений- вы сделали мега избыточную таблицу.

Про репликации что то я там слабо понял- какое это отношение имеет к проектированию БД. Если вам надо собирать с разных серверов эту инфу- ну и добавьте тогда id сервера на котором было зафиксировано измерение.
...
Рейтинг: 0 / 0
Перепроектирование системы мониторинга о сбоях
    #38926940
Serguei
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Какой же фигнёй вы занимаетесь, Nimua, - просто поразительно. Отсутствие продаж - это сбой? Первого января народ массово просыхает - это тоже сбой?

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

Так что спешить с выводами не надо.
...
Рейтинг: 0 / 0
Перепроектирование системы мониторинга о сбоях
    #38927044
Nimua
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Serguei,
Спасибо Вам большое за ответ!

Так и сделаем.
...
Рейтинг: 0 / 0
7 сообщений из 7, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Перепроектирование системы мониторинга о сбоях
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]