Zabbix элементы данных windows

Ключ
▲	Описание	Возвращаемое значение	Параметры	Комментарии
agent.hostname
	Возвращает имя хоста агента.	Строка	–	Возвращает действительное значение hostname агента из файла конфигурации. Этот элемент данных поддерживается начиная с версии 1.8.13.
agent.ping
	Проверка доступности агента.	Возвращает ‘1’, если доступен и ничего не возвращает, если недоступен.	–	Может быть использовано как TCP ping. Используйте функцию nodata() для проверки недоступности хоста.
agent.version
	Версия Zabbix агента.	Строка	–	Пример возвращаемого значения: 1.8.2
kernel.maxfiles
	Максимальное количество открытых файлов поддерживаемое ОС.	Количество файлов. Целочисленное.
kernel.maxproc
	Максимальное количество процессов поддерживаемое ОС.	Количество процессов. Целочисленное.
log[файл,<regexp>,<кодировка>,<макс кол-во строк>]
	Мониторинг файлов журналов (логов).	Журнал	файл – полное имя файла regexp – регулярное выражение для шаблона кодировка – Идентификатор кодовой страницы максимальное количество строк – Максимальное количество новых строк в секунду, которое может отправить агент Zabbix серверу или Прокси. Этот параметр заменяет опцию ‘MaxLinesPerSecond’ в zabbix_agentd.conf	Должен быть настроен как Активная проверка. Например: log[/home/zabbix/logs/logfile,,,100] Более подробную информацию смотрите здесь
logrt[имя файла в формате,<regexp>,<кодировка>,<макс кол-во строк>]
	Мониторинг файлов журналов (логов) с поддержкой ротации логов.	Журнал	имя файла в формате – имя файла в формате [абсолютный путь][имя файла в формате регулярного выражения] regexp – регулярное выражения для шаблона кодировка – Идентификатор кодовой страницы максимальное количество строк – Максимальное количество новых строк в секунду, которое может отправить агент Zabbix серверу или Прокси. Этот параметр заменяет опцию ‘MaxLinesPerSecond’ в zabbix_agentd.conf	Должен быть настроен как Активная проверка. Например: logrt[“\home\zabbix\logs\^logfile[0-9]{1,3}$”,,,100] Ротация логов базируется на времени последнего изменения файлов. Более подробную информацию смотрите здесь
eventlog[имя,<regexp>,<важность>,<источник>,<eventid>,<макс. кол-во строк>]
	Мониторинг журналов событий.	Log.	имя – имя журнала событий regexp – регулярное выражение важность – важность события Параметр может принимать следующие значения: “Information”, “Warning”, “Error”, “Failure Audit”, “Success Audit” источник – Имя источника eventid – регулярное выражение максимальное количество строк – Максимальное количество новых строк в секунду, которое агент может отправить Zabbix Серверу или Прокси. Этот параметр заменяет опцию ‘MaxLinesPerSecond’ в zabbix_agentd.conf	Должен быть настроен как Активная проверка. Например: eventlog[Application] eventlog[Security,,»Failure Audit»,,529|680] eventlog[System,,»Warning|Error»] eventlog[System,,,,^1$] eventlog[System,,,,@TWOSHORT] – здесь регулярное выражение с именем TWOSHORT, определено в веб-интерфейсе с типом результата Результат TRUE и самим выражением ^1$|^70$.
net.if.collisions[if]
	Коллизии Out-of-window.	Количество коллизий. Целочисленное.	if – интерфейс
net.if.in[if,<режим>]
	Входящая статистика по сетевому интерфейсу.	Целочисленное.	if – интерфейс режим – bytes количество байт (по умолчанию) packets количество пакетов errors количество ошибок dropped количество отброшенных пакетов	Начиная с версии 1.8.6 Zabbix агента поддерживаются мултибайтные имена интерфейса. \\Примеры: net.if.in[eth0,errors] net.if.in[eth0] Вы должны использовать для этого ключа Дельта (изменение в секунду), чтобы получить статистику по байтам в секунду.
net.if.list
	Список сетевых интерфейсов: Тип Состояние IPv4 Описание	Строковое		Поддерживается Zabbix агентом начиная с версии 1.8.1. Начиная с версии 1.8.6 Zabbix агента поддерживаются мултибайтные имена интерфейса. Отключенные интерфесы не добавляются в список. Обратите внимание, что включение/отключение некоторых компонентов Windows могут изменить порядок имени интерфейса в Windows.
net.if.out[if,<режим>]
	Исходящая статистика по сетевому интерфейсу.	Целочисленное.	if – интерфейс режим – bytes количество байт (по умолчанию) packets количество пакетов errors количество ошибок dropped количество отброшенных пакетов	Начиная с версии 1.8.6 Zabbix агента поддерживаются мултибайтные имена интерфейса. \\Примеры: net.if.out[eth0,errors] net.if.out[eth0] Вы должны использовать для этого ключа Дельта (изменение в секунду), чтобы получить статистику по байтам в секунду.
net.if.total[if,<режим>]
	Суммарная входящая и исходящая статистика на сетевом интерфейсе.	Целочисленное.	if – интерфейс режим – bytes количество байт (по умолчанию) packets количество пакетов errors количество ошибок dropped количество отброшенных пакетов	Примеры: net.if.total[eth0,errors] net.if.total[eth0] Вы должны использовать для этого ключа Дельта (изменение в секунду), чтобы получить статистику по байтам в секунду. Обратите внимание отброшенные пакеты поддердивабтся только если both net.if.in и net.if.out работают для отброшенных пакетов на вашей платформе.
net.tcp.dns[<ip>,зона]
	Проверяется работает ли сервис DNS.	0 – DNS недоступен 1 – DNS работает	ip – IP адрес DNS сервера (игнорируется) зона – зона для тестирования DNS	Пример: net.tcp.dns[127.0.0.1,zabbix.com] Интернациональные доменные имена не поддерживаются вместо них, пожалуйста, используйте имена IDNA.
net.tcp.dns.query[<ip>,зона,<тип>]
	Выполняет запрос на указанный тип записи DNS.	В случае успеха возвращает строку символов с типом требуемой информации.	ip – IP адрес DNS сервера (игнорируется) зона – зона для тестирования DNS тип – Тип записи запроса (по умолчанию SOA)	Пример: net.tcp.dns.query[127.0.0.1, zabbix.com, MX] тип может быть одним из: A, NS, CNAME, MB, MG, MR, PTR, MD, MF, MX, SOA, NULL, WKS, HINFO, MINFO, TXT, SRV Тип записи SRV поддерживается Zabbix агентом начиная с версии 1.8.6. Интернациональные доменные имена не поддерживаются вместо них, пожалуйста, используйте имена IDNA.
net.tcp.listen[порт]
	Проверяется находится ли указанный TCP порт в состоянии LISTEN.	0 – не находится 1 – находится в состоянии LISTEN	порт – номер порта TCP	Пример: net.tcp.listen[80] В Linux поддерживается начиная с версии Zabbix агента 1.8.4
net.tcp.port[<ip>,порт]
	Проверяет, возможно ли создать TCP подключение на указанный номер порта.	0 – не удалось подключиться 1 – подключение возможно	ip – IP адрес(по умолчанию 127.0.0.1) порт – номер порта	Пример: net.tcp.port[,80]может быть использовано для тестирования доступности Веб сервера, запущенного на 80 порту. Старое название: check_port[*] Для простого тестирования производительности TCP используйте net.tcp.service.perf[tcp,<ip>,<порт>] Заметьте, что эти проверки могут привести к возникновению дополнительных сообщений в файлах журналов системных демонов (сессии SMTP и SSH обычно журналируются).
net.tcp.service[сервис,<ip>,<порт>]
	Проверяется запущен ли сервис принимает ли он TCP подключения.	0 – сервис недоступен 1 – сервис работает	сервис – один из: ssh, service.ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp ip – IP адрес (по умолчанию 127.0.0.1) порт – номер порта (по умолчанию используется стандартный номер порта для указанного сервиса)	Например: net.tcp.service[ftp,,45] может быть использовано для проверки доступности FTP сервера на порту 45. Старое название: check_service[*] Обратите внимание, что в версиях Zabbix до 1.8.3 следует использовать service.ntp вместо ntp. Заметьте, что эти проверки могут привести к возникновению дополнительных сообщений в файлах журналов системных демонов (сессии SMTP и SSH обычно журналируются). Проверки зашифрованных протоколов (таких как IMAP на порту 993 или POP на порту 995) в настоящее время не поддерживаются. В качестве альтернативного способа, пожалуйста, используйте net.tcp.port для этих проверок. Проверка LDAP через Windows агента в настоящее время не поддерживается.
net.tcp.service.perf[сервис,<ip>,<порт>]
	Проверяется производительность сервиса	0 – сервис недоступен секунды – количество секунд потребовавшихся для подключения к сервису	сервис -один из: ssh, service.ntp, ldap, smtp, ftp, http, pop, nntp, imap, tcp ip – IP адрес (по умолчанию 127.0.0.1) порт – номер порта (по умолчанию используется стандартный номер порта для указанного сервиса)	Пример: net.tcp.service.perf[ssh] может быть использован для проверки скорости ответа SSH сервера. Старое название: check_service_perf[*] Обратите внимание, что в версиях Zabbix до 1.8.3 следует использовать service.ntp вместо ntp. Проверки зашифрованных протоколов (таких как IMAP на порту 993 или POP на порту 995) в настоящее время не поддерживаются. В качестве альтернативного способа, пожалуйста, используйте net.tcp.port для этих проверок. Проверка LDAP через Windows агента в настоящее время не поддерживается.
net.udp.listen[порт]
	Проверяется находится ли указанный UDP порт в состоянии LISTEN.	0 – не находится 1 – находится в состоянии LISTEN	порт – номер порта UDP	Пример: net.udp.listen[68] В Linux поддерживается начиная с версии Zabbix агента 1.8.4
proc.mem[<имя>,<пользователь>,<режим>,<cmdline>]
	Количество выделенной памяти под процесс с указанным именем запущенным под указанным пользователем	Использование памяти процессом.	имя – имя процесса пользователь – имя пользователя (по умолчанию все пользователи) режим – один из: avg, max, min, sum (по умолчанию) cmdline – фильтр по командной строке	Пример: proc.mem[,root] – использованная память для всех процессов работающих под пользователем “root”. proc.mem[zabbix_server,zabbix] – использованная память для всех процессов zabbix_server запущенных под пользователем zabbix proc.mem[,oracle,max,oracleZABBIX] – максимальное значение использованной памяти процессами запущенными под пользователем oracle и имеющими oracleZABBIX в содержимом командной строки
proc.num[<имя>,<пользователь>,<состояние>,<cmdline>]
	Количество процессов с указанным именем имеющим указанное состояние и запущенными под указанным пользователем	Количество процессов.	имя – имя процесса пользователь – имя пользователя (по умолчанию все пользователи) состояние – одно из: all (по умолчанию), run, sleep, zomb cmdline – фильтр по командной строке	Пример: proc.num[,mysql] – количество процессов запущенных под пользователем mysql proc.num[apache2,www-data] – количество процессов apache2 запущенных под пользователем www-data proc.num[,oracle,sleep,oracleZABBIX] – количество процессов в режиме sleep запущенных под пользователем oracle и имеющими oracleZABBIX в содержимом командной строки В Windows в качестве аргументов поддерживаются только имя и пользователь.
sensor[устройство,датчик,<режим>]
	Чтение аппаратного датчика.		устройство – имя устройства (если указывается <режим>, то в этом поле нужно вводить регулярное выражение) датчик – имя датчика (если указывается <режим>, то в этом поле нужно вводить регулярное выражение) режим – один из avg, max, min (если этот ключ не указан, устройство и датчик указываются дословно).	Для Linux 2.4 читает /proc/sys/dev/sensors. Например: sensor[w83781d-i2c-0-2d,temp1] До версии Zabbix 1.8.4 использовался формат датчика sensor[temp1]. Для OpenBSD читает hw.sensors MIB. Например: sensor[cpu0,temp0] – температура одного из ЦПУ sensor[cpu[0-2]$,temp,avg] – средняя температура первого из трех ЦПУ Поддерживается в OpenBSD начиная с Zabbix 1.8.4.
system.boottime
	Штамп времени (timestamp) времени загрузки системы.	Целочисленное.		Время в секундах.
system.cpu.intr
	Ошибки устройства.	Целочисленное.
system.cpu.load[<цпу>,<режим>]
	Загрузка ЦПУ.	Загрузка процессора(ов). Число с плавающей точкой.	cpu – номер CPU (по умолчанию все ЦПУ, поддерживается только “all”) режим – один из: avg1 (по умолчанию),avg5 (среднее за последние 5 минут), avg15	Пример: system.cpu.load[] Обратите внимание, возвращаемое значение не процентное отношение. Старое название: system.cpu.loadX
system.cpu.num[<тип>]
	Количество ЦПУ.	Количество доступных процессоров.	тип – один из: online (по умолчанию), max	Пример: system.cpu.num
system.cpu.switches
	Переключение контекста.	Счетчик переключений контекста.		Старое название: system[switches]
system.cpu.util[<cpu>,<тип>,<режим>]
	Утилизация ЦПУ.	Утилизация процессора в процентном отношении	cpu – номер ЦПУ (по умолчанию все ЦПУ) тип – один из: idle, nice, user (по умолчанию), system, kernel, iowait, interrupt, softirq, steal режим – один из: avg1 (по умолчанию),avg5 (среднее значение за последние 5 минут), avg15	Старое название: system.cpu.idleX, system.cpu.niceX, system.cpu.systemX, system.cpu.userX Пример: system.cpu.util[0,user,avg5]
system.run[команда,<режим>]
	Запускает указанную команду на удаленном хосте.	Текстовый результат выполнения команды	команда – команда для выполнения режим – один из: wait (по умолчанию ожидание завершения), nowait (без ожидания)	Пример: system.run[ls -l /] – подробный список файлов в корневой папке. Примечание: Для включения этой функциональности, в настройках агента должна быть опция EnableRemoteCommands=1.
system.hostname[<тип>]
	Возвращается имя хоста.	Строковое значение	тип (только для Windows, игнорируется остальными системами) – netbios (по умолчанию) или host	В Windows значение получается из функции GetComputerName() (для netbios) или функции gethostname() (для host) и из команды “hostname” в других системах. Пример возвращаемого значения www.zabbix.com Параметр для этого элемента данных поддерживается начиная с версии 1.8.6.
system.localtime
	Локальное системное время.	Численное или строковое значение.	utc – (по умолчанию) время начиная с начала Эпохи (00:00:00 UTC, Январь 1, 1970), измеряется в секундах. local – время в формате ‘гггг-мм-дд,чч:мм:сс.нн,+чч:мм’
system.stat[ресурс,<тип>]
	Статистика виртуальной памяти	Целочисленное	ent – количество процессорных единиц выделенных на ресурс (дробное) kthr,<тип> – информация о состояниях потоков ядра: r – среднее количество запускаемых потоков ядра (дробное) b – среднее количество потоков ядра помещенных в очередь ожидания Менеджера Виртуальный Памяти (дробное) memory,<тип> – информация о использовании виртуальной и реальной памяти: avm – активные виртуальные страницы (целое) fre – размер свободного списка (целое) page,<тип> – информация об ошибках страниц и активности страниц: fi – операции страничного ввода файлов в секунду (дробное) fo – операции страничного вывода файлов в секунду (дробное) pi – pages paged in from paging space (дробное) po – pages paged out to paging space (дробное) fr – pages freed (page replacement) (дробное) sr – количество сканированных страниц алгоритмом замещения страниц (дробное) faults,<тип> – соотношение ловушек и прервываний: in – прерывания устройства (float) sy – системные вызовы (float) cs – переключения контекста потока ядра (дробное) cpu,<тип> – разделеное использование процессорного времени в процентах: us – пользовательское время (дробное) sy – системное время (дробное) id – время простоя (дробное) wa – время простоя в ходе которого система обрабатывала запросы I/O диска/NFS (дробное) pc – количество использованных физических процессоров (дробное) ec – процентное соотношение размеченного занятого пространства (дробное) lbusy – indicates the percentage of logical processor(s) utilization that occurred while executing at the user and system level (дробное) app – отображает количество доступных физических процессоров в распределенном пуле (дробное) disk,<тип> – статистика о дисках: bps – отображает суммарное количество данных переданных (чтением или записью) на диск в байтах в секунду (целое) tps – indicates the number of transfers per second that were issued to the physical disk/tape (дробное) Этот элемент данных поддерживается начиная с версии 1.8.1.
system.swap.in[<устройство>,<тип>]
	Операции ввода в файл подкачки (с устройства в память).	Числовое значение	устройство – устройство файла подкачки (по умолчанию все устройства), тип – один из: count (по умолчанию, количество операций ввода в файл подкачки), sectors (количество секторов ввода в файл подкачки), pages (страниц ввода в файл подкачки). Смотрите поддержку по платформам для получения подробностей по умолчаниям.	Пример: system.swap.in[,bytes] Старое название: swap[in]
system.swap.out[<устройство>,<тип>]
	Операции вывода из файла подкачки (с устройства в память).	Числовое значение	устройство – устройство файла подкачки (по умолчанию все устройства), тип – один из: count (по умолчанию, количество операций вывода из файла подкачки), sectors (количество секторов вывода из файла подкачки), pages (страниц вывода из файла подкачки). Смотрите поддержку по платформам для получения подробностей по умолчаниям.	Пример: system.swap.out[,pages] Старое название: swap[out]
system.swap.size[<устройство>,<режим>]
	Размер swap.	Количество байт или процентное отношение	устройство – устройство swap (по умолчанию все устройства), режим – один из: free (по умолчанию, свободное пространство в swap), total (весь размер swap), pfree (свободное просмотранство в swap, в процентном отношении), pused (занятое просмотранство в swap, в процентном отношении)	Пример: system.swap.size[,pfree] – процентное отношение свободного места в swap Старое название: system.swap.free, system.swap.total
system.uname
	Возвращается подробная информация о хосте.	Строковое значение		Пример возвращаемого значения: FreeBSD localhost 4.4-RELEASE FreeBSD 4.4-RELEASE #0: Tue Sep 18 11:57:08 PDT 2001 [email protected]: /usr/src/sys/compile/GENERIC i386
system.uptime
	Время работы системы в секундах (uptime)	Количество секунд		Используйте Формат отображения s или uptime для того чтобы увидеть читаемые значения.
system.users.num
	Количество подключенных пользователей.	Количество пользователей		Используется команда who на стороне агента.
vfs.dev.read[<устройство>,<тип>,<режим>]
	Статистика чтения с диска.	Целочисленное значение для тип в: sectors, operations, bytes Дробное для тип в: sps, ops, bps	устройство – дисковое устройство (по умолчанию все;1; диски), тип – один из: sectors, operations, bytes, sps, ops, bps (необходимо указывать, какие именно параметры требуется использовать, т.к. они являются разными для различных ОС). состояния sps, ops, bps равны: сектора, операции, байт в секунду соответственно режим – один из: avg1 (по умолчанию),avg5 (среднее за последние 5 минут), avg15. Совместимо только в тип в: sps, ops, bps	Пример: vfs.dev.read[,operations] Старое название: io[*] Параметр тип со значениями ops, bps и sps лимитирован 8 устройствами на поддерживаемых платформах (7 устройств +1 для “all” устройств). Поддерживается LVM начиная с Zabbix 1.8.6. До Zabbix 1.8.6, можно было использовать только относительные имена устройств (например, sda), начиная с 1.8.6 опциональный префикс /dev/ может использоваться (например, /dev/sda)
vfs.dev.write[< устройство>,<тип>,<режим>]
	Статистика записи на диск.	Целочисленное значение для тип в: sectors, operations, bytes Дробное для тип в: sps, ops, bps	устройство – дисковое устройство (по умолчанию все;1; диски), тип – один из: sectors, operations, bytes, sps, ops, bps (необходимо указывать, какие именно параметры требуется использовать, т.к. они являются разными для различных ОС). состояния sps, ops, bps равны: сектора, операции, байт в секунду соответственно режим – один из: avg1 (по умолчанию),avg5 (среднее за последние 5 минут), avg15. Совместимо только в тип в: sps, ops, bps	Пример: vfs.dev.write[,operations] Старое название: io[*] Параметр тип со значениями ops, bps и sps лимитирован 8 устройствами на поддерживаемых платформах (7 устройств +1 для “all” устройств). Поддерживается LVM начиная с Zabbix 1.8.6. До Zabbix 1.8.6, можно было использовать только относительные имена устройств (например, sda), начиная с 1.8.6 опциональный префикс /dev/ может использоваться (например, /dev/sda)
vfs.file.cksum[файл]
	Подсчитывает контрольную сумму для файла	Подсчет контрольной суммы использует алгоритм UNIX cksum.	файл – полный путь к файлу	Пример возвращаемого значения: 1938292000 Пример: vfs.file.cksum[/etc/passwd] Старое название: cksum
vfs.file.exists[файл]
	Проверяется существует ли файл	0 – файл не существует 1 – файл существует	файл – полный путь к файлу	Пример: vfs.file.exists[/tmp/application.pid]
vfs.file.md5sum[файл]
	Контрольная сумма MD5 для файла	MD5 хэш для файла.		Пример возвращаемого значения: b5052decb577e0fffd622d6ddc017e82 Пример: vfs.file.md5sum[/etc/zabbix/zabbix_agentd.conf] Лимит в 64МБ для размера файла у этого элемента данных был удален в версии 1.8.6.
vfs.file.regexp[файл,regexp,<кодировка>]
	Поиск строки в файле	Найденная строка или EOF если выражение не найдено	файл – полный путь к файлу regexp – Регулярное выражение GNU кодировка – Идентификатор страницы кодировки	Пример: vfs.file.regexp[/etc/passwd,zabbix]
vfs.file.regmatch[файл,regexp,<кодировка>]
	Поиск строки в файле	0 – выражение не найдено \\1 – найдено	файл – полный путь к файлу regexp – Регулярное выражение GNU кодировка – Идентификатор страницы кодировки	Пример: vfs.file.regmatch[/var/log/app.log,error]
vfs.file.size[файл]
	Размер файла	Размер в байтах.	файл – полный путь к файлу	Файл должен иметь права чтения для пользователя zabbix Пример: vfs.file.size[/var/log/syslog]
vfs.file.time[файл,<режим>]
	Информация о времени файла.	Unix timestamp.	файл – полный путь к файлу режим – один из: modify (по умолчанию, время изменения), access – время последнего доступа, change – время последнего изменения	Пример: vfs.file.time[/etc/passwd,modify]
vfs.fs.inode[fs,<режим>]
	Количество inodes	Строковое значение	fs – файловая система режим – один из: total (по умолчанию), free, used, pfree (свободно в процентном отношении), pused (занято в процентном отношении)	Пример: vfs.fs.inode[/,pfree] Старое название: vfs.fs.inode.free[*], vfs.fs.inode.pfree[*], vfs.fs.inode.total[*]
vfs.fs.size[fs,<режим>]
	Размер диска	Размер диска в байтах	fs – файловая система режим – один из: total (по умолчанию), free, used, pfree (свободно в процентном отношении), pused (занято в процентном отношении)	В случае смонтированного диска, возвращает размер диска локальной файловой системы. Пример: vfs.fs.size[/tmp,free] Старые названия: vfs.fs.free[*], vfs.fs.total[*], vfs.fs.used[*], vfs.fs.pfree[*], vfs.fs.pused[*]
vm.memory.size[<режим>]
	Размер памяти	Размер памяти в байтах	режим – один из: total (по умолчанию), shared, free, buffers, cached, pfree, available	Старые названия: vm.memory.buffers, vm.memory.cached, vm.memory.free, vm.memory.shared, vm.memory.total
web.page.get[хост,<путь>,<порт>]
	Получает содержимое Веб страницы	Веб страницы в виде текста	хост – имя хоста пусть – путь к HTML документу (по умолчанию /) порт – номер порта (по умолчанию 80)	Возвращает EOF при ошибке. Пример: web.page.get[www.zabbix.com,index.php,80]
web.page.perf[хост,<путь>,<порт>]
	Получение времени полной загрузки Веб страницы	Время в секундах	хост – имя хоста пусть – путь к HTML документу (по умолчанию /) порт – номер порта (по умолчанию 80)	Возвращает 0 при ошибке. Пример: web.page.perf[www.zabbix.com,index.php,80]
web.page.regexp[хост,<путь>,<порт>,<regexp>,<длина>]
	Получает первое вхождение регулярного выражения в Веб странице	Совпадающая строка	хост – имя хоста путь – путь к HTML документу (по умолчанию /) порт – номер порта (по умолчанию 80) regexp – регулярное выражение GNU, длина – максимальное количество возвращаемых символов	Возвращает EOF в случае несовпадения или других неудачах (превышено время ожидания, ошибка подключения и т.п.). Пример: web.page.regexp[www.zabbix.com,index.php,80,OK,2]

[1] По умолчанию используется “all” первым параметром для ключей vfs.dev.* и возвращает суммарную статистику, включая: все блочные устройства такие как sda, sbd и их разделы sda1, sda2, sdb3 … и несколько устройств (MD raid) на основе этих блочных устройств/разделов и логические разделы (LVM) на основе этих блочных устройств/разделов.

В некоторых случаях возвращаемые значения следует рассматривать как относительные значения (изменяемые во времени), но не как абсолютные значения.

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

Шаблон или прототип элемента мониторинга будет выглядеть следующим образом (параметры для удобства пронумерованы):

eventlog[1- имя журнала,2-регулярное выражение,3-важность,4-источник,5-eventid,6-макс кол-во строк, 7-режим]

Тип данных: журнал (лог)

Далее рассмотрим конкретные практические примеры.

1. Ошибки в журнале приложений.

Максимально простой пример сбора ошибок в журнале «Приложение» (события уровня «Ошибка»)

eventlog[Application,,"Error",,,,skip]

2. Ошибки отложенной записи.

eventlog[System,,"Warning",,50,,skip]

краткие пояснения:

System — журнал система

Warning — тип события: предупреждение

50 — id события равно 50

skip — берем только свежие значения (не перечитываем весь лог)

триггер:

count(/Terminal server/eventlog[System,,"Warning",,50,,skip],30m)>7 and nodata(/Terminal server/eventlog[System,,"Warning",,50,,skip],60m)<>1

где Terminal server — это просто имя шаблона, в котором используются элемент данных и триггер

3. Ошибки диска.

eventlog[System,,"Warning",,153,,skip]

триггер:

count(/Template OS Windows by Zabbix agent active/eventlog[System,,"Warning",,153,,skip],30m)>5 and nodata(/Template OS Windows by Zabbix agent active/eventlog[System,,"Warning",,153,,skip],60m)<>1

4. ошибки в журнале событий от службы MSSQLSERVER.

eventlog[Application,,"Error","MSSQLSERVER",,,skip]

триггер:

count(/Template OS Windows SQL for 1C/eventlog[Application,,"Error","MSSQLSERVER",,,skip],8m)>0 and nodata(/Template OS Windows SQL for 1C/eventlog[Application,,"Error","MSSQLSERVER",,,skip],10m)<>1

---

Полезные ссылки:

https://www.zabbix.com/documentation/5.0/ru/manual/config/items/itemtypes/zabbix_agent/win_keys

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

 

zabbis_logos.png

Установка и настройка Zabbix 6.0

Раздел 1. Введение

Раздел 2. Запуск Zabbix

Раздел 3. Настройка Zabbix. Знакомство с системой.

Раздел 4. Мониторинг сетевых узлов по ICMP

Раздел 5. Расширенный мониторинг сетевых узлов по ICMP

Раздел 6. Мониторинг сетевых сервисов. Карты сетей.

Раздел 7. Агентный мониторинг

Раздел 8. Мониторинг базы данных MySQL

Раздел 9. Мониторинг и тюнинг Zabbix.

Раздел 10. Концепция мониторинга. Типы пользователей Zabbix.  Оповещения.

Раздел 11. Grafana — среда визуализации.

Раздел 1. Введение

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

1. Отслеживание состояния сетевого оборудования и серверов;

2. Определение работоспособности сетевых сервисов;

3. Проверка среды передачи данных, качества оказываемых услуг;

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

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

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

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

Платные

PRTG	Решение для мониторинга крупных корпоративных сетей.  Страна производитель — Германия.
OSG (Orange)	Решение для обслуживания крупных корпоративных сетей.  Замечательна в вопросах интеграции под техническое задание заказчика.  Страна производитель — Россия.
SolarWinds	Решение для обслуживания крупных корпоративных сетей/ Страна производитель — США.
SCOM	Решение для обслуживания серверов инфраструктуры Microsoft Windows Server. Страна производитель — США.
WatsUP Gold	Решение для мониторинга небольших сетей. Имеет ряд недостатков по сравнению с прочими платными аналогами. Страна производитель — США.
Cisco Prime	Mono Vendor ПО для обслуживания сетей, построенных на оборудовании Cisco.  Страна производитель — США.
SNMPc	Узкоспециализированное решение для мониторинга оборудования по протоколам SNMP и ICMP.  Страна производитель — Россия (Agneko SNMPc), США (SNMPc Network Manager)

Бесплатные (свободно распространяемые)

Zabbix	Универсальная, стабильная, масштабируемая, широкий функционал, возможность создания своих инструментов. Страна производитель — Латвия.
Prometheus	Универсальная, стабильная, имеет специализированную базу данных, способную выдерживать высокие нагрузки. Открытый проект.
Nagios + Cacti	Своеобразная система, запускаемая и поддерживаемая в ручном режиме.
10Strike	Ограниченный функционал, demo-версия. Расширенный функционал — в платном варианте. Подходит для небольших сетей. Страна производитель — Россия.

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

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

zab251

Система мониторинга Zabbix, с помощью специальных сетевых протоколов и инструментов (ICMP, SNMP, TCP/UDP, скрипты и агенты) собирает с объектов мониторинга различные параметры, характеризующие их работоспособность. Собранные данные упорядочиваются в базе данных Zabbix, анализируются и визуализируются в удобных для восприятия Администратором форматах (графики, карты сетей). При условии отклонения получаемых параметров от установленных эталонных значений (при срабатывании триггеров) – срабатывают инструменты оповещения администратора системы мониторинга или сконструированные администратором скрипты. Оповещение может быть визуальным, звуковым, в виде электронного письма – предусмотрено несколько различных видов реакции на зафиксированные события (рис ниже)

zab252

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

Классический мониторинг сетевых устройств осуществляется по протоколам ICMP и SNMP. 

Протокол ICMP служит для простой проверки доступности сетевого узла, с возможностью дополнительного анализа процента потерянных ICMP-пакетов и времени задержки. Этот протокол является базовым элементом любого мониторинга, и используется повсеместно.

Протокол SNMP – протокол, созданный для мониторинга и управления сетевыми устройствами. Все современные сетевые устройства без исключения поддерживают протокол SNMP. На сетевых устройствах существуют (запрограммированные при производстве) базы объектов SNMP, или так называемые MIB-базы (management information base). В MIB-базах содержатся как статические объекты, которые не изменяются в процессе работы устройства (инвентарные номера, модели и названия устройств), так и динамические, которые с течением времени меняют свои значения (загрузка трафиком сетевого интерфейса, температура и загрузка процессора, уровни ошибок, и многое другое). Производители размещают в сети Интернет документацию на MIB своих сетевых устройств – по сути, это структурированные текстовые файлы или группы файлов, которые содержат информацию обо всех SNMP-параметрах устройства, к которому они относятся, и их возможные значения. Каждый объект в MIB имеет свой уникальный цифровой адрес OID (Object IDentificator) и имя Object Name. Система мониторинга обращается к сетевому устройству по протоколу SNMP и запрашивает цифровые значения конкретных OID. Разумеется, нужно знать, какой OID в MIB-базе хранит в себе то или иное значение. Для этого нужно уметь работать с MIB-файлами (и документацией производителя), анализируя которые, можно получить требуемые для решения поставленных задач OID.

Протокол SNMP представляет массу возможностей для получения самой, казалось бы, неожиданной полезной информации при опросе сетевых устройств. Например, при опросе источников бесперебойного питания (если они имеют сетевые интерфейсы) – можно получить данные о температуре термодатчика и значения напряжения в сети электропитания. При опросе коммутаторов, можно получать такую специфическую информацию, как уровень ошибок на сетевом интерфейсе, а при работе с маршрутизаторами – получать статистику IP SLA тестов (технология мониторинга качества услуг связи). Протокол SNMP является незаменимым при мониторинге сетевого оборудования.

Доступность сетевых сервисов осуществляется с помощью открытия TCP-сессий на порт тестируемого сетевого сервиса (речь идет о так называемых безагентных проверках, когда на стороне тестируемого сервиса нет дополнительного ПО, и анализируется лишь возможность установления TCP-соединения). Для развернутого мониторинга серверов ОС Windows и Linux существует технология так называемых агентов, когда на объект мониторинга (сервер) устанавливается дополнительное ПО (Zabbix-агент), которое и отправляет серверу мониторинга Zabbix необходимые данные. Все эти и некоторые другие технологии мониторинга будут подробно рассмотрены в нашем курсе, и соответствующие инструменты будут реализованы на практике, в системе Zabbix.

Оглавление (↑↑↑↑↑↑↑↑↑)

Раздел 2. Запуск Zabbix

1) СОЗДАНИЕ ВИРТУАЛЬНОЙ МАШИНЫ И УСТАНОВКА UBUNTU 22.04

Для установки нам потребуется создать  виртуальную машину (будем  использовать virtual box + ubuntu server 22.04)

при создании виртуальной машины выбираем тип диска VMDK и фиксированный объем жесткого диска 15 гб

рекомендую выделить 4 гб оперативной памяти

в настройках сети выбираем «сетевой мост»

zab1

выбирайте простые имена пользователя 

во время установки выбираем «стандартную версию сервера», а не минимальную +  «open ssh сервер» (чтобы подключатсья по ssh), все отстальные пакеты выбирать не требуется

 2) НАСТРОЙКА ВИРТУАЛЬНОЙ МАШИНЫ

Настройка сети:

Для начала настроим сеть. В ubuntu это делается через netplan

 ip -c a  узнаем сетевой адрес, который настроен в данный момент (который получаем по dhcp)

cd /etc/netplan  — переходим в данную директорию и видим файлик по умолчанию 00-installer-config.yaml

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

cd /etc/netplan — переходим в директорию 

cp 00-installer-config.yaml 02_network_new.yaml создаем копию 

-rw-r—r— 1 root root 249 Feb 19 15:58 00-installer-config.yaml
-rw-r—r— 1 root root 284 Feb 19 16:02 02_network_new.yaml

nano 02_network_new.yaml — редактируем файлик (я выставил себе статический ip адрес 192.168.88.150)

  

zab2

 FAQ NETPLAN

Для проверки нашего конфигурационного файла вводим:

netplan —debug generate

Для применения настроек вводим:

netplan apply

Настройки сразу же применяются. Для проверки прописываем:

ip -c a

 

zab3

 Для настройки рекомендую подключиться к серверу по ssh (я использую mobaXterm)

Обновление системы:

sudo apt update

sudo apt upgrade

sudo -s   чтобы постоянно не прописывать судо (становимся рутом)

reboot

3) УСТАНОВКА ZABBIX

Будем устанавливать Zabbix 6.0 LTS на нашу UBUNTU Server 22.04

Заходим на сайт zabbix.com и выбираем нужную версию:

cat /etc/issue — узнаем какая версия дистрибутива установлена 

zab4

zab5

Команда wget добавит в файл /etc/apt/sources.list, содержащий список репозиториев по умолчанию, новый путь, указывающий на пакет zabbix, подходящий к нашей системе ОС Ubuntu (кстати, в качестве БД будет использована MySQL, из-за своей простоты).

# wget https://repo.zabbix.com/zabbix/6.0/ubuntu/pool/main/z/zabbix-release/zabbix-release_6.0-4%2Bubuntu22.04_all.deb

 Команда dpkg –i извлекает информацию о составляющих релиза Zabbix версии 6.0.

# dpkg -i zabbix-release_6.0-4+ubuntu22.04_all.deb

 Вновь обновим информации о репозиториях.

# sudo apt update

 На заметку! Команда dpkg –i актуализировала сведения о доступных для установки модулей пакета zabbix. После ввода в консоли команды «sudo apt-get install zabbix- » нажмите клавишу TAB – система предложит Вам возможные варианты дальнейшего ввода. Вводя первые буквы части команды и используя нажатие TAB – Вы сэкономите массу времени

Перед установкой Zabbix пропишите в браузере ip адрес вашей виртуальной машины, в моем случае:

zab6

 

Должна открыться заглушка апача:

zab7

Установите Zabbix сервер, веб-интерфейс и агент

# apt install zabbix-server-mysql zabbix-frontend-php zabbix-apache-conf zabbix-sql-scripts zabbix-agent

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

 Сначала осуществим вход в БД MySQL

# sudo mysql -uroot -p

root

Далее мы попадаем в командную строку БД. Создадим базу данных zabbix_db, с кодировкой utf-8:

mysql> create database zabbix_db character set utf8mb4 collate utf8mb4_bin;

При правильном вводе команды система подтвердит ввод сообщением OK. В случае ошибки – выведет ERROR. Cоздадим пользователя и пароль для доступа к конкретной базе.

mysql> create user zabbix_us@localhost identified by 'zabbix_pw'; 

Назначим пользователю базы данных (в нашем примере, имя этого пользователя – zabbix_us), который получит доступ к базе данных zabbix_db с паролем zabbix_pw, права на доступ к ней.

mysql> grant all privileges on zabbix_db.* to zabbix_us@localhost;

mysql> set global log_bin_trust_function_creators = 1;

mysql> quit;

На хосте Zabbix сервера импортируйте начальную схему и данные

sudo -s

zcat /usr/share/zabbix-sql-scripts/mysql/server.sql.gz | mysql --default-character-set=utf8mb4  -uzabbix_us -p zabbix_db   

(пароль zabbix_pw)

exit 

sudo mysql -uroot -p

(pass root)

set global log_bin_trust_function_creators = 0;

---

Важно! Удаление базы данных  и пользователя

DROP DATABASE zabbix_db;   --удалить базу данных

DROP USER 'имя_пользователя'@'хост';  --удалить пользователя

---

Следующий этап установки — измените конфигурационный файл zabbix_server.conf. В нем необходимо корректно указать название базы данных для Zabbix, а также логин и пароль для доступа к ней.

Откройте файл zabbix_server.conf:

# sudo nano /etc/zabbix/zabbix_server.conf

для поиска используйте ctrl+w. Для сохранения файлика ctrl+x

zab8

Запустите процессы Zabbix сервера и агента и настройте их запуск при загрузке ОС.

# systemctl restart zabbix-server zabbix-agent apache2

# systemctl enable zabbix-server zabbix-agent apache2

Мы почти закончили. Осталось немного – проверить конфигурацию PHP для веб-интерфейса Zabbix. Файл конфигурации Apache для веб-интерфейса Zabbix размещается в /etc/apache2/conf.d/zabbix или /etc/apache2/conf-enabled/zabbix.conf. Почти все параметры конфигурации PHP уже заданы. Отредактируйте файл zabbix.conf для веб-сервера:

# sudo nano /etc/apache2/conf-enabled/zabbix.conf

В этом документе нужно расскоментировать строчку : php_value date.timezone Europe/Moscow

После этого перезапускаем апач сервер:

# systemctl restart apache2

Теперь воспользуйтесь любым интернет-браузером на Вашем ПК – введите в адресной строке http://IP-адрес_виртуальной_машины/zabbix.

Для того, чтобы узнать ip, нужно прописать команду:

# ip -c a

В моем случае адрес zabbix —  192.168.88.150/zabbix

Для проверки времени в системе используем команду date или timedatectl:

date +%Y-%m-%d_%H:%M:%S

timedatectl 

Для установки нужной timezone, используем команду:

timedatectl list-timezones | grep Europe — узнаем доступные timezone

sudo timedatectl set-timezone Europe/Moscow — устанавливаем московской часовой пояс

sudo locale-gen ru_RU.UTF-8 — устанавливаем русскую локаль

sudo localectl set-locale LANG=ru_RU.UTF-8 — задать локаль по умолчанию

reboot — перезапускаем, чтобы применить изменения

Раздел 3. Настройка Zabbix. Знакомство с системой.

Открываем zabbix в браузере и выбираем русский язык:

zab10

Сервис запущен, но ему нужно провести самотестирование, проверить работоспособность всех модулей и корректность настроек. Нажмите кнопку «Далее» — Вы попадете в меню проверки настроек. Все пункты должны быть «ОК». Нажимае «Далее»

Настраиваем параметры подключения к базе данных (пароль мы устанавливали zabbix_pw)

zab11

Жмем «Далее» и устанавливаем имя сервера (к примеру zabbix-branch), временную зону по умолчанию и цветовую тему:

zab12

Нажмите кнопку «Далее» — и перейдите в финальное окно запуска системы

zab13

Логин и пароль по умолчанию – Admin / zabbix

Если у Вас проблема с подключением к БД, веб-интерфейс будет работать, но реально система мониторинга не будет функционировать, и статус запуска системы будет иметь значение «Нет».

zab14

ЗНАКОМСТВО С ZABBIX

Для того, чтобы попасть в веб-интерфейс zabbix мы используем адрес http://192.168.88.150/zabbix/

Чтобы интерфейс открывался при вводе ip, внесем небольшие изменения.

Отредактируйте конфигурационный файл 000-default.conf, отвечающий за работу с виртуальными хостами:

sudo nano /etc/apache2/sites-available/000-default.conf

Отредактируйте строку: DocumentRoot /var/www/html Приведя ее к виду: DocumentRoot /usr/share/zabbix

Сохраните изменения, и перезапустите сервис apache2:

sudo systemctl restart apache2 — перезапуск сервера апач

sudo systemctl status apache2 — проверка статуса 

После этого веб-интерфейс Zabbix будет доступен напрямую по IP-адресу.

Чтобы задать время хранения собранных данных в БД, войдите в меню Администрирование – Общие – Очистка истории. Мною выбран период хранения данных – 30 дней.

zab15

Для установки времени на сервере, жмем на виджет с часами и выставляем нужное время (как на сервере):

zab16

Приступим к освоению веб-интерфейса Zabbix! 

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

Меню Мониторинг – Панель отображает краткую сводку всей собираемой информации. Здесь гибко настраиваются панели отображения собранных данных, есть возможность размещать прямые ссылки на избранные графики, комплексные экраны и карты сетей (избранные – самые важные для администратора системы, по сути, быстрые ссылки на важные объекты).

!!ВАЖНО!! В Zabbix 6 используются панели, вместо комплексных экранов. В самих панелях можно создавать множество страниц и виджетов

zab17

Сконструируйте свою первую панель мониторинга (Меню Мониторинг – Панель, кнопка «Изменить панель»). Изучите инструменты изменения панели, и оставьте на ней 4 виджета — Информация о системе, Проблемы по важности, и две панели часов, для местного и московского времени.

zab18

Важно! Опыт мониторинга сетевой инфраструктуры с помощью Zabbix показывает, что для отображения основных сведений и проблемах в сети достаточно виджета «Проблемы по важности», или «Проблемы». Графики и карты сети нужны для анализа и визуализации. Но при правильной выстроенной концепции важностей триггеров, виджет «Проблемы по важности» — самый информативный инструмент в рамках Zabbix. Этому мы впоследствии будем уделять массу времени.

Теперь, для наглядности освоения системы, организуем мониторинг первого объекта, самого Zabbix-сервера, с помощью Zabbix-агента.

Отредактируйте конфигурационный файл агента :

# sudo nano /etc/zabbix/zabbix_agentd.conf

Для поиска используем ctrl+w

Для сохранения изменения ctrl+x

Предоставьте демону права root для сбора данных: AllowRoot=1 (раскоментировать нужную строчку и поставить 1)

Затем необходимо перезапустить zabbix agent:

# systemctl restart zabbix-agent

Для проверки статуса используем команду:

# systemctl status zabbix-agent

zab19

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

Для этого переходим в Настройка > Узлы сети, затем выбираем zabbix_server и активируем

zab20

Теперь познакомимся с панелью меню.

Панель — основной экран, на котором отображаются добавленные панели

Проблемы — предоставляет листинг зарегистрированных событий

Меню Мониторинг – Последние данные отображает все собранные данные с узла сети в значениях. Инструмент удобен для проверки работоспособности инструментов мониторинга как таковых, и, в случае необходимости, их отладки, в значении troubleshooting

zab21

Сохранение настроек + редактирование:

Для упрощения  подключения к серверу, рекомендую использовать  программу — moba_xterm

 

zab22

Создадим файлик в домшней директории:

cd — переходим в домашний каталог пользователя zabbix

mkdir dogi — создаем директорию dogi

cd  /home/zabbix/dogi — переходим в созданную директорю

nano credi.txt — создаем файлик с кредами и заполняем его

zab23

На этом этапе рекомендую отключить сервер и сделать снапшот в virtualbox

shutdown -h now

Далее запускаем виртуальную машину с заббиксом и продолжаем

 УСТАНОВИМ ЗАББИКС АГЕНТ НА СВОЙ ПК

Я буду устанавливать на пк с windows

Заходим на сайт заббикса, жмем скачать и выбираем заббикс агент

zab24

Создаем папку (где угодно) Я создал на диске C

C:\zabbix

В него скопирую содержимое скачанного архива (заббикс агент)

Редактируем C:\zabbix\conf\zabbix_agentd.conf  в нем нужно прописать ip адрес zabbix сервера

zab28

 

Если накосячили с конфигом заббикс агента (для винды) и запустили агент, то его можно удалить и запустить заново:

-i —install Установка Zabbix агента как сервиса. -d —uninstall Удаление сервиса Zabbix агента. -s —start Запуск сервиса Zabbix агента. -x —stop Остановка сервиса Zabbix агента.

zab27

Команда для установки заббикс агента (если создали папку C:\zabbix)

C:\zabbix\bin> .\zabbix_agentd.exe —config C:\zabbix\conf\zabbix_agentd.conf —install

После установки — нужно запустить агент:

C:\zabbix\bin> C:\zabbix\bin\zabbix_agentd.exe —start
zabbix_agentd.exe [15148]: service [Zabbix Agent] started successfully

Открываем порты firewall на пк с виндой (заходим в powershell через администратора) и прописываем 2 команды:

New-NetFirewallRule -DisplayName ‘Zabbix agent_inb’ -Profile ‘Any’ -Direction Inbound -Action Allow -Protocol TCP -LocalPort 10050

New-NetFirewallRule -DisplayName ‘Zabbix agent_out’ -Profile ‘Any’ -Direction Outbound -Action Allow -Protocol TCP -LocalPort 10050

 И тоже самое сделаем на нашем Zabbix сервере под управлением Ubuntu

sudo ufw allow from any to any port 10050 proto tcp

ДОБАВЛЕНИЕ ХОСТА В ЗАББИКС

Настройка->Узел сети-> Создать узел сети

Узказываем интерфейс — заббикс агент и вписываем ip адрес (пк на винде)

В шаблонах выбираем — операционные системы -> windows agent 

zab29

И в группу — операционные системы

zab30

Если все сделали правильно, то заббикс агент станет доступен (примерно через минуту, после добавления)

zab31

УСТАНОВКА zabbix-get

apt install zabbix-get — устанавливаем утилиту

Zabbix агент может работать в пассивном режиме и активном режиме

В пассивном режиме — zabbix сервер сам запрашивает информацию у заббикс агента по порту 10050

В активном режиме  — zabbix агент передает информацию по порту 10051

zabbix-get может отправить запрос для заббикс агента, имитируя заббикс сервер 

zabbix-get может быть на каком-то левом хосте , который никак не связан с zabbix server

Для работы zabbix get — необходимо, чтобы ip хоста (где установлен zabbix get) был добавлен в zabbix-get (в графе zabbix-get, где мы уже прописывали zabbix-get)

Примеры команд для zabix_get (<<= ссылка на оф документацию)

zabbix_get -s 192.168.88.20 -p 10050 -k «system.cpu.load[all,avg1]»

Прогоняем данную команду и видим 

zab32

 Все работает

 Теперь отлинкуем наш хост с windows

Для этого переходим в настройка->Узлы сети, затем жмем на имя (windows pc) и выбираем отсоединить и очистить

 

zab33

 Теперь наш zabbix server не собираем инфу с пк с windows (где установлен заббикс агент)

zab34

Логи заббикс агента (на linux) можем посмотреть следующей командой:

tail -f /var/log/zabbix-agent/zabbix_agentd.log

User parametrs — это параметр, который может вызывать заббикс сервер из вне, но по умолчанию,  в заббикс агенте — эта функция не работает

Этим параметром может быть python script,  то есть все, что угодно

Для теста так же создадим в virtual box виртуальную машину с Ubuntu Server

При создании разделов Ubuntu server — не забываем изменить рутовый раздел до максимума, из возможного

По умолчанию:

zab36

Стало, после изменений:

zab35

настроим ip адрес (192.168.88.160)   через netplan + пропишем в /etc/hosts  — адрес заббикс сервера и пк с винд

устанавливаем заббикс агент на новый сервер с убунтой

apt search zabbix-agent

apt install zabbix-agent

Добавим наш убнт сервер в zabbix

zab37

Посмотрим логи заббикс агента на убунта сервере

root@testubnt:/home/test# tail -f /var/log/zabbix-agent/zabbix_agentd.log

zab38

Видим, что он отбивается от попыток подключения заббикс сервера, так как в конфиге доступен адрес лупбека (127.0.0.1)

Правим конфиг заббикс агента на убунта сервере

nano /etc/zabbix/zabbix_agentd.conf

Найти строку просто: нажмите Ctrl+W (от английского «WhereIs»), введите то, что нужно найти, и нажмите Enter. Чтобы повторно найти ту же строку, нажмите Alt+W (следующий) и Alt+Q (предыдущий).

Находим Server и ServerActive, туда добавляем адрес нашего заббикс сервера

systemctl restart zabbix-agent — перезапускаем заббикс агент

systemctl enable zabbix-agent — включаем автозагрузку заббикс агента

systemctl status zabbix-agent — смотрим статус заббикс агента

Раздел 4. Мониторинг сетевых узлов по ICMP

Эта глава посвящена самому простому виду мониторинга сетевых узлов – с помощью протокола ICMP. Но так же мы изучим весь базовый функционал создания инструментов мониторинга и осуществления наблюдения за сетевыми узлами.  Скажем несколько слов о протоколе ICMP.

Протокол ICMP (Internet Control Message Protocol – протокол межсетевых управляющих сообщений) является диагностическим протоколом, он относится к сетевому уровню модели OSI (имеет канальный и сетевой заголовки, но не имеет транспортного заголовка). Наиболее распространённые инструменты ICMP – ping и traceroute (это условность, traceroute использует не только ICMP).

Ping служит для проверки доступности сетевых узлов (в том числе, возвращает информацию о потерях и задержке), traceroute определяет маршрут следования данных по IP-сетям (инструмент traceroute в Zabbix доступен в виде исполняемого скрипта, и применяется на Картах сети). Для обработки ICMP ping система Zabbix использует внешнюю утилиту fping. Эта утилита не является частью дистрибутива Zabbix и установлена дополнительно (в дистрибутиве ОС Ubuntu присутствует по умолчанию), в системе она хранится в каталоге /usr/sbin/fping.

Приступим к освоению материала. Внимательно отнеситесь к последовательности создания инструментов мониторинга — в дальнейшем это поможет избежать путаницы при администрировании системы (когда будет создано множество объектов). Сначала определимся с основными структурными единицами Zabbix – это Группы узлов сети, Шаблоны, и Узлы сети.

Группы узлов сети являются контейнерами для Шаблонов и Узлов сети. Группа узлов сети может существовать сама по себе, Шаблоны и Узлы сети обязательно входят в какую-либо Группу узлов сети. Шаблоны и Узлы сети невозможно создать или изменить так, чтобы они не входили в Группу узлов сети. Для удобства – в одних группах Администраторы Zabbix хранят Узлы сети, в других – шаблоны.

Шаблон – набор элементов данных (метрик, параметров), по ним Zabbix собирает информацию. В рамках Шаблона создаются все инструменты мониторинга для опроса конкретного узла, на их основе формируются графики и триггеры.

Узел сети – наблюдаемый объект, сетевой узел, который опрашивается по Шаблону.

Теперь к практике. Сначала создайте три Группы узлов сети: одну для Шаблонов, обслуживающих серверное оборудование (назовем ее Servers Templates), вторую — для пользовательских Шаблонов опроса (User Templates), которые мы будем создавать во время прохождения курса, и третью (Not Used Templates)– куда перенесем все предустановленные шаблоны Zabbix (ими мы пользоваться не будем). Заходим в настройки-> Создать группу узлов сети

Перенос шаблона в группу:

1) Настройки->Шаблоны

2) Открываем нужный шаблон (левым кликом по названию шаблона)

3) В графе  «группы» —  жмем «выбрать» и нходим нужную группу узлов сети

zab39

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

Теперь создайте группу узлов сети TEST internet Objects, для Узлов сети, располагающихся в сети Интернет, и в ней два узла сети – 8.8.8.8, и 8.8.8.5 (заведомо несуществующий), пример создания узла сети приведен ниже. Имена для узлов сети выберите самостоятельно.

настройки>> узлы сети>> создать узел сети

zab40

Имя узла сети – имя узла в базе данных Zabbix (и не может повторяться для разных Узлов сети), а видимое имя – имя узла во всех списках, картах и прочих элементах веб-интерфейса — может повторяться. Во избежание путаницы Видимое имя либо повторяет Имя узла сети, либо не заполняется вовсе. В поле IP-адрес Интерфейса агента добавьте 8.8.8.8. В данном примере не используйте DNS-имя google.com – сервис google распределенный, и в Российской Федерации доступен ряд серверов с совершенно другими IP-адресами.

На заметку! Если Вы все же работаете с доменными именами службы DNS, посмотреть соответствие IP-адресов доменным именам можно из консоли Ubuntu, с помощью команды nslookup google.ru

Результат должен получиться таким:

!Обратите внимание, что мы выбираем группу, используя фильтр (в правом вверхнем углу)

zab41

Создайте Шаблон Simple ICMP

zab42

После создания шаблона, переходим в настройки>>шаблоны и находим наш шаблон через фильтр

zab43

Внимание! При просмотре Шаблонов и Узлов сети – всегда делайте выборку по Группе узлов сети, которой принадлежат объекты. Это помогает избежать путаницы.

В Шаблоне Simple ICMP создайте свой первый элемент данных – первый инструмент мониторинга для опроса Узлов сети

Открываем шаблон, переходим в «элементы данных«, затем нажимаем «создать элемент данных» (в правом вверхнем углу)

zab45

имя: Доступность узла (любое имя)

ключ: выбираем из уже существующих — icmpping[<target>, <packets>, <interval>, <size>, <timeout>]

тип: простая проверка

тип информации: числовой (целое положительное)

интервал: 1m

zab44

 

Задайте параметры поля Ключ для инструмента icmpping. У icmpping 5 параметров: target – IP-адрес, по умолчанию используется адрес Узла сети, к которому применен Шаблон опроса; packets – количество пакетов (по умолчанию — 3), которые будут отправлены (если хотя бы один пакет вернется, опрос будет считаться удачным); interval – время между отправленными пакетами (по умолчанию — 1000 миллисекунд); size – размер пакета (по умолчанию 56 байт); timeout — время ожидания ответа (по умолчанию 500 миллисекунд).

Приведите запись к виду icmpping[,4,,,] – Элемент данных будет отправляться 4 icmp-запроса, 1 раз в секунду, размером 56 байт, с временем ожидания ответа 500 мс. Нажмите кнопку Добавить 

Для редактирования, просто изменяем значения в графе ключ (после того, как выбрали один из стандартных)

Должно получиться вот так:

  

zab46

Теперь несколько слов о триггерах. 

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

Пора создать первый Триггер. Учитывая проделанное выше, нас интересует Триггер, срабатывающий на неуспешный опрос Узла сети с помощью Элемента данных icmpping (такой триггер будет срабатывать, если сетевой узел будет недоступен, и элемент данных icmpping будет возвращать значение 0 вместо 1).

Конструирование триггера

Макрос — {HOST.CONN}

Список доступных макросов можно натйи в документации (>>>ссылка<<<)

zab49

В выражении триггера выбираем элемент данных из шаблона — Simple Icmp (доступность узла)

Выбираем функцию — анализировать последнее значение

Результат — какое значение элемента данных вызовет срабатывание триггера 

zab47

Финальный вид триггера

zab48

В окне редактирования триггера можно провести тест на срабатывание триггера

Для этого открываем конструктор выражений=>тест и проверяем 

zab50

Для нашей ситуации, если элемент данных icmpping[,4,,,] будет отдавать 1 при опросе сетевого узла, триггер срабатывать не будет (то есть, сетевой узел доступен), а если 0 – триггер сработает (с важностью – Чрезвычайная, узел недоступен).

zab51

Следующий инструмент Шаблона – график. Создайте график для нашего элемента данных

Здесь же, в настройках нашего шаблона simple icmp, переходив в пункт графики и жмем «добавить»

zab52

Настройте параметры отображения графика. Минимальное и максимальное значение оси Y настраивается для фиксированного или автоматического (вычисляемого) масштабирования данных по оси Y. В нашем случае Элемент данных icmpping имеет только два возможных значения – 0 и 1, имеет смысл зафиксировать ось Y в промежутке между 0 и 2.

Настроим сам график

Поле Функция может принимать значения – все, мин, сред, макс, и определяет, какие значения будут отображаться на Графике, когда существует более одного значения для элемента данных (после начала сбора мониторинга и занесения результатов опроса в базу данных, их всегда будет более одного). Выберем значение «все». Стиль отрисовки выберите Градиентная линия (смотрится эстетичнее прочих), расположение оси Y – По левой стороне, цвет – на Ваше усмотрение. После этого – добавьте сконструированный график.

Теперь присоедините к созданным ранее Узлам сети наш Шаблон Simple ISMP

zab53

zab54

В данном примере я использовал массовое действие. Присоединять Шаблоны к Узлам сети можно также в окне редактирования самих узлов сети, во вкладке Шаблоны

 

zab55

На заметку! Разные Узлы сети в одной Группе узлов сети могут наблюдаться разными Шаблонами опроса, и даже несколькими сразу.

Посмотрим на результат нашей работы. Войдите в меню Мониторинг – Панель

zab56

Мониторинг>>Последние данные 

zab57

Откроем график узла, который доступен

zab58

Сравним график с узлом, который не на связи

zab59

 

Мы наблюдаем сработавший триггер в поле «Проблемы», а в поле расшифровки триггера «Узел недоступен – 8.8.10.10» — это сработал тот самый макрос {HOST.CONN}, который мы использовали при создании триггера в его названии

!!На заметку!! Используйте макросы – это упрощает администрирование системы, повышает ее эффективность.

Например, при смене имени Узла сети – все триггеры, метки на картах сети и прочие инструменты, использующие макрос {HOST.NAME}, безболезненно сменят имена или конструкции. В противном случае Вам придется редактировать каждый элемент, что требует временных затрат и ненадежно (легко можно допустить ошибку).

Теперь создадим карту сети. Карта сети – инструмент визуализации узлов сети и топологий сетей.

Мониторинг>>Карты сетей >> создать карту сети

zab60

Параметры, доступные при создании карты сети:

zab61

!!Важно!! В данный момент Вы работает под правами учетной записи Zabbix Супер Администратора. Если Вы планируете разграничивать права пользователей на доступ к объектам мониторинга – Вам необходимо будет устанавливать права на каждую Карту сети определенным группам пользователей. Подробнее об этом будет рассказано далее.

Жмем добавить, затем открываем конструктор нашей карты сети (DNS сервера)

zab62

zab63

Обратите внимание на скриншот сверху – в подписи объекта на карте сети использованы два внутренних макроса Zabbix {HOST.NAME} и {HOST.CONN}. В случае изменения имени или IP-адреса самого узла сети, на Карте сети изменения произойдут автоматически.

Так же обратите внимание на скриншот сверху – на недоступном узле DNS Google fake, сработал триггер. Это триггер, который мы сконструировали в Шаблоне Simple ICMP.

Кликните на любом объекте карты сети, и ознакомьтесь с выпадающим меню. На данном этапе нас интересуют скрипты 

zab64

Скриптом в Zabbix может выступать любой пакет, исполняемый скрипт, системная утилита. Исполняются они на уровне операционной системы, от имени приложения Zabbix. В Zabbix предустановлены три скрипта, указывающие на системные утилиты namp (Detect operating system), fping (Ping), и traceroute (Traceroute). Пути для вызова скриптов указаны в меню Администрирование – Скрипты

zab65

Данные пути предустановлены в Zabbix по умолчанию. Но в дистрибутиве ОС Ubuntu 22.04 они отсутствуют, и их вызов с карты сети ведет к ошибке исполнения. Значит, нужно их установить и привести пути в соответствие.

С утилитой traceroute все довольно просто, ее нужно установить:

# sudo apt install traceroute

zab66

Трассировка уже работает, но мы можем изменить скрипт для трассировки. Для этого нужно исправить путь вызова скрипта в веб-интерфейсе Zabbix: traceroute -n {HOST.CONN}

Инструмент работоспособен. Теперь займемся nmap:

!!справка!! 

nmap — свободная утилита, предназначенная для разнообразного настраиваемого сканирования IP-сетей с любым количеством объектов, определения состояния объектов сканируемой сети.

 Для установки пропишем команду:

# sudo snap install nmap — доступна установка через snap пакет

найдем расположение nmap:

zab67

Дайте Zabbix-серверу права на исполнение утилиты от sudo:

Неправильный синтаксис файла /etc/sudoers может нарушить работу системы и сделать невозможным получение повышенного уровня привилегий, и поэтому очень важно использовать для его редактирования команду visudo

Допустим, вы хотите разрешить пользователю выполнять команды sudo без запроса пароля. Для этого откройте /etc/sudoersфайл:

командой # sudo visudo
Прокрутите вниз до конца файла и добавьте следующую строку:

username ALL=(ALL) NOPASSWD:ALL

Сохраните файл и выйдите из редактора . Не забудьте заменить «имя пользователя» на имя пользователя, которому вы хотите предоставить доступ.

Другой типичный пример — позволить пользователю запускать только определенные команды через файлы sudo . Например, чтобы разрешить только команды mkdir и rmdir , вы должны использовать:

/etc/sudoers

username ALL=(ALL) NOPASSWD:/bin/mkdir,/bin/rmdir

# sudo visudo

zabbix ALL = (ALL) NOPASSWD: ALL
zabbix ALL = (ALL) NOPASSWD: /snap/bin/nmap

zab68

Вместо редактирования файла sudoers вы можете сделать то же самое, создав новый файл с правилами авторизации в /etc/sudoers.d каталоге. Добавьте то же правило, что и в файл sudoers:

# echo «zabbix ALL = (ALL) NOPASSWD: /snap/bin/nmap» | sudo tee /etc/sudoers.d/zabbix

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

zab69

!!справка!! Команда tee в Linux считывает стандартный ввод и записывает его одновременно в стандартный вывод и в один или несколько подготовленных файлов. При обычном перенаправлении потока вывода строки команды будут записаны в файл, но мы не сможем увидеть вывод одновременно. С помощью команды tee мы можем это сделать!
!!справка!!  Команда echo — это очень простая и в то же время часто используемая встроенная команда оболочки Bash. Она имеет только одно назначение — выводить строку текста в терминал, но применяется очень часто в различных скриптах, программах, и даже для редактирования конфигурационных файлов.

Увеличьте в конфигурационном файле zabbix_server.conf время ожидания выполнения внешних скриптов до 15с (опция Timeout). Zabbix позволяет использовать сторонний программные модули, или скрипты, но со строгим ограничением времени выполнения. Это сделано для того, чтобы в случае невыполнения скрипта без его завершения (при условии массового мониторинга множества объектов), Zabbix не тратил ресурсы на бесполезное ожидание.

Я не знаю, где находится данный файл, поэтому запустим посик с помощью команды:

## find / -iname «zabbix_server.conf»    (поиск в директории по названию, без учета регистра)

zab70

открываем данный файлик через nano и находим в нем параметр Timeout

zab72

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

zab71

При попытке запустить —  выбивает ошибку:

zab73

Проблема связана с тем, что установили snap пакет. Сносим snap версию nmap и устанавливаем обычную

$ sudo snap remove nmap

$ sudo apt install nmap
run a command with nmap, if you get the error:
bash: /snap/bin/nmap: No such file or directory
use the following command to let go of the cached link:
hash -r
run nmap again,this worked for me.

После того, как удалили nmap (snap пакет) и прописали hash -r (почистили хеш) — заново пишем nmap и устанавливаем, как обычно

# sudo apt install nmap

Находим путь к данной утилите:

# sudo find / -name nmap

/usr/bin/nmap

Теперь правим права для пользователя zabbix:

# sudo visudo

zab74

Так же правим файлик /etc/sudoers.d/zabbix

# echo «zabbix ALL = (ALL) NOPASSWD: ALL» | sudo tee /etc/sudoers.d/zabbix

# echo «zabbix ALL = (ALL) NOPASSWD: /usr/bin/nmap» | sudo tee /etc/sudoers.d/zabbix

 

zab75

посмотрим содержимое данного файла:

#nano /etc/sudoers.d/zabbix

zab76

Правим настройки скрипта в самом заббиксе:

zab77

И проверяем работу всех скриптов (3 скрипта):

zab78

Скрипты работают, конечный вид вот такой:

zab79

 Хорошей альтернативой утилите traceroute является пакет mtr — он выполняет трассировку гораздо быстрее, и его отчеты гораздо информативнее. Самостоятельно установите mtr, и создайте скрипт с ключом ‘mtr {HOST.CONN} -c1 -w -n’. Ключ -n отключает разрешение доменных имен из IP-адресов, и это ускоряет работу команды.

 

zab80

Раздел 5. Расширенный мониторинг сетевых узлов по ICMP

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

Обратимся к меню Мониторинг => Панель, нас интересует раздел «Проблемы по важности»

zab81

Необходимо настроить уровни важности триггеров под наши требования. Уровни важности триггеров настраиваются централизованно в меню Администрирование –> Общие –> Опции отображения триггеров

Можно использовать свои названия для определения уровней важности

zab82

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

Теперь создадим шаблон опроса Complex Ping. Весь порядок действий по созданию элементов данных, триггеров и графиков в шаблоне опроса описан в предыдущей главе (сверху). Мы будем работать с элементами данных icmppingloss (возвращает процент потерь, или неудачных echo-запросов, то есть «пингов»), и icmppingsec (возвращает значение задержки в секундах, хотя общепринято использовать значение задержки в милисекундах). Создадим 3 элемента данных icmppingloss в шаблоне Complex Ping – они должны отправлять серии из десяти echo-запросов длиной 200, 1476, и 1500 байт. Пример ниже:

zab83

Инструмент icmppingloss определяет процент потерянных пакетов от общего количества отправленных, за один опрос. При создании элемента данных icmppingloss используйте тип элемента данных «Простая проверка», выберите стандартный элемент данных icmppingloss[<target>,<packets>,<interval>,<size>,<timeout>], и приведите ключ к виду icmppingloss[,10,,200,]. В результате у Вас должно получиться следующее

zab84

 

 Создаем три одинаковых элемента данных, меняем в них только размер пакетов:

zab85

Создадим триггеры для каждого элемента данных, с порогом в 10.  Для этого создаем триггер, в поле «выражение» — нажимаем добавить (не нужно прописывать вручную). Затем настраиваем условие — выбираем элемент данных + устанавливаем уcловие для функции >=10

zab86

 

Вот наши три созданных триггера:

zab87

Эти триггеры будут срабатывать при потере хотя бы одного icmp-пакета. В коммерческих сетях взято за правило обеспечение доставки не менее 99.9% отправляемых данных. На практике, это соблюдается в рамках крупных областей, но при достаточном удалении объекта (другая страна, или континент), потери могут достигать 90%, что, разумеется, недопустимо. Создадим график для всех трёх элементов данных icmppingloss

zab88

По аналогии, создайте 3 элемента данных icmppingsec, с теми же параметрами ключей, пороги триггеров укажите 300мс, и сконструируйте для них отдельный график. Вы уже научились создавать такие объекты, и легко справитесь с задачей. Единственный момент, который мы упомянули чуть раньше – инструмент icmppingsec отдает значение в секундах, но это крайне неудобно для восприятия (допустим, при отклике в 25мс, Zabbix вернет значение 0.025). Соответственно, нужно модифицировать получаемые данные. Для этого в элементе данных существует вкладка Предобработка, где данные можно обрабатывать перед размещением в базе данных. Нас интересует пункт Пользовательский множитель, установите его значение 1000. Важно помнить, что Zabbix сначала примет значение в секундах, а только потом домножит его на 1000, поэтому Тип информации должен быть с плавающей точкой

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

Вот пример элемента данных:

zab90

Вот так настраивается предобработка:

zab91

Настроим триггеры для каждого элемента данных (3):

zab92

 

В результате Вы должны получить примерно следующее

zab93

zab94

Добавьте в Группу узлов сети «Test internet Objects» следующие узлы (добавлять будем по доменным именам — DNS): seac.gov.cn, atlas.mx, tecos.mx, fuutmex.net, uol.com.br, terra.com.br, fc2.com, mixi.jp, livedoor.com, kyoto-u.ac.jp. Эти веб-сайты находятся в Китае, Мексике, Бразилии, Японии – мы выбрали их, потому что до них наблюдается «большой пинг», то есть большая задержка, и в некоторых случаях – потери пакетов. Присоединять к ним шаблоны опроса Simple ICMP и Complex ping. Быстрее будет – сначала добавить Узлы сети, а потом ко всем одновременно присоединить оба Шаблона, с помощью процедуры Массовое обновление

zab95

Результат привязки шаблонов к новым узлам сети:

zab96

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

На заметку!! Вообще, можно было объединить шаблоны опроса Simple Icmp и Complex Ping в один общий шаблон с тремя элементами данных (icmpping, icmppingloss, icmppingsec). Однако, в зависимости от поставленных задач, иногда лучше использовать несколько шаблонов опроса, опрашивающих различные элементы данных, чтобы не собирать лишнее.

В нашем примере, у нас не было задачи собирать с веб-сервера 8.8.8.8 элементы данных icmppingloss и icmppingsec, и мы использовали для него только шаблон опроса Simple ICMP.

Проанализируйте собранную статистику.

Сводная статистика на основной панели мониторинга

zab97

Выдержка из Последних данных

zab98

zab99

Графики:

zab100

Теперь обратимся к практической стороне – зачем вообще мы собираем данные задержки и потерь, да еще и с определенной длиной пакетов? С пакетами длиной 200 байт всё более менее очевидно – такая длина пакетов присуща сервисам голосовой телефонии. По картине вариации задержки (джиттера) и потерь, с помощью echo-запросов, можно делать косвенное заключение о качестве среды передачи. А вот с пакетами длиной 1476 и 1500 байт всё немного сложнее.

Мы посылаем данные через несколько стран, на соседний континент. Данные проходят через оборудование десятков провайдеров, различные среды передачи информации, через оборудование разных производителей. На канальном уровне модели OSI, разумеется, данные проходят и через сегменты сетей, работающих по технологии Ethernet. Максимальный размер полезного блока данных (MTU) для канального уровня составляет 1500 байт. Разумеется, передающая сторона, если требуется отправить большой объем данных, на канальном уровне упаковывает кадр с максимальной загрузкой в 1500 байт. Теоретически, если по пути прохождения данных стоит оборудование, которое по каким-то причинам не поддерживает MTU такой длины (самое явное – GRE-туннель, сокращающий MTU до 1476 байт за счет собственных заголовков), оно фрагментирует (разбивает) уже пакет (полезную нагрузку кадра) на два или более небольших блоков и передает дальше. И в общем случае никто не замечает такого ограничения. Но бывают сетевые приложения, которые при передаче запрещают фрагментировать свои данные (с помощью флага DF в заголовке IP-пакета). И тогда интерфейс, не поддерживающий большие MTU, удаляет данные, и уведомляет передающую сторону (с помощью специального пакет ICMP) о том, что необходимо уменьшить MTU. Некоторые сетевые сервисы могут просто не работать при использовании такой среды передачи.

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

zab101

Так же мы можем проверить это через консоль. Пинганем ресурс, изменив размер пакета

zab102

zab103

СПРАВКА по MTU!!

Параметр MTU (Maximum Transmission Unit; максимальная единица передачи) означает максимальный размер пакета, который может быть передан по сети без фрагментации. Если пакет будет иметь больший размер, чем установленное значение MTU, он будет фрагментироваться (разбиваться) на более мелкие. При большом количестве таких пакетов это может значительно замедлить передачу данных по сети.

При использовании неправильного размера MTU возможны проблемы с открытием некоторых сайтов в браузерах, сбои в работе VoIP-телефонии, проблема с приемом или передачей файлов по сети. Для исправления такой ситуации нужно проверить установленное текущее значение MTU, а также выяснить оптимальный его размер. Использование оптимального размера MTU может значительно улучшить производительность сети. Максимальная скорость достигается, когда нагрузки всех пакетов в потоке имеют длину, равную значению MTU.

Во многих сетевых устройствах имеется возможность установить вручную значение MTU для нужного интерфейса, но нужно правильно определить его оптимальный размер.

Рассмотрим один из самых простых и точных способов определения оптимального размера MTU.
Для этого будем использовать утилиту ping. С помощью неё мы будем отправлять запросы в сеть и постепенно увеличивать размер пакета до тех пор, пока не появится сообщение о необходимости фрагментации пакета.

Выполнение команды ping будем производить в командной строке операционной системы Windows. Для подключения к командной строке Windows 10 нажмите комбинацию клавиш Win + R (в ранних версиях Windows нажмите Пуск > Выполнить) и в появившемся окне в поле Открыть впишите команду cmd. Нажмите кнопку OK (или клавишу Enter на клавиатуре).

Синтаксис используемой команды ping будет следующий:

ping [url] -f -l <размер_пакета>

В качестве url используйте какой-нибудь популярный домен.

Флаг -f запрещает фрагментацию пакета.

Флаг -l <размер_пакета> устанавливает размер пакета при отправке его в сеть. Обращаем ваше внимание, что во флаге -l используется строчная буква L.

Приведем пример. Выполним пинг до сайта www.yandex.ru с размером пакета 1450 байт:

ping www.yandex.ru -f -l 1450

ping-mtu-01.png

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

ping-mtu-02.png

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

Но это ещё не значение MTU. Мы получили значение MSS (Maximum Segment Size), которое определяет максимальный размер блока данных в байтах. Этот параметр не учитывает длину заголовков ICMP и IP. В нашем случае значение MTU = MSS + заголовок IP + заголовок ICMP.

Теперь к полученному в ходе тестирования числу прибавим 28 байт, которые зарезервированы под заголовок данных (20 байт для заголовка IP и 8 байт для заголовка запроса протокола ICMP). Для нашего примера MTU=1464+28=1492 байт (это оптимальное значение параметра MTU).

Для выхода из интерфейса командной строки выполните команду exit.

---

На этом мы заканчиваем с мониторингом объектов в данной главе, однако у нас возникла новая проблема. Мы включили мониторинг некоторого количества объектов по протоколу ICMP, что привело к небольшому росту используемых Zabbix аппаратных ресурсов. Это может показаться странным, но предустановленный конфигурационный файл Zabbix по умолчанию имеет крайне низкие требования к аппаратной платформе (не может задействовать больше, чем регламентировано его конфигурационным файлом). В результате –при попытке обработать 10 Узлов сети с 6-ю элементами данных на каждый Узел (по 10 echo-запросов на каждый), возникают очереди обработки запросов, так как нужно обработать порядка 600 запросов в минуту

Возникновение очередей обработки запросов:

zab104

Заполненость процессинга icmp:

zab105

Нужно предоставить Zabbix системные ресурсы, отредактировав некоторые параметры его конфигурационного файла. Этот процесс иногда называют «тюнингом» конфигурационного файла. В дальнейшем мы подробнее разберемся в параметрах конфигурационного файла, а пока просто сделаем систему работоспособной – предоставив ресурсы утилите fping (Zabbix не имеет собственного инструмента отправки echo-запросов, он использует fping, которая исполняет запросы на уровне ОС). О том, что системные ресурсы нужны именно утилите fping, можно судить из кривой «Zabbix busy icmp pinger process» на рисунке сверху, и веренице очередей Простых проверок (под которую и подпадает fping). Чтобы предоставить Zabbix ресурсы для работы fping – отредактируйте конфигурационный файл Zabbix:

# sudo nano /etc/zabbix/zabbix_server.conf

StartPollers = 3

StartPingers = 50
StartPreprocessors = 30
StartPollersUnreachable = 30

После сохранения файла – перезагрузите Zabbix:

# systemctl restart zabbix-server zabbix-agent apache2

Результатом наших действий является очистка очереди и падение параметра кривой «Zabbix busy icmp pinger process»

Заполненность очереди Простых проверок после тюнинга параметров:

zab107

 Заполненность процессинга ICMP после тюнинга параметров:

zab106

Система Zabbix собирает, упорядочивает и предоставляет администратору данные о результатах мониторинга, причем именно администратор конструирует все необходимые инструменты мониторинга, пороговые значения триггеров, формат вывода данных. Zabbix можно сравнить с конструктором, и Ваша задача – овладеть им.

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

Раздел 6. Мониторинг сетевых сервисов. Карты сетей.

В этой главе мы изучим методы проверки доступности сетевых сервисов (так называемые простые проверки). Как известно, тип сетевого сервиса определяется на транспортном уровне модели OSI – по номеру порта приложения. Основные протоколы транспортного уровня модели OSI – TCP (протокол с установлением соединения (TCP-сессии) и гарантией доставки) и UDP (протокол без установления соединения и без механизма гарантии доставки). Zabbix осуществляет мониторинг с помощью инструментов, проверяющих доступность сетевых сервисов. Zabbix располагает четырьмя инструментами (по два на каждый протокол), проверяющими, отвечает ли сетевой узел на TCP и UDP запросы по определенным портам, и измеряет их производительность по времени отклика 

Таблица Инструменты мониторинга сетевых сервисов

zab108

Создайте:

1) шаблон опроса TCP UDP Service Monitor, в который войдут все четыре инструмента мониторинга сетевых сервисов, приведенных в таблице (инструменты мониторинга сетевых сервисов)

2) В этом шаблоне создайте элемент данных net.tcp.service[http,,80] и триггеры, срабатывающие на наличие и отсутствие ответа сервиса.

3) Также создайте элемент данных net.tcp.service.perf[http] и график, показывающий время ответа сервиса. Используйте тип данных «Числовой (с плавающей точкой)», и множитель 1000.

4) Затем аналогичным образом создайте элементы данных для мониторинга таких сетевых сервисов, как HTTP, HTTPS, FTP, SSH, NTP.

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

!!ВАЖНО!! Для клонирования элемента данных — нужно в него войти, затем нажать «клонировать» (после этого, снизу появится кнопка «добавить»), затем изменить название и ключ элемента данных. Если изменить ключ, но не изменить название — элемент будет создан. Получится 2 элемента данных с одинаковыми названиями, поэтому тут аккуратней

zab109

Проверим результаты проделанной работы. Вы должны получить следующий набор инструментов

 

zab110

zab115

 

zab112

Теперь проверьте работу Шаблона опроса TCP UDP Service Monitor. Создайте группу узлов сети Internet Sites Service, и добавим в нее такие узлы, как ya.ru, google.com, 127.0.0.1 («петлевой интерфейс» нашей ОС Ubuntu, система будет опрашивать сама себя), mozilla.org, ftp.mozilla.org, ntp1.stratum1.ru. У Вас должен получиться следующий набор узлов сети:

zab116

Теперь перейдите на основную панель мониторинга, и проанализируйте сработавшие триггеры

zab117

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

На заметку! Тщательно планируйте количество триггеров и степени их важности, не делайте оповещения избыточными. Любое массовое оповещение о маловажных событиях ведет к снижению эффективности системы мониторинга, поскольку администратор системы перестает воспринимать информацию от нее. Для «журналирования» (упорядоченного хранения) информации – используйте графики, и при необходимости извлекайте информацию из них.

Уменьшить количество триггеров и повысить эффективность мониторинга для нашего примера можно несколькими способами:

1) Деактивировать (или удалить) триггеры в шаблоне TCP UDP Service Monitor – но тогда мы потеряем часть важных срабатываний;

2) Разбить группу Internet Sites Service на несколько групп, где Узлы сети будут объединены в отдельные группы по принадлежности к тому или иному сетевому сервису (HTTP, NTP, SSH) и создать для каждой группы свой шаблон опроса – такой подход является самым правильным. Его нужно применять при глобальном планировании системы оповещений, но мы уже создали группу узлов сети и шаблон для нее.

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

Теперь создадим инструмент мониторинга, интересный с прикладной точки зрения. Допустим, стоит задача осуществлять мониторинг времени отклика различных NTP-серверов, чтобы выбрать самый «близкий» из доступных.

Создайте группу узлов сети Internet Sites NTP, и шаблон опроса NTP Service Monitor (в группе User Templates). В шаблоне NTP Service Monitor, создайте элемент данных net.udp.service.perf[ntp,,123], и график к нему. После этого добавьте в группу узлов сети Internet Sites NTP ряд NTP-серверов, находящихся в различных уголках мира: 0.ru.pool.ntp.org, 0.africa.pool.ntp.org, 0.europe.pool.ntp.org, 0.oceania.pool.ntp.org, 0.south-america.pool.ntp.org, 0.north-america.pool.ntp.org

zab118

Сейчас мы имеем для каждого узла сети отдельный график, но чтобы сравнить все результаты мониторинга серверов точного времени на одном графике, создайте его в рамках узла сети 0.ru.pool.ntp.org (а не шаблона NTP Service Monitor). Войдите в меню Настройка – Узлы сети, и создайте график NTP All

Создание графика для отденого узла сети

zab119

zab120

В результате, для каждого узла группы узлов сети Internet Sites NTP стал доступен график NTP all (поскольку в его построении участвуют элементы данных, относящиеся к каждому узлу сети группы). При анализе графика можно выбрать самый «быстрый» по времени отклика сервер, и использовать его как источник точного времени в своей сети 

Общий график времени откликов NTP серверов

zab121

Очевидно, что самым стабильным показывает себя сервер 0.ru.pool.ntp.org.

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

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

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

1) сначала подберите подходящий фон для карты – найдите в сети Интернет и сохраните на свой компьютер любую схематичную карту мира. Загрузите ее в Zabbix в качестве фона (перейдите в меню Администрирование – Общие – Изображения – Фон – Создать фон)

2) После этого создайте Карту сети (Мониторинг-Карта сетей-Создать карту сети), и разместите на ней сервера точного времени (используйте найденный фон). В Вашем распоряжении шесть NTP-серверов – добавьте 6 иконок, и настройте их следующим образом

zab122

 

Установите объектам тип «Узел сети», и в поле Узел сети начинайте вводить имена объектов группы Internet Sites NTP – в выпадающем списке Вы сможете выбрать нужный узел. В поле «Подпись» добавьте запись вида:

{HOST.NAME}
Время отклика: {0.ru.pool.ntp.org:net.udp.service.perf[ntp,,123].last()}

для узла 0.ru.pool.ntp.org. Это обращение к значению, сохранённому в базе данных Zabbix. На карте будет отображаться последнее значение элемента данных net.udp.service.perf[ntp,,123] для узла 0.ru.pool.ntp.org. Обязательно нажмите на кнопку «обновить», после того, как добавите все необходимые элементы на карту.

Запомните этот прием – он очень полезен при визуализациях! В итоге, у Вас должно получиться примерно следующее 

 

zab123

Шутка, за такое вас уволят. В курсе представлен старый формат прописи макроса, а нам нужен новый, так как курс для 6й версии

Нам нужно изменить составить макрос, для определения задержки.

1) Создаем тестовый триггер и определяем, как должно выглядеть выражения, для определения последнего значения (last) для элемента данных «Время отклика NTP». Для этого переходим в узлы сети и жмем на «триггер» и «создать триггер»

zab124

2) В графе «выражение», жмем «добавить» , заполняем и жмем «вставить»

zab125

3) Видим, как выглядит выражение, для определения последнего значения нашего элемента данных «Время отклика NTP»

last(/0.africa.pool.ntp.org/net.udp.service.perf[ntp,,123])=0

4) Подпись к иконке, любая строка.
В этом поле поддерживаются макросы выражений, но только с with avg, last, min и max функциями, со временем в качестве пара

5) Финальный вид подписи, чтобы она корректно отрабатывала

{HOST.NAME}

Время отклика: {?last(/0.africa.pool.ntp.org/net.udp.service.perf[ntp,,123])}

К нашему выражению, которое мы получили при создании триггера, нужно просто добавить ? и заключить все в {}

zab126

Финальный результат 

 

zab127

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

Раздел 7. Агентный мониторинг

Этот раздел посвящен мониторингу узлов сети с помощью специального ПО – Zabbix-агентов. Они применяются для мониторинга серверов и рабочих станций, и совместимы с большинством распространённых ОС — Windows, Linux, MacOS. Принцип действия следующий: на объект наблюдения устанавливается специальное ПО – Zabbix-агент, который, в зависимости от установленного режима, активного или пассивного, отправляет на Zabbix-сервер запрашиваемые данные. Взаимодействие Zabbix-сервера и Zabbix-агента может проходить в нешифрованном и шифрованном режиме.

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

В активном режиме Zabbix-агент сам инициирует TCP-соединение с Zabbix-сервером, и сам запрашивает содержимое шаблона опроса. Затем Zabbix-агент собирает данные с локальной ОС, где он установлен, и сам отправляет данные на Zabbix-сервер (push-модель опроса). Часто применяется для работы из приватных подсетей, скрытых за NAT (немного упрощается процесс настройки сетевого оборудования), и снижения нагрузки на Zabbix-сервер, потому что в этом режиме Zabbix-сервер не инициирует запросы сам, а только принимает готовые данные.

В данном разделе будет рассмотрен пассивный агентный мониторинг ОС Windows без шифрования.

В качестве объекта мониторинга будет использован компьютер или ноутбук, на котором Вы изучаете данный курс (предполагается, что Вы используете ОС Windows, на которой запущена виртуальная машина с ОС Ubuntu и установленным на ней Zabbix-сервером).

Сначала необходимо скачать исходный код агента

zab128

Затем создать папку C:\Program Files\Zabbix Agent и скопировать в нее разархивированное содержимое папки bin. Туда же скопировать папку conf, содержащая конфигурационный файл zabbix_agentd.conf.

Далее нужно привести несколько параметров файла zabbix_agentd.conf к следующему виду:

Указать ip-адрес сервера Zabbix в дерективе:
### Option: Server
Server=192.168.88.150
Ip-адрес сервера Zabbix, в моем случае на момент написания данной главы был 192.168.88.150 – посмотреть его можно в консоли виртуальной машины командой ip -c a

Задать имя хоста – должно совпадать в данном файле и в названии узла сети в системе Zabbix:  

Можно прописать\посмотреть в: 

c:\windows\system32\drivers\etc\hosts

Для Linux, Ubuntu, Unix, BSD — /etc/hosts

Прописать порт для обмена данными, по умолчанию 10050:
### Option: ListenPort
ListenPort=10050

Задать максимальный размер лога для ротации:
### Option: LogFileSize
LogFileSize=1

Запустите командную строку cmd от имени Администратора и выполните следующие команды (их можно скопировать и вставить, проверьте соответствие имен файлов и путей к ним):

Установка агента:

cd ‘C:\zabbix agent\’

.\zabbix_agentd.exe —config «C:\zabbix agent\conf\zabbix_agentd.conf» —install

zab130

Запуск службы:

.\zabbix_agentd.exe —config «C:\zabbix agent\conf\zabbix_agentd.conf» —start

 

zab131

Просмотр доступных для мониторинга компонентов:

.\zabbix_agentd.exe —config «C:\zabbix agent\conf\zabbix_agentd.conf» —print

После установки убедитесь, что служба будет автоматически запускаться

Для этого переходим в «службы» (можно найти через пуск-поиск-службы)

zab132

На этом настройка Zabbix-агента в ОС Windows завершена.

Важно!! Не забудьте отключить брандмауэр (или сделать на нем исключение для взаимодействия по порту 10500), и удостовериться, что Ваш антивирус не блокирует порт 10050. Вообще, порт 10050 – стандартный порт системы Zabbix для работы агентов и Zabbix-прокси. При осуществлении комплексного мониторинга корпоративных сетей межсетевые экраны, брандмауэры и антивирусы должны разрешать сетевые взаимодействия для протоколов транспортного уровня (модели OSI) TCP / UDP по портам 10050 (агент) и 10051 (траппер – при необходимости).

Теперь перейдем к системе мониторинга. В Zabbix создайте группу узлов сети Agent Monitoring Servers, и в ней – узел сети host.windows.home, с IP-адресом Вашего ПК, на который Вы установили Zabbix-агент.

Важно!! Название Узла сети (который будет опрашиваться как Zabbix-агент) в системе мониторинга должно совпадать с параметром Hostname в конфигурационном файле Zabbix-агента (zabbix_agentd.conf). Иначе связка Сервер – Агент не будет работать.

При создании сетевого узла в меню «Инвентаризация» установите параметр «Автоматически» — благодаря этой настройке инвентарные данные (определенные элементы данных), собранные агентом с ОС, будут автоматически вноситься в базу данных Zabbix как инвентарные данные, и станут доступны для просмотра в меню Инвентаризация

zab133

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

Администрирование-Общие-Другое 

zab134

Создайте шаблон опроса Agent Windows Monitor (разумеется, в группе User Templates). Шаблон опроса Agent Windows Monitor Вы будете заполнять необходимыми элементами данных согласно документации разработчиков системы Zabbix, описывающей возможности Zabbix-агента для ОС Windows — обязательно ознакомьтесь с ней. Для наглядности воспользуйтесь таблицей ниже, в которую внесены элементы данных, необходимые для полноценного мониторинга ОС Windows с помощью Zabbix-агента:

zab135

Самый первый, базовый элемент данных, присутствующий почти во всех шаблонах опроса – проверка доступности узла с помощью echo-запроса (по протоколу ICMP). Создайте его c соответствующими триггером и графиком. 

На заметку!! Проверка доступности сетевого узла по протоколу ICMP, а так же триггер и график для этой проверки – должны присутствовать почти в любом шаблоне опроса. Это повышает удобство использования системы и ее прозрачность (иначе к узлу сети приходится применять два разных шаблона – один для проверки доступности и второй для всего остального), что подходит не для всех ситуаций.

Второй элемент данных, отражающий работоспособность самого Zabbix-агента (agent.ping), можно визуализировать в виде графика. Однако, с триггером есть проблема. Она заключается в том, что о работоспособности Zabbix-агента предоставить информацию может только сам Zabbix-агент. Соответственно, если он по какой-то причине не отвечает (не функционирует, недоступен весь узел сети) – сообщить об этом системе мониторинга он не может. Zabbix-сервер при попытке опроса этого элемента данных, не будет получать никаких значений. Для того, чтобы правильно оповещать администратора сети о недоступности Zabbix-агента, необходимо использовать сложный комплексный триггер, который будет срабатывать на условие, при котором сам Узел сети доступен по ICMP, а вот Zabbix-агент не отдает никаких данных. В нашем шаблоне  Agent Windows Monitor  уже создан элемент данных, который проверяет доступность нашего домашнего пк. Он нам понадобится для проверки доступности заббикс агента 

zab136

Теперь в этом же шаблоне Agent Windows Monitor создадим новый элемент данных 

Картинка с сайта: test.playincloud.ru

zab137

Теперь создадим триггер, для проверки доступности zabbix agenta

В графе «выражение» нажмите на кнопку добавить. Мы будем использовать 2 условия — доступность хоста и недоступность заббикс агента

Для заббикс агента используем наш элемент данных agent.ping и функцию nodata. Выражение будет создано автоматически

zab138

Конечный результат

zab139

Теперь прицепите данный шаблон к нашему узлу

zab140

И отрубите заббикс агент на вашем пк с windows

C:\zabbix agent> .\zabbix_agentd.exe —config «C:\zabbix agent\conf\zabbix_agentd.conf» —stop
zabbix_agentd.exe [11748]: service [Zabbix Agent] stopped successfully

zab141

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

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

zab142

 Элемент данных «Время работы» Ед измерения — uptime

zab143

Конечный результат (мониторинг->последние данные)

zab144

Просмотр инвентарных данных узла сети

zab145

На заметку!! Сбор инвентарных данных – важная часть мониторинга сети. С серверов можно собирать сведения об ОС, с сетевого оборудования – точные названия моделей (так называемые Product ID (PID) и серийные номера шасси). Все это помогает упорядочить наблюдаемую сеть и упростить задачи по ее администрированию.

Обратите внимание, используемый Тип данных – Zabbix-агент. В данной главе во всех элементах данных будет использоваться только он.

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

zab147

Седьмой элемент данных, system.cpu.load, запрашивает средние значения загрузки процессора за 1, 5 или 15 минут. Вообще, данный параметр (в компьютерной технике называемый Load Average), замечателен с точки зрения наглядности работы процессоров. Load Average — это среднее значение загрузки системы за некоторый период времени (1, 5 и 15 минут), вычисляемое по сложной формуле, зависящей от так называемой «длины очереди выполнения». Длина очереди выполнения — количество всех процессов, выполняемых в данный момент времени, плюс количество процессов, ожидающих в очереди. В данном примере Load Average переведено как «Нагруженность процессора», однако полноценного краткого аналога данного термина в русском языке нет.

Создайте 3 элемента данных system.cpu.load для периодов времени 1, 5 и 15 минут, график со всеми тремя элементами данных, и триггеры для каждого элемента данных (порог срабатывания триггера установите из расчета 0.7 для каждого ядра процессора – данный пример был подготовлен на шестиядерном процессоре i5 10400f, и порог срабатывания составил 4.2). Для пояснения рассмотрим рисунок ниже (аномальная загрузка процессора была вызвана с помощью запуска нескольких процессов архивации видеофайлов):

zab146

Восьмой элемент данных — vm.memory.size[pavailable] отображает долю свободной (незанятой) оперативной памяти (в процентах). У элемента данных vm.memory.size масса параметров для отображения общего количества памяти, занятости различных типов памяти – все это используется в зависимости от поставленных задач. Для простого мониторинга свободной оперативной памяти создайте элемент данных, триггер (с оповещением о том, что доступной оперативной памяти менее 20%), и график.

Девятый элемент данных  — system.cpu.util показывает «утилизацию», или загруженность процессора. По сути, загруженность процессора — процент времени, в течение которого процессор загружен работой (не простаивает). system.cpu.util запрашивает усреднённую утилизацию процессора за интервал времени. На каждом отрезке, на котором не выполняется Idle Thread (этот термин обозначает простой), процессор считается занятым какой-то реальной нагрузкой. Чем больше полученное значение (в нашем случае, речь идет о процентах), тем больше загрузка процессора и меньше простоев. Создайте элемент данных, триггер (с порогом 80%), и график.

Важно!! При создании шаблонов опроса, элементов данных, триггеров и графиков, возьмите за правило называть их понятными именами, и при необходимости добавлять описания и пояснения.

Осталось последнее – организовать мониторинг сетевых интерфейсов и свободного пространства на жестких дисках. Возникает интересный момент – речь идет о мониторинге однотипных объектов, число которых может меняться со временем (например — разбиение жесткого диска на несколько разделов, добавление новых жестких дисков или удаление старых, установка внешних носителей памяти). Значит, нужен некий инструмент, способный автоматически находить, создавать, упорядочивать и удалять элементы данных, принадлежащие определенной группе. Этот инструмент – низкоуровневое обнаружение (Low-level discovery — LLD).

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

В Zabbix 6.0 поддерживаются несколько встроенных типов элементов данных для обнаружения:

обнаружение сетевых интерфейсов;
обнаружение CPU и ядер CPU;
обнаружение SNMP OID;
обнаружение с использованием SQL запросов ODBC;
обнаружение Windows служб.

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

Вернемся к обнаружению сетевых интерфейсов и жестких дисков. Начнем с мониторинга загрузки трафиком сетевых интерфейсов — в шаблоне опроса Agent Windows Monitor перейдите в подменю «Правила обнаружения» и создайте правило обнаружения.

В созданном правиле обнаружения заполните следующие поля (Рис. ниже): Имя (название правила), Тип (тип LLD – в нашем случае Zabbix-агент), ключ – net.if.discovery (инструмент LLD для Zabbix-агента), Интервал обновления (как часто будет проводиться обнаружение – на этапе создания обнаружения установите значение 1 минута, после того, как добьетесь стабильной работы шаблона – установите 1 час), Период сохранения потерянных ресурсов (в случае, если при новом обнаружении ранее существовавший объект не будет обнаружен, как скоро можно его удалить – установите 0, то есть немедленно).

Настройка правила обнаружения 

 

zab148

Теперь в правиле обнаружения необходимо создать так называемые прототипы элементов данных для подсчета трафика (для Zabbix-агента это net.if.in и net.if.out). Прототипы элементов данных отличаются от обычных элементов данных тем, что в их ключах (идентификаторах обращения к определенному объекту) присутствует переменная. По сути, имеет место цикл, который проходит по всем однотипным объектам, в именах (адресах, или идентификаторах) которых отличается только один параметр.

По логике работы LLD, сначала net.if.discovery найдет сетевые интерфейсы, а элементы данных net.if.in и net.if.out считают различные показатели трафика для каждого из них (благодаря переменной в ключе). Элементы данных net.if.in и net.if.out имеют следующие ключи: net.if.in[if,<режим>], net.if.out[if,<режим>].

Аргумент if – как раз таки название (или уникальный идентификатор) сетевого интерфейса — для корректной работы прототипов элементов данных if заменяется макросом {#IFNAME}. Далее, после обнаружения сетевых интерфейсов, эти макросы заменяются реальными значениями и становятся основой для создания реальный элементов данных, триггеров и графиков (на основе прототипов триггеров и графиков, в автоматическом режиме).

Аргумент <режим> — может принимать значения bytes (счетчик байт, прошедших через интерфейс), packets (счетчик пакетов – его использовать мы не будем), errors (счетчик «искаженных» etherhnet-кадров), dropped (счетчик отброшенных etherhnet-кадров).

Создадим прототип элементов данных net.if.in[{#IFNAME},bytes], для подсчета входящего трафика. При заполнении полей прототипа элементов данных, пользуйтесь макросом {#IFNAME}. В поле Имя введите «Входящий трафик {#IFNAME}», в поле ключ – «net.if.in[{#IFNAME},bytes]», Единицы измерения – byte (для корректного масштабирования значений сетевого трафика), правило предобработки установите «Изменение в секунду»  (рис.ниже):

Создание элемента прототипа данных:

zab149

Правило Предобработка указывает, как хранить полученные данные – например, для этого случая необходимо использовать правило Изменение в секунду. Zabbix отдает разность полученных значений за единицу времени (или шаг опроса) — для фиксации динамики изменений параметров. В прошлых версиях Zabbix этот параметр назывался «Дельта (скорость в секунду)». Счетчики траффика на сетевых интерфейсах просто увеличиваются при прохождении через них данных, поэтому для корректного отображения именно скорости, а не количества трафика, используется Изменение в секунду.

Аналогичным образом создайте остальные прототипы элементов данных — net.if.out[{#IFNAME},bytes], net.if.in[{#IFNAME},dropped], net.if.out[{#IFNAME},dropped], net.if.in[{#IFNAME},errors], net.if.out[{#IFNAME},errors]. У Вас должно получиться следующее (рис. ниже:)

Прототипы элементов данных для мониторинга трафика

zab150

Создайте 2 прототипа графиков – для отображения загрузки интерфейсов трафиком и всех видов ошибок на интерфейсах. Прототипы графиков создаются в рамках правил обнаружения. В названиях прототипов графиков обязательно используйте макрос {#IFNAME}. Помещать и загрузку трафика, и уровень ошибок на один график не рекомендуется из-за большого различия величин загрузки трафиком и количества ошибок (несколько порядков). Скорость трафика на интерфейсе может быть несколько Мбит/с, а ошибок может быть 1-2, и из-за масштабирования всех кривых эти ошибки будут не видны на фоне уровня загрузки трафиком.

zab151

Еще один важный момент – в ОС Windows существует множество объектов, подпадающих под понятие «сетевой интерфейс» и обнаруживающихся с помощью LLD-инструмента net.if.discovery (это виртуальные шлюзы IPv6, адаптеры, всевозможные «псевдоинфтерфейсы» и виртуальный интерфейсы платформ виртуализации, туннелей, некоторых служб и приложений). Когда Вы создадите прототипы элементов данных, Zabbix обнаружит и внесет в узел сети main.lan массу объектов (Рис. ниже):

Сетевые интерфейсы в OC Windows:

zab152

Для того, чтобы корректно отфильтровать полезную информацию, воспользуйтесь фильтрацией для правил обнаружений с помощью регулярных выражений. LLD-инструмент net.if.discovery будет получать информацию о сетевых интерфейсах, и регистрировать только те данные, макросы {#IFNAME} которых пройдет через фильтр регулярного выражения. На рисунке ниже показан процесс подключения набора регулярных выражений win-eth (обратите внимание на синтаксис, в поле вносится значение «@win-eth»). 

Символ @ в Zabbix используется как ссылка на глобальные регулярные выражения.

 

zab153

Осталось создать само регулярное выражение. Перейдите в меню Администрирование – Общие – Регулярные выражения и создайте новое регулярное выражение «win-eth». Обратите внимание, знак @ перед ним не ставится (Рис. ниже):

Создание регулярного выражения:

zab154

Конечный результат:

zab155

После создания регулярного выражения, все объекты, не прошедшие фильтр, будут удалены и больше не появятся в списке обнаруженных (фильтрация происходит одновременно с обнаружением – если частота обнаружения установлена, например, 1 час, то и фильтр к обнаруживаемым объектам будет применяться один раз в час, в процессе обнаружения). Проверьте, что фильтрация работает – в элементах данных Узла сети должны исчезнуть ненужные объекты, и, соответственно, должны исчезнуть лишние графики

Результат фильтрации сетевых интерфейсов (лишние элементы данных  и графики — пропали):

zab156

Следующий шаг – создание еще одного низкоуровневого обнаружения, для мониторинга свободного дискового пространства на энергонезависимых носителях. Инструмент низкоуровневого обнаружения накопителей памяти — vfs.fs.discovery, прототип элемента данных для отображения доли свободного дискового пространства (в процентах) — vfs.fs.size[{#FSNAME},pfree], где {#FSNAME} – макрос, несущий в себе букву диска (C:/, D:/ и т.п.). Создайте LLD самостоятельно (учтите, фильтр для него не нужен), прототип графика и триггера (с порогом, например, 20%).

zab157

На этом создание шаблона опроса для серверов с ОС Windows с помощью Zabbix-агента завершено. Благодаря этому шаблону мы получаем данные о производительности системы, состоянии памяти и жестких дисков. Убедитесь, что обнаружения, прототипы триггеров и графиков работают корректно. В результате работы шаблона, для просмотра должны быть доступны графики и инвентарные данные, настроены триггеры и обнаружения.

Осталось визуализировать получаемые значения. Воспользуйтесь инструментом Панель. В zabbix 6 — вместо комплексных экранов используются панели.  Они служит для размещения на одной веб-странице нескольких графиков. Панели в Zabbix бывают двух типов:

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

Вторые создаются в меню Мониторинг –> Панель->Создать панель, и они доступны только из раздела меню Мониторинг –> Панель, и они несут только те элементы, которые Вы настроили при создании панели (это минус, полностью отсутствует автоматизация и масштабирование).

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

Мы можем добавлять виджеты, либо страницы  (а на них уже виджеты)

zab159

ВАЖНО!! Ваша панель (созданная внутри шаблона)  — отображается на карте сетей. Нужно войти в Мониторинг-> Карты сетей -> Создать карту сетей (либо добавить элемент уже в ранее созданную карту сетей)

Я добавил элемент в карту сетей «DNS сервера». Не забудьте нажать на кнопку «обновить»

zab160

Далее нужно войти в Карты сетей->DNS сервера и нажать на наш узел

zab161

Отследите плюсы и минусы использования прототипов графиков на комплексном экране. Пример панели приведён на рисунке ниже (обратите внимание на часы – это аналог Виджета Панелей мониторинга.)

Пример комплексного экрана (красота

zab162

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

Агентный мониторинг ОС Linux

В данном разделе будет рассмотрен активный и пассивный агентный мониторинг ОС Linux с шифрованием. В роли объекта мониторинга будет выступать виртуальная машина с ОС Ubuntu. Zabbix-агент мы установили ранее.

СПРАВКА!!

hostname — посмотреть имя хоста

sudo hostnamectl set-hostname ubuntu.lan —  установить имя хоста

sudo nano /etc/hosts — вписать хосты

zab163

Откройте конфигурационный файл агента для редактирования.

# sudo nano /etc/zabbix/zabbix_agentd.conf

И внесите следующие изменения:

Server=192.168.88.150

ServerActive=192.168.88.150

#Server и ServerActive раскомментированы и имеют одинаковые адреса

Hostname=ubuntu.lan

#Имя сервера в файле конфигурации должно совпадать с именем Узла сети на Zabbix-сервере

BufferSend=10

#Время хранения данных в буфере, если не удается отправить, в секундах

BufferSize=1000

#Максимальное количество значений в буфере памяти.

AllowRoot=1

#Эта настройка дает агенту запускаться с правами рута. Убирает проблемы нехватки прав на некоторые параметры инвентаризации.

После этого перезапустите сервис агента.

# sudo systemctl restart zabbix-agent

Важно! Версия Zabbix-агента должна совпадать с версией Zabbix-сервера. При обновлении серверного ПО – не забывайте обновлять агенты на удаленных серверах.

На этом базовая настройка Zabbix-агента в активном режиме завершена.

Перейдите в систему мониторинга, и создайте шаблон опроса Agent Linux Monitor (в группе User Templates). В группе узлов сети Agent Monitoring Sevrers создайте новый узел сети ubuntu.lan (с IP-адресом 192.168.88.160), присоедините к нему шаблон опроса Agent Linux Monitor.

zab164

В шаблоне Agent Linux Monitor создайте элемент данных для мониторинга доступности агента, и настройте его в активном режиме

zab165

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

zab166

zab167

zab168

Перейдем к настройки шифрования. Сгенерируйте Pre-Shared Key (PSK):

openssl rand -hex 32

c7a02a015b522464f83495c46dea3e15f67db450d65ea4b654838ac9c5dd9c8a

Создайте на виртуальной машине с нашей Ubuntu (не на серваке с zabbix)  — .psk-файл, куда поместите сгенерированный PSK:

sudo nano /etc/zabbix/zabbix-agent.psk —создавать лучше в директории, к которой у всех пользователей будет доступ (например в /etc)

справка!! команда, для того, чтобы переименновать файл mv zabbix_agentd.psk (<-старое название) zabbix-agent.psk (<-новое название)

sudo chown zabbix /etc/zabbix/zabbix-agent.psk —сделаем пользователя zabbix  — владельцем данного файла (пользователь zabbix добавляется автоматически, при установкеzabbix agenta на ВМ с Ubuntu )

Задать права доступа к PSK файлу — он должен быть доступен для чтения всем пользователям:

sudo chmod a+r /etc/zabbix/zabbix-agent.psk —даем всем права на чтение 

(a — разрешить всем, u — разрешить владельцу, g- разрешить группе, o — разрешить всем остальным)

+ разрешить — запретить  = присвоить

r чтение w запись x исполнение

Донастройте конфигурационный файл zabbix-агента. Нужно изменить параметры TLS в файле конфигурации zabbix_agentd.conf, а именно задать:

TLSConnect=psk

TLSAccept=psk

TLSPSKFile=/etc/zabbix/zabbix-agent.psk

TLSPSKIdentity=PSK 002

Параметр TLSPSKIdentity – идентификатор PSK (идентификатор, уникальный для каждого агента с точки зрения сервера мониторинга).

После внесения изменений – перезапустите агент:

sudo systemctl restart zabbix-agent —перезапустим  заббикс агента

sudo systemctl status  zabbix-agent —убедимся, что все запустилось нормально

zab174

Если заббикс агент  не запускается, то проверяем логи и устраняем проблему:

sudo tail -n10000 -f /var/log/zabbix-agent/zabbix_agentd.log —проверяем последние 10000 строк + видим обновления в реальном времени

После этого, настройте Шифрование на узле сети ubuntu.lan

Настройка шифрования агента

zab169

zab170

zab171

Теперь можно переходить к созданию полноценного шаблона заполните Шаблон Agent Linux Monitor элементами данных, триггерами, графиками, и обнаружениями. С одной стороны, шаблон для мониторинга ОС Linux похож на шаблон для ОС Windows, и почти все элементы будут повторяться. С другой стороны, возможности Zabbix-агента по предоставлению различных данных для Linux гораздо шире, и элементов данных будет значительно больше. Не забудьте, тип элементов данных будет «Zabbix агент активный».

Начните с элементов данных для инвентаризации

Элементы данных для инвентаризации ОС Linux:

zab172

Для элемента данных «время работы системы» используйте единицы измерения «uptime», чтобы время отображалось корректно (а не тупо в секундах)

zab175

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

Созданные элементы данных для инвентаризации

zab173

 Результат инвентаризации виртуальной машины с ОС LINUX

zab176

Если необходимо сопоставлять данные от разных серверов, необходимо распределить самые важные опрашиваемые параметры инвентаризации между полями Имя, Тип, ОС, Серийный номер А, Этикетка, МАС адрес А. Zabbix в сводной таблице инвентаризации выводит только эти параметры

zab177

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

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

При просмотре инвентарных данных, есть удобный способ сортировать выдачу данных, запрашивая для группы устройств только одно инвентаризационное поле (Инвентаризация – Обзор – Сгруппировать по). Данный подход очень удобен при анализе информации о большой группе однотипных устройств. Например, нужно быстро узнать и предоставить серийные номера или модели коммутаторов, использующихся на предприятии (например, когда их 50-500 единиц). При условии, что сбор такой информации предусмотрен в соответствующих шаблонах (а в Инвентарных данных выводятся собранные сведения со всех опрошенных Узлов сети, независимо от Шаблона опроса), это делается в «несколько кликов мышью».

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

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

Элементы данных для мониторинга ОС Linux

zab178

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

Созданные элементы данных для шаблона OC LINUX

zab179

Созданные графики для шаблона ОС Linux

zab180

Создайте триггеры на свое усмотрение, по аналогии с шаблоном для мониторинга ОС Windows (обязательно используйте и протестируйте комплексный триггер с использованием nodata).

Теперь, как и в случае с ОС Windows, необходимо создать два низкоуровневых обнаружения – для обнаружения жестких дисков и сетевых интерфейсов. 

zab181

Для обнаружения жестких дисков, используйте 2 прототипа элементов данных — vfs.fs.size[{#FSNAME},used] и vfs.fs.size[{#FSNAME},total], и поместите их на один прототип графика. Для прототипа триггера, сигнализирующего об отсутствии свободного места на жестком диске, используйте конструкцию

last(/Agent Linux Monitor/vfs.fs.size[{#FSNAME},used])/last(/Agent Linux Monitor/vfs.fs.size[{#FSNAME},total])>0.9

По сути, прототип триггера будет вычислять отношение занятого места к общему, и сравнивать с пороговым значением срабатывания 0.9, то есть сигнализировать о том, что занято более 90% свободного места.

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

После обнаружения жестких дисков, Zabbix отображает все директории корневого каталога, нам же интересна только директория «/». Создайте фильтр и исключение для всех букв алфавита (директория / будет обнаруживаться, а папки нет). Регулярное выражение для фильтра – Результат ЛОЖЬ = [a-z]

Шаблон готов – удостоверьтесь, что обнаружения, прототипы триггеров и графиков работают корректно. Для просмотра доступны графики и инвентарные данные, настроены триггеры и обнаружения – используйте панель для представления результатов

Созданные триггеры на нашем узле сети ubuntu.lan

zab186

Созданные графики на нашем узле сети ubuntu.lan

zab187

Создадим панель в нашем  шаблоне Agent Linux Monitor

zab188

Добавим элемент на нашу карту сетей

zab189

В панели global view, я создал страницу «карта сетей», в которой отображается конкретная карта карта сетей «Dns сервера»

На ней отображаются наши основные хосты. Нажимаем на нужный элемент и выбираем пункт «панель»

zab190

Финальный вид нашей панели для мониторинга ubuntu.lan

zab191

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

Раздел 8. Мониторинг базы данных MySQL

Эта глава посвящена технологиям мониторинга баз данных. В качестве объекта наблюдения будет использована СУБД MySQL, обслуживающая систему мониторинга Zabbix. База данных, по сути — совокупность упорядоченных данных, которые могут использовать приложения для работы с ними.

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

1. Внешняя проверка (запуск скрипта, написанного администратором):

Преимущества — максимально гибкий, надежный.

Недостатки — на начальном этапе освоения Zabbix, ОС Linux и скриптового программирования, может вызывать сложности.

2. Мониторинг баз данных (технология ODBC):

Преимущества – при правильно настроенной связке Zabbix + ODBC это простой в использовании инструмент.

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

3. SSH — агент (удаленное подключение по SSH к хосту и выполнение на нём скриптов):

Преимущества — можно использовать и команды, и полноценные скрипты. Не нужно использовать дополнительные параметры.

Недостатки — требует компиляции Zabbix с соответствующим пакетом SSH на этапе установки Zabbix, необходимо наличие логина и пароля для доступа по SSH.

4. Zabbix-агент (дополнительно установленный на объекте мониторинга демон):

Преимущества — прост в развертывании, не требует сложных настроек.

Недостатки – функционал ограничен выводом статистики СУБД, а так же непрозрачности концепции мониторинга.

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

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

В файле /etc/zabbix/zabbix_agentd.conf проверьте наличие строки «Include=/etc/zabbix/zabbix_agentd.d/*.conf»:

# sudo nano /etc/zabbix/zabbix_agentd.conf

Удостоверьтесь, что эта строка есть и раскомментирована (в начале строки стерт символ «#»).

Удостоверьтесь, что файл /etc/zabbix/zabbix_agentd.d/userparameter_mysql.conf существует, и в нем присутствуют переменные:

UserParameter=mysql.status[*],echo «show global status where Variable_name=’$1′;» | HOME=/var/lib/zabbix mysql -N | awk ‘{print $$2}’

UserParameter=mysql.size[*],echo «select sum($(case «$3″ in both|»») echo «data_length+index_length»;; data|index) echo «$3_length»;; free) echo «data_free»;; esac)) from information_schema.tables$([[ «$1» = «all» || ! «$1″ ]] || echo » where table_schema=’$1′»)$([[ «$2» = «all» || ! «$2» ]] || echo «and table_name=’$2′»);» | HOME=/var/lib/zabbix mysql –N

UserParameter=mysql.ping,HOME=/var/lib/zabbix mysqladmin ping | grep -c alive

UserParameter=mysql.version,mysql -V

Если данного конфигурационного файла нет, то необходимо скопировать его из /usr/share/doc/zabbix-agent/userparameter_mysql.conf в /etc/zabbix/zabbix_agentd.d/ без изменения присутствующих в нем настроек.

Для этого необходимо выполнить команду:

# sudo cp /usr/share/doc/zabbix-agent/userparameter_mysql.conf /etc/zabbix/zabbix_agentd.d/

Важно!! После копирования, я вставил в него  переменные из курса, а все остальные записи — закомментировал:

zab192

Обратите внимание на переменную HOME. Создайте каталог, указанный в переменной HOME:

# sudo mkdir /var/lib/zabbix

В нём создайте файл «.my.cnf» (название с точками, это обязательно) 

# sudo nano /var/lib/zabbix/.my.cnf

Содержимое .my.cnf

[client]
user = agent
password = agent

Этот файл указывает, с какими учетными данными Zabbix-агент будет подключаться к базе данных. Перезапустите zabbix-agent:

# sudo systemctl restart zabbix-agent

Удостоверьтесь, что процесс запустился корректно:

# sudo systemctl status zabbix-agent

Обратите внимание, в файле /var/lib/zabbix/.my.cnf, для доступа к базе данных, использована пара логин/пароль agent/agent. Нужно создать соответствующие учетные данные в базе данных MySQL. Выполните следующие команды (для администрирования баз данных существует свой собственный, так называемый структурированный язык запросов — SQL):

# sudo mysql -uroot -proot —Осуществлен вход в командную строку управления базы данных.

>CREATE USER ‘agent’@’localhost’ IDENTIFIED BY ‘agent’; —Создан пользователь с учетными данными agent/agent.

>GRANT ALL PRIVILEGES ON *.* TO ‘agent’@’localhost’; —Пользователю agent даны полные привилегии на работу с данными базы.

>FLUSH PRIVILEGES; —Изменения применены – без этой команды предыдущие действия не имеют силы.

>quit  —Выход из режима конфигурирования базы данных.

Zabbix-агент готов к опросу базы данных. Концепция осуществления мониторинга Zabbix-агентом следующая – Zabbix-агент авторизуется в консоли управления базой данных, и извлекает параметры, запрашиваемые командами «mysqladmin status» и «mysqladmin extended-status». Эти команды также можно вводить в консоли ОС, часть результата приведена на рисунке ниже.

Вывод команд «mysqladmin status» и «mysqladmin extended-status»

zab193

Файл userparameter_mysql.conf содержит в себе переменные, которые будут извлечены из БД.

Создайте шаблон опроса User Mysql monitor в группе User Templates. В группе узлов сети Agent Monitoring Servers создайте узел сети host.myssql.home (с IP-адресом 127.0.0.1), и присоедините к нему шаблон User Mysql monitor. Приступим к наполнению шаблона элементамиданных

Элементы данных для мониторинга суббд mysql

zab194

 

Получим в результате следующее:

Элементы данных шаблона user mysql monitor

zab196

Триггер, срабатывающий на недоступность базы данных

 

zab197

Графики шаблона User Mysql monitor

zab198

График, отображающий кол-во запросов к бд

zab199

График, отражающий объемы трафика, принимаемого и отдаваемого базой данных

zab200

График, отражающий количество операций в базе данных

zab201

Чтобы понять, что именно отражается на этих графиках, нужно разобраться с принципами работы баз данных.

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

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

Вернемся к рисунку «График, отображающий кол-во запросов к бд». Параметр «Открыто соединений» показывает количество подключений сервисов к БД. Посмотреть их можно в консоли MqSQL (mysql -uroot -proot) с помощью команды «SHOW PROCESSLIST;». Там будет отображено порядка 60 процессов для сервиса Zabbix-server, и два для root.

zab202

Параметр «количество медленных запросов», или slow query – очень интересный параметр, характеризующий оптимальность работы базы данных. Запрос считается медленным, если база данных не может его обработать в пределах короткого временного промежутка.

По стечению обстоятельств любой запрос может иногда выполняться медленно (ожидание окончания обработки других запросов, занятость дискового пространства сервера, высокая нагрузка на сервер). Случайные медленные запросы не являются признаком проблем. Однако, при систематических долгих запросах возникает большая нагрузка на сервер и базу данных, что приводит к серьезным задержкам или неработоспособности сервиса. Долгое исполнение запроса может быть обусловлено отсутствием индексов (специальных указателей, ускоряющих поиск требуемых данных), либо не оптимально составленными запросами (база данных Zabbix достаточно стабильна, slow query не должны иметь места). При наличии регулярных медленных запросов требуется реорганизация запросов и, возможно, архитектуры базы данных. Задача системы мониторинга – выявить эту проблему.

Параметр «количество обрабатываемых запросов» показывает суммарное количество всех запросов, обрабатываемых базой в данный момент.

Теперь обратимся к рисунку «График, отражающий количество операций в базе данных»

SQL — Structured Query Language, или язык сктруктурированных запросов. 

Основные операторы манипулирования данными (или операторы DML (Data Manipulation Language)), перечислены ниже:

— SELECT — отобрать строки из таблиц;

— INSERT — добавить строки в таблицу;

— UPDATE — изменить строки в таблице;

— DELETE — удалить строки в таблице;

— COMMIT — зафиксировать транзакцию;

— ROLLBACK – отменить транзакцию;

Не вдаваясь в подробности, операторы SELECT, INSERT, UPDATE и DELETE – оперируют непосредственно данными в таблицах. А операторы COMMIT и ROLLBACK – отвечают за транзакции. Транзакция – важное понятие, раскрывающее особенности работы баз данных.

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

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

Теория функционирования баз данных обширна, это отдельное направление в IT.

Последний элемент данных, который войдет в шаблон опроса User Mysql monitor, будет вычислять объем базы данных. Он будет извлекаться исполняемым скриптом, написанным на скриптовом языке Perl. Скрипт – это небольшая программа, автоматизирующая некоторую задачу, которую пользователь иначе делал бы вручную.

Приступим к написанию скрипта (интерпретатор Perl предустановлен в ОС Ubuntu, расширение файлов perl-скриптов — .pl). Все исполняемые скрипты, которые будет использовать Zabbix, должны находиться в каталоге, указанном в конфигурационном файле /etc/zabbix/zabbix_server.conf, в переменной ExternalScripts. В рамках данного курса, я использовал каталог по умолчанию — /usr/lib/zabbix/externalscripts/.

Создайте файл скрипта:

# sudo nano /usr/lib/zabbix/externalscripts/db_size.pl

И внесите в него следующий код:

#!/usr/bin/perl

use DBI;
my $host = «localhost»; #MySQL-Server
my $port = «3306»; #Default port MySQL
my $user = «agent»; #Имя пользователя БД
my $pass = «agent»; #Пароль пользователя
my $db = «zabbix_db»; #Название базы данных
$dbh = DBI->connect(«DBI:mysql:$db:$host:$port»,
$user,$pass); #Подключение к БД, Enter после $port», обязателен!
$sth = $dbh->prepare(«SELECT table_schema $db, sum( data_length + index_length )/1024/1024 FROM information_schema.TABLES GROUP BY table_schema»);
$sth->execute; #Исполнение запроса

while ($ref = $sth->fetchrow_arrayref) {
if («$$ref[1]»>50){
print «$$ref[1]\n»;
} #Извлечение параметра из массива полученных данных
}

$rc = $sth->finish;
$rc = $dbh->disconnect; #Закрытие соединения

Полностью скопируйте синтаксис и соблюдайте переносы (или их отсутствие), иначе скрипт не будет работать.

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

#sudo apt install libdbi-perl libyaml-perl libdbd-mysql-perl

После написания скрипта, выдайте ему права на исполнение:

# sudo chmod +x /usr/lib/zabbix/externalscripts/db_size.pl

Теперь Вы можете проверить работоспособность скрипта, просто вызвав его из консоли ОС — /usr/lib/zabbix/externalscripts/db_size.pl, поскольку скрипт стал исполняемым.

Текст скрипта с цветным форматированием текстового редактора nano приведен на Рисунке ниже

 

zab203

#!/usr/bin/perl

use DBI;
my $host = «localhost»; #MySQL-Server
my $port = «3306»; #Default port MySQL
my $user = «agent»; #Имя пользователя БД
my $pass = «agent»; #Пароль пользователя
my $db = «zabbix_db»; #Название базы данных

#Connect to MySQL
$dbh = DBI->connect(«DBI:mysql:$db:$host:$port»,
$user,$pass); #Подключение к БД, Enter после $port», обязателен!

#SQL query
$sth = $dbh->prepare(«SELECT table_schema $db, sum( data_length + index_length )/1024/1024 FROM information_schema.TABLES GROUP BY table_schema»);

#Query
$sth->execute; #Исполнение запроса

while ($ref = $sth->fetchrow_arrayref) {
if («$$ref[1]»>50){
print «$$ref[1]\n»;
} #Извлечение параметра из массива полученных данных
}

$rc = $sth->finish;
$rc = $dbh->disconnect; #Закрытие соединения

#`print «$$ref[1]\n» — чтобы работал перенос на новую строчку

В данном скрипте была использована библиотека DBI для работы с базами данных, и запрос на языке SQL. Скрипт подключается к базе данных, выполняет запрос, и передает в Zabbix результат. Вы можете выполнить запрос в консоли MySQL, и посмотреть, что он отдает.

Важно!! Не копируйте файл с текстом скрипта из ОС Windows в ОС Linux (например, по FTP). В конце каждой строки текстового файла, созданного в Windows, записывается символ переноса строк«^M».В файлах Linux его очень сложно идентифицировать и удалить (требуется специальная программа). Работать такой скрипт не будет.

Чтобы научиться писать хорошие скрипты, нужно, во-первых, много практиковаться, а во-вторых – изучать используемый язык, его модули и команды. Данный скрипт написан некорректно и неэффективно с точки зрения программирования. Результатом запроса будет таблица данных, состоящая из названий всех доступных баз данных, созданных в MySQL, и их размер. После этого из столбца размеров баз данных извлекается лишь тот, который больше 50 (имеется ввиду размер в Мб). Вам нужно самостоятельно улучшить этот запрос, чтобы он отдавал размер только одной базы данных – zabbix_db, и переписать часть отдачи данных в Zabbix, убрав порог в 50 Мб (подсказка — для этого исправьте запрос к БД, он должен запрашивать table_schema = ‘zabbix_db’).

Добейтесь работоспособности скрипта. Можно напрячь чат-бота  (https://chat.chatgptdemo.net/) 

zab204

zab205

Теперь создадим в шаблоне User Mysql monitor элемент данных «Размер базы данных» с ключом db_size.pl и типом Внешняя проверка

Элемент данных db_size.pl, извлекающий размер базы данных

 

Элемент данных db_size.pl, извлекающий размер базы данных

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

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

1) версию базы данных

2) время работы

3) размер базы данных 

Инвентарные данные базы данных

zab207

Панель для mysql представлена ниже

zab209

В этой главе Вы научились осуществлять мониторинг базы данных MySQL (для других баз данных процесс почти не отличается, могут меняться инструменты, но это решается путем изучения документации на БД). Важное достижение – запуск первого исполняемого скрипта. Возможность запускать скрипты в рамках опроса объектов мониторинга является одним из преимуществ Zabbix перед другими системами мониторинга.

Раздел 9. Мониторинг и тюнинг Zabbix.

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

Сначала визуализируем задачу. В группе шаблонов опроса ServerTemplates присутствует предустановленный шаблон Zabbix server health, присоединенный к существующему узлу Zabbix server (127.0.0.1). Нужно открыть любой график, затем настроить фильтр, для отображения zabbix server. Просмотрите доступные графики и проанализируйте состояние сервера

Анализ производительности Zabbix

zab211

Самый показательный график, отражающий быстродействие сервера – Zabbix data gathering process busy. Он показывает, насколько сильно сервер загружен теми или иными процессами (например, poller – это процессы, исполняющие всевозможные проверки и опросы, или icmp – выполнение команды ping с помощью утилиты fping, discoverer – процедуры обнаружения элементов данных с помощью инструмента discovery, unreachable poller – неудачные проверки, ожидающие таймаута). 

Необходимо доработать конфигурационный файл Zabbix, чтобы сервис получал системные ресурсы в достаточном количестве. Откройте файл zabbix_server.conf текстовым редактором и просмотрите параметры, которые можно задействовать или изменить:

# sudo nano /etc/zabbix/zabbix_server.conf

Полный список параметров конфигурационного файла приведен в «Zabbix Documentation 6.0 — Zabbix сервер». Нас интересуют такие параметры, как объемы рабочих кэшей, количества различных «поллеров» и таймауты. Установите следующие значения параметров:

StartPollers=50

Параметр `StartPollers` в Zabbix отвечает за количество процессов-опросчиков (poller processes), которые используются для сбора данных от мониторируемых узлов.

Когда Zabbix опрашивает мониторируемые узлы для получения данных, процесс-опросчик (poller process) отвечает за выполнение этой задачи. Каждый процесс-опросчик может обрабатывать несколько запросов одновременно.

Параметр `StartPollers` позволяет указать количество процессов-опросчиков, которые будут запущены при старте сервера Zabbix. Значение по умолчанию для этого параметра — 5.

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

StartPreprocessors = 60

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

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

StartPollersUnreachable=30

Параметр StartPollersUnreachable в Zabbix отвечает за количество процессов-опросчиков (poller processes), которые будут использоваться для опроса недоступных (unreachable) хостов.

Когда хост становится недоступным (например, из-за сетевой проблемы или неполадки), Zabbix переводит его в состояние «недоступный». В этом состоянии Zabbix не будет пытаться опрашивать хост, чтобы собирать данные. Однако, параметр StartPollersUnreachable позволяет настроить количество процессов-опросчиков, которые будут продолжать опрашивать недоступные хосты.

Увеличение значения параметра StartPollersUnreachable позволяет увеличить количество процессов-опросчиков, которые будут заниматься опросом недоступных хостов. Это может быть полезно, если важно получать данные от недоступных хостов, даже если они временно недоступны.

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

Значение параметра StartPollersUnreachable можно настроить в файле конфигурации Zabbix (zabbix_server.conf) и перезапустить сервер Zabbix, чтобы изменения вступили в силу.

StartPingers=100

Параметр StartPingers в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за количество предварительно запущенных экземпляров пингеров (pingers) в Zabbix сервере.

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

Указанное значение в параметре StartPingers определяет количество экземпляров пингеров, которые будут предварительно запущены и готовы к обработке проверок доступности. Например, если параметр StartPingers=10, то будет предварительно запущено 10 экземпляров пингеров.

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

CacheSize=64M

Параметр CacheSize в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за размер кэша (cache) в Zabbix сервере. Кэш используется для хранения временных данных, которые могут быть использованы повторно без необходимости выполнения долгих операций чтения или вычислений.

Указанное значение в параметре CacheSize определяет максимальный размер кэша в мегабайтах (МБ). Например, если параметр CacheSize=128, то размер кэша будет ограничен 128 МБ.

Значение параметра CacheSize должно быть выбрано с учетом доступной оперативной памяти на сервере. Увеличение размера кэша может улучшить производительность, но может также потребовать больше оперативной памяти.

Обратите внимание, что значение параметра CacheSize должно быть степенью двойки, например, 32, 64, 128, 256 и т.д.

HistoryCacheSize=32M

Параметр HistoryCacheSize в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за размер кэша исторических данных (history cache) в Zabbix сервере. Исторические данные представляют собой временные данные о метриках, таких как значения CPU, использование памяти, сетевой трафик и т. д., которые могут быть использованы для анализа и отображения в графиках и отчетах.

Указанное значение в параметре HistoryCacheSize определяет максимальный размер кэша исторических данных в мегабайтах (МБ). Например, если параметр HistoryCacheSize=128, то размер кэша исторических данных будет ограничен 128 МБ.

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

Обратите внимание, что значение параметра HistoryCacheSize должно быть степенью двойки, например, 32, 64, 128, 256 и т.д.

HistoryIndexCacheSize=16M

Параметр HistoryIndexCacheSize в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за размер кэша индексов исторических данных (history index cache) в Zabbix сервере. Индексы исторических данных используются для быстрого поиска и доступа к конкретным историческим записям.

Указанное значение в параметре HistoryIndexCacheSize определяет максимальный размер кэша индексов исторических данных в мегабайтах (МБ). Например, если параметр HistoryIndexCacheSize=64, то размер кэша индексов исторических данных будет ограничен 64 МБ.

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

Обратите внимание, что значение параметра HistoryIndexCacheSize должно быть степенью двойки, например, 32, 64, 128, 256 и т.д.

TrendCacheSize=16M

Параметр TrendCacheSize в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за размер кэша трендовых данных (trend cache) в Zabbix сервере. Трендовые данные представляют собой долгосрочные данные о метриках, таких как значения CPU, использование памяти, сетевой трафик и т. д., которые могут быть использованы для анализа и прогнозирования долгосрочных трендов.

Указанное значение в параметре TrendCacheSize определяет максимальный размер кэша трендовых данных в мегабайтах (МБ). Например, если параметр TrendCacheSize=256, то размер кэша трендовых данных будет ограничен 256 МБ.

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

Обратите внимание, что значение параметра TrendCacheSize должно быть степенью двойки, например, 32, 64, 128, 256 и т.д.

ValueCacheSize=32M

Параметр ValueCacheSize в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за размер кэша значений (value cache) в Zabbix сервере. Кэш значений используется для хранения временных данных, таких как значения метрик, полученных от мониторируемых устройств.

Указанное значение в параметре ValueCacheSize определяет максимальный размер кэша значений в мегабайтах (МБ). Например, если параметр ValueCacheSize=64, то размер кэша значений будет ограничен 64 МБ.

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

Обратите внимание, что значение параметра ValueCacheSize должно быть степенью двойки, например, 32, 64, 128, 256 и т.д.

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

Timeout=20

Параметр Timeout в файле конфигурации Zabbix (`zabbix_server.conf`) отвечает за таймаут (в секундах) для сетевых операций, таких как подключение к удаленным хостам, чтение данных и отправка запросов.

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

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

Например, если параметр Timeout=10, то максимальное время ожидания ответа или выполнения операции будет составлять 10 секунд.

Обратите внимание, что некоторые операции, такие как проверка доступности хоста или получение данных, могут иметь свои собственные таймауты, которые могут быть настроены отдельно.

После произведенных изменений необходимо перезапустить сервис Zabbix.

# sudo systemctl restart zabbix-server

Анализируя график «Анализ производительности Zabbix«, необходимо добиться максимального снижения загруженности системы

Результат оптимизации производительности Zabbix (↓↓↓)

zab212

 

Данная оптимизация необходима при мониторинге уже более 500 элементов данных, то есть конфигурация сервера по умолчанию не будет справляться с любой, даже незначительной, нагрузкой. Кроме того, считается, что количество «поллеров» должно быть не максимально допустимым, а оптимальным — в зависимости от обслуживаемой сетевой инфраструктуры. Это связано с тем, что системные ресурсы резервируются под сконфигурированное количество «поллеров» в момент запуска сервиса мониторинга. 

На заметку!! В ситуации, если Вы не ограничены системными ресурсами – теоретически, Вы можете наращивать объемы данных мониторинга и количество обслуживаемых узлов без ограничений, просто редактируя параметры системы, предоставляя ей все больше ресурсов. На практике же, рост базы данных (в рамках СУБД MySQL) уже свыше 50 ГБ приведет к медленной работе некоторых инструментов отображения информации (графики, карты сети), и проявит себя ограничение на количество запросов в БД MySQL – скажем, свыше 50000 метрик в минуту записать в БД MySQL может быть проблематично, её так же необходимо тюнинговать.

Результат оптимизации конфигурационного файла Zabbix будет наглядно представлен в сокращении Очередей. Войдите в меню Администрирование >>Очередь

Анализ наличия очередей процессов мониторинга в Zabbix (↓↓↓↓↓↓)

zab213

Хорошо оптимизированная система не содержит больших очередей (более одной минуты и 10-15 значений). В идеальных условиях очереди должны быть пусты. Если очереди заняты – необходима оптимизация (хотя на больших нагрузках, например, 100-200 значений в секунду, их не избежать).

Перейдем к настройке базы данных – самому важному этапу тюнинга системы.

# sudo cat /etc/mysql/mysql.conf.d/mysqld.cnf

Нас интересуют следующие параметры:

max_connections = 400
tmp_table_size = 256M
max_heap_table_size = 256M
table_open_cache = 64M
join_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 16M
key_buffer_size = 16M
thread_stack = 192K
thread_cache_size = 8
query_cache_limit = 2M —НЕ НУЖНО ИСПОЛЬЗОВАТЬ, с ним mysql не запускается

Параметр `query_cache_limit` отвечает за ограничение размера каждого отдельного запроса, который может быть кэширован в памяти кэша запросов MySQL. Этот параметр определяет максимальный размер запроса, который может быть сохранен в кэше.

Значение `query_cache_limit` должно быть указано в байтах. Рекомендуется выбрать значение, которое подходит для вашей конкретной ситуации и объема памяти на сервере.

Однако, важно заметить, что начиная с версии MySQL 5.7, кэш запросов был удален из MySQL, поскольку он был считается неэффективным и мог вызывать проблемы с производительностью в некоторых сценариях. Таким образом, если вы используете MySQL версии 5.7 или новее, параметр `query_cache_limit` может быть проигнорирован.

Если вы все же хотите использовать кэш запросов и ваша версия MySQL поддерживает эту функцию, рекомендуется выбрать значение `query_cache_limit`, которое соответствует типу запросов, которые вы обрабатываете. Например, если у вас много запросов с большими результатами, вы можете установить более высокое значение, например, 2M (2 мегабайта). Если же ваши запросы обычно возвращают небольшие результаты, вы можете установить меньшее значение, например, 256K (256 килобайт).

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

query_cache_size = 32M —НЕ ИСПОЛЬЗУЕТСЯ

Значение параметра `query_cache_size` по умолчанию в MySQL зависит от версии и конфигурации сервера. В более ранних версиях MySQL (до 5.7), значение `query_cache_size` по умолчанию было 0, что означает, что кэш запросов был отключен.

Однако, начиная с версии MySQL 5.7, кэш запросов был удален из MySQL, и параметр `query_cache_size` больше не используется. Это было сделано, потому что кэш запросов был считается неэффективным и мог вызывать проблемы с производительностью в некоторых сценариях.

Если вы используете MySQL версии 5.7 или новее, значение параметра `query_cache_size` будет игнорироваться, независимо от того, какое значение вы установите в конфигурации.

Если у вас установлена более ранняя версия MySQL и вы хотите узнать значение `query_cache_size` по умолчанию, вы можете выполнить следующий запрос SQL:

SHOW VARIABLES LIKE ‘query_cache_size’;

Этот запрос отобразит текущее значение параметра `query_cache_size`. Если значение равно 0, это означает, что кэш запросов отключен. Если значение отличается от 0, это будет указывать на размер кэша запросов в байтах.

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

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

— использование мощной аппаратной платформы, многоядерного процессора, максимально доступного объема оперативной памяти (например, от 8 Гб и выше), дисковых массивов RAID 10;

---

справка!!

RAID 10 (также известный как RAID 1+0) представляет собой комбинацию двух уровней RAID: RAID 1 (зеркалирование) и RAID 0 (стрипинг). Этот уровень RAID обеспечивает как повышенную отказоустойчивость данных, так и улучшенную производительность чтения и записи.

В RAID 10, данные делятся на блоки и дублируются на разных дисках в зеркальном массиве (RAID 1). Затем эти зеркалированные блоки объединяются в массивы (RAID 0), где они распределяются по нескольким дискам. Таким образом, RAID 10 обеспечивает как дублирование данных для отказоустойчивости, так и распараллеливание операций чтения и записи для повышения производительности.

Преимущества RAID 10 включают:
— Высокую отказоустойчивость: если один диск выходит из строя, данные все еще доступны на зеркальных дисках.
— Быструю производительность чтения и записи: благодаря параллельной обработке данных на разных дисках RAID 0.
— Более низкую стоимость по сравнению с другими уровнями RAID, такими как RAID 5 или RAID 6.

Однако, RAID 10 требует большего количества дисков по сравнению с другими уровнями RAID, так как он использует комбинацию зеркалирования и стрипинга. Также важно отметить, что RAID 10 не обеспечивает защиту от потери данных в случае сбоя нескольких дисков, как это делают некоторые другие уровни RAID, такие как RAID 5 или RAID 6.

RAID 10 обычно используется в ситуациях, где требуется комбинация высокой отказоустойчивости и высокой производительности, например, для баз данных, виртуализации серверов или хранения больших объемов данных.

---

— использование по одному innodb-файлу на каждую таблицу. По умолчанию MySQL хранит все таблицы внутри уникального файла данных. Благодаря этому методу все новые таблицы будут созданы в собственных файлах. Это позволяет хранить файлы в разных файловых системах и делать резервные копии собранных данных.

Переменные для тюнинга базы данных (в этом же файле /etc/mysql/mysql.conf.d/mysqld.cnf):

1. `innodb_file_per_table = 1`: Этот параметр указывает, что каждая таблица InnoDB будет храниться в отдельном файле данных. Это позволяет более гибко управлять пространством на диске и улучшает производительность.

2. `innodb_status_file = 1`: Этот параметр включает запись информации о состоянии InnoDB в файле, что может быть полезно для мониторинга и анализа производительности.

3. `innodb_buffer_pool_size = 2G`: Этот параметр устанавливает размер буферного пула InnoDB, который является основной областью памяти, используемой для кэширования данных и индексов. Установка оптимального размера буферного пула может значительно повысить производительность.

4. `innodb_flush_log_at_trx_commit = 2`: Этот параметр определяет, как часто InnoDB записывает лог транзакций на диск. Значение 2 означает, что запись происходит каждую секунду, что может повысить производительность за счет сокращения операций записи на диск.

5. #`innodb_support_xa = 0`: Этот параметр указывает, поддерживает ли InnoDB распределенные транзакции (XA). Значение 0 означает отключение поддержки XA. С этим параметром — mysql не стартует, хотя моя версия mysql поддерживает данный параметр.

6. `innodb_log_file_size = 256M`: Этот параметр устанавливает размер файла журнала транзакций InnoDB. Больший размер файла может улучшить производительность при обработке большого объема транзакций.

7. `innodb_log_buffer_size = 16M`: Этот параметр устанавливает размер буфера журнала транзакций InnoDB. Больший размер буфера может улучшить производительность при записи транзакций на диск.

Каждый из этих параметров имеет свою роль в настройке и оптимизации работы InnoDB в MySQL, и они могут быть важными в зависимости от требований и характеристик вашей системы.

— использование партицирования таблиц и отключения housekeeper (функции автоматической очистки базы данных zabbix, об этом ниже);

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

На этом тюнинг базы данных закончен. Не забывайте, если объект мониторинга недоступен, процессы опроса его параметров будут заняты промежуток времени, равный таймауту на опрос. Если недоступно, например, 500 объектов, а с каждого из которых система собирает 10-15 параметров, всё это займет очереди и ресурсы системы и может привести к ее загруженности (500*15=7500 единиц ресурсов). Поэтому внимательно относитесь к созданию элементов данных в шаблонах опроса, и обнаружений, они должны происходить не чаще, чем это необходимо.

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

Параметр `HousekeepingFrequency` для Zabbix прописывается в конфигурационном файле `zabbix_server.conf`. Этот файл обычно находится в директории `/etc/zabbix/` . Полный путь —  `/etc/zabbix/zabbix_server.conf` на большинстве Linux-систем. 

Настраивается он в конфигурационном файле Zabbix  (zabbix_server.conf ) двумя параметрами:

HousekeepingFrequency = 1 #Частота запуска процедуры очистки (в часах, от 1 до 24);

MaxHousekeeperDelete = 1000000 #Количество удаляемых за раз значений из БД (от 1 до 1000000)

Чтобы Housekeeper заработал, необходимо раскомментировать параметры его работы в настройках конфигурационного файла Zabbix, и включить в веб-интерфейсе

Настройки Housekeeper в веб-интерфейсе Zabbix (↓↓↓↓↓↓↓↓)

Настройки Housekeeper в веб-интерфейсе Zabbix

Партицирование – иной подход к хранению данных, собранных Zabbix. Если InnoDB подразумевает создание отдельного файла под каждую таблицу (что на больших БД неэффективно, потому что таблицы могут достигать 100-150ГБ), партицирование создает для каждой таблицы отдельный файл каждые сутки, что гарантирует малый размер хранимых файлов, и их мгновенное удаление. В сети Интернет есть несколько рецептов партицирования для СУБД MySQL. На больших БД партицирование предпочтительнее HouseKeeper, поскольку мгновенное удаление устаревших данных не ведет к деградации производительности СУБД (в случае с HouseKeeper).

Раздел 10. Концепция мониторинга. Типы пользователей Zabbix.  Оповещения.

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

Начнем с концепции мониторинга и оповещений о событиях. Я считаю, что мониторинг сетевой инфраструктуры должен быть детальным. То есть, если вы имеете сервер, на котором развернуты сетевые сервисы – значит, нужно осуществлять мониторинг каждого сервиса в отдельности, производительность базы данных, ресурсов процессора и его температуры (можно получать либо по SNMP, либо с помощью связки агент-скрипт, запускаемый агентом), свободном пространстве на дисках. Если речь идет о мониторинге сетевого оборудования, необходимо собирать данные о пропускной способности линков и загруженности их трафиком, нагрузки на процессоры устройств, данные о температуре и значении напряжения в электрической сети с ИБП (если таковой имеется). Такая концепция позволяет видеть направления развития сети, текущие проблемы, узлы, которым необходима модернизация, а так же анализировать тенденции процессов, происходящих в сети, и прогнозировать необходимость масштабирования.

Оповещения о происходящих событиях, как ни странно, должны быть минимальны и селективны. Например, все сотрудники организации не должны получать почтовую, или смс-рассылку, о том, что на «необитаемом» складе вышел из строя коммутатор. Эти данные должен получить эксплуатационный инженер, причем один раз. Я рекомендую для онлайн мониторинга использовать основную панель Zabbix (Мониторинг — Панель). В крупных организациях обычно есть круглосуточные дежурные, которые могут наблюдать состояние инфраструктуры online, причем Zabbix предусматривает звуковое оповещение о событиях (нет необходимости online смотреть в экран физически).

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

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

Настройка уведомлений должна соответствовать следующим принципам:

— выбор параметров, для которых нужны уведомления. Не на все параметры их нужно настраивать;

— определение приоритета (степени важности);

— определение порога срабатывания. Для некоторых параметров имеет смысл установить несколько порогов срабатывания с разными уровнями важности (настроить несколько триггеров в шаблоне, или на узле сети).

Настройка уведомлений – не разовая задача. Этим следует заниматься постоянно, т.к. меняются приоритеты и появляются новые параметры. Возьмите на вооружение несколько простых правил:

— Избегать «слепоты». Если Вы несколько раз подряд получили уведомление и никак на него не отреагировали, уведомление нужно отключить. Значит, оно не важно.

— Избегать «постоянного участия». Система мониторинга должна отвлекать по важным событиям, а не слать уведомления о десятках проблем и статусов, некоторые из которых невозможно исправить или даже изменить. Для этого существует Dashboard (Мониторинг — Панель).

— Использовать разные механизмы уведомлений. Например, СМС только для исключительных случаев (отсутствие свободного места на дисковом хранилище), причем только однократное оповещение. Почтовые сообщения — для событий средней важности, например, недоступность узловых сетевых устройств, на которых строится архитектура сети. Для всего остального — Dashboard (Мониторинг — Панель).

— Учитывать особенности архитектуры сети и значения параметров в «штатном» режиме. Такие показатели, как Load Average или уровни загрузки трафиком, могут выходить за установленные пределы в разгар рабочего дня по очевидным причинам. Необходимо подбирать пороговые значения для триггеров, чтобы добиться полезности уведомлений.

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

Типы пользователей Zabbix

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

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

Рассмотрим порядок работы с учетными записями пользователей

Создание группы пользователей

zab215

Создание группы пользователей «Гостевая группа с правами на просмотр»

zab216

Выбор прав на просмотр для группы пользователей «Гостевая группа с правами на просмотр»

zab217

При выборе групп узлов сети, необходимо сразу назначать им права, иначе они не будут добавлены в список прав доступа.

Таким образом мы создали группу пользователей «Гостевая группа с правами на просмотр», с правами на просмотр групп узлов сети «Internet Objects», «Internet Sites NTP», «Internet Sites Service», «Templates/Network devices»

В процессе создания группы пользователей, можно отредактировать параметр «Доступ к веб-интерфейсу». Этот параметр задает тип аутентификации пользователя при входе в системы со своим логином и паролем.

Теперь создайте в этой группе пользователя

Создание пользователя (↓↓↓↓↓↓↓↓↓)

zab218

Выбор типа пользователя, и автоматическое наследование прав на объекты (из группы пользователей) (↓↓↓↓↓↓)

zab220

Выпадающее меню «Роль»  при создании пользователя определяет уровень прав к административным меню и уровень прав к данным групп узлов сети. 

Типы пользователей:

User  role
Пользователь имеет доступ только к меню Мониторинг. По умолчанию пользователь не имеет прав доступа к каким-либо ресурсам. Права доступа на просмотр групп узлов сети наследуются от прав группы пользователей, к которой данный пользователь принадлежит.

Admin role
Пользователь имеет доступ в меню Мониторинг и в меню Настройка. По умолчанию пользователь не имеет прав доступа к каким-либо ресурсам. Права доступа на просмотр групп узлов сети наследуются от прав группы пользователей, к которой данный пользователь принадлежит.

Super admin role
Пользователь имеет доступ ко всему меню — Мониторинг, Настройка и Администрирование. Пользователь имеет права Чтения-Записи ко всем группам узлов сети. Запрет доступа к каким-либо группам узлов сети никак не ограничивает права доступа пользователя.

Авторизуйтесь в системе как пользователь test (*53*79*11*)

Вид Zabbix и права на объекты для пользователя test

zab221

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

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

Оповещения

Следующая задача, которую нужно решить – это настройка почтовых оповещений. Я придерживаюсь той точки зрения, что E-Mail уведомления стоит использовать как можно реже. Но в каждом конкретном случае – все зависит от архитектуры сети, поэтому перейдем к делу.

Чтобы настроить уведомления, зайдите в меню Администрирование –> Способы оповещений –> Email

Справка!! В контексте Zabbix параметры «email» и «email (html)» относятся к форматам отправки уведомлений по электронной почте.

1. Параметр «email»: Этот параметр определяет формат отправки уведомлений в виде простого текста (plain text). При использовании этого формата, уведомления отправляются в виде обычного текста без форматирования или стилей.

2. Параметр «email (html)»: Этот параметр определяет формат отправки уведомлений в виде HTML-сообщений. При использовании этого формата, уведомления отправляются с использованием HTML-разметки, что позволяет добавлять стили, изображения, ссылки и другие элементы в сообщение.

При настройке уведомлений в Zabbix вы можете выбрать один из этих двух форматов в зависимости от ваших предпочтений и требований. Если вы хотите отправлять простые и компактные уведомления без дополнительного форматирования, используйте «email». Если вам нужно добавить стили или использовать более сложный формат сообщений, выберите «email (html)».

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

Отредактируйте настройки уведомлений согласно Рисунку ниже. Zabbix выступает почтовым клиентом, а значит – Вы должны иметь электронный почтовый ящик.

Рекомендую создать почтовый ящик на mail.ru, так как в gmail запрещено проходить авторизацию со сторонних приложений. В настройках почты mail.ru, в разделе Пароль и безопастность->Безопастность->Пароли дня внешних приложений —  мы можем  установить пароль специально для zabbix. Именно его и вводим в настройках zabbix, пример ниже. 

Настройка подключения к почтовому ящику (↓↓↓↓↓↓↓↓)

zab230

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

Имя – название уведомления, может быть любым;

Тип – Email, задается строго;

SMTP — сервер, задается строго; для gmail.com – smtp.gmail.com (зависит от настроек почтового сервера);

Порт SMTP сервера – 465, задается строго (зависит от настроек почтового сервера);

SMTP email – настоящий автор письма, отображается в свойствах принятого письма, в теле параметра «X-Google-Original-From»;

Безопасность подключения – SSL/TLS, задается строго, для всех современных почтовых серверов.

Проверки SSL узла и хоста – не включать.

Аутентификация – обычный пароль;

Имя пользователя – Ваш почтовый логин. Для почтового ящика This email address is being protected from spambots. You need JavaScript enabled to view it. параметр имя пользователя будет «user».

Пароль – действующий пароль от почтового ящика This email address is being protected from spambots. You need JavaScript enabled to view it..

Если все настроено корректно – почтовые уведомления будут работать (сразу проверьте)

zab231

После этого войдите в меню Администрирование –> Пользователи -> Admin (Ваша учетная запись, с которой Вы работаете по умолчанию) –> Оповещения, и добавьте созданный Вами способ уведомления (рис ниже)

Настройка уведомлений в рамках учетной записи (↓↓↓↓↓↓↓↓)

zab223

Нажмите «Добавить», а потом, в окне Оповещений – «Обновить», чтобы применить изменения.

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

Теперь необходимо настроить сами действия, то есть зафиксированные Zabbix-сервером события, которые служат сигналом для отправки электронных писем. Перейдите в меню Настройка –> Действия триггеров, и создайте новое действие . Источников событий в Zabbix может быть несколько – триггеры (настроенные в шаблонах, и срабатывающие в зависимости от значения полученного элемента данных), обнаружения (когда используются автообнаружения узлов), авторегистрация активных агентов (если ранее неизвестный агент Zabbix запросил у сервера мониторинга проверку и начал отправлять ему данные), и внутренние события (речь идет о нештатных событиях в самой системе мониторинга, например, когда элемент данных или низкоуровневое обнаружение принимает значение «Не поддерживается», например, вследствие некорректных настроек элемента данных). Нас интересуют только триггеры.

Создайте новое действие (рис ниже)

Создание действия (↓↓↓↓↓↓↓↓↓)

zab224

Созданное на рисунке (выше) действие будет совершено при любом из условий, например, имя триггера (неважно, к какому шаблону или узлу сети он будет относиться) будет иметь значение «Узел недоступен», или важность триггера имеет значение «Высокая». Тип вычисления «ИЛИ» для нескольких условий гарантирует отправку оповещения при срабатывании триггера на событие, совпадающее с любым из Условий. Кроме того, для любых событий, случившихся в группах узлов сети Agent Monitoring Servers, Internet Objects, или Internet Site Service – так же будет сгенерировано оповещение.

Продолжайте настройку оповещения (↓↓↓↓↓↓↓↓)

zab225

Problem: {EVENT.NAME} на {HOST.NAME}

Problem started at {EVENT.TIME} on {EVENT.DATE}

Problem name: {EVENT.NAME}
Host: {HOST.NAME}
Severity: {EVENT.SEVERITY}

Originak problem ID: {EVENT.ID}
{TRIGGER.URL}

Настройка оповещения на сработавший триггер (↓↓↓↓↓↓↓↓↓)

zab226

В полях «Тема по умолчанию» и «Сообщение по умолчанию» уже присутствуют шаблонные сообщения с использованием макросов. Количество писем, их периодичность, адресаты – всё очень гибко настраивается. Самостоятельно заполните вкладку «Операции восстановления» — и тогда почтовые уведомления будут приходить как для сработавшего триггера, так и для его восстановления в нормальное состояние.

Результат приведен ниже (↓↓↓↓↓↓↓↓↓↓↓):

 

zab227

Для заполнения вкладки «операции восстановления» можно воспользоваться помощью чатЖПТ

zab228

!!!справка!!!  

Когда вы создаете операцию восстановления в Zabbix, вы можете заполнить пункт «Детали операции» с помощью макросов, чтобы включить информацию о событии в сообщение. Вот пример заполнения пункта «Детали операции» для операции восстановления:

Событие восстановлено:
{EVENT.RECOVERY.DATE} {EVENT.RECOVERY.TIME}

Триггер: {TRIGGER.NAME}
Хост: {HOST.NAME}
IP-адрес: {HOST.IP}
Описание: {EVENT.RECOVERY.NAME}
Значение: {ITEM.VALUE1}

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

— {EVENT.RECOVERY.DATE}: Дата восстановления события.
— {EVENT.RECOVERY.TIME}: Время восстановления события.
— {TRIGGER.NAME}: Имя триггера, который вызвал событие.
— {HOST.NAME}: Имя хоста, на котором произошло событие.
— {HOST.IP}: IP-адрес хоста.
— {EVENT.RECOVERY.NAME}: Описание восстановленного события.
— {ITEM.VALUE1}: Значение элемента данных, связанного с триггером.

Вы также можете добавить дополнительные макросы или изменить текст сообщения в соответствии с вашими потребностями. Убедитесь, что макросы заключены в фигурные скобки {} для правильного распознавания Zabbix.

---

Отладку оповещений можно производить, например, с основной панели . Этот функционал дублируется в меню Мониторинг –>> Проблемы. Разумеется, в файле логов Zabbix-сервера так же есть подробная информация о происходящем.

zab229

Подробные отчеты об отправке уведомлений находятся в меню Отчеты – >Журнал действий (рис ниже ↓↓↓↓↓↓↓↓)

zab232

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

Важно!! При использовании почтовых уведомлений – используйте однократную отправку письма по определенным конкретным событиям (их можно гибко настроить в Действиях), угрожающим работоспособности всей сети, или ее ключевым сервисам. Реакцией на письмо должно быть немедленное устранение причин аварии. Если в такой реакции нет необходимости или устранить аварию нет возможности – такое уведомление нужно сразу же выключить. Дело в том, что результат таких уведомлений отсутствует, а Администратор системы перестает воспринимать письма от Zabbix как оповещения и руководство к действию.

Раздел 11. Grafana — среда визуализации.

Следующая тема, которую стоит рассмотреть в рамках курса Zabbix – отображение данных, собранных системой мониторинга Zabbix, в среде визуализации Grafana. 

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

Начнем с установки Grafana на нашу ОС Ubuntu 22.04. Посетите официальный сайт grafana.com, и получите ссылку для скачивания пакета. Подробная навигация по сайту отображена на рисунке ниже

Официальный сайт проекта Grafana (↓↓↓↓↓↓↓↓↓)

zab233

zab234

Выбор версии и редакции продукта под OS 

zab235

Подробную информацию по установке Grafana можно найти на сайте https://grafana.com/docs

Вы можете установить Grafana, используя официальный репозиторий APT, загрузив пакет .deb или загрузив бинарный файл .tar.gz.

«Установка из репозитория APT» выглядит вот так. При таком способе установки Grafana будет автоматически обновляться каждый раз, когда вы запускаете команды:

zab236

Я установлю через .deb пакет

# sudo apt-get install -y adduser libfontconfig1 musl

Расшифровка команды `sudo apt-get install -y adduser libfontconfig1 musl`:

— `sudo`: команда для выполнения следующей команды с правами суперпользователя (администратора).
— `apt-get`: команда для работы с менеджером пакетов Advanced Packaging Tool (APT) в Ubuntu.
— `install`: опция команды `apt-get`, указывающая на установку пакетов.
— `-y`: опция команды `apt-get`, указывающая на автоматическое подтверждение всех вопросов о подтверждении при установке пакетов.
— `adduser`: имя пакета, который будет установлен. Этот пакет предоставляет команды для добавления новых пользователей на систему.
— `libfontconfig1`: имя пакета, который будет установлен. Этот пакет содержит библиотеку для управления конфигурацией шрифтов в Linux.
— `musl`: имя пакета, который будет установлен. Этот пакет представляет собой реализацию стандартной библиотеки языка C для микроконтроллеров и встроенных систем.

Таким образом, данная команда устанавливает пакеты `adduser`, `libfontconfig1` и `musl` на вашу систему Ubuntu с автоматическим подтверждением всех вопросов о подтверждении.

# wget https://dl.grafana.com/oss/release/grafana_10.1.1_amd64.deb

# sudo dpkg -i grafana_10.1.1_amd64.deb

Запустите сервер Grafana с помощью systemd

# sudo systemctl daemon-reload
# sudo systemctl start grafana-server
# sudo systemctl status grafana-server

Теперь добавьте сервис Grafana в автозагрузку:

# sudo systemctl enable grafana-server

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

# grafana-cli plugins list-remote

Для Zabbix существует плагин, созданный Александром Зобниным, установите его:

# sudo grafana-cli plugins install alexanderzobnin-zabbix-app

И после этого, перезапустите сервис Grafana:

# sudo systemctl restart grafana-server

Пора осуществить первый вход. Веб-интерфейс Grafana находится на том же IP-адресе, что и Zabbix, но сервис по умолчанию работает на порту 3000 (это можно изменить в настройках, главное, чтобы Вы не пытались разместить и Zabbix, и Grafana, как и любые другие сервисы, за одним и тем же портом, такая конструкция, разумеется, не будет работать). http://192.168.88.150:3000/login

Логин и пароль по умолчанию – admin / admin (я установил пароль —  admin1).

Сразу после входа – включите плагин для Zabbix в настройках Administration –> Plugins

Включение плагина Zabbix

zab237

После этого необходимо настроить источник данных, с которого Grafana будет извлекать значения. Grafana взаимодействует с Zabbix через Zabbix API (обратите внимание, Grafana не подключается напрямую к СУБД MySQL, потому что Zabbix индексирует свои данные определенным образом, а нам нужно, чтобы Grafana видела эти данные именно с точки зрения Zabbix).

API (application programming interface) – набор готовых процедур и функций, предоставляемых приложением для использования во внешних программных продуктах. По сути, API информационной системы создается для того, чтобы предложить набор готовых решений сторонним приложениям. В этом случае интеграция разных продуктов проходит прозрачно, и без необходимости изменять исходный код готовых программных продуктов. Настройка API Zabbix как источника данных приведена на рисунке ниже

zab238

 

zab240

Поле URL заполняется следующим образом:

http://_Ваш_IP_адрес_/zabbix/api_jsonrpc.php

Также нужно заполнить поля Username / Password. Речь идет об учётных данных Zabbix – Суперадминистратора, которые Вы используете для входа в Zabbix. Соответственно, при использовании этой учетной записи, Grafana получит доступ ко всем собранным данным всех узлов сети.

Важно!! При сохранении настроек источника данных, в случае успешного подключения Grafana к Zabbix API, будет выведено сообщение «Zabbix API version: 6.0.13», в зеленом поле. Если Вы не получили это сообщение – настройки источника данных неверны.

Теперь пора заняться отображением данных из Zabbix. В рамках курса Zabbix мы не будем рассматривать процесс администрирования Grafana, а только кратко познакомимся с принципами ее работы. Подробная документация по функционалу Grafana приведена на официальном сайте проекта.

Итак, воспользуемся готовыми панелями Dashboard, которые когда-то создали пользователи связки Zabbix / Grafana, и поделились своими наработками на официальном сайте проекта.

На официальном сайте проекта, в разделе Dashboards (https://grafana.com/grafana/dashboards/), с помощью поиска найдите готовые Dashboard, созданные для Zabbix. Выберите понравившуюся, и скопируйте в буфер обмена её кодовый номер (поле «Get this dashboard:»)

zab241

В интерфейсе Grafana, войдите в меню импорта панелей, и вставьте этот номер

zab242

Во время  импорта готовой Dashboard нужно выбрать datasource Zabbix

zab243

Для того, чтобы была возможность редактировать дашборд — нужно нажать на dashboard settings (в правом вверхнем углу) и включить возможность редактировать

zab247

После импорта готовой Dashboard, войдите в нужный график (наводим на нужный график, затем жмем на вертикальные точки  и выбираем edit), и отредактируйте в каждом графике источники данных (визуализируйте параметры работы узла Zabbix server), в поле Query type

Редактирование графика в рамках готовой панели

zab248

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

Элементы данных узла сети Zabbix server

zab249

После настройки элементов Dashboard, у Вас должна получиться примерно следующая картина

Готовая Dashboard с отображением данных из Zabbix

zab250

Вы получили альтернативный инструмент отображения статистики, собранной системой мониторинга Zabbix. Главное преимущество Grafana перед Zabbix (с точки зрения отображения данных) – полная масштабируемость инструментов визуализации. Так же, субъективно, интерфейс и графики Grafana гораздо красивее, чем у Zabbix.

Пример мониторинга логов на Windows.

Условие таково: есть сервер windows 2003 R2, нужно мониторить системный лог на появление ошибок.

Для начала нужно проверить файл настройки клиента, C:\Program Files\Zabbix Agent\zabbix_agentd.conf

Поля:

Server=192.168.1.19

ServerActive=192.168.1.19

Hostname=win-serv2003

Где: Server — ip сервера zabbix, ServerActive — ip сервера zabbix (используется для активных проверок), Hostname — имя машины клиента, оно должно совпадать с именем в поле «DNS имя» настроек узала сети.

Идем в web морду zabbixa

Настройки->Узлы сети->win-serv2003->Элементы данных->Добавить Элемент данных->

имя — SystemLogItem

тип — zabbix agent (активный)

ключ — eventlog[System,,»error»,,,,skip]

тип информации — Журнал (лог)

Интервал обновления (в сек) — 60

Период хранения истории (в днях) — 7

Группы элементов данных — logs        (группа должна быть уже создана)

Жмем Обновить.

Описание ключа: eventlog[имя,<регулярное выражение>,<важность>,<источник>,<eventid>,<макс. кол-во строк>,<режим>]

имя — имя журнала событий.
регулярное выражение — регулярное выражение описывающее требуемый шаблон
важность — регулярное выражение описывающее важность
Параметр может принимать следующие значения: “Information”, “Warning”, “Error”, “Failure Audit”, “Success Audit”
источник — идентификатор источника
eventid — регулярное выражение описывающее идентификатор(ы) событий
макс. кол-во строк — максимальное количество новых строк в секунду, которое агент будет отправлять Zabbix серверу или прокси. Этот параметр заменяет значение ‘MaxLinesPerSecond’ в zabbix_agentd.win.conf
режим — возможные значения:  all (по умолчанию), skip (пропускать обработку старых данных)

Переходим во вкладку триггеры.

Жмем Создать триггер.

имя — ERROR SYSTEM LOG {HOST.NAME}

важность — средняя

выражение проблемы — {TemplateAtlant Windows Servsers:eventlog[System,,»error»,,,,skip].regexp(^.*$,200)}<>0

Выражение восстановления {TemplateAtlant Windows Servsers:eventlog[System,,»error»,,,,skip].nodata(210)}=1

Жмем Обновить.

Пояснение: TemplateAtlant Windows Servsers — имя шаблона которому принадлежит триггер,  .regexp(^.*$,200) — условие найти любую строку за последние 200 секунд,  .nodata(210) — условие если нет данных за последние 210 секунд.

Проверим тригер

На клиенте в командной строке пишем

eventcreate /t error /id 999 /l system /
so «1Zabbix test event» /d «Test ERROR event log by Zabbix»

 Пример мониторинга по SNMP

Добавим в узел интерфейс SNMP

Настройка -> Узлы сети -> Имя Узла -> Интерфейсы SNMP -> Добавить -> Заполняем ip, dns имя, порт.

Создаем шаблон, заходим в него.

Элементы данных -> Добавить элемент данных

имя — TempheratureCPU2; Тип — SNMPv2 агент; ключ — любое понятное описание; SNMP OID — 1.3.6.1.4.1.232.6.2.6.8.1.4.0.2; SNMP comunity — public; заполняем все остальные поля

Чтобы найти правильные OID пользуемся гуглом. Проверяем, используя snmpwalk на линуксе.

snmpwalk -v2c -c rdon 192.168.21.27 1.3.6.1.4.1.232 > /etc/snp.txt

snmpget -v2c -c rdon 192.168.21.27 1.3.6.1.4.1.232.6.2.6.8.1.4.0.2

так мы получаем значения, а описания ищем вбивая сам OID в гугле, вот несколько сайтов.

https://wiki.opennms.org/wiki/HP_Insight_Manager

http://oidref.com/1.3.6.1.4.1.232.3.2.5.1.1.6

Создадим правило автообнаружения.

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

И так для чистоты эксперемента я создал отдельный шаблон test snmp, и узел сети Server.

Заходим в наш шаблон и жмем Обнаружения->Создать правило обнаружения->

Имя — Discover HDD SNMP      (придумываем сами)

Тип — SNMPv2 агент

Ключ — cpqDaPhyDrvBay      (придумываем сами)

SNMP OID — discovery[{#SNMPVALUE}, .1.3.6.1.4.1.232.3.2.5.1.1.5]

SNMP Community — public

Интервал обновления — 43200       (12 часов, если надо проверить незамедлительно на время ставим 10 сек)

Период сохранения потерянных ресурсов — 7    (После 7 дней удалиться диск, который умер и был извлечен)

Жмем добавить.

Заходим в Прототипы элементов данных-> Создать Прототип элементов данных->

Имя — Статус {#SNMPVALUE} физического диска

Тип — SNMPv2 агент

Ключ — cpqDaPhyDrvStatus.[{#SNMPINDEX}]

SNMP OID — 1.3.6.1.4.1.232.3.2.5.1.1.6.{#SNMPINDEX}      (Обратить вниамние на отличие в конце — 6,  предидущие OID выводил порядковай номер, а этот значение статуса диска)

SNMP Community — public

Тип информации — Числовой (Целое положительное)

Тип данных — Десятичный

Интервал обновления — 60

Период хранения информации — 7

Группа элементов — SNMP HDD         (предварительно ее создать)

Жмем Добавить.

Заходим в Прототипы тригерров-> Создать прототип триггеров->

Имя — Статус диска на сервере {HOST.NAME} в отсеке {#SNMPVALUE} — FAILED

Выражение -{Server:cpqDaPhyDrvStatus.[{#SNMPINDEX}].last()}=4        (Добавить->Выбрать прототип)

Добавить