Zabbix-агент недоступен

Небольшая капля информации о мониторинге и простой установке Zabbix.

Диагностика работы сервера и агента Zabbix. Самые простые способы найти причины неработоспособности.

Что такое мониторинг

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

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

Обычно от мониторинга ждут следующего:

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

Таким первым шагом может быть установка системы мониторинга Zabbix. Это не единственное решение, но весьма себя зарекомендовавшее. Другими решениями можно назвать:

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

И снова проблема

Мы рано радовались. Снова появилась проблема — сервер Zabbix не запускается, хотя на этапе настройки веб-интерфейса все могло быть хорошо. В логах ‘/var/log/zabbix/zabbix_server.log’ можно увидеть такую информацию:

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

# разрешаем соединение веб-сервера с Zabbix
setsebool httpd_can_connect_zabbix on

# Следующий пункт мы уже сделали ранее
# Если база данных доступна через сеть (включая ‘localhost’ в случае PostgreSQL) вам также потребуется разрешить соединение между Zabbix веб-интерфейсом и базой данных:
# setsebool -P httpd_can_network_connect_db on

# Перезапускаем Apache
service httpd restart

Но пока и этого недостаточно. Нужно настроить политики SELinux, чтобы разблокировать заблокированные операции Zabbix’а. Для быстрой настройки установим пакет ‘policycoreutils-python’:

Теперь мы можем создать правила SELinux на основании событий в логах:

Перезапускаем Zabbix и теперь все готово:

systemctl restart zabbix-server

# Проверяем статус
systemctl status zabbix-server

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

One of the servers monitored by Zabbix is not reachable. I have no idea why as this works normally with other servers.

Agent log after restart of zabbix-agent service

When I telnet to the agent-server, then enter agent.version, it returns: ZBXD2.2.11

Contents of /etc/zabbix/zabbix_server.conf (server):

Contents of /etc/zabbix/zabbix_agentd.conf (agent)

PidFile=/var/run/zabbix/zabbix_agentd.pid
LogFile=/var/log/zabbix/zabbix_agentd.log
LogFileSize=0
EnableRemoteCommands=1
Server=zabbix-server-ip
ListenPort=10050
StartAgents=3
# ServerActive=zabbix-server-ip # commented out
Hostname=server.test
Timeout=3
AllowRoot=1
Include=/etc/zabbix/zabbix_agentd.d/

Netstat on zabbix server

Netstat on problematic agent

Netstat on working agent

Active vs passive agent

All in all, the active mode may have been set in the agent config on several servers, it has never worked. All reports are from passive agents.

I don’t know why this happens, but it seems strange.

What can cause this connection problem? How can I reconnect the server with the agent?

Ребут и агента нет

Бывают случаи, когда агент был успешно установлен и настроен на хосте, мониторинг работает как надо. Н О! При очередном запланированном перезапуске сервера (хоста) Zabbix-агент не смог запуститься.

Причин тому может быть несколько:

При этом в файле лога агента может не быть какой-либо полезной информации, но она есть в системных журналах ОС. Чаще всего это поведение встречал в ОС Windows.

Решение достаточно простое: нужно установить для службы Windows режим запуска “Автоматически (отложенный запуск)”. В большинстве случаев проблема будет решена.

Быстро и просто!

Агент еще жив

Основные способы диагностики сервера Zabbix мы рассмотрели. А что на счет агентов на хостах, которые входят в мониторинг?

Выше уже было упомянуто, что у агента есть свои логи. Именно они и являются основным источником данных для диагностики его работы. Если мы говорим о *.nix системах, то обычно файл лога находится в “/var/log/zabbix/zabbix_agent.log”. Вот, например, его содержимое при старте процесса агента.

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

Может не открыт порт на сервере? Или сервер недоступен? Или ошибка в конфигурационном файле агента?

Аналогичный файл лога есть для агентов всех поддерживаемых операционных систем, в том числе и Windows. Его расположение можно уточнить в самом конфигурационном файле агента в параметре “LogFile”. Для Windows это может быть каталог самого агента, например:

### Option: LogFile
# Log file name for LogType ‘file’ parameter.

# Mandatory: no

C:rogram FilesabbixAgentabbix_agentd.log

В любом случае, если у Вас проблемы в работе агента, то первым делом идем в его логи и смотрим что вообще происходит.

Ох уж эта безопасность

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

firewall-cmd public 80/tcp
firewall-cmd

# «local» is for Unix domain socket connections only
all all peer
# IPv4 local connections:

# Разрешаем подключение к базе zabbix пользователю zabbix

host zabbix zabbix 127.0.0.1/32 password

host all all 127.0.0.1/32 ident
# IPv6 local connections:

# Разрешаем подключение к базе zabbix пользователю zabbix

host zabbix zabbix ::1/128 password

host all all ::1/128 ident

# replication privilege.
replication all peer
host replication all 127.0.0.1/32 ident
host replication all ::1/128 ident

Проверяем подключение к базе zabbix с помощью psql:

psql 127.0.0.1 zabbix

Если после ввода пароля запустилась сессия работы с PostgreSQL, то все в порядке. В противном случае проверьте настройки файла pg_hba.conf и корректность пароля.

Настраиваем агента Linux

Теперь рассмотрим процесс подключения новой машины к мониторингу. Установим агента Zabbix на сервер под управлением CentOS 7.

На самом деле мы это уже в какой-то мере уже сделали, т.к. на сервер Zabbix мы уже устанавливали пакет “zabbix-agent”. А в веб-интерфейсе мы уже видели собираемые данные о сервере.

Установку и конфигурирование начнем с самого главного — перейдем на страницу с выбором необходимой версии агента:

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

Как и с установкой сервера, сначала рекомендую обновить компоненты системы, пакеты:

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

# Добавляем репозиторий
sudo rpm -Uvh https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-1.el7.noarch.rpm

Установим и сам пакет агента Zabbix, а после запустим его.

# Установка пакета агента
yum zabbix-agent

# Запускаем агент
systemctl start zabbix-agent

# Проверяем состояние
systemctl status zabbix-agent

Запустили мы, конечно, рано, нужно еще сконфигурировать работу агента. Идем в файл ‘/etc/zabbix/zabbix_agentd.conf’ и изменяем три параметра:

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

# Перезапускаем агента
systemctl restart zabbix-agent

# Проверяем состояние
systemctl status zabbix-agent

И проверяем логи работы агента. Возьмем последине 30 строк для анализа:

Мы получим все что происходило при запуске агента. В нашем примере вывод был таким:

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

Ошибка снова связана с настройками безопасности. Нужно открыть порт 10051 сервера Zabbix.

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

# Перезапускаем агента
systemctl restart zabbix-agent

# Проверяем состояние
systemctl status zabbix-agent

# Проверяем что там в логах
30 /var/log/zabbix/zabbix_agentd.log

В этот раз все отлично.

Также на вкладке “Templates” (Шаблоны) выбираем шаблоны показателей, которые будем собирать. Сейчас просто выбрал шаблон стандартных метрик для Linux OS.

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

Ситуация, думаю, понятная. На клиентской машине нужно открыть порт 10050 для взаимодействия с сервером мониторинга. Делается это аналогичными командами как и для порта 10051 сервера выше.

Ждем немного времени и видим, что с соединением теперь все отлично.

Данные от агента поступают и все работает как надо. Дело сделано, мониторинг этой машины работает. Далее рассмотрим кратко установку агента на хост с операционной системой Windows.

Все в очередь

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

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

Самыми распространёнными причинами увеличения очереди являются:

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

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

Логи наше все

Логи по традиции мира *.nix хранятся в текстовых файлах и располагаются в каталоге ‘/var/log/zabbix’.

В этом же каталоге можно увидеть файлы логов Zabbix-агента. Чаще всего на сервере Zabbix для отслеживания работы сервера установлен агент. Да, Zabbix-сервер следит сам за собой.

Прочитать содержимое можно стандартными для Linux способами:

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

Вот, например, вывод последних 10 событий из файла логов.

Здесь мы видим события процесса housekeeper, который отвечает за удаление устаревшей информации из базы данных мониторинга. Далее идут более интересные события об ошибке связи с хостом “YY-COMP”, а также события последующего восстановления соединения с агентом этого хоста.

1386:20201017:002028.428 Zabbix agent item on host failed: first network error, 15 seconds
1394:20201017:002043.521 Zabbix agent item on host failed: another network error, 15 seconds
1394:20201017:002058.554 Zabbix agent item on host failed: another network error, 15 seconds
1394:20201017:002113.579 temporarily disabling Zabbix agent checks on host : host unavailable
1394:20201017:003815.366 enabling Zabbix agent checks on host : host became available

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

Подготовка к установке

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

Будем считать, что CentOS уже установлена, а также сконфигурирован firewall, сетевые настройки, SELinux и прочее. Мы лишь остановимся на настройках, непосредственно связанных с Zabbix. Единственное, рекомендую обязательно обновить пакеты, компоненты системы до свежих версий командой:

Настраиваем базу данных

Ранее мы установили СУБД, теперь время создать пользователя баз данных для системы мониторинга.

Когда база создана, необходимо импортировать схему данных базы.

Теперь в файле ‘/etc/zabbix/zabbix_server.conf’ изменим параметр пароля базы данных zabbix:

mcedit /etc/zabbix/zabbix_server.conf
# Ищем ‘DBPassword=’ и подставляем пароль, указанный выше для пользователя zabbix

Совсем немного о Zabbix

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

Сбор данных Zabbix может выполнять на основе:

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

Пройдем все основные шаги по установке и началу использования Zabbix.

Продолжение следует

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

Не смотря на большой объем, на самом деле тема эта очень простая и не требует большого количества времени для изучения. Все что нужно — это один раз ознакомиться с документацией и попробовать использовать. После можно считать, что мониторинг Вам уже не страшен.

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

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

Удачи в делах и вдохновения!

Будьте в курсе

По любым вопросам пишите на электронную почту. Адрес в самом низу страницы.

Установка и конфигурирование Zabbix

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

Теперь начнем установку Zabbix.

Немного опечатались

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

Можно потратить много времени на разбор ситуации, а причина окажется очень проста — ошибка в файле конфигурации из-за “копипасты”. То есть конфигурацию скопировали, но в файле не поменяли параметр “Hostname”. В итоге сервер Zabbix говорит, что агент доступен, но сам агент присылает данные для другого хоста. Вот так выглядит список дисков для проблемной машины. Нет никакой информации о дисках, но при этом общие показатели агент все же передал.

Как только мы исправим в файле конфигурации параметр “Hostname” на нужный (в нашем случае это “SRV-SQL-01-VM”), то картина сразу же изменится. В списке появятся все диски сервера.

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

Копипаст — зло! Будьте осторожны!

Первый поход на фронт

А также уже есть собранные данные для анализа. Это информация о самом сервере Zabbix.

Все готово для использования.

Немного настроек для фронта

Осталась еще одна настройка — это настроить часовой пояс для PHP в файле ‘/etc/httpd/conf.d/zabbix.conf’:

mcedit /etc/httpd/conf.d/zabbix.conf
# Пример конфигурации:
# php_value date.timezone Europe/Moscow

Подготавливаем базу данных

Прежде чем устанавливать сам Zabbix, установим и настроим PostgreSQL 11, который будет хранилищем данных системы мониторинга. Конечно, можно было бы представить просто список команд в терминале и остановиться на этом, но это было бы некорректно.

Вместо этого рекомендую сначала перейти на официальную страницу загрузки / установки PostgreSQL, а уже на ней выбрать операционную систему, версию СУБД, платформу и архитектуру. После этого будет выдана актуальная инструкция по установке СУБД для выбранных параметров. Это может пригодиться, если Вам нужна другая версия СУБД или при использовании другой операционной системы.

Мы же продолжим пример для CentOS 7 и PostgreSQL 11. Устанавливать СУБД будем на тот же сервер, где будет находиться и сам Zabbix. В рабочем окружении это не всегда правильно и для масштабирования хранилища может потребоваться вынести PostgreSQL на отдельный сервер (или даже нескольких серверов). Но в нашем простом примере все будет на одной машине.

# Установка репозитория
yum https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm

# Устанавливаем PostgreSQL
yum postgresql11-server

# Дополнительные настройки
# Инициализация кластера баз данных
/usr/pgsql-11/bin/postgresql-11-setup initdb
# Включаем автоматический запуск PostgreSQL
systemctl postgresql-11
# И запускаем его
systemctl start postgresql-11

Проверим успешно ли прошла установка. Запустим утилиту psql и выполним запрос на получение версии СУБД.

# Запускаем psql от имени пользователя postgres
postgres psql

# Выполняем запрос получения версии СУБД

SELECT VERSION

# Пример результата:
# PostgreSQL 11.9 on x86_64-pc-linux-gnu,
# compiled by gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-39), 64-bit

Ошибок нет — значит все прошло отлично. Можно также провести тюнинг настроек PostgreSQL, но это уже другая история. Можете использовать сервис PGTune, чтобы подобрать настройки под себя. Подробнее об этом останавливаться сейчас не будем. На этапе установки Zabbix мы еще вернемся к некоторым настройкам СУБД, но это будет позже.

Мониторинг системы мониторинга

Благодаря тому, что Zabbix позволяет собирает метрики о состоянии самого себя, мы можем отслеживать некоторые проблемы с его помощью. После установки сервера, по умолчанию в списке хостов содержится сам сервер с шаблоном “Template App Zabbix Server”.

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

Например, если Вы увидите уведомления о проблеме “Zabbix poller processes more than 75% busy” от одного из триггеров этого шаблона, то идем в официальную документацию и читаем что это. Можно увидеть, что проблему можно решить изменив параметр “StartPollers” в файле конфигурации Zabbix-сервера.

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

Таймаут выполнения скриптов

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

ZBX_NOTSUPPORTED: Timeout executing a shell script

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

### Option: Timeout
# Spend no more than Timeout seconds on processing

# Mandatory: no
# Range: 1-30

Имеется три основных варианта решения:

### Option: Timeout
# Spend no more than Timeout seconds on processing

# Mandatory: no
# Range: 1-30

30

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

Мастер настройки Zabbix

Мы находимся на начальной странице настройки Zabbix.

Жмем “Next step” и попадаем на страницу с проверкой всех требований к работе системы мониторинга. Везде должно быть ОК. Если нет, то смотрите документацию по ситуации. Обычно необходимо установить совместимую версию PHP с текущей версией Zabbix.

Идем далее и попадаем на страницу настройки подключения к базе данных. Даже если сейчас введем пароль для пользователя zabbix, то ничего не выйдет. Мы получим ошибку “Error connecting to database.” и не будет понятно почему так произошло.

# Читаем последние 25 строк из файла логов
25 /var/log/audit/audit.log

то можем увидеть такое сообщение:

Именно SELinux блокирует подключение Apache (https) к PostgreSQL. Интуитивно это понять никак не получится, нужно просто знать 🙂 (а возможно и гуглить). Исправить это можно добавив правило, разрешающее такое подключение:

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

Проверяем их и идем на финальный шаг.

Ура! Все эти настройки можно будет изменить в конфигурационном файле ‘/etc/zabbix/web/zabbix.conf.php’ по необходимости.

Установка пакетов

Первым делом устанавливаем репозитории, пакеты Zabbix-сервера, веб-интерфейс и агент сбора данных.

# Установка репозитория
rpm https://repo.zabbix.com/zabbix/4.0/rhel/7/x86_64/zabbix-release-4.0-2.el7.noarch.rpm
# Предварительная очистка
yum clean all

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

# Установка основных пакетов сервера, веб-интерфейса и агента
yum zabbix-server-pgsql zabbix-web-pgsql zabbix-apache-conf zabbix-agent

Особые проблемы со счетчиками

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

При этом для хоста у элементов данных будет такая ошибка.

ZBX_NOTSUPPORTED: Cannot obtain system information.

Проблема в некорректном списке доступных счетчиков производительности Windows на хосте с агентом, то есть на машине, которую мы собираемся мониторить. Можно проверить наличие нужного счетчика через “Монитор производительности” (perfmon.exe) или через ветку реестра:

# Ключ «Counter» содержит список всех доступных счетчиков производительности.

Если нужного счетчика нет, то можно попытаться перестроить все счетчики ОС командой:

lodctr /r

# Утилита находится в «C:WINDOWSSystem32»

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

Счетчики производительности для мониторинга Windows — отличный инструмент. И его, конечно же, нужно использовать.

База данных требует внимания

Zabbix хранит данные метрик в одной из поддерживаемых СУБД: MySQL или PostgreSQL. Для оптимальной производительности обязательно нужно выполнить их настройку. Я предпочитаю использовать PostgreSQL, но тут все полностью зависит от задач.

Касательно PostgreSQL нужно обязательно адаптировать ее настройки под ресурсы сервера, т.к. по умолчанию там установлены максимальные ограничения на используемую память и другие ресурсы. Рекомендую зайти на сайт PGTune, который поможет подобрать параметры СУБД под Ваш сервер. Просто берете и переносите их в свой файл конфигурации “postgresql.conf”.

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

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

Стартуем процессы

Теперь все готово для запуска процессов Zabbix.

# Перезапускаем процессы
systemctl restart zabbix-server zabbix-agent httpd
# Устанавливаем автоматический запуск
systemctl zabbix-server zabbix-agent httpd

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

Это была еще одна небольшая публикация по теме мониторинга с помощью Zabbix. В следующих статьях мы поговорим об обновлении Zabbix с версии 4.0 на 5.0, создадим свой шаблон для сбора метрик и рассмотрим некоторые особенности этого процесса, настроим уведомления в Telegram-канал, а также получении данных с Prometheus и визуализации данных в Grafana. И, конечно же, оптимизация производительности сервера мониторинга Zabbix!

Будьте на связи 🙂

Настраиваем агента Windows

Установка агента для Windows принципиально не отличается от той же установки для *.nix, которую мы рассмотрели выше:

Единственным отличием может быть синтаксис команд по настройке службы и правил брэндмауэра на стороне Windows. Их мы и опишем.

Сначала идем на страницу установки и выбора параметров. В нашем случае мы будем ставить агента на Windows Server 2012 для Zabbix 4.0. Вот эта конфигурация. Внизу страницы скачиваем предлагаемый клиент. Там же есть ссылка на документацию.

Скачиваем архив с приложением, распаковываем. Создаем каталог для приложения. Например: ‘C:Program FilesZabbixAgent’. В этот каталог из скачанного архива переносим два файла:

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

# Открываем порты со стороны агента Zabbix для Windows

«Open Zabbix agentd port 10050 inbound»

«Open Zabbix agentd port 10050 outbound»

# Устанавливаем агента как службу и запускаем

# Проверяем состояние службы

# Пример вывода
#Status Name DisplayName
#—— —- ————
#Running Zabbix Agent Zabbix Agent

Далее на всякий случай проверяем логи:

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

Подробнее информацию об установке агента на Windows можно также узнать в официальной документации.

Solution

It turns out that the IP address set in the host configuration (via the web interface) was that of the zabbix-server itself. This should of course be the address of the agent-server.

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

Ничего сверхестественного. Только базовая информация, которая дает представление о том куда нужно двигаться при наличии проблем в работе мониторинга на базе Zabbix.

Решение некоторых проблем

Рассмотрим решение некоторых проблем в работе сервера и агента. Это ни в коем случае не полноценный мануал, а скорее пара заметок. Небольшая порция “траблшутинга”. Более развернутую информацию Вы можете найти в официальной Wiki.