Глава 7. Управление шаблонами

Шаблон хоста очень похож на обычный хост. Оба являются коллецией элементов, механизмов запуска (триггеров), графиков, экранов и правил обнаружения низкого уровня. Оба требуют уникального имени, как и любая другая сущность в Zabbix. Оба могут относиться к одной или более группам. Критически важной разницей является то, что хост имеет одно или более средств для контакта, следовательно сервер Zabbix реально может брать с него измерения, как это проиллюстрировано в Главе 4, Сбор данных. Это может быть один или более IP адрес, или имена хоста, которые представляют интерфейсы агента, или же адреса или имена SNMP, JMX и IPMI. Таким образом, хост является объектом, у которого сервер Zabbix может запрашивать информацию или от которого он может ожидать данные. Шаблон, с другой стороны, не имеет никакого интерфейса, поэтому сервер Zabbix никогда не может осуществить попытку проверить является ли некий шаблон доступным или у него самые последние измерения элемента.

Создание шаблона очень прямолинейное и не стоит на нём особенно останавливаться. Вы перемещаетесь в закладку Configuration | Templates и кликаете по своей кнопке Create template. Появляется форма создания необходимого шаблона, причём она состоит из трёх различных закладок. Позже в этой главе мы рассмотрим закладку Linked templates и закладку Macros, поскольку они не являются существенными при создании базового шаблона. Фактически, единственным важным элементом для базового шаблона является его имя, однако будет полезным также назначить его в одну или более групп чтобы он был более прост при обнаружении в прочих разделах веб интерфейса. Если вы уже настраивали хосты, вы также могли настраивать для этих хостов и конкретный интересный вам шаблон напрямую из закладки создания шаблона. В противном случае вам необходимо перейти в закладку настройки Hosts и настравивать шаблоны в ней. Когда вы это сделаете, шаблон будет создан и доступен из перечня шаблонов, однако он всё ещё будет пустым объектом. Вашим следующим заданием будет создание элементов, запускающего механизма (trigger), графиков, экранов и правил обнаружения шаблонов, если таковые имеются.

Добавление элемента или любой другой сущности к шаблону практически идентично такой же операции выполняемой на обычном хосте. В особенности это верно для элементов. Как вы уже знаете, ключи элемента являются основными строительными блоками конвейера мониторинга Zabbix, и у вас нет необходимости определять какой- либо вид адреса или интерфейса при создании их, так как Zabbix получит данный вид информации от необходимого хоста, которому нзначается данный элемент. Это означает, что при создании элементов для шаблона вы в сущности создаёте элемнты для некоего идеального хоста, которые позже будут применены к реальным хостам, когда вы свяжете этот шаблон с конкретными хостами, для которых вы хотите осуществлять мониторинг.

Это также применимо и к прочим типам сущностей, однако так как они всегда относятся к одному или более элементов, вам необходимо удостовериться, что вы выбрали именно те элементы, которые относятся к правильному шаблону, а не к обычному хосту:

Это может казаться очевидным, однако далеко не просто выбрать содержащиеся в вашем шаблоне Items, Graphs или Screens используя связи в врехней части окна.

Основная разница между сущностями шаблона и сущностями хоста, и в особенности, она проявляется когда дело доходит до механизмов запуска (триггеров) и заключается она в том, что для сущностей шаблона чрезвычайно полезны макросы чтобы сделать более выразительными и адаптивными имена или параметры триггера или графика.

Мы можем просуммировать все сущности, которые могут быть собраны в группы в шаблонах следующим образом:

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

Как вы уже убедились в Главе 6, Управление сигналами тревоги, макросы очень полезны чтобы делать сообщения достаточно общими, чтобы применять их к широкому диапазону событий. Это будет уже заданием сервера Zabbix подставлять все значения макроса в некое сообщение с реальным содержимым на основе специфики обрабатываемого им события. Так как сообщение действия фактически является шаблоном, который должен быть применён к определённому событию, легко увидеть как та же самая концепция является важной для эффективности шаблонов хоста. Некоторые изменения состоят в контексте; в то время как событие имеет достаточно богатый контекст, так как оно может относиься к механизму запуска и одному или более различных элементов или хостов, контекст простого, обычного хоста, как признаётся всеми, более ограничен. Это отражается в общем числе доступных макросов, поскольку их не очень много:

Имя макроса	Макрос транслируется в	Замечания
{HOST.CONN}	Имя хоста или IP адрес этого хоста	Это будет идентично {HOST.IP} или {HOST.DNS} в зависимости от опции Connect to в форме настройки данного хоста.
{HOST.DNS}	Имя вашего хоста	Должно соответствовать полностью определённому доменному имени как оно определяется сервером DNS данного домена.
{HOST.DNS}	Имя вашего хоста	Должно соответствовать полностью определённому доменному имени как оно определяется сервером DNS данного домена.
{HOST.HOST}	Имя вашего хоста, как оно определено в Zabbix	Это идентификатор вашего главного хоста. Он должен быть уникальным для конкретного сервера Zabbix. При применении агента то же самое имя должно присутствовать в настройке этого хоста для данного агента.
{HOST.IP}	IP адрес этого хоста	Хост может иметь более одного IP адреса. Вы можете ссылаться на них, применяя {HOST.IP1}, {HOST.IP2} и так далее, вплоть до {HOST.IP9}.
{HOST.NAME}	Отображаемое имя хоста, как оно определено в Zabbix	Это будет орпеделённое имя, видимое в списках, картах, экранах и тому подобном.

Чтобы лучше прояснить разницу между различными макросами {HOST.*}, давайте рассмотрим пример настройки хоста:

В данном случае, {HOST.HOST} будет разрешено в ZBX Main, {HOST.NAME} в Main Zabbix Server, {HOST.IP} в 127.0.0.1, а {HOST.DNS} в zabbix.example.com. Наконец, так как опция Connect to установлена на IP, {HOST.CONN} будет также разрешён в 127.0.0.1.

Наиболее очевидное применение таких макросов состоит в создании имён механизмов запуска (trigger) и графиков более динамичными и приспособливаемыми к нашим реальным хостам, к которым они будут применяться. Так как имя графика отображается в качестве заголовка при отображении такого графика, жизненно важно делать отличие между различными графиками одного и того же типа, относящимся к различным хостам, в особенности когда они отображаются вместе на одном экране, как это объяснялось в Главе 5, Визуализация данных.

Менее очевидно применение таких макросов внутри определения ключа элемента. Мы вкраце обсуждали это в Главе 4, Сбор данных, и вы встретитесь с этим в следующей главе, поэтому мы не хотим сильно вдаваться в подробности этого в данном месте. Чего было бы достаточным сказать об этом с точки зрения создания элемента, так это то, что всё что вам нужно знать о внешнем сценарии это его имя и все параметры, которые вам могут понадобиться чтобы правильно выполнить его.

Так как внешние сценарии, исходя из своей природы, не используют совместно с остальным Zabbix никакую информацию, отличную от своих аргументов, которые им передаются, а также возвращаемых ими значений, часто будет важным включать IP адрес хоста или его имя в качестве одного из аргументов. Это будет гарантировать, что такой сценарий будет соединён с правильным хостом и собирать верные данные. Отдельный, хорошо настроенный сценарий может исполнять одну и ту же операцию на множестве различных хостов благодаря шаблонам систем и макросом, таким как {HOST.CONN}, {HOST.IP} и тому подобным.

В качестве примера возьмём сценарий, который проверяет бедет ли определённое приложение работающим с применением индивидуального протокола. Вы можете иметь внешний сценарий, скажем, app_check.sh, который примет имя или IP адрес хоста в качестве аргумента, соединится с ним с применением протокола приложения, и вернёт 1 если оно работает и все хорошо, и 0 в случае провала проверки. Ваш ключ шаблона элемента мог бы выглядеть аналогично следующему снимку экрана:

В этих случаях, применение макроса в качестве вашего аргумента к ключу такого элемента является единственным способом выполнить внешнюю проверку для некоторой части шаблона и будет полезным для любого обычного хоста.

Другой пример будет состоять в связке хостов Zabbix которые не представлены машинами с обычными операционными системами, физическими или виртуальными, а только отдельными приложениями или экземплярами базы данных. В таком сценарии все хосты приложения должны совместно применять одни и те же соединения и интерфейсы - те что реальный сервер предоставляет приложениям - и они будут связаны с шаблоном, содержащим только относящиеся к уровню приложения (или уровню базы данных) измерения элементов. Чтобы сохранять вещи простыми, давайте скажем что у вас имеется сервер приложений (Альфа), размещающий три различных приложения:

Для каждого из этих приложений вам в общем и целом интересно получение следующих замеров:

Опять же, ради упрощения, скажем, что у вас имеется куча внешних сценариев которые, получив IP адрес и имя приложения, могут замерить в точности предписанную метрику. Ключ внешнего сценария хотелось бы иметь легко читаемым и самообъясняющим, однако все они могут быть одинаково применены к значениям консоли JMX, счётчиками производительности Windows, запросам баз данных, а также любым остальным видам элементов.

Один из вариантов осуществления мониторинга такой настройки состоит в создании только одного хоста, Альфа и, в дополнение к обычным элементам мониторинга ОС и аппаратных средств, выделяется некоторое число элементов измерению приложения, что повторяется для каждого их них. Это, несомненно, может работать, однако если вам необходимо добавить новое приложение, вам необходимо создавать свои элементы, механизмы запуска и графики, связанные с ним, даже если они отличаются от остальных только имененм приложения.

Так как это единственное отличие в остальном идентичных собраниях сущностей, более гибким решением было бы расщеплять мониторинг каждого приложения на различные хосты и применять общий шаблон.

Вместо создания множества аналогичных элементов, триггеров и тому подобного для конкретного хоста, Альфа, вы бы создали индивидуальный шаблон приложения и заполнили его элементами, которые выглядели бы аналогично следующему снимку экрана:

Затем вы можете создать по одному хосту для каждого приложения, причём с IP адресом Альфа в качестве интерфейса соединения, и с именем приложения в качестве имени хоста. Привязывая такой шаблон вы просто создали бы такие хосты, которые дали бы вам те же основные результаты, как ранее, однако намного более гибкие; добавление подлежащего мониторингу приложения теперь просто является предметом создания хоста и связыванием его с правильным шаблоном. Если вы переместите некое приложение с одного сервера на другой, вам просто будет необходимо обновить его IP адрес. Если вы поместите все эти хосты приложений в отдельную группу, вы даже сможете предоставить доступ к наблюдаемым ими данным определённой группе пользователей без необходимости предоставлять им доступ к данным мониторинга данного приложения. К тому же, это происходит без присказки что добавление, удаление или изменение сущности в шаблоне применяется немедленно ко всем объектам мониторинга.

 

Определяемые пользователем макросы

Специальным классом шаблонов и макросов уровня хоста являются определяемые пользователем. Вы можете настроить их в закладке Macros любого создания и административной формы хоста или шаблона. Они достаточно просты и они предоставляют только возможность трансляции из индивидуальной метки в предварительно определённое, фиксированное значение. Снимок экрана внизу отображает это:

При применении в шаблоне они доказывают свою достаточную полезность в определении общих порогов для запускающих механизмов (triggers), поэтому если у вас есть потребность в модификации кучи триггеров тайм- аута, вы можете просто изменить свой макрос {$NODATA} вместо изменения каждого отдельного триггера, который применяет его. Определяемые пользователем макросы могут применяться везде где могут использоваться встроенные макросы.

Такая польза даже ещё увеличивается, при применении нами в соединении со встроенными шаблонами, как мы вскоре убедимся.

Наиболее распространённые варианты применения глобальных макросов и макросов хоста таковы:

Практическим примером использования макроса может быть применение макроса уровня хоста в ключах вашего элемента, например, Status of SSH daemon:

net.tcp.service[ssh,,{$SSH_PORT}]
 	   

Этот элемент может быть назначен множеству хостов один раз при определении вами на уровне хоста текущего значения {$SSH_PORT}. Выполнив это, вы обобщаете индивидуальный элемент в котором {$SSH_PORT} может изменяться от сервера к серверу; это же может быть также выполнено для службы HTTP, помимо всего прочего.

Zabbix предоставляет хорошую и полезную функциональность импорта/ экспорта. Объекты, которые могут быть экспортированы/ импортированы таковы:

Описываемую функциональность экспорта достаточно просто понять; тем не менее, функция импорта была расширена. Следующий снимок экрана улавливает это обсуждение:

Раздел импорта подразделяется на три колонки; первая, Update existing, будет всё равно осуществлять обновление, даже если элемент уже определён. Эта функция является фундаментальной, если вы хотите обновлять элемент или просто добавить пропущенные объекты. Вторая колонка, Create new, достаточно проста для понимания, так как она разрешит только новый элемент. Третья и последняя колонка была добавлена в Zabbix начиная с версии 2.4, Delete missing, если она выбрана, она удалит все ваши элементы которые не были экспортированы если они присутствуют в нашей настройке.

Как вы можете видеть, объекты шаблона хорошо определены, так что мы можем определять для экспорта только Template screens, Template linkage и/или Templates.

Чтобы связать некий шаблон с каким- нибудь хостом, мы можем либо выбрать конкретный хост, который вы хотите связать с формой настройки определённого шаблона, как мы это видели в разделе Создание шаблонов, или же мы можем выбрать определённый шаблон необходимый вам для какого- либо хоста в форме настройки этого хоста перейдя в закладку Template.

Когда связывание произведено, хост унаследует все сущности данного шаблона. Существовавшие до этого сущности с теми жа самыми именами будут перезаписаны, однако сущности не содержащиеся в этом шаблоне останутся в прежнем виде и не будут затронуты никоим образом при операции связывания.

Все сущности будут поддерживать свои первоначальные имена шаблона при отображении раздела настройки в нашем веб интерфейсе даже при просмотре из страницы настройки хоста. Однако, это не означает что изменяя их в закладке настройки шаблона будет тем же самым, что и изменение их в закладке настройки связанного хоста.

Если вы изменяете сущность (элемент, триггер, график и тому подобное) в закладке настройки шаблона, такое изменение будет применено немедленно ко всем связанным хостам. Сдругой стороны, если вы изменяете сущность некоторого шаблона из закладки настройки определённого хоста, такие изменения будут применены только к этому хосту, а не к уровню шаблона. Хотя это и может быть полезным в отношении неких особенных случаев для отличного от обычного хоста, это также может создать некоторую путаницу если вы выполняете множество локальных изменений которые могут стать трудными для отслеживания. Более того, не все стороны сущности шаблона могут быть изменены на уровне хоста. Вы можете изменять частоту некоего элемента, например, однако не его ключ.

Отвязывание какого- либо шаблона от хоста не уничтожает его сущности пока вы не отцепите и не очистите его. Будьте аккуратны с данной операцией, так как все исторические данные и обобщённые динамики (trends) этих элементов станут недоступными. Если вы собрали какие- либо востребованные данные, скорее всего лучше просто отцепить некий шаблон от хоста, а затем запретить все неиспользуемые элементы и триггеры при сохранении всех их исторических данных.

Также как вы можете присоединить некий шаблон к какому- либо хосту, вы также можете присоединить некий шаблон к другому шаблону. Такая операция идентична связыванию шаблона с каким- либо хостом; если вы перейдёте в закладку Linked templates в форме настройки некоторого шаблона и выберите конкретный шаблон, который вы хотите присоединить.

Хотя это и может показаться неуклюжей операцией, она может показать достаточную пользу в двух случаях.

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

В качестве конкретного примера, давайте допустим, что у вас имеется шаблон Template Macros, содержащий макрос пользователя {$PFREE} со значением 5, помимо всего прочего. Вы можете применить этот макрос для представления объема свободного лискового пространства в процентах для проверки свободной доступной памяти, или, другого такого порогового значения. Такой шаблон может быть связан как с шаблоном Template OS Linux, так и с шаблоном Template OS Windows, а макрос {$PFREE} применяется в запускающих механизмах (triggers) этих шаблонов. В дальнейшем, если вам даже понадобится изменить значение по умолчанию вашего процентного соотношения свободного дискового пространства для его проверки, вам нужно будет всего лишь изменить значение по умолчанию вашего перваначального наблона Template Macros, и такое обновлённое значение будет распространено по всем связанным шаблонам для мониторинга хостов.

Во втором, до некторой степени ограниченном, но всё ещё полезном, вариант применения встроенных шаблонов состоит в расширении наследования между макросами на все прочие сущности. Это может стать преимуществом когда вам необходим общий набор свойств в определённом технологическом уровне, однако различные применения на прочих уровнях. Давайте возьмём, например, вариант при котором нам необходимо большое число вертикально идентичных серверов, которые размещают только пару версий операционных систем (Linux и Windows для простоты обсуждения), однако они по очереди выполняют много различных специализированных функций: базы данных, файлового сервера, веб сервера и тому подобного.

Несомненно, вы можете создать несколько монолитных шаблонов со всеми такими элементами, которые вам нужны для любого данного сервера, включая проверки аппаратуры, проверки ОС, а также особенные для приложения проверки. Они последовательно будут унаследованы специфичными для приложений шаблонами, которые будут иметь имена подобные Linux Apache Template или Win Exchange Template. Эти шаблоны будут иметь все свои элементы, механизмы запуска и графики, особенные для их приложений, для которых они предназначены выполнять мониторинг помимо всех своих специфичных для ОС проверок, которые уни наследуют из шаблонов своего аппаратного уровня. Это означает, что при создании хоста, вам всё ещё необходимо связыват его с отдельным шаблоном, однако вы также будете иметь большую гибкость при создании новых шаблонов и их настройке или изменению существующих только в одном месте, а также отслеживании распространения изменений по всем своим связанным шаблонами цепочкам. Это также означает максимальную общность, и в то же время сопровождении возможности выполнять специфичную для хоста индивидуализацию, если таковая понадобится.

Другой способ выполнения шаблонов модульными состоит в создании определённых шаблонов для любого заданного технологического уровня и производить их, но при этом не связывать, в некоторой иерархии на уровне вашего шаблона. Вместо этого вы можете связать их - столько сколько пожелаете - напрямую с требующимся для мониторинга хостом до тех пор, пока не возникнет какого- либо конфликта или перекрытия имён элементов или ключей. Как и в предыдущем сценарии, хост A может иметь связанными некий шаблон проверок IPMI, шаблон для ОС Linux, а также шаблон какого- то сервера Apache, в то время как хост B может иметь некий шаблон проверок IPMI и какой- то шаблон OC Linux, однако далее иметь шаблон некоторой базы данных PostgreSQL.

Окончательный результат практически тот же самый, как и описанное ранее решение встроенных шаблонов, следовательно зачем кто- то должен принимать ваш выбор? В основном это зависит от предпочтений, однако возможным критерием может быть то, что если у вас имеется относительно низкое число шаблонов низкого уровня и хорошая согласованность в вашем оборудовании, ОС и технологиях настройки, тогда встраиваемое решение может быть более простым в управлении. Вы будете только должны связывать свои шаблоны один раз, а затем использвовать их на большом числе хостов. Такой подход также хорошо работает при функциональности обнаружения хоста, так как он сохраняет вещи простыми при связывании шаблонов с хостами. Если же, с другой стороны, у вас имеется огромное количество шаблонов низкого уровня и огромная изменчивость в ваших технологиях настройки и ландшафта, вы можете точно также выбирать нужные вам при создании своих хостов шаблоны. Фактически, любая предварительная настройка могла бы оказаться слишко жёсткой чтобы оказаться полезной. Такой подход хорошо работает если вы хотите всегда обдумывать то, как вы создаёте и настраиваете свои хосты, а также требуется большой объём локальной персонализации, которая сделала бы любое энергичное наследование свойств спорным вопросом.