Grow-zabbix-node: Наращивание эталонной конфигурации: различия между версиями
Нет описания правки |
Нет описания правки |
||
Строка 125: | Строка 125: | ||
[[Категория: Инструментарий для развёртывания Zabbix-ноды]] | [[Категория: Инструментарий для развёртывания Zabbix-ноды]] | ||
[[category:ZABBIX]] | [[category:ZABBIX]] | ||
{{Category navigation|title=Zabbix|category= | {{Category navigation|title=Инструментарий для развёртывания Zabbix-ноды|category=Инструментарий для развёртывания Zabbix-ноды|sortkey={{SUBPAGENAME}}}} |
Версия от 12:31, 22 октября 2020
Наращивание эталонной конфигурации
В данном разделе рассказывается как с помощью инструмента grow-zabbix-node
подготовить конфигурационный пакет для развёртывания ноды, участвующей в распределённом мониторинге. Конфигурационный пакет подготавливается на основании дампа БД некоторой базовой конфигурации и конфигурационного файла. Используя информацию, содержащуюся в конфигурационном файле, базовая конфигурация «наращивается». Отсюда и происходит название инструмента.
Формат конфигурационного файла
Рассмотрим формат конфигурационного файла.
Конфигурационный файл должен содержать одну секцию <region> … </region>
, определяющую непосредственно параметры локальной ноды и, относительно неё, параметры относящихся к ней объектов. Основные параметры локальной ноды определяются следующим образом:
<region> <id>идентификатор ноды</id> <name>имя ноды</name> <type>имя шаблона</type> <group>имена групп через запятую</group> <ipaddr>IP адрес ноды</ipaddr> <timezone>смещение часового пояса, в часах</timezone>
Шаблон для локальной ноды должен выбираться с учётом того, что нода будет наблюдаться «изнутри».
Имена шаблонов, нод и узлов должны состоять только из символов ASCII (7-bit). Имена групп могут быть произвольными. Если группа не определена в базовой конфигурации, то она будет добавлена.
Идентификатор ноды в общем случае должен быть больше 0. В противном случае нода не будет настроена для работы в рамках распределённого мониторинга. При работе в распределённой системе, идентификатор каждой ноды должен быть уникальным в рамках этой системы.
Если узел должен быть добавлен на сигнальную карту, необходимо указать его координаты:
<pos> <lat>широта ноды</lat> <lon>долгота ноды</lon> </pos>
И определить параметры самой карты:
<map> <upper> <lat>широта верхнего левого угла карты</lat> <lon>долгота верхнего левого угла карты</lon> </upper> <lower> <lat>широта нижнего правого угла карты</lat> <lon>долгота нижнего правого угла карты</lon> </lower> <width>ширина изображения карты, в пикселях</width> <height>ширина изображения карты, в пикселях</height> <image>имя файла изображения карты</image> </map>
Для одной ноды может быть определена только одна карта.
В том случае, если нода не является самой старшей в конфигурации, то следует указать параметры мастер-ноды, т.е. ноды, на которую необходимо отправлять собираемые данные:
<supregion> <id>идентификатор мастер-ноды</id> <name>имя узла мастер-ноды</name> <timezone>смещение часового пояса мастер-ноды, в часах</timezone> <ipaddr>IP адрес мастер-ноды</ipaddr> </supregion>
Определения дочерних нод перечисляются в отдельных секциях <subregions> … </subregions>
, которых может быть несколько. Для каждой секции может быть определёно имя шаблона ноды и имена групп ноды, используемые по умолчанию:
<subregions type="имя шаблона дочерних нод" group="имена групп дочерних нод через запятую"> <region> <id>идентификатор дочерней ноды</id> <name>имя дочерней ноды</name> <ipaddr>IP адрес дочерней ноды</ipaddr> <timezone>смещение часового пояса дочерней ноды, в часах</timezone> <pos> <lat>широта дочерней ноды</lat> <lon>долгота дочерней ноды</lon> </pos> </region> … </subregions>
Географические координаты каждой дочерней ноды определяют её положение на карте, определённой для локальной ноды. Аналогично параметрам локальной ноды, имя шаблона и имена групп могут быть переопределены для каждой ноды в отдельности.
Шаблон для дочерних нод должен выбираться с учётом того, что каждая дочерняя нода будет наблюдаться «снаружи». Для каждой определяемой в конфигурации дочерней ноды автоматически регистрируется узел.
Информация обо всех наблюдаемых узлах, которые должны быть включены в конфигурацию постоянно, определяется в отдельных секциях <hosts> … </hosts>
, которых может быть несколько. Для каждой секции определяются имя шаблона узла и имена групп узла, используемые по умолчанию:
<hosts type="имя шаблона наблюдаемых узлов" group="имена групп наблюдаемых узлов через запятую"> <host> <name>имя наблюдаемого узла</name> <ipaddr>IP адрес наблюдаемого узла</ipaddr> </host> … </hosts>
На этом конфигурационный файл завершается:
</region>
Кроме приведённого выше формата, конфигурационный файл может состоять из единственной пустой секции <template />
. Такой конфигурационный файл используется для «нулевого наращивания» базовой конфигурации, т.е. для создания конфигурационного пакета, возвращающего ноду к базовому состоянию.
Примеры конфигурационных файлов предоставляются пакетом grow-zabbix-node-examples
.
Работа с инструментом
Создание конфигурационного пакета
Типичный вариант работы с программой grow-zabbix-node
заключается в дополнении базовой конфигурации, представленной в виде дампа БД, информацией, определённой в конфигурационном файле:
grow-zabbix-node -b имя-файла-дампа -o базовое-имя-выходного-фала имя-конфигурационного-файла
Конфигурационный пакет будет запакован с использованием tar cz
и иметь суффикс .tar.gz
. По умолчанию выходной дамп формируется для СУБД MySQL (базовый дамп в этом случае тоже должен быть совместим с MySQL).
В качестве базового дампа может быть использован дамп, поставляемый вместе с ПО Zabbix или один из дампов, предоставляемых пакетами grow-zabbix-node-altlinux-*-dump-*
.
Сведения обо всех опциях и аргументах можно получить введя grow-zabbix-node --help
или man grow-zabbix-node
.
Опорные файлы конфигурации ПО
Помимо содержимого БД, конфигурация ноды определяется настройкой сервера мониторинга, агента сбора данных и пользовательского административного интерфейса. Пакет grow-zabbix-node
предоставляет конфигурационные файлы для настройки этих подсистем, которые конфигурационная программа использует в качестве образцов, изменяя в них лишь ключевые параметры. В случае необходимости, имена используемых в качестве образцов конфигурационных файлов могут быть переопределены:
-z SRVCONF, --server-reference-config=SRVCONF
- имя конфигурационного файла сервера мониторинга, принимаемого за образец;
-f FNTCONF, --frontend-reference-config=FNTCONF
- имя конфигурационного файла подсистемы пользовательского административного интерфейса, принимаемого за образец;
-a ACONF, --agent-reference-config=ACONF
- имя конфигурационного файла агента мониторинга, принимаемого за образец.
Создание конфигурационного пакета для базовой конфигурации
Часто, не удаётся создать хорошую базовую конфигурацию с первого раза. Вернуть ноду к состоянию, определяемому базовым дампом и продолжить работу над его совершенствованием позволит базовый конфигурационный пакет. Создать его можно на основе специального конфигурационного файла /usr/share/gwor-zabbix-node/template.xml
.
Важным отличием получаемого таким образом конфигурационного пакета от большинства пакетов с рабочими конфигурациями является то, что при его применении нода не переводится в рабочий режим (идентификаторы определённых в БД объектов остаются такими же, какими они определены в базовом дампе).