Zabbix только для линукс

Установка и начальная настройка сервера мониторинга Zabbix на Ubuntu Server

Сервер Zabbix используется для сбора и анализа информации о состоянии узлов сети. В данной статье будет рассмотрен процесс его установки и развертывания веб-интерфейса для его управления. В качестве сервера баз данных мы будем использовать MariaDB/MySQL. Версия операционной системы, которая использовалась для написания инструкции — 18.04 (LTS), версия Zabbix — 4.2.

Подготовка сервера

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

1. Правильное время

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

Для этого сначала задаем правильную временную зону:

timedatectl set-timezone Europe/Moscow

* в данном примере задается московское время.

Затем устанавливаем и запускаем сервис синхронизации времени:

apt-get install chrony

systemctl enable chrony

systemctl start chrony

2. Настройка брандмауэра

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

ufw allow 80,443,10050,10051/tcp

ufw allow 10050,10051/udp

* где 80 — порт для http запросов (веб-интерфейс); 443 — для https запросов (веб-интерфейс); 10050 — порты для получения информации от zabbix агентов.

Установка веб-сервера

Управление сервером Zabbix будет осуществляться посредством веб-интерфейса. Для этого необходимо установить и настроить веб-сервер, СУБД и PHP.

В данному инструкции мы будем использовать сервер баз данных mariadb.

Для установки вводим:

apt-get install mariadb-server

Разрешаем автозапуск сервера баз данных и запускаем mariadb:

systemctl enable mariadb

systemctl start mariadb

Задаем пароль для суперпользователя СУБД:

mysqladmin -u root password

* после ввода команды система потребует ввести пароль два раза.

Веб-сервер

Для наших целей будем использовать веб-сервер NGINX.

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

apt-get install nginx

Запускаем nginx и разрешаем его автозапуск:

systemctl enable nginx

systemctl start nginx

Открываем веб-браузер и переходим по ссылке http:// / — мы должны увидеть окно приветствия:

PHP и PHP-FPM

Интерфейс zabbix разработан на PHP — наш веб-сервер должен обрабатывать скрипты, написанные на нем.

Устанавливаем php и необходимые компоненты:

apt-get install php php-fpm php-mysql php-pear php-cgi php-common php-ldap php-mbstring php-snmp php-gd php-xml php-gettext php-bcmath

Для настройки php, открываем файл:

* где 7.2 — версия PHP. В вашем случае это может быть другая версия. Проверить можно командой php -v.

Редактируем следующие параметры:

date.timezone = «Europe/Moscow»
.
max_execution_time = 300
.
post_max_size = 16M
.
max_input_time = 300
.
max_input_vars = 10000

Разрешим запуск php-fpm и перезапустим его:

systemctl enable php7.2-fpm

systemctl restart php7.2-fpm

NGINX + PHP

Для того, чтобы NGINX обрабатывал PHP, открываем конфигурационный файл:

В секции location добавляем параметр index:

Внутри секции server добавим следующее:

\.php$ <
set $root_path /var/www/html;
fastcgi_buffer_size 32k;
fastcgi_buffers 4 32k;
fastcgi_pass unix:/run/php/php7.2-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
>

* где /var/www/html — корневой путь хранения скриптов; /run/php/php7.2-fpm.sock — путь до сокетного файла php-fpm (точное расположение файла можно посмотреть в конфигурационном файле /etc/php/7.2/fpm/pool.d/www.conf).

Проверяем настройки nginx:

И перезагружаем его:

systemctl restart nginx

Создаем index.php со следующим содержимым:

Открываем веб-браузер и переходим по ссылке http:// / — теперь мы должны увидеть сводную информацию по PHP и его настройкам:

Веб-сервер готов для работы с Zabbix Web.

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

Переходим к установке самого Zabbix сервера.

Установка

Сначала установим репозиторий последней версии Zabbix. Для этого переходим на страницу https://repo.zabbix.com/zabbix/ и переходим в раздел с самой последней версией пакета — затем переходим в ubuntu/pool/main/z/zabbix-release/ — копируем ссылку на последнюю версию релиза:

* в моем случае это ссылка на https://repo.zabbix.com/zabbix/4.2/ubuntu/pool/main/z/zabbix-release/zabbix-release_4.2-1+bionic_all.deb. Чтобы понять, какое кодовое название нашей системы, вводим команду cat /etc/lsb-release | grep DISTRIB_CODENAME.

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

dpkg -i zabbix-release_4.2-1+bionic_all.deb

Обновляем списки пакетов:

Устанавливаем сервер, вводя команду:

apt-get install zabbix-server-mysql zabbix-frontend-php zabbix-get

Настройка базы данных

Входим в оболочку ввода sql-команд:

Создаем базу данных:

> CREATE DATABASE zabbix DEFAULT CHARACTER SET utf8 DEFAULT COLLATE utf8_bin;

* мы создали базу zabbix.

Создаем пользователя для подключения и работы с созданной базой:

> GRANT ALL PRIVILEGES ON zabbix.* TO zabbix@localhost IDENTIFIED BY ‘zabbixpassword’;

* в данном примете мы создали пользователя zabbix с доступом к базе zabbix и паролем zabbixpassword.

Выходим из sql-оболочки:

В составе zabbix идет готовая схема для СУБД MySQL/MariaDB или postgreSQL. В нашем случае, нам нужен MySQL.

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

Распаковываем архив с дампом базы:

Восстанавливаем базу их дампа:

mysql -v -u root -p zabbix / — откроется страница установки Zabbix Web. Кликаем по ссылке Next Step:

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

Когда все результаты будут OK, кликаем по Next Step:

В следующем окне мы оставляем настройки подключения к базе как есть — дополнительно прописываем пароль, который задали при создании пользователя zabbix. После нажимаем Next Step:

* в нашем случае, пароль был zabbixpassword;

В следующем окне оставляем все как есть:

. и нажимаем Next Step.

В последнем окне мы проверяем настройки и кликаем Next Step.

Установка завершена — нажимаем Finish:

В открывшемся окне вводим логин Admin и пароль zabbix (по умолчанию) — откроется окно со сводной информацией по мониторингу:

Zabbix Agent

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

apt-get install zabbix-agent

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

Отредактируем следующую опцию:

* в данном примере мы указываем агенту сервер Zabbix — мы может указать его имя или IP-адрес.

Разрешаем автозапуск агента и запускаем его:

Источник

Операционные системы Astra Linux

Оперативные обновления и методические указания

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

1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).

Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».

На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.

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

Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.

Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.

В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.

Очередные обновления (версии) предназначены для:

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

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

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

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

Источник

Мониторинг доступности службы 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 предоставляет огромные возможности по мониторингу. Какой тип наблюдения и сбора данных подойдет в конкретном случае нужно решать на месте, исходя из сути сервиса, за которым вы наблюдаете.

Источник