Grow-zabbix-node: Наращивание эталонной конфигурации: различия между версиями

Материал из ALT Linux Wiki
(Наращивание эталонной конфигурации)
 
Нет описания правки
Строка 123: Строка 123:
Важным отличием получаемого таким образом конфигурационного пакета от большинства пакетов с рабочими конфигурациями является то, что при его [[#Полная замена конфигурации локального центра мониторинга|применении]] нода не переводится в рабочий режим (идентификаторы определённых в БД объектов остаются такими же, какими они определены в базовом дампе).
Важным отличием получаемого таким образом конфигурационного пакета от большинства пакетов с рабочими конфигурациями является то, что при его [[#Полная замена конфигурации локального центра мониторинга|применении]] нода не переводится в рабочий режим (идентификаторы определённых в БД объектов остаются такими же, какими они определены в базовом дампе).


[[Категория: ZABBIX]]
[[Категория: Инструментарий для развёртывания Zabbix-ноды]]
[[Категория: Инструментарий для развёртывания Zabbix-ноды]]
[[Категория: Admin]]
[[Категория: Руководства]]
[[Категория: Руководства]]
[[category:ZABBIX]
{{Category navigation|title=Zabbix|category=ZABBIX|sortkey={{SUBPAGENAME}}}}

Версия от 06:30, 1 июля 2015

Наращивание эталонной конфигурации

В данном разделе рассказывается как с помощью инструмента 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.

Важным отличием получаемого таким образом конфигурационного пакета от большинства пакетов с рабочими конфигурациями является то, что при его применении нода не переводится в рабочий режим (идентификаторы определённых в БД объектов остаются такими же, какими они определены в базовом дампе). [[category:ZABBIX]