Как посмотреть версию zabbix сервера
Как мы Zabbix обновляли
Кстати, о прометее. А вы используете его для своей железной инфраструктуры? Вот и мы не используем.
Как и многие, кто мониторит давно и у кого есть «голое» железо, мы используем Zabbix, который, кстати, на том железе и располагается. Увы, на данный момент заббикс и IaC — вещи не связанные. Настраивать заббикс можно или вручную, или через API.
Предыстория
Особых проблем с 3.4 почти не было:
А в 4.0 появились интересные фичи вроде родных HTTP-итемов и периодов обслуживания не на весь хост целиком.
Да и где же это видано, на неактуальной версии мониторинга сидеть, даже не на LTS? Надо идти в ногу со временем.
Тем более что при планировании обновления выяснилась интересная деталь: прогресс не стоит на месте, можно взять более быстрые машины по меньшей цене. А попутно нашелся способ сэкономить на уже ненужной услуге хостера в нескольких проектах коллег. Как говорится, это мы удачно зашли.
Обновление «в лоб»
Ничего особо сложного в обновлении заббикса сейчас нет. Закажи сервер, проведи его настройку, слей копию базы. Поставь пакеты мониторинга и укажи им базу, запусти заббикс — и он тебе сам всё обновит, накатит все миграции. Ну да, наверное, вы знаете, каким лёгким стал апгрейд заббикса.
В сумме миграции БД заняли около 15-ти минут и даже без особой ругани. И вроде бы всё хорошо. Да? Как бы не так! Несмотря на то, что IP нового сервера не прописан в белых листах агентов, и он собирает данные лишь с нескольких тестовых хостов, на нём по прежнему стабильно происходит Невозможное.
К чести разработчиков заббикса надо сказать, они своё слово держат — версия 4.2 на тот момент поддерживается. После общения в трекере проекта мы выясняем, что причина невозможного в том что не совпадает с ожидаемой структура одной из таблиц БД.
То есть, по факту, мы имеем не поддерживаемую разработчиками схему базы, а свой собственный «форк». Другой тип данных колонок это, потенциально:
Думаете, в лучшую сторону? Сомнительно. По прошлому опыту работы с техподдержкой и разработчиками заббикса, тюнить СУБД они умеют.
И этот тип данных колонок можно, но сложно и долго менять. И невозможно без долгого простоя мониторинга. Без гарантий успеха, без поддержки со стороны разработчика в будущем. Нужен другой путь.
И его есть у заббикса. Потому что в апреле 2019-го выходит zabbix-4.2
Второй подход к снаряду
Основная фича 4.2 для нас — поддержка секционирования «из коробки» посредством TimescaleDB. Пообщавшись с представителями заббикса и ознакомившись с результатами тестирования его техподдержкой этой возможности (перевод на хабре), мы решаем протестировать инсталляцию с timescaledb и по результатам принять решение о переходе. Более конкретно: некоторое время у нас все данные мониторинга параллельно будут писаться и в старую, и в новую версии. А потом мы просто переключим запись в DNS.
Конечно, такой подход не позволяет сохранить данные истории и трендов — новая БД наполняется с нуля. Но так ли уж они нужны? История имеет значение только здесь и сейчас, она довольно быстро накопится заново (посмотрите на тот же прометей). Остаётся только несомненная полезность трендов для планирования мощностей. В любом случае, архив с уже собранными данными у нас остаётся (забегая вперёд — некоторым клиентам он пригодился). Ещё одна особенность поддержки timescaledb в заббиксе — перестают действовать индивидуальные периоды хранения истории/трендов.
У нас есть клиенты, которые настаивают на «вечном» хранений всех собранных данных любой ценой. Им мы можем предложить рассмотреть установку/поддержку отдельной инсталляции мониторинга со специфическими настройками. Наша основная задача — обеспечивать стабильную работу проектов/серверов клиентов при сохранений приемлемой стоимости услуг, в которую входит в том числе и мониторинг.
Итого, для миграции потребуется выполнить следующие шаги:
Звучит просто, не так ли? Действительно, первое не очень сложно, ведь во время предыдущего подхода мы написали роль для установки заббикс-сервера, достаточно просто налить конфигурацию. Третий пункт тоже выглядит просто — переключаем DNS и все заббикс-агенты, прокси, клиенты API и живые люди попадают на новую версию. Но как сделать второй пункт?
Например, что насчёт вручную заведённых пользователей и их паролей, которые при создании проектов генерируются случайными, навешанных на хосты шаблонов мониторинга (со своими кастомными значениями макросов), вручную созданных итемов, комплексных экранов, графиков, дэшбордов, периодов обслуживания, прокси-серверов? Это всё и многое другое нужно переносить для плавной миграции.
На счастье, у заббикса есть встроенный функционал по экспорту/импорту объектов — доступный в том числе и через API. Увы, он покрывает не более половины всех существующих объектов. И код для его использования ещё и написать нужно. В общем, нельзя просто взять и импортировать конфигурацию одного заббикса в другой.
Или можно?
Тут мозг услужливо вспоминает задачу из бэклога о том, что неплохо было бы организовать хранение истории конфигурации мониторинга внешними средствами. Увы, это больное место заббикса. Со ссылкой на статью на хабре и репозиторий с кодом. Но есть нюансы:
На удачу, есть люди немного знающие язык проекта (python) и имеющие опыт работы с заббикс API. Всего делов-то — сделать импорт объектов из готовых YAML-дампов. Долго ли, коротко ли, но после трёх недель работы и полутора сотен коммитов получился вполне годный для наших целей форк. Собственно, ради чьего представления и пишется вся статья:
Импорт поддерживается почти исключительно созданием новых объектов. Если объект существует, он не будет изменён. Это позволило удержать сложность кода хоть в каких-то рамках, сэкономить время и здорово увеличить скорость работы — при импорте тысяч объектов. Использовать импорт очень просто:
(предполагается, что параметры целевого мониторинга указаны в переменных среды, подробнее в выводе —help)
Вообще, можно указать любое количество входных YAML-файлов — и все они будут обработаны. Но с учётом того, что между объектами существует множество зависимостей, больше смысла импортировать объекты тип за типом, начиная с самых простых и базовых. Плюс, если вы импортируете один объект из одного файла, может иметь смысл явно указать его тип, чтобы немного ускорить импорт — загружаются не все кэши, а только необходимые.
Таким образом, в нашем гитлабе появились два репозитория с периодически обновляемыми YAML-дампами двух версий мониторинга, текущей и новой. И, конечно же, возможность восстановить почти любой объект мониторинга на любой момент времени.
Continuous monitoring deployment и сама миграция
В итоге мы пришли к тому, что гитлаб по расписанию запускает пайплайн на репозитории нового мониторинга, который шаг за шагом иерархически импортирует из старого мониторинга один тип объектов за другим. Это позволило импортировать подавляющее большинство объектов и дать нашим командам администраторов время спокойно починить вылезшие проблемы — а их не так уж мало накопилось за годы. «Лишние» объекты не удалялись.
Вопрос с паролями пользователей — они тоже экспортируются/импортируются, но при создании назначается случайный пароль — удалось решить преобразованием SQL-дампа таблицы с учётными данными текущего мониторинга в SQL-операторы для установки правильных паролей в новом мониторинге.
Чтобы не получать двойную порцию задач во время параллельной работы, все действия в новом мониторинге были сразу же выключены и более не удалялись.
Таким образом, переключение прошло довольно легко и свелось к следующим пунктам:
(план сокращён в целях упрощения)
Что дальше?
Конечно, код не идеален и не особо красив. Он импортирует не всё, в частности, есть проблемы с некоторыми шаблонами — ищите FIXME в коде. Но для нас этого хватило. Возможно, этот форк пригодится кому-то ещё. Логичным продолжением видится развитие в сторону подобную работе утилиты Terraform, когда целевой мониторинг полностью приводится к виду, заданному, например, каталогом с YAML-дампами. В том числе и с приведением существующих объектов к нужному виду.
Камо грядеши?
После изучения материалов конференций и митапов, официального роадмапа, трекера ошибок и (скромного) опыта личного общения с разработчиками заббикса складывается впечатление, что они отлично понимают ситуацию, в которой сейчас оказались. Когда начинался заббикс, ни о каком IaC авторы не думали, решая свои задачи. Спустя десятилетие продукт возмужал и расцвёл. Оборотной стороной успеха стала набранная масса клиентов компании, у которых мониторинг решает их задачи. И которым не очень-то симпатичны революции. В современных условиях они, с одной стороны, против того, чтобы всё ломать и начинать с нуля. С другой стороны, они же местами испытывают недостаток возможностей мониторинга и смотрят «на сторону», не забывая озвучивать хотелки разработчикам заббикса. Рисковать ими компания не собирается, несмотря на любые симпатии к новому, удобному, модному, молодёжному.
Нового, правильного прометея из заббикса мы в ближайшее время не увидим. Как ни хотелось бы. Но работа явно идёт — и если вы, как и заббикс, основательны и терпеливы, будущее вас также ожидает безоблачное.
Система мониторинга Zabbix для начинающих
Содержание:
Zabbix — это универсальный инструмент мониторинга, способный отслеживать динамику работы серверов и сетевого оборудования, быстро реагировать на внештатные ситуации и предупреждать возможные проблемы с нагрузкой. Система мониторинга Zabbix может собирать статистику в указанной рабочей среде и действовать в определенных случаях заданным образом.
В этой обзорной статье расскажем об основных принципах и ключевых инструментах, на которых построена универсальная система мониторинга Zabbix.
Обзор
Систему создал Алексей Владышев на языке Perl. Впоследствии проект подвергся серьезным изменением, которые затронули и архитектуру. Zabbix переписали на C и PHP. Открытый исходный код появился в 2001 г., а уже через три года выпустили первую стабильную версию.
Веб-интерфейс Zabbix написан на PHP. Для хранения данных используются MySQL, Oracle, PostgreSQL, SQLite или IBM DB2.
На данный момент доступна система Zabbix 4.4. Скачать ее можно на официальном сайте. Там же можно найти официальные курсы и вебинары для начинающих пользователей системы.
Далее рассмотрим, из чего состоит и как работает технология Zabbix в доступном формате «для чайников».
Архитектура Zabbix
У Zabbix есть 4 основных инструмента, с помощью которых можно мониторить определенную рабочую среду и собирать о ней полный пакет данных для оптимизации работы.
Основные возможности
Функционал включает в себя общие проверки для наиболее распространенных сервисов, в том числе СУБД, SSH, Telnet, VMware, NTP, POP, SMTP, FTP и т.д. Если стандартных настроек системы недостаточно, их можно изменить самостоятельно или же пользоваться дополнением через API.
Стандартные функции системы
Проверки
Для описания системы мониторинга Zabbix существует два ключевых понятия:
Сам Zabbix-агент способен отражать текущее состояние физического сервера, собирая совокупность данных. У него достаточно много метрик. С их помощью можно проверить загруженность ядра (Processor load), время ожидания ресурсов (CPU iowait time), объем системы подкачки (Total swap space) и многое другое.
В Zabbix существует целых 17 способов, дающих возможность собирать информацию. Указанные ниже, входят в число наиболее часто применяемых.
У проверок есть заданные шаблоны (Templates), которые упрощают создание новых. Кроме обычных операций существует возможность регулярно проверять доступность веб-сервера с помощью имитации запросов браузера.
Проверка через пользовательский параметр
Чтобы выполнить проверку через агент, нужно прописать соответствующую команду в конфигурационный файл Zabbix-агента в качестве пользовательского параметра ( UserParameter ). Сделать это можно с помощью выражения следующего вида:
Помимо самой команды, приведенный синтаксис содержит уникальный (в пределах узла сети) ключ элемента данных, который надо придумать самостоятельно и сохранить. В дальнейшем, ключ можно использовать для ссылки на команду, внесенную в пользовательский параметр, при создании элемента данных.
Пример
С помощью данной команды можно настроить агент на постоянное возвращение значения « 1 » для элемента данных с ключем « ping ».
Триггеры
У каждого триггера существует уровень серьезности угрозы, который маркируется цветом и передается звуковым оповещением в веб-интерфейсе.
Некоторые функции триггеров
Прогнозирование
Триггеры обладают еще одной важной функцией для мониторинга — прогнозированием. Она предугадывает возможные значения и время их возникновения. Прогноз составляется на основе ранее собранных данных.
Анализируя их, триггер выявляет будущие проблемы, предупреждает администратора о возникшей вероятности. Это дает возможность предотвратить пики нагрузки на оборудование или заканчивающееся место на жестком диске.
Функционал прогнозирования добавили с обновлением системы 3.0, вышедшим в феврале 2016 года.
Действие
Действие (Action) представляет собой заданную реакцию на событие (Event). Действие может устанавливаться автоматически или вручную как для одного из событий, так и для целой группы.
Параметры действий
Для событий, вызванных триггером или обнаружением, есть свои типы условий. Например, «Application» с операторами « = », « like » и « not like » значит, что триггер является частью указанного приложения. Или «Service type» с операторами « = », « »и « > » предусматривает, что обнаруженный сервис совпадает с указанным.
Операции
Пользователь может указать для событий операцию или группу операций.
Параметры операций
Низкоуровневое обнаружение
Функция Низкоуровневого обнаружения (LLD) автоматически создает элементы и триггеры, которые позволяют отслеживать системы сервера, находящимся под наблюдением. Включение функции происходит через настройку атрибутов, которую можно сделать, пройдя по пути: «Настройка» → «Шаблоны» → «Обнаружение» (вкладка в строке с шаблоном) → вкладки «Правила обнаружения»/«Фильтры».
Что можно обнаружить
Дополнительные типы
Задать собственные типы низкоуровневого обнаружения возможно с применением формата JSON. Типы проверок, для которых можно указать список портов и интервал для них:
Если хост пропадает или обнаруживается, для события можно привязать любое действие — условия и операцию для них.
Прокси
Функция буферизации через прокси используется в том случае, когда существующая инфраструктура достаточно большая, а выделенный сервер не способен нести такую нагрузку. Прокси выступает промежуточным звеном, которое собирает информацию с агентов в буфер, а после отправляет данные на сервер.
Прокси используется еще в нескольких случаях — если агенты находятся далеко друг от друга или ограничены локальной сетью. Это сказывается на доступности агентов и величине пингов.
Zabbix прокси функционирует как демон. Для его использования обязательно наличие отдельной базы данных.
Особенности веб-интерфейса
Система мониторинга Zabbix располагает удобным веб-интерфейсом, в котором сгруппированы элементы управления. Консоль предусматривает просмотр собранных данных, их настройку. Для безопасности входа и работы осуществляется автоматическое отсоединение через 30 минут пользовательского бездействия.
На главном экране всегда представлена информация о состоянии узлов сети и триггеров.
Пользователю доступны пять функциональных разделов, включая Monitoring («Мониторинг»), Inventory («Инвентарные данные»), Reports («Отчеты»), Configuration («Конфигурация») и Administration («Администрирование»).
В разделе «Конфигурации» можно найти группы хостов. По каждому элементу списка можно посмотреть более подробную информацию, например, последние события и графики данных.
Управлять шаблонами, доступными администратору, можно в соответствующем подразделе — Templates («Шаблоны»).
Версия 4.4
Узнать версию установленного Zabbix сервера можно во время запуске в файле-протоколе.
Основные нововведения в Zabbix 4.4
Заключение
Zabbix по праву считается одним из самых продвинутых инструментов для удалённого мониторинга аппаратных и программных ресурсов. Система с успехом позволяет решать задачи по отслеживанию сетевой активности и работоспособности серверов, а также предупреждать о потенциально опасных ситуациях. Благодаря встроенным механизмам анализа и прогнозирования, Zabbix может стать основой для создания полноценной стратегии эффективного использования IT-инфрастуктуры в компаниях любого масштаба.
Способности Zabbix ограничены только имеющимися в распоряжении ресурсами. VDS от Eternalhost на SSD-дисках обеспечит системе максимальное быстродействие и возможность мониторить множество узлов в сети.
Установка и настройка Zabbix 5
В этой статье мы расскажем об установке и настройке Zabbix с нуля на сервер с ОС CentOS, в виде Docker-контейнера и в виде образа виртуальной машины в формате OVF.
Дополнительно разберемся с Zabbix-прокси, установкой Zabbix-агента на Windows, базовыми настройками и интеграцией с системой визуализации Grafana. После прочтения статьи вы сможете самостоятельно настроить мониторинг и оповещения на почту или в мессенджер, как следствие, начнете контролировать свои серверы, сайты, приложения и другие элементы инфраструктуры.
Оглавление:
Знакомство с системой
Zabbix — популярная система мониторинга ИТ-инфраструктуры и приложений с открытым исходным кодом, которой пользуются малые, средние, крупные и очень крупные компании по всему миру. Основное преимущество продукта — большое сообщество пользователей и, как следствие, много полезной информации о подходах к использованию, настройке, созданию шаблонов мониторинга и многом другом.
Получить Zabbix можно на официальном сайте. Скачивание доступно в различных форматах. Кроме CentOS, установка Zabbix-сервера из бинарного файла возможна на следующие операционные системы:
В середине мая 2020 года вышла 5-я версия Zabbix, установку которой мы и разберем в статье.
Установка Zabbix и его компонентов
Zabbix — распределенная система мониторинга, состоящая из четырех основных компонентов:
Установка Zabbix-сервера на CentOS
В первую очередь установим сервер. В панели управления это делается в несколько кликов. После ввода учетных данных и входа в систему нужно перейти на представление Серверы и нажать кнопку Создать сервер.
На открывшемся представлении ввести имя сервера, выбрать регион и зону (если необходимо) и нажать на кнопку Выбрать источник, чтобы выбрать необходимую операционную систему.
Затем откроется следующее представление, где для установки Zabbix-сервера выберем CentOS 7 64-bit.
После выбора операционной системы можно прокрутить колесико мышки вниз и выбрать плавающий IP-адрес для возможности подключения к серверу через SSH и к веб-консоли Zabbix через браузер. На этом же экране можно скопировать пароль root для дальнейшего доступа к серверу по SSH. Нажимаем на кнопку Создать.
Как только сервер будет создан и его статус сменится на Active, можно подключаться к внешнему плавающему IP-адресу по протоколу SSH.
Далее установим репозитории ПО. Это необходимо для получения актуального набора пакетов с компонентами Zabbix и PostgreSQL.
Репозитории с актуальными версиями устанавливаемых компонентов для различных платформ можно найти на сайте производителей:
Следующий шаг — установка Zabbix-сервера и Zabbix-агента:
Теперь внесем изменения в конфигурацию репозитория Zabbix: нужно включить zabbix frontend в файле конфигурации /etc/yum.repos.d/zabbix.repo, изменив значение ключа enabled со значения 0 на значение 1.
Установим Red Hat Software Collections для упрощения процесса дальнейшей настройки:
Следующий шаг — установка PostgreSQL и других необходимых пакетов. Обратите внимание, что в нашем примере мы работаем с локальным хранилищем на базе PostgreSQL (в случае с MySQL имя пакета для Zabbix-сервера будет отличаться).
Инициализируем, настроим автозапуск и запустим БД PostgreSQL:
После успешного запуска создадим базу данных для Zabbix и пользователя в ней. Первая команда запросит пароль:
Внесем изменения в конфигурационный файл /var/lib/pgsql/12/data/pg_hba.conf для корректного подключения к БД PostgreSQL с паролем. Метод для обоих подключений должен быть md5:
После создания пользователя организуем для него схему по умолчанию:
Следующий шаг — установка в БД схемы данных:
Теперь впишите созданный для БД пароль в конфигурационный файл Zabbix /etc/zabbix/zabbix_server.conf в параметры DBHost, DBName, DBSchema, DBUser и DBPassword.
Настроим NGINX для его корректной работы в Zabbix. Настройки выполняются в конфигурационном файле /etc/opt/rh/rh-nginx116/nginx/conf.d/zabbix.conf. Необходимо раскомментировать две строки и указать IP-адрес или имя сервера:
Следующий файл, который нужно скорректировать, — /etc/opt/rh/rh-php72/php-fpm.d/zabbix.conf. Вносим изменения в двух местах:
Теперь запускаем сервисы Zabbix и добавляем их в автозапуск:
Если на предыдущих шагах все было сделано верно, при переходе по имени или адресу сервера в браузере откроется начальное окно настройки Zabbix 5.0:
Переходим на экран Configure DB connection и указываем реквизиты подключения к БД:
На экране Zabbix server details — имя хоста, на котором установлен Zabbix, порт должен остаться указанным по умолчанию:
Переходим на последний экран и нажимаем Finish. Настройка завершена.
Стандартная учетная запись для входа: Admin с паролем zabbix.
Zabbix готов к работе, и можно приступать к его настройке. В некоторых ситуациях для корректной работы системы необходимо отключить SElinux.
Установка Zabbix в виде Docker-контейнера
Быстрая установка — выполняется за 10 минут или меньше. Добавим репозиторий Docker и установим необходимые пакеты:
Следующий шаг — клонирование репозитория Zabbix с Github:
Перейдем в клонированный репозиторий. Команда ls покажет имеющиеся объекты:
Запустим демон Docker:
Соберем и запустим контейнеры с Zabbix:
После выполнения команды выше запустятся компоненты Zabbix, можно переходить в веб-интерфейс:
Установка Zabbix из готовых образов
Это самый быстрый тип установки — разворачивание займет не более 5 минут. В этом разделе рассмотрим установку готового Zabbix-сервера из образа в формате Open virtualization format (OVF). Образ можно скачать на сайте Zabbix.
Для разворачивания OVF-образа на локальной машине потребуется установленный VirtualBox, который доступен для различных платформ на сайте Oracle. После загрузки образа Zabbix в интерфейсе VirtualBox нужно нажать кнопку Импортировать.
Выбираем образ zabbix_appliance-5.0.0.ovf (рядом с ним должен находиться zabbix_appliance-5.0.0-disk001.vmdk).
На следующем экране все параметры должны остаться по умолчанию. Теперь можно нажать кнопку Импорт. После успешного импорта виртуальную машину можно Запустить. Обратите внимание, что для корректного подключения к интерфейсу Zabbix или виртуальной машине по SSH в сетевых настройках должен быть указан тип подключения Сетевой мост.
Дожидаемся успешного запуска виртуальной машины, входим под учетными данными root / zabbix в консоли VirtualBox и выполняем команду:
В результате отобразятся настройки сети на виртуальной машине с установленным Zabbix.
Теперь можно выполнить подключение к Zabbix-серверу через браузер. Учетные данные стандартные — Admin / zabbix.
Данные по производительности сразу же начинают собираться.
Таким образом, установка завершена.
Установка агента Zabbix на Windows
Перед началом установки создадим в панели управления Selectel сервер с ОС Windows. Для этого в представлении Серверы нажмем на кнопку Создать сервер.
В открывшемся представлении нажимаем Выбрать тип источника и выбираем один из доступных образов операционных систем Windows.
Выбираем плавающий IP-адрес для подключения к серверу через RDP. На этом же экране можно скопировать пароль учетной записи Administrator для дальнейшего доступа к серверу по RDP. Нажимаем на кнопку Создать.
После выполнения перечисленных действий ожидаем создания сервера. После его создания и перехода в статус Active можно подключаться к внешнему плавающему IP-адресу по протоколу RDP к созданному серверу.
Установка и настройка Zabbix-агента на Windows-сервер в ручном режиме занимает около 10 минут. Скачивание дистрибутива доступно на сайте Zabbix. После скачивания архива его необходимо распаковать в созданную директорию (в нашем примере это C:\Zabbix):
В папке conf хранится конфигурационный файл, в который необходимо внести изменение:
Далее установим агент в виде сервиса и запустим его. Для этого выполним zabbix_agentd со специальными реквизитами:
Следующий шаг — добавление данного агента в интерфейсе Zabbix. Переходим на представление Configuration — Hosts, затем в верхнем правом углу нажимаем Create Host:
Следующий шаг — ввод данных сервера. Требуется указать имя сервера, группу и сетевой интерфейс, через который будет выполняться подключение к агенту.
Далее переходим на вкладку Templates. Так как речь идет об ОС Windows, применим к узлу соответствующий шаблон Template OS Windows by Zabbix agent. Сохраняем изменения и ожидаем начала сбора метрик.
Собираемые по узлам метрики доступны на представлении Monitoring — Latest Data.
Напротив каждой метрики (Item) есть кнопка Graph, при нажатии на которую открывается соответствующий график.
Настройка мониторинга узла с ОС Windows завершена.
Настройка и интеграция Zabbix 5
В этом блоке расскажем о добавлении пользователя, настройке оповещений и изменении шаблонов мониторинга. Также опишем ключевые технологии и элементы инфраструктуры Zabbix.
Добавление пользователя
Каждому пользователю в Zabbix соотнесены имя пользователя и пароль — реквизиты, с которыми можно войти в систему. Все пароли в Zabbix хранятся в зашифрованном виде. При необходимости можно настроить авторизацию пользователей через Active Directory или LDAP. В этой статье мы рассмотрим работу встроенных в Zabbix пользователей.
В Zabbix каждый пользователь должен входить в группу. На основе групп в Zabbix присваиваются те или иные права.
Для добавления пользователя в веб-интерфейсе Zabbix необходимо перейти на представление Administration — Users и в верхнем правом углу нажать Create User.
Теперь появятся поля, в которых важно указать имя пользователя, группу и пароль. Остальное можно оставить по умолчанию.
Для каждого пользователя можно указать его данные для оповещения: электронную почту, аккаунт в Telegram, имя в Slack и т. д. Чтобы привязать эти данные к пользователю, перейдем на вкладку Media, нажмем Add и добавим адрес электронной почты. Здесь можно указать критичность событий, по которым нужно отправлять уведомления, и интервал оповещений.
После сохранения этих данных можно нажать Add на вкладке User и сохранить созданного пользователя.
Чтобы сменить пароль любого пользователя, на представлении Administration — Users нужно кликнуть на соответствующего пользователя, нажать Change password и ввести новый пароль.
Аналогичным образом создаем группу пользователей. На представлении Administration — Groups в верхнем правом углу нажмем Create user group.
Указываем имя группы и созданного пользователя. Далее переходим на вкладку Permissions.
На вкладке Permissions указываем имя группы хостов, к данным по которой у создаваемой группы будет доступ. После добавления группы нажимаем Add.
Таким образом, группа создана, ей предоставлен требуемый уровень прав и привязан пользователь.
Низкоуровневое обнаружение (Low Level Discovery, LLD)
Низкоуровневое обнаружение позволяет автоматически ставить на мониторинг динамические экземпляры узлов. Например, файловые системы или сетевые интерфейсы, которые добавят администраторы, автоматически обнаружатся и появятся на мониторинге. Правила автоматического обнаружения настраиваются в рамках шаблона.
Ниже, в качестве примера, Discovery Rules (правила обнаружения) для шаблона Windows. Здесь их четыре для следующих сущностей:
Рассмотрим устройство правила обнаружения для файловых систем. В поле Key указан элемент данных vfs.fs.discovery, встроенный в Zabbix. Этот элемент возвращает список файловых систем, примонтированных к серверу. Другие встроенные элементы данных собраны на специальной странице производителя.
На вкладке Filters перечислены прототипы данных, которые в случае обнаружения новых элементов распознают их и записывают в БД.
В Zabbix возможно добавление собственных элементов данных, собственных фильтров и макросов.
Изменение шаблонов Zabbix
Шаблоны включают в себя:
Каждый из этих элементов отвечает за те или иные возможности. В статье мы разберем формирование пороговых схем в триггерах на примере шаблона для Windows и его части — шаблона для файловых систем.
В примере ниже мы видим прототипы триггеров, которые соответствуют порогам по файловым системам серверов Windows. Чтобы изменить пороговую схему, достаточно перейти в нужный шаблон и внести корректировки.
Получить подробную информацию о создании выражений для настройки порогов можно в документации на сайте Zabbix.
Zabbix Proxy
Zabbix Proxy — это специальный сервис, который работает на выделенном сервере. Он обеспечивает буферизацию поступающих от агентов данных и их дальнейшую трансляцию в сторону Zabbix-сервера. Zabbix Proxy использует отдельную базу данных и поддерживает SQLite, MySQL и PostgreSQL.
Сервис эффективно использовать для сбора метрик с агентов в выделенных или удаленных сетях (за файерволом), участков инфраструктуры с ненадежной связью и для снижения нагрузки на Zabbix-сервер. Начиная с версии 5.0 прокси поддерживает предобработку данных на своей стороне.
Интеграция Zabbix с внешними системами
В этом разделе разберем возможности интеграции Zabbix с системой визуализации Grafana, которую можно использовать для отображения статусов, графиков, значений и других типов данных. Для ускорения процесса установим и запустим Grafana в виде Docker-контейнера.
После установки удостоверимся, что контейнер с Grafana выполняется:
Используя ID контейнера, установим специализированный плагин для Zabbix и перезагрузим контейнер:
Входим в Grafana через браузер (учетные данные по умолчанию admin / admin):
Далее нужно активировать плагин для Zabbix. Чтобы это сделать, перейдем в Configurations — Plugins и включим плагин для Zabbix:
Плагин включен, осталось его настроить. Важные поля для заполнения — URL, User, Password:
После выполненных настроек можно добавлять на дашборды различные элементы данных на основе метрик из Zabbix.
У Grafana есть много готовых дашбордов, их можно найти на сайте проекта и импортировать через интерфейс Grafana.
Заключение
В статье мы рассмотрели различные подходы для установки Zabbix и проведение дополнительных настроек. Этого достаточно для настройки базового мониторинга и контроля инфраструктуры и приложений.
Для визуализации, например, статусов доступности и производительности мы рекомендуем использовать удобный и мощный инструмент Grafana. Он легко устанавливается и настраивается. Кроме того, есть мобильное приложение, в котором можно просматривать «здоровье» инфраструктуры в режиме реального времени.