Глава 3. Мониторинг с помощью Агентов Zabbix и Базовые протоколы

Ранее мы устанавливали своего агента Zabbix на том же самом хосте и выполняли мониторинг для него единственный элемент. Настало время расшириться и посмотреть как работает связь между хостами.

Для продолжения установите агента Zabbix на другом хосте. Самый простой способ может быть установкой из пакетов распространения - либо вы можете выбрать его компиляцию из исходного кода. Если вы устанавливаете из пакетов в системах на основе систем Red Hat Enterprise Linux (RHEL)/ Debian, обратитесь к Главе 1, Приступая к работе с Zabbix. Потенциально названием пакета агента может являться zabbix-agent.

Компиляция такого агента только из исходного кода делается аналогично тому как все компоненты включались для компиляции в Главе 1, Приступая к работе с Zabbix. Вместо полной строки configure мы будем применять на этот раз единственный флаг:

$ ./configure --enable-agent
		

Настройка должна завершиться успешно и важны такие итоговые строки:

Enable server:         no
Enable proxy:          no
Enable agent:          yes
		

Если полученный вами вывод соответствует только что приведённому, продолжите вызовом такой команды:

$ make install
		

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

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

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

После установки соответствующего агента самое время запустить его. Как это сделать целиком определяется вашим методом установки - и если вы выполняли установку из соответствующих пакетов, это также зависит и от самого дистрибутива. За примерами того как запускать вашего агента отсылаем к Главе 1, Приступая к работе с Zabbix. В качестве быстрого напоминания, если вы устанавливали из пакетов в системе на основе RHEL/Debian, ваш агент вероятно можно запустить как- то так:

# systemctl start zabbix-agentd
		

Если вы устанавливали из исходного кода, напрямую исполните свой исполняемый файл:

# <path>/zabbix_agentd
		

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

Вот несколько советов по заполнению данной формы:

По завершению кликните по кнопке Add в самом низу.

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

Чтобы проще запомнить пассивный или активный в Zabbix лучше рассуждать с точки зрения самого агента. Если к серверу подключается сам агент, он является активным. Если это не так - он пассивный:

Давайте создадим другой пассивный элемент для проверки своего удалённого хоста:

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

Но что произошло с тем самым ,,80 добавленным к названию этой службы? Кликните по кнопке Select следующей за полем Key. Это откроет некое окно с отличным списком ключей для выбора из него совместно с кратким описанием каждого из них:

Ниспадающее меню Type в правом верхнем углу позволит вам переключаться между некоторыми типами элементов - мы обсудим все прочие типы позднее. А сейчас отыщите в этом списке net.tcp.service и просмотрите его описание. Здесь следует изучить два момента:

Данный ключ, net.tcp.service слегка особенный: он пытается проверить что соответствующая служба отвечает стандартным манером, что означает, что такая служба явно должна поддерживаться. На момент написания Zabbix поддерживал такие службы для ключа net.tcp.service:

Служба TCP является слегка особенной своим собственным образом. В то время как все прочие осуществляют соответствующие службе проверки, TCP в действительности не является службой; это просто проверка наличия подключения TCP. Он ближе к некому ключу, который мы рассматривали парой строк выше в своём списке элементов, net.tcp.service. Как пишет его описание, этот пункт пытается открыть некое подключение TCP по любому произвольному порту без выполнения каких- либо относящихся к службе проверок относительно возвращаемого значения. Если вы попытаетесь применить некую произвольную строку, которая не поддерживается, вы просто получите сообщение об ошибке, которое проинформирует, что такой ключ элемента не поддерживается.

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

Теперь мы можем проследовать в Monitoring | Latest data и дождаться здесь появления необходимых значений, но это было бы никуда не годным. Вместо этого после пары минут вам следует посетить Configuration | Hosts. В зависимости от настроек вашей сетевой среды, вы можете увидеть некий красный маркер ZBX вслед за этим хостом. Эта иконка представляет ошибки, которые произошли при попытке выборки данных с некоторого пассивного агента Zabbix.

Чтобы посмотреть реальные сообщения об ошибках, переместите курсор мыши на эту иконку и вам откроется контекстное меню. Кликните по соответствующей иконке ошибки и это превратит данное всплывающее меню в постоянно действующее и позволит вам скопировать данное сообщение об ошибке:

Если вы обнаружите некое сообщение подобное Get value from agent failed: cannot connect to [[192.168.1.100]:10050]: [111] Connection refused (скорее всего с другим IP адресом), это означает, что ваш сервер Zabbix не смог подключиться к такому порту демона агента. Это может происходить по целому ряду причин, наиболее частой из них является межсетевой экран - либо некий сетевой между вашими сервером Zabbix и удалённым хостом, либо некий локальный в самом удалённом хосте. Убедитесь что разрешено подключение с вашего сервера Zabbix к подлежащей отслеживанию машине по порту 10050. Если вы наблюдаете нечто подобное тому что было отображено в нашем предыдущем снимке экрана с no route to host, тогда вы скорее всего допустили ошибку при настройке и ваш сервер Zabbix не может подключиться к данному хосту с его агентом Zabbix.

Если вы всё сделали верно (или если у вас нет некого межсетевого экрана, блокирующего это подключение), вы могли бы снова пройти в Monitoring | Latest data - только это опять же было бы бессмысленным. Чтобы посмотреть почему освежите список хостов. Вскорости вы должны обнаружить, что иконка состояния этого агента Zabbix вновь окрасится красным, вам следует поместить на неё курсор мыши чтобы обнаружить другое сообщение об ошибке, Received empty response from Zabbix Agent at [192.168.1.100], что предполагает, что ваш агент сбросил данное подключение по причине полномочий доступа. Теперь всё иначе. О каких полномочиях идёт речь и почему всё работало для нашего первого хоста?

Со своего сервера Zabbix выполните следующее (замените IP адрес правильным для вашего хоста):

$ telnet 192.168.1.100 10050
		

Замените IP адрес адресом своего удалённого хоста. Вы должны увидеть следующий вывод и ваше подключение должно немедленно закрыться:

Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
Connection closed by foreign host.
		

Теперь попробуйте то же самое в отношении localhost:

$ telnet localhost 10050
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'
		

Обратите внимание, что на этот раз соединение не закрывается сразу, следовательно, существует отличие. Данное подключение скорее всего будет закрыто слегка позднее - тремя секундами позже, что может быть весьма особым. Если это не произойдёт по какой- то причине, нажмите, как и предписано, Ctrl + ], а затем введите quit - это должно закрыть данное соединение:

^]
telnet> quit
Connection closed.
		

Как оказалось, настройка демона агента Zabbix на другой машине будет слегка сложнее чем раньше.

В отличие от установке на самом сервере Zabbix нам придётся внести изменения в файл настроек этого демона агента на данной удалённой машине. Откройте в предпочитаемом вами редакторе zabbix_agentd.conf от имени root и отыщите параметр Server. В настоящее время он настроен на 127.0.0.1, что и является той причиной, по которой мы не способны общаться с ним со своего сервера Zabbixю Как постулирует соответствующий комментарий, этот параметр должен содержать IP адрес вашего сервера Zabbix, поэтому замените здесь 127.0.0.1 на верный адрес своего сервера Zabbix.

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

# systemctl restart zabbix-agentd
		

Если вы устанавливали из исходного кода и не создавали или не приспосабливали некий сценарий init, вам придётся вручную остановить и запустить этот процесс агента:

# killall -15 zabbix_agentd; sleep 3; zabbix_agentd
		

Наша предыдущая команда остановит все процессы с названием zabbix_agentd в данной системе. Её не следует применять если в такой системе запущено множество агентов. Кроме того, установленной задержки в 3 секунды должно быть более чем достаточно в большинстве случаев, но если ваш агент не будет запущен после этого, проверьте его файл журнала для потенциальных причин. Также имеется возможность, что вам придётся определить само местоположение этого исполняемого файла zabbix_agentd если этот файл не находится в вашем пути, например, /usr/bin/zabbix_agentd.

Для проверки изменений попробуйте снова подключится telnet -ом к своей удалённой машине:

$ telnet 192.168.1.100 10050
		

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

Наконец, стоит открыть Monitoring | Latest data. Однако мы увидим только свой ранее созданный элемент; причина кроется в том самом фильтре, который мы меняли ранее. Мы в явном виде фильтровали только один хост; следовательно, второй созданный нами хост вовсе не отображается.

В этом фильтре, который всё ещё должен быть раскрыт, очистите соответствующее поле хоста и выберите Linux servers в поле Host groups, а затем кликните по Apply.

Во многих полях фильтров Zabbix мы можем либо начать набирать и получить некий список соответствующих записей, либо кликнуть по кнопке Select чтобы просмотреть перечень всех доступных логических объектов. Набор является очень удобным способом когда мы знаем по крайней мере часть нужного названия. Возможность посмотреть весь список полезна при работе в некоторой среде когда она нам менее знакома.

Теперь мы должны наблюдать два отслеживаемых хоста, причём каждый из них имеет по одному элементу:

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

Клонирование элементов

Давайте теперь выполним мониторинг другой службы, например, той, которая запускается по порту 22, SSH:

В этот раз в самом низу существуют доступными различные кнопки. Помимо прочих изменений, вместо кнопки Add теперь имеется Update.

Существует также и Delete, которая, очевидно, удаляет открытый в данный момент элемент. Мы не желаем делать этого сейчас. Вместо этого нажимаем на Clone.

Обратите внимание как эта открытая форма предлагает создавать новый элемент, ибо в данном случае все значения настроены теми же самыми что и в первоначальном элементе который мы должны клонировать. Наша кнопка Update также изменена на Add. Кликните по Add и вы должны получить отказ. Помните, мы говорили о том, что ключ предполагается уникальным в каждом хосте; именно об этом и говорит сообщение об ошибке:

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

Это всё что нам требовалось сделать сейчас, поэтому кликните по кнопке Add в самом низу снова. На этот раз данный элемент должен быть успешно добавлен. Теперь перейдите в Monitoring | Latest data, где Another host должен иметь перечисленными два элемента - SSH server status и Web server status. Их состояние будет определяться тем какая служба запущена в нашем удалённом хосте. Поскольку он удалённый, SSH скорее всего запущен (и следовательно имеет значение 1), однако будет ли запущен веб сервер, целиком зависит от вашей ситуации. Имейте в виду, что может пройти несколько минут, прежде чем вы получите самое первое значение в имеющихся последних данных для своего нового элемента:

Опрос элементов вручную

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

В Debian/Ubuntu выполните такую команду:

# apt install zabbix-get
		

Red Hat/Centos запустите следующую команду:

# yum install zabbix-get
		

Вот та команда, которую следует запустить в оболочке нашего сервера Zabbix:

$ zabbix_get -s 127.0.0.1 -k system.cpu.load
		

Она получит своё значение в точности тем же образом, как если бы это делал наш сервер. Если вы желаете получать подобные этим значения от другого хоста, вы можете запустить zabbix_get на самом сервере Zabbix. Попытка запустить его в том же самом хосте, на котором исполняется данный агент завершится отказом, поскольку мы изменили имеющийся параметр Server на приём соединений только от своего сервера Zabbix. Если вы желали бы опрашивать своего агента с локального хоста для целей отладки, в параметр Server можно добавить 127.0.0.1 через запятую - это иногда делается во всех системах при развёртывании его агента. Параметр -s служит для определения соответствующего IP/ имени хоста для такого хоста, а -k для задания значения ключа элемента, как мы его определяли в Zabbix для своего элемента. Для проверки всех имеющихся параметров, которые вы можете применять, исполните zabbix_get --help.

Это завершает основы обычных, или пассивных элементов Zabbix, когда сами серверы опрашивают агентов. Давайте перейдём к прочим типам элементов.

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

Здесь на поле выходят активные элементы. В противоположность пассивным элементам, что касается активных элементов, именно сам агент подключается к своему серверу; сам сервер никогда не подключается к такому агенту. При подключении этот агент выгружает перечень элементов для проверки и затем периодически выдаёт отчёт о своих новых данных соответствующему серверу. Давайте создадим некий активный элемент, но на этот раз мы попытаемся воспользоваться некоторой помощью при выборе соответствующего ключа:

В этот раз мы применим такие значения:

На этот раз мы делаем нечто иное со своим полем Key.

Кликните по кнопке Select и в возбуждённом диалоге, который мы уже наблюдали ранее, кликните по net.if.in[if,<mode>]. Это заполнит выбранную вами строку следующим образом:

Если в вашей системе имеются сетевые интерфейсы с различными названиями, применяйте их вместо eth0. Вы можете выявит свои названия интерфейсов с помощью команд ifconfig или ip addr show. Во многих современных дистрибутивах ранее стандартная схема именования ethX была заменена на схему, которая в результате приводит к различным именам интерфейсам, таким как enp0s3 и em1. Далее замените все вхождения eth0 на правильное название своего интерфейса:

Перейдите к Monitoring | Latest data и проверьте появятся ли новый значения.

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

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

$ telnet < Zabbix server IP or DNS name>  10051
		

Эта команда должна предоставить вывод, похожий на следующее:

Trying <Zabbix server IP>...
Connected to <Zabbix server IP or DNS name> .
Escape character is '^]'.
		

Нажмите Ctrl + ] и введите quit в появившемся в результате приглашении:

telnet> quit
Connection closed.
		

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

# To check you local firewall rules run
# For iptables
iptables -S

# For firewalld
$ firewall-cmd --list-all
		

Следовательно, что- то может быть не так с самим агентом; давайте рассмотрим подробнее. Мы можем попробовать посмотреть файл журнала демона нашего агента, итак, отыщите параметр настройки LogFile. Если вы применяете установленные по умолчанию файлы настройки из архива исходного кода, им должен быть /tmp/zabbix_agentd.log. Если вы делали установку из пактов, он скорее всего в /var/log/zabbix или в чём- то похожем. Откройте этот файл журнала и отыщите все интересные сообщения относительно активных проверок. Каждая строка имеет префикс PID и timestamp в данном синтаксисе, PID:YYYYMMDD:HHMMSS. Скорее всего вы обнаружите нечто подобное:

15794:20141230:153731.992 active check configuration update from [127.0.0.1:10051] started to fail (cannot connect to [[127.0.0.1]:10051]: [111] Connection refused)
 	   

Ваш агент пытается запросить необходимый список активных проверок, но соединение падает. Эта попытка кажется не правильной - наш сервер Zabbix должен иметься в другой системе, нежеди локальный хост. Посмотрим как это можно исправить. В своей удалённой машине откройте файл настроек zabbix_agentd.conf и проверьте параметр ServerActive. (данный файл скорее всего находится в /etc/zabbix/.) Устанавливаемый по умолчанию файл будет иметь строку подобную следующей:

ServerActive=127.0.0.1
 	   

Данный параметр сообщает вашему агенту с кем он должен соединяться для активных элементов. В нашем случае локальный хост не будет работать в качестве необходимого нам сервера Zabbix в некоторой удалённой машине. поэтому нам следует подправить это. Замените 127.0.0.1 на IP адрес или имя DNS своего сервера Zabbix, а затем перезапустите своего агента либо при помощи сценария systemd, или методом вручную: killall.

Пока у вас открыт фал настроек, взгляните в нём на другой параметр - StartAgents. Этот параметр управляет тем сколько процессов обрабатываются для входящих подключений в случае пассивных элементов. Если он установлен в 0, это запретит такому агенту выполнять ожидание входящих подключений со стороны его сервера. Это делает возможным индивидуально настраивать агентов на поддержку либо одного, либо обоих имеющихся методов. С точки зрения безопасности может оказаться лучше запретить пассивные элементы, но это очень удобно в целях проверок и отладки различных проблем. Кроме того, некоторые элементы будут работать только в качестве пассивных. Активные элементы могут быть запрещены путём отсутствия описания ServerActive (экранирование его комментарием). Запрет и активных и пассивных элементов не будет работать; такой демон агента выразит недовольство и отвергнет запуск, и окажется прав - запуск при отключениях обоих был бы бессмысленным. Давайте посмотрим:

zabbix-agentd [16208]: ERROR: either active or passive checks must be enabled
 	   

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

15938:20141230:154544.559 no active checks on server [192.168.1.3:10051]: host [Zabbix server] not monitored 
 	   

Если мы внимательно прочтём эту запись, мы заметим, что наш агент сообщает о своём имени хоста как о Zabbix server, однако это то название хоста, которое установлено значением по умолчанию, которое мы решили не применять и оставили отключённым. Соответствующее сообщение журнала подтверждает: оно отмечает, что для этого хоста не выполняется мониторинг.

Если мы взглянем на сообщения при запуске, также имеется ещё строка, упоминающая следующее:

15931:20141230:154544.552 Starting Zabbix Agent [Zabbix server]. Zabbix 4.0.0 (revision 85308)
 	   

так как это не то название хоста, который мы бы желали применять, давайте проверим вновь фал настроек своего демона агента. Имеется некий параметр с названием Hostname, который в настоящее время считывает Zabbix server. Предоставляемый с этим параметром комментарий гласит: Required for active checks and must match hostname as configured on the server (Требуется для активных проверок и должен соответствовать названию хоста, который настроен в соответствующем сервере), это должно быть тем что мы ищем. Измените данный параметр настройки своего агента на Another host. Проверьте новые записи в соответствующем файле zabbix_agentd.conf; больше не должно быть ошибок.

Пока мы здесь, давайте также обновим настройки агента в A test host. Внесите изменения в zabbix_agentd.conf и установите Hostname=A test host, а затем перезапустите соответствующий демон агента.

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

Настало время вернуться к своему интерфейсу и убедиться в разделе Monitoring | Latest data что данные начали поступать:

Отметим что данная система в приводимом снимке экрана в действительности обладает интерфейсом enp0s3, а не eth0. Мы обнаружим как Zabbix заботится о названиях интерфейсов и автоматически их обнаруживает в Главе 11, Автоматизация настройки.

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

Великолепно, данные в конце концов потекли, но значения выглядят очень странно. Если вы немного подождёте, вы обнаружите, что отображаемое в колонке Last Value просто продолжает увеличиваться. Итак, в чём дело? Хорошо, ключи сетевого обмена получают свои данные из счётчиков интерфейса, то есть ваш сетевой интерфейс добавляет весь обмен, и именно этими данными запитывается имеющаяся в Zabbix база данных. Это имеет одно большое преимущество - даже когда опрашиваемые данные имеют большие интервалы скачки обмена не останутся незамеченными при наличии данных соответствующего счётчика, но это также делает для вас данные в значительной степени плохо читаемыми, а графики будут выглядеть как постоянно растущая линия (если хотите поглядеть каково это, кликните по ссылке Graph для данного элемента). Мы даже можем обозвать его графиком горы:

К счастью, Zabbix предоставляет встроенную возможность иметь дело с подобные таким счётчикам:

Нам придётся слегка подождать пока наши изменения вступят в силу, поэтому сейчас лучшее время для обсуждения нашего выбора параметра Type of information для данного элемента. Мы установили его в Numeric (unsigned), что принимает целые значения. Значения для данного элемента первоначально в действительности являются целыми - это значения счётчиков, обозначающие число байт, получаемых в данном интерфейсе. Наш параметр Preprocessing steps был изменён на Changes per second (в предыдущих версиях Delta speed per second)), тем не менее, почти всегда это приводит к появлению некоторой десятичной части; это делит значение общего обмен между двумя значениями на значение секунд, прошедших между ними. В тех случаях, когда Zabbix получает некое десятичное число и должен сохранять его в поле с целочисленным значением, его поведение будет отличаться в зависимости от того каким он образом он получил данное десятичное значение так:

Данное поведение отображается на следующей схеме:

Почему имеется подобное отличие и почему мы оставляем данный элемент неким целым, раз это приводит в конечном результате к меньшей точности? Десятичные значения в применяемой в Zabbix схеме базы данных имеет меньшее число значимых цифр, доступных перед десятичной точкой, чем у целых значений. Для нагруженных интерфейсов с высокой скоростью мы можем переполнять этот предел и это повлекло бы к полной утрате получаемого значения. Обычно лучше будет потерять небольшую часть точности - десятичную часть - чем утратить всё значение. Отметим, что теряется точность в самом меньшем элементе: байте или бите. Даже если Zabbix показывает 5 Gbps в своём интерфейсе, его отсекаемая десятичная часть будет значением в битах; следовательно, такая утрата точности на самом деле должна быть очень незначительной. Предлагается применять целые значения для элементов у которых имеется подобный обсуждённому риск, по крайней мере пока пределы схемы базы данных не возрастут.

Проверьте вновь Monitoring | Latest data и вы обнаружите что изменяющееся число является отрицательным, покольку мы теперь рассчитываем изменение в секунду вместо постоянно увеличивающегося значения. Следовательно, получаемое нами значение скорее всего будет меньше чем в прошлый раз.

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

Так- то лучше; Zabbix теперь автоматически вычисляет изменение между каждыми двумя проверками (именно этому и служит дельта) и сохраняет его, но значения всё ещё не кажутся слишком дружественными для пользователя. Может быть они будут лучше на своём графике - давайте откроем соответствующую ссылку Graph чтобы узнать об этом:

Ух. Хотя мы очевидно можем видеть вступившие в действие сделанные изменения, но это всё же оставляет нас с очень корявыми историческими данными. Ось Y- этого графика представляет значение полного счётчика (а следовательно общее значение с начала отслеживания системой), однако наша ось X- предоставляет правильные данные (дельта). Вы также можете просматривать эти данный в численном виде, переходить к ниспадающему меню в правой верхней части, которая в настоящий момент считывает Graph. Выберите здесь 500 latest values. Вы получите следующий снимок экрана:

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

Четвёртая слева кнопка с названием Clear history, скорее всего, делает то что нам нужно. Отметим текст 1 selected слева от кнопок активности - он отображает общее число выбранных элементов, поэтому мы всегда знаем к какому числу элементов мы применяем действие. Кликните по кнопке Clear history. Вы должны получить всплывающий вопрос JavaScript относительно подтверждения на продолжение. Поскольку очистка истории может занять много времени для больших наборов данных, в нашем случае это должно произойти почти моментально, поэтому кликните по кнопке OK. Это должно избавить нас от всей истории значений для данного элемента, включая наши гигантские.

Тем не менее, глядя на ось Y на данном графике, мы видим, что поступающие значения не сопровождаются никаким пояснением того что они представляют, а при больших значениях применяются K, M и прочие идентификаторы множителя. Было бы намного лучше, если бы Zabbix знал как вычислять это в байтах или подобных единицах:

Давайте проверим есть ли какие- то улучшения в Monitoring | Latest data:

Прекрасно; данные всё ещё поступают. Даже ещё лучше, отметим как теперь Zabbix автоматически вычисляет KB, MB и тому подобное где это требуется. Хорошо, в нашем примере хоста было бы лучше иметь побольше обмена. Давайте просмотрим свой сетевой обмен; кликните по Graph:

Обратите внимание на ось Y- - если у вас возрастает обмен, единицы будут пересчитаны чтобы сделать ваш график более читаемым, а вычисления единиц применяются задним числом к ранее собранным значениям.

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

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

Применяя данный фильтр, мы можем создать сложные правила относительно подлежащих отображению элементов. Взглянув в левый верхний угол данного фильтра мы можем обнаружить что мы не ограничены просмотром элементов с некоторого отдельного хоста; мы также можем выбрать Host group. Когда нам это нужно, мы можем сделать выбор фильтра и кликнуть по подлежащей ссылке Filter. В настоящий момент он имеет только одно условие - поле Host содержит Another host, поэтому ссылка Items из применяемого нами перечня хостов была единственной установленной этим фильтром:

Теперб взгляните справа ниже самого основного элемента фильтра - это Subfilter, который, как и указывает его заголовок, оказывает воздействие только на уже отфильтрованное в основном фильтре.

Все элементы в данном субфильтре работают как переключатели реле - если мы включим какой- то, он работает как некий фильтр относительно этих данных дополнительно ко всем прочим включённым управлениям субфильтра. Давайте теперь кликнем по Zabbix agent (active). Отметим что наш список элементов теперь содержит лишь один элемент; именно это представлено значением числа 1 вслед за данным реле Subfilter. Но наш субфильтр также теперь выглядит иначе:

Когда вам приходится отслеживать много различных хостов, достаточно просто забыть какую версию демона агента Zabbix имеет каждый хост, причём даже если вы под рукой имеете автоматизированное развёртывание программного обеспечения, было бы чудесно иметь возможность просмотра того какую версию имеет каждый хост прямо на месте.

Применим следующие значения:

По завершению кликните по кнопке Add. Следует сделать два замечания относительно сделанного нами. Прежде всего мы установили тип информации в Character, что перезагрузило нашу форму, слегка изменив доступные параметры. Что наиболее заметно, поля, которые относились в численной информации стали скрытыми, например, единицы измерения, множители и тенденции.

В- вторых, мы ввели очень большой интервал обновления, 86400s, что эквивалентно 24 часам. Хотя это может и показаться слишком большим, вспомните что мы отслеживаем здесь, версию агента Zabbix, поэтому скорее всего (к счастью) она не будет изменяться по нескольку раз в день. В зависимости от своих потребностей, вы можете установить даже ещё большее значение, например неделю.

Чтобы проверить полученные результаты своей работы, пройдём в Monitoring | Latest data.

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

Теперь относительно ожидания - почему нам приходится ожидать появления своих данных? Ладно, помните как работают активные элементы? Сам агент опрашивает свой сервер относительно списка элементов, о которых он должен выдать отчёт и затем отправляет периодически данные, однако такая проверка его списка элементов также периодически выполняется. Чтобы выяснить насколько часто, откройте соответствующий файл настроек zabbix_agentd.conf в своей удалённой машине и отыщите параметр RefreshActiveChecks. Значением по умолчанию являются две минуты, которые настраиваются в секундах, следовательно здесь у нас 120 секунд.

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

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

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

Для пассивных элементов допуск входящих подключений со множества серверов Zabbix выполняется тем же самым образом - путём добавления множества IP адресов в соответствующий параметр Server.

Мы создали некие элементы, которые применяют Zabbix в обоих направлениях и собирают данные. Но это не единственные доступные элементы. Вы можете ознакомиться с полным списком при создании какого- то элемента вновь (проидите в Configuration | Hosts, кликните по Items для любого из хостов и затем кликните по кнопке Create item после кнопки Select, следующей за соответствующим полем Key) чтобы посмотреть какие элементы встроены для агентов Zabbix с кратким описанием для большей части из них.

Рассматривая данный список, мы можем видеть какие категории элементов агенты Zabbix поддерживают естественным путём - настройку системы, сетевой обмен, сетевые службы, загруженность системы и использование памяти, мониторинг файловой системы и прочее. Но это не означает, что всё что вы видите будет работать в любой системе в которой исполняется демон агента Zabbix. Поскольку каждая платформа имеет свой отличный способ выставления такой информации и некоторые параметры могут оказаться специфичными для этой платформы, нет гарантии что все ключи будут работать во всех хостах.

Например, когда для userspace изменяется отчёт определённой статистики дискового устройства, имеющийся агент Zabbix должен особым образом реализовывать поддержку для такого нового метода, причём более ранние версии будут поддерживать меньшее число параметров имеющихся в настоящий момент систем Linux. Если вам интересно будет ли определённый параметр работать в конкретной версии особой операционной системы, наилучшим способом будет ознакомиться с соответствующим руководством Zabbix, а затем проверить его. Вот некотороые из наиболее часто применяемых ключей элементов агента:

Для большей части из них могут быть указаны различные параметры для фильтрации результатов или выбора конкретной части информации. К примеру, proc.num[,zabbix] будет исчислять число всех процессов, которые запущены соответствующим пользователем Zabbix.

Хотя мы и обсуждаем агенты Zabbix в качестве активных или пассивных, некий агент на самом деле не является тем или иным - само направление коммуникации определяется на уровне его элемента. Некий агент способен (и при определении по умолчанию делает это) работать в обоих режимах в одно и то же время. Тем не менее, мы будем вынуждены выбирать какой именно тип элемента применять - активный или пассивный. Говоря кратко - рекомендуется применение активных элементов.

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

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

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

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

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

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

Вот преимущества активных элементов:

Вот преимущества пассивных элементов:

В Главе 8, Упрощение сложных настроек через шаблоны мы будем обсуждать применение и изменение шаблонов.

Ранее, когда мы обсуждали что вводит задержку перед проверкой некого нового элемента - мы упоминали имеющийся кэш настроек сервера Zabbix. Для пассивных элементов также имеется некий иной вовлечённый фактор и это тот способ коим Zabbix планирует опрос элементов. Каждый элемент планируется под опрос в некое определённое время, причём значение времени между двумя опросами всегда постоянно. Даже ещё больше, некий конкретный элемент всегда планируется одним и тем же образом, вне зависимости от того как был запущен сам сервер Zabbix. Например, некий элемент имеет какой- то интервал в 60- секунд, он может быть настроен на опрос на 13 секунде каждую минуту. Если существующий сервер Zabbix перезапускается, этот элемент всё ещё будет опрашиваться на 13 секунде каждую минуту. Такое планирование основывается на некотором внутреннем идентификаторе элемента; следовательно, некий определённый элемент не получит такое изменение времени на протяжении своего времени жизни, только если он не удалён и создан повторноили изменён сам интервал элемента.

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

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

Это означает что при установленном по умолчанию интервале в 30 секунд, это может потребовать от 30 до 90 секунд пока такое первое значение появляется для данного элемента. Если такой элемент имеет очень длинный интервал, такой как серийный номер или настроенная нами ранее версия агента, может потребоваться очень длительный промежутков времени пока автоматически не появится самое первое значение. Не существует пути для ускорения опроса элемента кроме того чтобы добавить ему некий короткий интервал для первого раза и затем увеличивая этот интервал когда вы проверили что данный элемент работает как ожидалось.

После добавления некоторого активного элемента, он вновь сохраняется в имеющейся базе данных, и опять же, сам сервер Zabbix пока ещё не знает о нём. Сам активный агент Zabbix периодически подключается к своему серверу для получения информации об элементах, которые как он предположительно должен был мониторить, однако, поскольку он ещё не настроил соответствующий кэш настроек. По умолчанию этот кэш настроек обновляется каждые 30 секунд. После того как этот сервер обнаруживает такой новый элемент, этот элемент становится доступным данному агенту, тем не менее данный агент подключается к своему серверу по умолчанию каждые две минуты. Раз агент обнаружил такой новый элемент, он немедленно пытается собрать для него самое первое значение.

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

Тем не менее, в Zabbix 4.0 было введено некое свойство, которое было самым запрашиваемым на протяжении долгих лет, и которое позвояет нам ускорять эти моменты, но только для пассивных проверок на текущий момент. К тому же нам всё ещё придётся подождать пока кэш настроек не подхватит такие изменения прежде чем мы сможем воспользоваться данной функциональностью. Переходя к некоторому пассивному элементу у нас в самом низу его страницы имеется кнопка Check now, которая позволяет нам выбрать самое последнее значение данного элемента. К счастью, эта функциональность в ближайшем лучшем будет улучшена с тем чтобы она впредь работала бы как для активных, так и для пассивных элементов:

Все изначально создаваемые элементы требуют установки, исполнения и способности соединяться в обоих направлениях самого демона агента Zabbix. Но что если вы не можете или не желаете устанавливать своего агента на некотором удалённом хосте, а вам всего лишь требуется отслеживать простые вещи? Именно в этом вам способны помочь простые проверки. Такие проверки не требуют исполнения никакого специализированного агента на вашей удалённой стороне, а для запросов мониторинга всего лишь полагаются на базовые сетевые протоколы, такие как ICMP (Internet Control Message Protocol) и TCP.

Теперь давайте создадим самую базовую проверку:

Воспользуйтесь следующими значениями:

Ниспадающее меню Type в правом верхнем углу должно уже сообщать Simple check, если это не так, приведите его в соответствие. В списке Key кликните по ключу net.tcp.service[service,<ip>,<port>] и затем внесите в него изменения. Замените service на smtp и удалите всё после него в квадратных скобках чтобы ключ превратился в net.tcp.service[smtp], как здесь:

По завершению кликните по кнопке Add в самом низу. Чтобы проверить полученный результат, пройдите в Monitoring | Latest data - наша новая проверка должна быть здесь и, в зависимости от того имеется ли у вас запущенный и доступный для вашего сервера Zabbix необходимый сервер SMTP, должен перечислять либо 1 (если исполняется и доступен), либо 0.

Что если вы заботитесь лишь о базовой достижимости некоторого хоста, например, какого- то маршрутизатора или коммутатора, который вышел из под вашего управления? Пинг ICMP (запрос эхо и отклик) был бы в этом случае неким подходящим методом для мониторинга, причём Zabbix поддерживает такие простые проверки. Обычно это не работает сразу; чтобы применять их нам придётся настроить некую отдельную утилиту, fping, которую Zabbix применяет для проверок ICMP. Она должна быть доступной в большинстве дистрибутивов, так что просто установите её при помощи инструментов управления пакетами своего дистрибутива. Если не получается, вам придётся выгрузить и скомпилировать fping вручную; она доступна на http://fping.sourceforge.net/.

После того как fping установлена как следует, вашему серверу Zabbix следует знать где её отыскивать и иметь возможность исполнять её. В своём сервере Zabbix откройте zabbix_server.conf и отыщите параметр FpingLocation. По умолчанию он скрыт комментарием, а его значением по умолчанию является /usr/sbin/fping. Вы можете быстро разыскать местоположение исполняемого файла fping при помощи команды:

$ which fping
		

Если одним из полученных результатов является /usr/sbin/fping, вам не придётся изменять данный параметр. Если же это не так, поменяйте данный параметр с тем, чтобы он указывал на верное местоположение fping и перезапустите свой сервер Zabbix с тем, чтобы он узнал о данном изменении настроек. Это ещё не всё. Zabbix также нуждается в способности запускать fping с полномочиями администратора, поэтому от имени root исполните следующее:

# chgrp zabbix /usr/sbin/fping
# chmod 4710 /usr/sbin/fping
		

Поскольку исполняемый файл fping должен был до этого находиться во владении root, этого должно быть достоточно для его использования вашей группой Zabbix, как то и требуется; давайте убедимся в этом.

Как обычно, перейдите в Configuration | Hosts, кликните по Items вслед за Another host, и кликните по Create item. Настройте следующие подробности:

Соответствующие параметры для закладки Preprocessing таковы:

После того как все поля заполнены как положено, кликните по кнопке Add в самом низу. Выполните обычный обратный путь в Monitoring | Latest data - пинг ICMP уже должен иметь записанными данные. Если вы подождёте несколько минут, вы также сможете взглянуть на некий относительно интересный график чтобы отметить какие- то изменения в имеющейся сетевой производительности.

Здесь мы настроили измерение в секундах сетевых задержек пинга ICMP. Если вы просто желаете проверять связь с хостом, вам следовало выбрать соответствующий ключ icmpping, который лишь записывает был ли пинг успешным или нет. Это самый простой способ проверки связи в большом масштабе, поскольку он помещает очень маленькую нагрузку в вашей сетевой среде (если только вы не применяете смехотворно маленькие интервалы). Конечно, имеются моменты, о которых вам следует знать, к примеру, выполнение чего- то иного для проверки связи с Интернетом - этого может быть достаточно для проверки связи с вашим маршрутизатором, межсетевым экраном или даже с маршрутизаторами поставщика интернет- услуг. Наилучшим способом был бы выбор некоторых удалённых целей для мониторинга, о которых известно что они имеют очень хорошее соединение и доступность.

Для элементов пинга ICMP могут определяться некоторые параметры. К примеру, полный синтаксис ключа icmpping следующий:

icmpping[<target>,<packets>,<interval>,<size>,<timeout>]
 	   

По умолчанию target получается от самого хоста, которому назначен данный элемент, но это можно изменить. Параметр packets позволяет вам определять сколько пакетов следует выпускать при каждом вызове - обычно значением по умолчанию fping является 3. Значение параметра interval позволяет вам настраивать величину интервала между такими пакетами - как правило установкой по умолчанию fping является одна секунда для одной и той же цели, выставляемая в миллисекундах. Относительно size, здесь значение по умолчанию некого отдельного пакета может различаться на основе версии, архитектуры и возможно прочих параметров самого fping. А самый последний - timeout - настраивает индивидуальные таймауты для цели, при том что обычно распространённым является значение по умолчанию в 500 миллисекунд.

Отметим, что нам не следует настраивать элементы пинга ICMP с очень большими таймаутами или значениями числа пакетов; они могут приводить к странным результатам. Например, установка значения числа пакетов в 60 и применение 60- секундного интервала в некотором элементе скорее всего приведут в результате к тому, что элемент будет терять значение чере каждую секунду.

Если для одного и того же хоста вы настроите несколько элементов ICMP, Zabbix вызовет соответствующую утилиту fping только один раз. Если множество хостов имеют элементы пинга ICMP, Zabbix будет запускать fping по одному для всех хостов, для которых требуется выполнять пинг в одно и то же время с теми же самыми параметрами (такими как packet, size и timeout)/

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

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

Что за чертовщина в самом последнем случае? Ну, ключи элемента Zabbix не подлежат интерпретации оболочкой. Zabbix целенаправленно поддерживает двойные кавычки для заключения в кавычки параметра ключа. Одинарные кавычки трактуются как и все прочие символы.

Пока мы работаем с элементами, давайте изучим ещё немного трюков:

Вы можете заметить его прямо сейчас, либо проследуйте в Monitoring | Latest data и загляните в имеющийся перечень. Несмотря на то что мы изменили только ключ, название элемента также обновилось:

именно это делает наша часть $1 в поле Bold имени. Она работает как обычный позиционный параметр, получая самый первый параметр данного ключа элемента. Если у нас имеются ещё параметры, мы можем осуществлять к ним доступ для включения в своё название с помощью $2, $3 и так далее. Это в основном полезно когда вы хотите создать несколько элементов, которые наблюдают за различными логическими объектами с тем чтобы клонировать такие элементы, вам придётся изменять только отдельный экземпляр своего идентификатора. Достаточно просто, чем можно было бы предположить, пропустить некоторые изменения в случае наличия нескольких местоположений и тем самым создать элементы с ошибочными настройками.

Теперь когда у нас есть ещё настроенные элементы, было бы неплохо взглянуть на другое представление мониторинга. Хотя мы в основном проводили время в Monitoring | Latest data, на этот раз перейдите в Monitoring | Overview. Ниспадающее меню Type в нашем правом верхнем углу теперь перечисляет Triggers, которые не представляют для нас черезчур захватывающего зрения: у нас имеется созданным только один единственный триггер. Но мы создали несколько элементов, поэтому переключим это ниспадающее меню на Data:

На этот раз обозреваемая нами страница чуть интереснее: мы можем видеть какие хосты имеют какие элементы и значения элементов.

Теперь всё выглядит достаточно неплохо - мы можем наблюдать свои отслеживаемые данные в некотором компактном виде. Вот эти результаты 1, которые обозначают текущее состояние для различных серверов - что они значают? Служило ли 1 некому рабочему состоянию, иди это была какая- то ошибка навроде кода выхода? Это не очень понятно на интуитивном уровне, следовательно давайте постараемся исправить это. Пройдите в Configuration | Hosts и кликните по Items для Another host. Выберите все три элемента состояния сервера (SMTP, SSH и Web) и затем взгляните на кнопки, имеющиеся внизу данного списка элементов.

На этот раз мы желаем выполнить отдельное изменение для всех своих выбранных элементов, итак, вторая кнопка справа выглядит как та, что требуется нам - она вещает Mass update (массовые обновления). Кликнем по ней:

Теперь у нас имеется некий забавный экран - он позволяет нам изменять некие параметры для множества элементов за раз. При его выполнении осуществляются только отмеченные и предписанные изменения, поэтому мы можем изменять некие общие значения для иным способом основательно отличающихся элементов. Это позволяет нам устанавливать такие вещи как Update interval или любой иной параметр совместно для всех отобранных элементов:

на этот раз нас интересует только одно значение, а именно то, которое определяет как это значение отображать для нас. Пометьте флажок вслед за Show value entry чтобы увидеть доступные варианты.

Выглядит так, как если бы мы уже определяли здесь записи, но давайте отыщем что это означает в действительности прежде чем примем некое решение. Кликните по ссылке Show value mappings справа в той же самой строке:

Рассматривая этот список мы можем видеть различные названия, причём каждое из них имеет некий список ссылок соответствия. Взгляните на колонку Name, в которой ваши предварительно установленные записи имеют советы относительно того для чего они хороши. Вы можете наблюдать относящиеся к UPS соответствия, общие соответствия статус/ состояние, соответствия SNMP и относящиеся к службам Windows соответствия. Ваша колонка Value map отображает точное соответствие, которое назначено каждой записи. Но что именно они означают? Рассматривая имеющиеся записи мы можем видеть вещи подобные 0 => Down или 1 => Up. Поступающие для элемента, которому назначено сопоставление значения, данные будут отображать эти описательные сопоставления. Вы можете создать любое отображение по своему желанию. Для создания новой категории сопоставляемых данных вам требуется воспользоваться имеющейся в правом верхнем углу кнопкой с названием Create value map. Мы не будем делать этого прямо сейчас, так как одно из доступных соответствий отвечает нашим потребностям достаточно неплохо. Посмотрите на записи - помните те элементы, которыми мы интересовались? Они отслеживали некую службу и применяют 1 для обозначения того что служба исполняется и 0 для указания что некая служба отключена. Взглянув на имеющийся список мы можем обнаружить некую запись, Service state, которая определяет 0 как Down, и 1 как Up - в точности то что нам требуется. Ну, это означает что нам не придётся создавать или изменять какие бы то ни было записи, поэтому просто закройте это окно.

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

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

Давайте рассмотрим как наши изменения повлияли на отображаемую информацию. Настройка и назначение соответствий значениям используется в большинстве мест интерфейса Zabbix, где это имеет значение. Например, давайте посетим своего старого друга, Monitoring | Latest data. Давайте внимательнее присмотримся к различным записям состояния сервера - Zabbix всё ещё отображает численные значения для этой ссылки, но каждая теперь без труда перечисляет соответствующее поставленное в соответствие значение дружелюбного названия:

Мы только что остановили свой сервер SNMP чтобы убедиться что работают оба соответствия, и 1 => Up, и и 0 => Down - как мы можем видеть, это так и есть. Установка соответствий значениям может оказаться полезной для возвращаемых данных, которые работают как кодовые значения - состояния служб, состояния оборудования (например, батареи) и прочие аналогичные наблюдаемые данные. Мы видим некоторые предварительно определённые ранее образцы в своём экране настроек соответствия значений, причём мы вольны изменять их или создавать новые соответствия согласно своим потребностям.

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

Перейдите обратно к Monitoring | Overview и снова взгляните на различные записи состояния сервера для ANOTHER HOST:

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

Ранее мы уже настраивали единицы измерения для некоторых элементов, применяя такие значения как B или ms. Хотя получаемый эффект был достаточно просто виден в нашем разделе мониторинга, существуют некоторые нетипичные различия в обработке различных единиц.

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

Что интересно, для нашего элемента пинга ICMP мы не применяли ничего из этого; мы использовали вместо этого ms. Основная причина состояла в том, что в определённых случаях очень маленького прохода в обе стороны значение может быть очень малым для сохранения в имеющейся схеме базы данных Zabbix. Применяя множитель 1000 при настройке данного элемента мы преобразуем поступающие значения в секундах в миллисекунды, что никогда не выходит за рамки имеющейся схемы базы данных. Одним из недостатков будет то, что если пинг требует значительного времени, получаемое значение не будет отображаться в секундах - и нам придётся вычислять его из значения в миллисекундах.

Другим свойством элемента, которое мы уже кратко обсуждали, было индивидуальными интервалами. Большинство типов имеют настроенными свои собственные интервалы, которые определяют насколько часто необходимо собирать значения элементов. Но что если бы вы пожелали изменять такой интервал на основе дня недели или времени дня? Именно это способны выполнять для нас индивидуальные интервалы. Для индивидуальных интервалов существует два режима:

Гибкие интервалы

Гибкие интервалы переопределяют обычный интервал в определяемое ими время. Напрмиер, некий элемент может собирать значения каждые 60 секунд, но этот элемент может не иметь значения в выходные дни. В таком случае может быть добавлен некий гибкий интервал со значением 3600 и определяемым временем 6-7,00:00-24:00. В течении суббот и воскресений этот элемент будет проверяться только раз в час:

Дни представляются целыми числами 1-7, а также применяется 24- часовая нотация HH:MM-HH:MM.

Также имеется возможность устанавливать обычный интервал в 0 и настраивать гибкие интервалы. В таком случае наш элемент будет проверяться только в то время, которое установлено в его гибких интервалах. Данная функциональность может применяться для проверки неких элементов только в особые дни недели или даже имитировать некий сырой планировщик. Если некий элемент добавляется с обычным интервалом равным 0, гибким интервалом в 60 секунд, а время определено как 1,09:00-09:01, такой элемент будет проверяться по понедельникам в 9 утра.

Индивидуальное планирование

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

Это может звучать подобно crontab, однако индивидуальное планирование Zabbix применяет собственный синтаксис. Сам префикс времени следует за неким фильтруемым элементом. Множество префиксов времени соединяются, проходя от наибольших к наименьшим. Поддерживаемые префиксы времени таковы:

Скажем, некая запись m13 будет планировать такой элемент для опроса каждый час в начале 13 минуты. Если он соединяется с неким описанием дня недели, например, wd3m13, это будет выполнять опрос каждый час начиная с 13 минуты только по средам. Изменение ссылки дня недели на день месяца - или дату - выглядит как md13m13 и это означает что данный элемент будет опрашиваться каждый час начиная с 13 минуты только по 13 числам.

Вот пример опроса данного элемента утром в понедельник в 09:00, который мы видели ранее и он представлен wd1h9:

Наш фильтр также может иметь диапазон. Например, опрос некоторого элемента в понедельник, вторник и среду выполнялся бы как wd1-3h9.

В конце конкретного фильтра мы также можем добавить некий шаг через слэш. К примеру, wd1-5h6-10/2 опрашивал бы данный элемент с понедельника по пятницу начиная с 06:00 каждый следующий час вплоть до 10:00. Данный элемент опрашивался бы в 06:00, 08:00 и 10:00. Для опроса некоторого элемента на протяжении всех дней каждый второй час может быть применён синтаксис h/2.

Множество индивидуальных интервалов также может определяться разделением их точкой с запятой; и wd1-5/2 и wd1;wd3;wd5; опрашивают некий элемент в начале понедельника, среды и пятницы.

Рассматривая тот же самый экран обзора, ваши данные выглядят более простыми для понимания с текстуальными подсказками, предоставленными для ранее выглядевших криптографией численных значений, но всё ещё имееься кое- что отображаемого, что далеко от идеального. Обратите внимание на те тире, отображающие элемент CPU load для Another host и все прочие значения A test host. Мы не создали соответствующих элементов в обоих хостах и здесь отображаются данные элемента, что означает, что следует создать пропущенные элементы для каждого из хостов с целью получения данных. Однако повторное создание всех элементов было бы слишком скучным. К счастью, имеется простое и прямолинейное решение данной проблемы.

Пройдите в Configuration | Hosts и кликните по Items за A test host. Для данного хоста у нас имеется только единственный настроенный элемент, поэтому пометьте флаг вслед за этим элементом. Давайте снова рассмотрим доступные кнопки внизу данного списка:

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

Когда эта операция завершится, измените поле Host filter (раскройте этот фильтр если он закрыт) на Another host, а после этого кликните по Filter внизу самого этого фильтра. Заметьте что в данном списке появился соответствующий элемент CPU load. На этот раз пометьте все имеющиеся элементы кроме CPU load, так как именно этот единственный элемент имеет A test host. Вы можете воспользоваться здесь функциональностью выбора стандартного диапазона - пометьте флаг вслед за элементом производительности пинга ICMP (самый первый элемент в том диапазоне, который мы намерены выбрать), нажмите на клавишу Shift на клавиатуре и кликните по флагу всед за версией агента Zabbix (самый последний элемент в выбираемом нами диапазоне). Это должно выполнить выбор всех элементов между двумя флагами, по которым мы кликнули.

Для этих выбранных элементов выполните следующее:

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

Но всё ещё лучше - при наведении курсора мыши на отображаемые значения, вы можете заметить как выделяется выбираемая строка. Давайте кликнем по значениям CPU load:

Как вы можете видеть, наш экран обзора не только показывает нам ваши данные в виде закладок, он также допускает быстрый доступ к графикам временного масштаба и к Latest values для данного элемента. не стесняйтесь попробовать это всё.

Когда вы просмотрите все данные, кликните по одному из значений версии агента Zabbix:

Заметим, что на этот раз у нас нет записей для графиков. Помните: графики были доступны только для численных данных, следовательно Monitoring | Latest data и такое ниспадающее меню экрана обзора предлагают только историю подобного значения.

на данный момент мы создали некий новый хост и добавили несколько обычных или пассивных элементов агента и активных элементов агента.

Мы изучили что хорошей практикой является отключение активных элементов когда они не используются путём экранирования комментарием соответствующего параметра ServerActive. Если не применяются пассивные агенты, их можно отключать установкой в 0 StartAgents, при этом оставление их включёнными может помогать при проверках и отладке.

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

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

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

Перечисляемые ниже значения портов по умолчанию могут изменяться при необходимости:

Такие простые проверки были различными: они никогда не использовали агента Zabbix и выполнялись напрямую с самого сервера Zabbix. Простые проверки включают в себч и проверку порта TCP.

Это всё охватывает два основных, наиболее часто применяемых видов проверок - некоторого агента Zabbix с поддержкой подключений в обоих направлениях и простых проверок, которые выполняются напрямую с самого сервера.

В своей следующей главе мы рассмотрим мониторинг SNMP. Мы начнём с быстрого введения в инструментарий Net-SNMP и основы управления MIB (Management Information Base), а также мы настроим опрос SNMP с фиксированными и динамическими OID. Также мы получим ловушки SNMP и их соответствие хостам и элементам с применением как встроенных методов, так и очень индивидуальных подходов.

Для получения дополнительных сведений ознакомьтесь со следующими статьями: