Всем доброго времени суток! Есть такой вопрос, на который я не могу найти ответ в документации. Началось все с того, что база начинает пухнуть с добавлением узлов и вообще занимает много места при своих количествах наблюдаемых узлов. Начал я с перебора элементов данных, а именно уменьшать частоту опроса эд, которые не нужны так часто и не участвуют в триггерах и нужны для отчетов статистики. Уменьшил срок хранения трендов и истории для всех эд сразу. Уменьшать срок хранения трендов для отдельных эд, я не могу, так как у меня postgresql timescaledb и housekeeper удаляет данные чанками, то есть срок хранения должен быть для всех эд одинаковым, иначе housekeeper сходит с ума и не может удалить чанки, в итоге база пухнет на глазах. Далее я подумал включить для многих эд троттлинг, у которых нет в триггерах значений типа брать два последних значений. Но вот мне стало интересно, если, например, у хоста есть эд - серийный номер (таких эд много, которые очень редко меняются), который не меняется в течении всей жизни хоста. Что будет при включенном троттлинге для данного эд, если он никогда не менялся и наступил момент очистки данных housekeeper? У меня не будет серийного номера? Или при удалении из базы, он запросится заново? Так же, если есть советы по уменьшению размеры базы буду благодарен за советы.
-
-
Пока решил не рисковать, выставил троттлинг по времени, период для каждого эд разный, но меньше чем хранение трендов и истории. Таким образом я точно буду иметь нужную информацию в базе для отчетов. Так же к оптимизации размера базы, отключил хранение истории и трендов у эд, которые выступают как родитель для зависимых эд. Часто это json и он нигде потом не используется после извлечения данных для зависимых эд, а текстовая информация весит много. -
Еще много эд перевел в правила обнаружения. А то была ситуация, что у железки и нет такого параметра, или она не может корректно ответить на него. В итоге получалось, что ответ приходил некорректный или отрицательный, но хранился в базе, никакой пользы от него нет.Comment
-
Хинт - элементы которые редко меняются и нужны только для учета удобно пихать в инвентарные данные. Серийники всякие или номера лицензий.....
И если не отслеживать факт изменения - то можно вообще не хранить в базе.
Если отслеживать - тротлинг с периодическим контролем.Comment
-
Все же изменения бывают и информация нужна. У нас в компании много чего строится на именах железок, например, на офисе поменяли маршрутизатор, имя должно остаться тоже самое, которое и было, так как оно прямо говорит, что эта железяка оттуда-то, а данные по ней должны измениться. Попробую рассмотреть тему инвентарных данных. Давно обходил эту тему стороной.
Comment
-
Штатного метода расширения списка полей или их переименования нет. Всё прошито в коде.
Но самих полей много - используйте любое свободное.
Поменять наименование инвентарного поля можно изменив файл локализации /путь_к_фронтенду/locale/ru/LC_MESSAGES/frontend.po и сделав из него frontend.mo
(make_mo.sh в помощь)
Comment
Comment