Проверка zabbix агента linux

Установка и настройка zabbix агента в Ubuntu Linux

Zabbix agent устанавливается на удаленном хосте для мониторинга жесткого диска, процессора памяти и т. д. Агент собирает данные и отправляет их обратно на Zabbix — сервер.

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

Эту инструкцию мы начнем с установки Zabbix агента на удаленный хост Ubuntu 20.04, а затем добавим Хост на панель мониторинга Zabbix server.

Рекомендую. к прочтению:

Шаг 1: Включите репозиторий Zabbix на удаленном хосте

Как всегда начните с обновления списков пакетов на удаленном хосте.

Затем загрузите Zabbix файл из репозитория Центра загрузки Zabbix. Делается это следующим образом.

Затем включите его с помощью команды dpkg следующим образом:

$ sudo dpkg -i zabbix-release_5.0-1+focal_all.deb

Далее обновите индекс пакетов Ubuntu, чтобы убедиться, что репозиторий синхронизирован

Шаг 2: Установка Zabbix агента

Как только репозиторий будет создан, установите Zabbix агент в Ubuntu Linux.

После завершения установки проверьте, работает ли демон Zabbix-agent следующим образом:

Zabbix — agent прослушивает порт 10050. Возможно, вы захотите проверить это. Сделать проверку можно с помощью команды netstat:

На изображении выше видно, что Служба Zabbix agent запущена и работает.

Шаг 3: Настройка Zabbix агента

Мы установили агент Zabbix и работает он как ожидалось. Но этого недостаточно. Нам нужно внести несколько изменений в конфигурационный файл. Сделайте изменения в файле /etc/zabbix/zabbix_agentd.conf, чтобы агент мог взаимодействовать с сервером Zabbix..

$ sudo vim /etc/zabbix/zabbix_agentd.conf

Здесь мы собираемся включить пассивные проверки агента. Сначала найдите переменные “server” и “Hostname” в файле zabbix_agentd.conf.

Например, мой IP адрес Zabbix-сервера — 10.128.0.16, а имя хоста (client system).

Сохраните изменения и выйдите из файла. Затем перезапустите службу Zabbix agent для внесения изменений.

$ sudo systemctl restart zabbix-agent

Примечание: Если вы настраиваете активную проверку, то ищите переменную “ServerActive” и используйте порт 10051.

Шаг 4: Настройка брандмауэра

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

Затем перезагрузите брандмауэр

А так же убедитесь, что порт был открыт и разрешен на брандмауэре.

Идеально! Теперь zabbix — агент должен работать.

Шаг 5: Добавление Хоста на Zabbix — Server Ubuntu Linux

По умолчанию Zabbix отслеживает только тот сервер, на котором он установлен. В этом разделе мы добавим Zabbix-Host на Zabbix-Server через браузер.

Итак, войдите в свой экземпляр Zabbix-сервера используя браузер.

В левой навигационной панели выберите пункт Configuration > > Hosts

Настройка хостов на Zabbix сервера

Перейдите в правый верхний угол и нажмите кнопку «Создать хост«. (Create host)

Создать хост

В появившемся окне заполните данные удаленного хоста, такие как имя хоста. видимое имя, IP-адрес, краткое описание и нажмите на кнопку «Выбрать» (Select) рядом с текстовым полем «Группы«.

Заполните все поля

В появившемся списке выберите пункт «Серверы Linux‘ и нажмите кнопку «Выбрать«.

Добавить группу хостов

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

Добавить группу серверов Linux

Затем перейдите на вкладку «шаблоны» (Templates) и нажмите кнопку «Выбрать» рядом с текстовым полем «Связать новые шаблоны» (Link new Templates).

Перейдите на вкладку шаблоны

Нажмите на кнопку «Выбрать«(Select) рядом с текстовым полем «Группа хостов«, как показано на рисунке.

Поиск группы хостов

Нажмите на опцию «Шаблоны/операционные системы» (Templates/Operating systems), как показано на рисунке.

выберите шаблоны опции операционной системы

Затем выберите опцию «Template OS Linux by Zabbix agent’ и нажмите кнопку «Выбрать» (Select).

Выберите шаблон OS Linux с помощью Zabbix агента

Затем нажмите на кнопку «Добавить» (Add).

Ссылка новый шаблон для Zabbix агента

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

Удаленный хост добавлен на в Zabbix сервер

Заключение

В этой инструкции мы подробно показали, как установить агент Zabbix в системе Ubuntu 20.04 Linux. А так же как настроить его для связи с сервером Zabbix. Это поможет вам активно отслеживать целевые локальные ресурсы и приложения.

Источник

Мониторинг доступности службы linux с помощью Zabbix

Ранее я рассматривал различные конфигурации для мониторинга параметров и программ в windows и linux. Сейчас я хочу рассказать, как мониторить с помощью Zabbix произвольный сервис (службу), который работает либо локально на сервере, либо на внешнем tcp порту. Это может быть что угодно — ssh, ldap, smtp, ftp, http, pop, nntp, imap, tcp, https, telnet или любой другой сервис.

Введение

Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:

То же самое на Debian 10, если предпочитаете его:

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

• Zabbix агент. Устанавливается на наблюдаемую машину и отправляет данные на сервер мониторинга.
• SNMP агент. Чаще всего присутствует на устройстве, либо может быть установлен на сервер.
• Простые проверки — simple check. Выполняются непосредственно на сервере zabbix с помощью встроенных инструментов, не требуют дополнительных действий со стороны хоста.
• Внешние проверки — external checks. Как и простые проверки выполняются на сервере мониторинга, но не встроенными средствами, а внешними скриптами.

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

Тут можно пойти разными путями. Меня интересует мониторинг различных линукс служб, работающих как локально (samsdaemon, postgrey) в пределах конкретного сервера, так и для публичного доступа по сети, в частности squid, smtp, imap, http. Первое, что пришло в голову, это использовать итем с ключом service_state[]. Но как оказалось, этот тип данных снимает значения только с системных служб windows. Я не сразу это понял и некоторое время повозился в консоли, не понимая, почему при тестировании значения получаю сообщение, что данный item не поддерживается:

Дальше придумал через UserParameter запускать какой-нибудь скрипт, который будет проверять запущен ли сервис в системе или нет. Например с помощью ps ax | grep squid. В принципе, рабочий вариант, но мне казалось, что такую простую задачу можно решить проще и быстрее, без создания на каждом хосте скрипта и изменения файла конфигурации. И я не ошибся. Есть 2 различных способа мониторинга служб (сервисов) в linux с помощью zabbix. Рассмотрим первый из них.

Описание работы простых проверок (simple check)

Стал искать материал на эту тему и прочитал про simple check (простые проверки) в zabbix. Оказалось, это то, что нужно. Их можно использовать для безагентских проверок удаленных сервисов. При этом требуется минимум настроек и только на сервере. Можно создать шаблон и распространить на любое количество хостов.

Принцип работы простых проверок следующий. Вы создаете item, в нем указываете тип simple check, в качестве ключа выбираете net.tcp.service[сервис, , ], указываете соответствующие параметры в скобках и все. Сервер сам начинает опрашивать указанный сервис и возвращать в зависимости от его доступности 0 или 1. Устанавливать агент на хост не нужно. Мониторить можно любую сетевую службу, к которой есть доступ по tcp.

Возвращаемые значения net.tcp.service

0	сервис недоступен
1	сервис работает

Всего в простых проверках доступны 5 ключей. Подробнее о них читайте в документации. В данном случае меня будет интересовать только ключ net.tcp.service. В нем предопределены алгоритмы проверок следующих служб: ssh, ntp, ldap, smtp, ftp, http, pop, nntp, imap, https, telnet. Детали реализации проверки каждой службы описаны тут. Если вы мониторите службу, которая не входит в указанный выше список, то происходит просто проверка возможности подключения, без отправки и получения каких-то данных.

Мониторинг доступности сервиса по сети

В качестве примера настроим мониторинг доступности прокси сервера squid. Он запущен на linux сервере и этот хост уже добавлен на сервер мониторинга. Данные поступают с помощью агента, но мы не будет его использовать. Просто создадим одиночный item для проверки доступности squid и trigger для отправки уведомления, если сервис не работает. В данном примере я рассмотрю настройку на примере конкретного хоста. Если у вас несколько серверов с squid, которые вы хотите мониторить, то все элементы лучше создать не отдельно на каждом хосте, а сразу сделать template и назначить его нужным хостам.

Итак, идем в Configuration -> Hosts и выбираем там хост, на котором установлен squid. Переходим в раздел Items и нажимаем Create item.

Заполняем необходимые параметры элемента.

Обязательно заполнить первые 3, остальные на ваше усмотрение. Я считаю, что проверять каждые 30 секунд и хранить 90 дней информацию излишне, поэтому изменяю эти параметры в сторону увеличения.

Squid status	Имя итема.
Simple check	Тип итема.
net.tcp.service[tcp,,3128]	Проверять tcp порт 3128 на указанном хосте. Если вы проверяете статус службы, расположенной не на том же хосте, к которому прикрепляете item, то после первой запятой можно указать необходимый адрес.

Сразу создадим триггер, который в случае возврата в последних двух проверках значения итемом 0, будет отправлять уведомление о том, что служба недоступна. Для этого идем в раздел triggers и жмем Create trigger. Заполняем параметры элемента.

Выражение =0 означает, что триггер срабатывает, если 2 последних значения были равны 0.

Ждем пару минут и идем в Latest data проверять поступаемые значения.

Чтобы проверить работу триггера, достаточно зайти на сервер и остановить squid. Если вы все сделали правильно, то после второй проверки, которая определит, что squid не отвечает по заданному адресу, вы получите уведомление на почту об этом. Если у вас не настроены или не работают уведомления на почту в zabbix, то читайте мою статью на эту тему.

Мониторинг локальной службы в linux

С мониторингом удаленного tcp сервиса разобрались, а что делать, если служба работает локально и к ней невозможно подключиться из вне. Тут уже не обойтись без установки zabbix агента. Если он установлен на хосте, то можно воспользоваться итемом с ключом proc.num. Этот ключ возвращает в качестве значения количество запущенных процессов. И если таких процессов больше одного, можно считать, что служба запущена.

Рассмотрим на примере мониторинга службы postgrey, реализующей greylist для борьбы со спамом. Она работает локально на почтовом сервере linux и является критическим сервисом, так как без него почтовый сервер postfix не будет принимать почту, выдавая временную ошибку почтовой системы. Проверим работу ключа proc.num:

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

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

Создаем триггер с оповещением о недоступности сервиса. При последних двух значениях равных 0 срабатываем.

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

Вот и все. Мы настроили мониторинг локальных служб linux в заббиксе.

Заключение

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

Разница тут получается вот в чем. Допустим, сервер squid у вас запущен и работает на сервере. Проверка работы локальной службы показывает, что сервис работает и возвращает значение 1. Но к примеру, вы настраивали firewall и где-то ошиблись. Сервис стал недоступен по сети, пользователи не могут им пользоваться. При этом мониторинг будет показывать, что все в порядке, служба запущена, хотя реально она не может обслужить запросы пользователей. В таком случай только удаленная проверка покажет, что с доступностью сервиса проблемы и надо что-то делать.

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

Источник