В последнее время Docker набирает всё больше и больше популярности благодаря возможности быстро развертывать сложные приложения, состоящие из большого количества сервисов. Portainer — это система управления docker контейнерами в Linux. Она позволяет управлять как локальными контейнерами, так и удалёнными с помощью Docker API.
С помощью Portainer вы сможете отслеживать состояние контейнеров, запускать, останавливать и удалять их, развертывать новые приложения, а также многое другое. Сегодня мы поговорим как выполняется установка Docker Portainer на ваш компьютер, а также как пользоваться программой
КАК УСТАНОВИТЬ DOCKER PORTAINER
Для выполнения этой статьи вам понадобится уже установленный в вашей системе Docker. Я не буду подробно рассказывать как установить docker и docker-compose. Для этого воспользуйтесь этой статьей для Ubuntu или этой для CentOS.
После того, как Docker будет установлен, можно развернуть контейнер с Portainer. Было бы странно, если бы программа поставлялась в каком-либо другом виде. Создайте хранилище данных для Portainer:
Эта команда настраивает автоматический запуск Portainer после перезагрузки, а также постоянное хранилище, чтобы ваши настройки не потерялись при удалении и повторном разворачивании контейнера. Чтобы убедится, что Portainer запущен выполните такую команду:
docker ps
НАСТРОЙКА PORTAINER
1. ВХОД
Получить доступ к программе вы можете через веб-интерфейс на порту 9000. Откройте его в браузере. На первом шаге надо будет ввести имя пользователя и пароль, под которым вы будете входить в систему:
Затем выберите метод подключения к Docker. Для начала можно подключиться к локальному сервису Docker. Для этого выберите Local:
2. СПИСОК УЗЛОВ И КОНТЕЙНЕРОВ
После нажатия кнопки Connect вы попадите в панель управления контейнерами:
Сначала вам надо выбрать узел, на котором вы будете управлять контейнерами, в данном случае, это local. Здесь вы можете уже управлять вашими контейнерами. Например, в разделе Containers можно посмотреть все доступные контейнеры:
А в разделе Stacks — все доступные приложения:
3. РАЗВОРАЧИВАНИЕ ПРИЛОЖЕНИЯ
В разделе App Templates вы можете развернуть новое приложение на основе одного из существующих шаблонов. Например, давайте развернем WordPress. Для этого найдите его в списке:
Затем шаблон надо настроить. В данном случае, надо указать пароль для базы данных и имя приложения:
После этого нажмите кнопку Deploy the stack и новое приложение появится в списке раздела Stasks. Как видите, теперь программа сообщает, что у неё есть полный контроль над этим приложением, потому что она его создала:
4. УПРАВЛЕНИЕ ПРИЛОЖЕНИЕМ
Если вы откроете приложение, там будут отображены его контейнеры. По каждому контейнеру можно посмотреть логи, открытые порты и даже подключится через терминал. Чтобы увидеть логи нажмите на иконку похожую на записную книжку возле состояния контейнера:
Для командной строки рядом есть значок с символом приглашения ввода. Вот так выглядит командная строка:
А открытые порты находятся в самом конце характеристик контейнера в разделе Published ports:
Если вы кликните по ссылке с надписью 32768:80 для контейнера WordPress, то попадёте на сайт WordPress:
КАК ОБНОВИТЬ PORTAINER
Чтобы обновить Portainer надо удалить текущий образ и запустить его снова. Это не вызовет никаких проблем, так как при создании предыдущего образа мы использовали внешнее хранилище для хранения данных. Остановите образ и удалите его:
Как видите установка Portainer очень простая, если у вас есть уже установленный docker, а далее программа только помогает пользоваться контейнерами. Вы можете подключить к ней и удалённые узлы, однако для этого надо, чтобы у них был публичный IP адрес, потому что в локальной сети взаимодействовать с ними вы не сможете. А вы используете Portainer или пользуетесь другим интерфейсом для управления Docker? Напишите в комментариях!
С появлением стандартных готовых шаблонов для различных приложений жизнь с заббиксом стала значительно проще. Сегодня я покажу это на примере мониторинга Mysql сервера в Zabbix 5 с использованием стандартного шаблона. Все стало не просто, а очень просто. Практически ничего делать не надо, разработчики все сделали за нас.
Введение
Напоминаю одну важную деталь. Если вы ставите Zabbix Server не с нуля, а обновляете старую версию, у вас не обновляются стандартные шаблоны. А они последнее время сильно изменились, плюс появились новые. Посмотреть их можно на github — https://github.com/zabbix/zabbix/tree/master/templates.
В данном случае я буду использовать шаблон из директории /db/mysql_agent/. Он написан для старого агента. Напомню, что начиная с версии 4.4 доступна новая версия агента, написанная на Go — zabbix_agent2. Для него появился новый функционал и новые шаблоны. Я пока буду использовать старого агента, так как с новым еще не разбирался.
Если у вас еще нет своего сервера для мониторинга, то рекомендую материалы на эту тему. Для тех, кто предпочитает систему CentOS:
Для примера настроим мониторинг Mysql на самом сервере мониторинга Zabbix. Так как это часто узкое место производительности системы, мониторинг базы zabbix лишним не будет. Первым делом добавим новые параметры в агенте. Для этого создаем конфигурационный файл /etc/zabbix/zabbix_agentd.d/template_db_mysql.conf следующего содержания.
UserParameter=mysql.ping[*], mysqladmin -h"$1" -P"$2" ping
UserParameter=mysql.get_status_variables[*], mysql -h"$1" -P"$2" -sNX -e "show global status"
UserParameter=mysql.version[*], mysqladmin -s -h"$1" -P"$2" version
UserParameter=mysql.db.discovery[*], mysql -h"$1" -P"$2" -sN -e "show databases"
UserParameter=mysql.dbsize[*], mysql -h"$1" -P"$2" -sN -e "SELECT COALESCE(SUM(DATA_LENGTH + INDEX_LENGTH),0) FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='$3'"
UserParameter=mysql.replication.discovery[*], mysql -h"$1" -P"$2" -sNX -e "show slave status"
UserParameter=mysql.slave_status[*], mysql -h"$1" -P"$2" -sNX -e "show slave status"
После этого сразу перезапустим zabbix-agent.
systemctl restart zabbix-agent
Дальше идем в консоль mysql и создаем пользователя, от которого будет работать мониторинг. Ему достаточно ограниченных прав на чтение.
mysql -uroot -p
> CREATE USER 'zbx_monitor'@'%' IDENTIFIED BY 'TTRy1bRRgLIB';
> GRANT USAGE,REPLICATION CLIENT,PROCESS,SHOW DATABASES,SHOW VIEW ON *.* TO 'zbx_monitor'@'%';
> quit
Теперь смотрим, где у нас домашняя директория пользователя zabbix.
Подготовка к мониторингу mysql сервера завершена. Идем теперь в web интерфейс системы мониторинга Zabbix.
Настройка мониторинга Mysql сервера
В веб интерфейсе идем в раздел Настройка -> Шаблоны и импортируем шаблон template_db_mysql_agent.xml.
После этого прикрепляем добавленный шаблон к хосту, где мы только что настроили zabbix-agent и добавили пользователя mysql. Для того, чтобы сразу увидеть все метрики, принудительно выполним сбор данных. Для начала вручную запустим правила автообнаружения, так как у них интервал проверок 1 час. Не хочется столько времени ждать данных. Идем в хост, далее во вкладку Правила обнаружения. Выбираем 2 правила от шаблона mysql и запускаем их.
Ждем несколько секунд и переходим на вкладку Элементы данных. Фильтруем элементы по названию группы MySQL и Zabbix raw items.
Теперь переходим к списку элементов данных. Выделяем все элементы, которые относятся к Mysql и имеют тип Zabbix Agent и запускаем их принудительную проверку. Основной элемент тут — MySQL: Get status variables. Почти все итемы получаются в результате предобработки данных с него.
После этого идем в раздел Мониторинг -> Последние данные и наблюдаем собираемые метрики.
На этом по базовой настройке мониторинга сервера mysql все. Дальше раскрою некоторые нюансы.
Мониторинг репликации MySQL
Вообще, шаблон достаточно навороченный. Там и автообнаружение, и зависимые элементы с предобработкой xml, и предобработка с помощью JavaScript. Рассмотрю отдельно некоторые моменты представленного шаблона zabbix по мониторингу mysql. Во-первых, некоторые параметры задаются с помощью макросов. Вот их список.
Из настраиваемых параметров ясно, что мониторить можно не только локальный mysql сервер, но и удаленный, задав параметры подключения к нему.
Так же в шаблоне реализован мониторинг репликации базы данных. Для этого есть отдельное правила автообнаружения с триггерами. Теперь моя старая статья по мониторингу репликации mysql стала не актуальна. Этот же функционал реализован в базовом шаблоне. Если у вас не настроена репликация, то автообнаружение просто не найдет ничего. Можно это правило выключить.
Для мониторинга репликации автоматически создаются 4 триггера.
Replication lag is too high (over {$MYSQL.REPL_LAG.MAX.WARN} for 5m) — отставание реплики больше заданного в макросе времени. По умолчанию 30 минут.
The slave I/O thread is not connected to a replication master — Демон по сбору бинарного лога запущен, но не подключен к мастеру. Его параметр slave_io_running имеет значение не Yes.
The slave I/O thread is not running — демон по сбору бинарного лога не запущен. Его параметр slave_io_running равен No.
The SQL thread is not running — демон выполнения команд локального relay лога не запущен. Его парметр slave_sql_running равен No.
В целом, этих четырех метрик достаточно для мониторинга репликации. Я так же настраивал мониторинг именно их.
Триггеры шаблона
Для полноты картины, поясню остальные триггеры шаблона, чтобы у вас было понимание, за чем они следят и как правильно реагировать на них. Ниже список триггеров шаблона для мониторинга mysql сервера.
Buffer pool utilization is too low (less {$MYSQL.BUFF_UTIL.MIN.WARN}% for 5m) — под innodb пул выделено слишком много памяти и она не используется вся. Триггер чисто информационный, делать ничего не надо, если у вас нет дефицита памяти на сервере. Если нехватка оперативной памяти есть, то имеет смысл забрать немного памяти у mysql и передать другому приложению. Настраивается потребление памяти пулом параметром innodb_buffer_pool_size.
Failed to get items (no data for 30m) — от mysql сервера не поступают новые данные мониторинга в течении 30 минут. Имеет смысл уменьшить этот интервал до 5-10 минут.
Refused connections (max_connections limit reached) — срабатывает ограничение на максимальное количество подключений к mysql. Увеличить его можно параметром mysql сервера — max_connections. Его необходимо увеличить, если позволяют возможности сервера. Напомню, что увеличенное количество подключений требует увеличения потребления оперативной памяти. Если у вас ее уже не хватает, нет смысла увеличивать число подключений. Нужно решать вопрос с потреблением памяти.
Server has aborted connections (over {$MYSQL.ABORTED_CONN.MAX.WARN} for 5m) — сервер отклонил подключений выше заданного порога в макросе. Надо идти в лог mysql сервера и разбираться в причинах этого события. Скорее всего там будут подсказки.
Server has slow queries (over {$MYSQL.SLOW_QUERIES.MAX.WARN} for 5m) — количество медленных запросов выше установленного макросом предела. Надо идти и разбираться с медленными запросами. Тема не самая простая. Надо заниматься профилированием запросов и решать проблемы по факту — добавлением индексов, редактированием запросов, увеличения ресурсов mysql сервера и т.д.
Service has been restarted (uptime < 10m) — информационный триггер, срабатывающий на перезапуск mysql сервера (не ребут самого сервера).
Service is down — служба mysql не запущена.
Version has changed (new version value received: {ITEM.VALUE}) — версия mysql сервера изменилась. Тоже информационный триггер, сработает, к примеру, после обновления mysql сервера.
На этом по мониторингу MySQL сервера с помощью стандартного шаблона Zabbix все. Надеюсь, я доступно и понятно раскрыл данную тему. Если у вас есть замечания, жду вас в комментариях.
Заключение
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!
Здорово, что разработчики сами занялись написанием готовых шаблонов для мониторинга сетевых устройств, операционных систем и приложений. Поняли, что это будет способствовать развитию продукта. Многие шаблоны, которые разрабатывали сами пользователи, становятся неактуальными, так как разработчики их делают лучше. Собственно, это и логично. Кто лучше всех знает продукт, как не они. За последнее время появилось много обновления по этой теме. Надеюсь, будет еще больше.
Недавно вышла новая версия сервера Zabbix 5.0. Сегодня я расскажу, как обновить предыдущую версию zabbix 4.4 до актуальной 5.0. Делать это придется в обязательном порядке всем, так как версия 4.4 не LTS и имеет ограниченное время поддержки. В то время 5.0 как раз LTS с циклом поддержки в 5 лет.
Введение
Ранее я написал подробную статью по установке и настройке Zabbix 5, где в том числе рассказал своими словами обо всех основных нововведениях. Настоятельно рекомендую с ними ознакомиться, прежде чем обновляться. Обязательно сначала прочитайте всю статью, только потом начинайте обновление. По ходу дела будут важные замечания.
Второй момент. В этой версии очень много изменений, как в настройках, так и в интерфейсе. Обновлять без подготовки не рекомендую. Если у вас несколько серверов, начните с самого простого. Если же только один, то настоятельно рекомендую сделать его копию и проверить обновление на ней.
Еще один момент, который я упускал, когда обновлялся со старых версий Zabbix. В новых версиях часто обновляются стандартные шаблоны, но вы их не увидите при обновлении. У вас останутся работать старые версии. Новые нужно вручную переносить из свежих установок и подключать к хостам.
С одной стороны это плюс, так как шаблоны зачастую меняются очень сильно. Нужен ручной контроль. А с другой стороны неудобно вручную обновлять все шаблоны, которые еще и зависимости свои имеют. Рассмотрю все эти моменты по ходу дела. Приступаем к обновлению сервера мониторинг Zabbix версии 4.4 до 5.0.
Подготовка к обновлению
Перед обновлением, сделаем на всякий случай бэкап базы данных. Для этого предварительно остановим сервер.
systemctl stop zabbix-server
У меня что-то активно писалось в базу, поэтому сервер выключался долго. При этом systemd выдал ошибку:
Failed to stop zabbix-server.service: Connection timed out
See system logs and 'systemctl status zabbix-server.service' for details.
Я проверил лог zabbix-server, чтобы убедиться в корректном выключении. Там все нормально было, сервер штатно завершил работу, дописав то, что у него там накопилось. Так что бэкапим.
ключ -p и дальше пароль пользователя бд, если в пароле есть спецсимволы, экранируйте их одиночными кавычками
На всякий случай сохраним php скрипты админки, чтобы можно было оперативно запустить старую версию в случае нештатной ситуации. Хотя лично я сделал снепшот виртуалки перед обновлением, чтобы откатиться назад в случае проблем.
Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории — https://repo.zabbix.com/zabbix/5.0/ Дальнейшее обновление не будет отличаться от текущего.
К обновлению подготовились, можно приступать.
Установка обновления zabbix 4.4 до 5.0
Centos 8
Устанавливаем само обновление zabbix на сервер Centos следующей командой:
Это список пакетов заббикса для общего случая. Если у вас установлено что-то еще, лучше обновить все сразу. Посмотреть список установленных пакетов zabbix можно командой:
В Centos 7 обновить Zabbix с 4-й вертки на 5-ю может оказать не такой простой задачей. Связано это с тем, что необходима версия php 7.2, в ее в базовых репозиториях Centos 7 нет. Необходимо подключать репозиторий centos-release-scl и ставить пакеты из него. Но просто так взять и поставить не получится, будет конфликт с текущими версиями пакетов. Так что нужно аккуратно что-то удалить, а что-то добавить. Действуем аккуратно и внимательно.
Удаляем старые пакеты, которые будут заменены при обновлении:
yum remove zabbix-web-*
Подключаем репозиторий centos-release-scl:
yum install centos-release-scl
Редактируем файл /etc/yum.repos.d/zabbix.repo, разрешая обновляться пакетам из zabbix-frontend. Не забудьте проверить, что у вас подключился репозиторий от 5-й версии.
[zabbix-frontend]name=Zabbix Official Repository frontend - $basearch baseurl=http://repo.zabbix.com/zabbix/5.0/rhel/7/$basearch/frontend enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-ZABBIX-A14FE591
Теперь убедитесь, что у вас активирован новый конфиг zabbix для apache. У вас должен быть файл /etc/httpd/conf.d/zabbix.conf, а в нем следующая строка:
Дальше инструкция общая для всех систем. После завершения обновления, запускаем сервер:
systemctl start zabbix-server
В момент запуска произойдет обновление базы данных. Для маленькой базы (1-2 гб) это не займет много времени. Вы можете даже не заметить процесса. Если база больше, то надо подождать, пока не закончится обновление. Следить за ним можно с помощью просмотра лог файла zabbix сервера.
tail -f /var/log/zabbix/zabbix_server.log
После завершения обновления базы, сервер запустится. После этого можно запустить и агент.
systemctl start zabbix-agent
В логах агента и сервера можно посмотреть версию запущенных сервисов.
Теперь можно идти в веб интерфейс и смотреть на обновленную версию zabbix server. Перед этим почистите кэш браузера и удалите куки от страницы заббикса. Если этого не сделать, то могут быть проблемы и ошибки, с чем я не раз сталкивался. Если у вас в качестве веб сервера используется nginx, не забудьте поменять владельца директории /etc/zabbix/web на nginx, в том случае, если веб сервер работает от него. После обновления он будет принадлежать apache, а web интерфейс не заработает.
chown -R nginx:nginx /etc/zabbix/web
Можете лицезреть обновленную версию web интерфейса.
Сначала провел обновление на небольшом сервере. У меня весь процесс прошел без ошибок и накладок. Новый интерфейс сразу заработал.
Основные изменения в интерфейсе Zabbix 5.0
Я потратил некоторое время, пока искал привычные настройки на новых местах. Чтобы сэкономить вам время, дам несколько подсказок.
Web проверки и графики теперь живут в разделе Узлы сети.
Я долго искал web проверки и перепугался, не убрали ли их совсем из системы. Для меня это очень актуальный функционал. С его помощью настроен мониторинг сайтов.
Для того, чтобы посмотреть на одном экране набор произвольных графиков хотса, надо перейти в Узлы сети, открыть графики конкретного хоста. Затем перейти в Фильтр и там выбрать необходимые графики. Стало удобно.
Раньше, чтобы быстро посмотреть несколько графиков на одном экране, надо было их собирать в дашборд или комплексный экран. Теперь можно без проблем вывести в три клика все, что надо. Жаль, что сами графики так и остались старыми. Выглядят они ужасно 🙁
Настройка шаблонов оповещений теперь находится в способах оповещений. Все старые шаблоны, что были в действиях, удалены. Так что сохраняйте их перед обновлением.
Вот подтверждение того, что несмотря на обновление zabbix server до 5.0, шаблон остался старый.
В новом шаблоне этого триггера уже нет. Так что добавлять в систему и обновлять шаблоны у хостов придется вручную. Я уже немного занимался этим еще в версии 4.4 и могу сказать, что это хлопотно. В новых шаблонах больше данных и триггеров, которые не всегда и не везде нужны. Надо внимательно все смотреть и отключать не нужное. А так же редактировать некоторые триггеры под свои нужды.
С другой стороны, если вас старые шаблоны полностью устраивают, то и менять их не обязательно. Я скорее всего на старых установках так и оставлю старые шаблоны, а в новых буду использовать новые. Потом сделаю какую-то универсальную компиляцию для себя из того, что нужно конкретно мне.
О нововведениях свежей версии zabbix 4.4 в этот раз я почти ничего не слышал. Не видел ни статей на эту тему, ни видео выступлений, хотя обычно наблюдаю их. Либо материала было меньше, либо просто все прошло вне поля моего зрения. Слышал только, что готовится поддержка TimescaleDB, видел публикации на эту тему. Так что пришлось читать официальные what’s news и release notes на самом сайте zabbix. Вот что нового нам обещают в zabbix 4.4.
Новый zabbix-agent, написанный на Go. Из новых возможностей агента заявлено — фреймворк для кастомизации проверок, возможность сохранения состояния между проверками, более гибкий планировщик, более эффективная передача данных, замена текущих агентов с поддержкой большего количества платформ в будущем.
Вебхуки и более продвинутая логика для действий и оповещений на основе JavaScript. С помощью этих улучшений станет проще настраивать интеграцию с внешними сервисами.
Новый стандарт для шаблонов. Как я понял, разработчики решили упорядочить создание шаблонов и предложили свой формат для их оформления. Подробнее описано в Zabbix template guidelines. Я пока еще не вникал и не разбирался с этой темой. Посмотрим, что в итоге получится. На мой взгляд хороший шаг сделан. Давно пора было как-то упорядочить шаблоны.
Как я уже сказал ранее, добавлена поддержка TimescaleDB. Это должно существенно увеличить производительность хранилища данных, что является узким место системы мониторинга zabbix.
Реализована база знаний для итемов и триггеров. Теперь их можно будет документировать. Любопытная фича, надо будет попробовать. Я обычно поле description для этого раньше использовал.
Расширился функционал визуализации. Появились новые виджеты для дашбордов, новые типы графиков, возможность агрегировать данные с помощью функций.
Добавилась поддержка новых версий операционных систем — centos 8, debian 10 и т.д.
Нововведения, как обычно, любопытные и кое-где я обновлю сервера, чтобы потестировать новые фичи. Там, где новый функционал не нужен, обновление ставить не буду. Я больше предпочитаю использовать LTS версии в production.
Основные нововведения Zabbix 4.4 разобрали, приступим к обновлению.
Подготовка к обновлению
Если у вас версия Zabbix ниже 4.0, то предварительно обновите ее до указанной. У меня есть цикл статей на тему обновления Zabbix:
Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории — https://repo.zabbix.com/zabbix/4.4/ Дальнейшее обновление не будет отличаться от текущего.
К обновлению подготовились, можно приступать.
Установка обновления zabbix 4.2 до 4.4
Centos
Устанавливаем само обновление zabbix на сервер Centos следующей командой:
Это список пакетов заббикса для общего случая. Если у вас установлено что-то еще, лучше обновить все сразу. Посмотреть список установленных пакетов zabbix можно командой:
Дальше инструкция общая для всех систем. После завершения обновления, запускаем сервер:
systemctl start zabbix-server
В момент запуска произойдет обновление базы данных. Для маленькой базы (1-2 гб) это не займет много времени. Вы можете даже не заметить процесса. Если база больше, то надо подождать, пока не закончится обновление. Следить за ним можно с помощью просмотра лог файла zabbix сервера.
tail -f /var/log/zabbix/zabbix_server.log
После завершения обновления базы, сервер запустится. После этого можно запустить и агент.
systemctl start zabbix-agent
В логах агента и сервера можно посмотреть версию запущенных сервисов.
Теперь можно идти в веб интерфейс и смотреть на обновленную версию zabbix server. Перед этим почистите кэш браузера и удалите куки от страницы заббикса. Если этого не сделать, то могут быть проблемы и ошибки, с чем я не раз сталкивался. Если у вас в качестве веб сервера используется nginx, не забудьте поменять владельца директории /etc/zabbix/web на nginx. После обновления он будет принадлежать apache, а web интерфейс не будет работать.
chown -R nginx:nginx /etc/zabbix/web
В веб интерфейсе в самом низу будет показана текущая версия сервера:
Можете изучать новую версию zabbix 4.4 и пробовать улучшения.
Заключение
Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!
Процедура обновления Zabbix сервера обычно не сложная. Проблемы чаще всего возникают в двух случаях:
Проблемы с зависимостями пакетов, чаще всего php или mysql.
Большая база данных, которая очень долго обновляется, либо не обновляется по какой-то причине.
Первая проблема решается ручным удалением или установкой нужных пакетов. Тут универсального совета дать невозможно. Зависит от того, что вы делали на сервере и почему у вас сломаны зависимости. Вторая проблема решается, в зависимости от причин проблем с базой. Если она слишком большая и поэтому все тормозит и длится слишком долго, надо либо ускорять сервер, либо чистить базу.
Иногда база не обновляется из-за каких-то проблем с записями. Чаще всего в полях acknowledged, куда можно понаписать всего, что угодно. Надо тоже разбираться по месту и удалять то, что мешает обновлению. Но в общем и целом, обновление проходит штатно и лично у меня никогда не было с ним проблем.
Сервер Zabbix используется для сбора и анализа информации о состоянии узлов сети. В данной статье будет рассмотрен процесс его установки и развертывания веб-интерфейса для его управления. В качестве сервера баз данных мы будем использовать MariaDB/MySQL. Версия операционной системы, которая использовалась для написания инструкции — 18.04 (LTS), версия Zabbix — 4.2.
Подготовка сервера
Перед установкой Zabbix выполняем подготовительные процедуры.
1. Правильное время
Для получения актуальной информации необходимо, чтобы на сервере было правильное время.
Для этого сначала задаем правильную временную зону:
timedatectl set-timezone Europe/Moscow
* в данном примере задается московское время.
Затем устанавливаем и запускаем сервис синхронизации времени:
* где /var/www/html — корневой путь хранения скриптов; /run/php/php7.2-fpm.sock — путь до сокетного файла php-fpm (точное расположение файла можно посмотреть в конфигурационном файле /etc/php/7.2/fpm/pool.d/www.conf).
Проверяем настройки nginx:
nginx -t
И перезагружаем его:
systemctl restart nginx
Создаем index.php со следующим содержимым:
nano /var/www/html/index.php
<?php phpinfo(); ?>
Открываем веб-браузер и переходим по ссылке http://<IP-адрес сервера>/ — теперь мы должны увидеть сводную информацию по 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.
При установке zabbix-web файлы портала копируются в каталог /usr/share/zabbix. Наш веб-сервер работает с каталогом /var/www/html.
Меняем это — открываем конфигурационный файл nginx:
vi /etc/nginx/sites-enabled/default
nano /etc/nginx/sites-enabled/default
Редактируем параметры root и set $root_path:
...
root /usr/share/zabbix;
...
set $root_path /usr/share/zabbix;
...
Перезапускаем nginx:
systemctl restart nginx
Установка портала для управления Zabbix
Открываем браузер и переходим по адресу http://<IP-адрес сервера>/ — откроется страница установки 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
Откроем конфигурационный файл:
nano /etc/zabbix/zabbix_agentd.conf
Отредактируем следующую опцию:
Server=localhost
* в данном примере мы указываем агенту сервер Zabbix — мы может указать его имя или IP-адрес.
В данной инструкции мы сначала соберем кластер Proxmox для управления всеми хостами виртуализации из единой консоли, а затем — кластер высокой доступности (HA или отказоустойчивый). В нашем примере мы будем работать с 3 серверами — pve1, pve2 и pve3.
Мы не станем уделять внимание процессу установки Proxmox VE, а также настройки сети и других функций данного гипервизора — все это можно прочитать в пошаговой инструкции Установка и настройка Proxmox VE.
Подготовка нод кластера
Серверы должны иметь возможность обращения друг к другу по их серверным именам. В продуктивной среде лучше всего для этого создать соответствующие записи в DNS. В тестовой можно отредактировать файлы hosts. В Proxmox это можно сделать в консоли управления — устанавливаем курсор на сервере — переходим в Система — Hosts — добавляем все серверы, которые будут включены в состав кластера:
* в данном примере у нас в hosts занесены наши два сервера Proxmox, из которых мы будем собирать кластер.
Настройка кластера
Построение кластерной системы выполняется в 2 этапа — сначала мы создаем кластер на любой из нод, затем присоединяем к данному кластеру остальные узлы.
Создание кластера
Переходим в панель управления Proxmox на любой их нод кластера. Устанавливаем курсов на Датацентр — кликаем по Кластер — Создать кластер:
Для создания кластера нам нужно задать его имя и, желательно, выбрать IP-адрес интерфейса, на котором узел кластера будет работать:
… кликаем Создать — процесс не должен занять много времени. В итоге, мы должны увидеть «TASK OK»:
Присоединение ноды к кластеру
На первой ноде, где создали кластер, в том же окне станет активна кнопка Данные присоединения — кликаем по ней:
В открывшемся окне копируем данные присоединения:
Теперь переходим в панель управления нодой, которую хотим присоединить к кластеру. Переходим в Датацентр — Кластер — кликаем по Присоединить к кластеру:
В поле «Данные» вставляем данные присоединения, которые мы скопировали с первой ноды — поля «Адрес сервера» и «Отпечаток заполняться автоматически». Заполняем пароль пользователя root первой ноды и кликаем Присоединение:
Присоединение также не должно занять много времени. Ждем несколько минут для завершения репликации всех настроек. Кластер готов к работе — при подключении к любой из нод мы будем подключаться к кластеру:
Готово. Данный кластер можно использовать для централизованного управления хостами Proxmox.
Посмотреть статус работы кластера можно командой в SSH:
pvecm status
Отказоустойчивый кластер
Настроим автоматический перезапуск виртуальных машин на рабочих нодах, если выйдет из строя сервер.
Для настройки отказоустойчивости (High Availability или HA) нам нужно:
Минимум 3 ноды в кластере. Сам кластер может состоять из двух нод и более, но для точного определения живых/не живых узлов нужно большинство голосов (кворумов), то есть на стороне рабочих нод должно быть больше одного голоса. Это необходимо для того, чтобы избежать ситуации 2-я активными узлами, когда связь между серверами прерывается и каждый из них считает себя единственным рабочим и начинает запускать у себя все виртуальные машины. Именно по этой причине HA требует 3 узла и выше.
Общее хранилище для виртуальных машин. Все ноды кластера должны быть подключены к общей системе хранения данных — это может быть СХД, подключенная по FC или iSCSI, NFS или распределенное хранилище Ceph или GlusterFS.
1. Подготовка кластера
Процесс добавления 3-о узла аналогичен процессу, описанному выше — на одной из нод, уже работающей в кластере, мы копируем данные присоединения; в панели управления третьего сервера переходим к настройке кластера и присоединяем узел.
2. Добавление хранилища
Подробное описание процесса настройки самого хранилища выходит за рамки данной инструкции. В данном примере мы разберем пример и использованием СХД, подключенное по iSCSI.
Если наша СХД настроена на проверку инициаторов, на каждой ноде смотрим командой:
* где iqn.1993-08.org.debian:01:4640b8a1c6f — IQN, который нужно добавить в настройках СХД.
После настройки СХД, в панели управления Proxmox переходим в Датацентр — Хранилище. Кликаем Добавить и выбираем тип (в нашем случае, iSCSI):
В открывшемся окне указываем настройки для подключения к хранилке:
* где ID — произвольный идентификатор для удобства; Portal — адрес, по которому iSCSI отдает диски; Target — идентификатор таргета, по которому СХД отдает нужный нам LUN.
Нажимаем добавить, немного ждем — на всех хостах кластера должно появиться хранилище с указанным идентификатором. Чтобы использовать его для хранения виртуальных машин, еще раз добавляем хранилище, только выбираем LVM:
Задаем настройки для тома LVM:
* где было настроено:
ID — произвольный идентификатор. Будет служить как имя хранилища.
Основное хранилище — выбираем добавленное устройство iSCSI.
Основное том — выбираем LUN, который анонсируется таргетом.
Группа томов — указываем название для группы томов. В данном примере указано таким же, как ID.
Общедоступно — ставим галочку, чтобы устройство было доступно для всех нод нашего кластера.
Нажимаем Добавить — мы должны увидеть новое устройство для хранения виртуальных машин.
Для продолжения настройки отказоустойчивого кластера создаем виртуальную машину на общем хранилище.
3. Настройка отказоустойчивости
Создание группы
Для начала, определяется с необходимостью групп. Они нужны в случае, если у нас в кластере много серверов, но мы хотим перемещать виртуальную машину между определенными нодами. Если нам нужны группы, переходим в Датацентр — HA — Группы. Кликаем по кнопке Создать:
Вносим настройки для группы и выбираем галочками участников группы:
* где:
ID — название для группы.
restricted — определяет жесткое требование перемещения виртуальной машины внутри группы. Если в составе группы не окажется рабочих серверов, то виртуальная машина будет выключена.
nofailback — в случае восстановления ноды, виртуальная машина не будет на нее возвращена, если галочка установлена.
Также мы можем задать приоритеты для серверов, если отдаем каким-то из них предпочтение.
Нажимаем OK — группа должна появиться в общем списке.
Настраиваем отказоустойчивость для виртуальной машины
Переходим в Датацентр — HA. Кликаем по кнопке Добавить:
В открывшемся окне выбираем виртуальную машину и группу:
… и нажимаем Добавить.
4. Проверка отказоустойчивости
После выполнения всех действий, необходимо проверить, что наша отказоустойчивость работает. Для чистоты эксперимента, можно выключиться сервер, на котором создана виртуальная машина, добавленная в HA.
Важно учесть, что перезагрузка ноды не приведет к перемещению виртуальной машины. В данном случае кластер отправляет сигнал, что он скоро будет доступен, а ресурсы, добавленные в HA останутся на своих местах.
Для выключения ноды можно ввести команду:
systemctl poweroff
Виртуальная машина должна переместиться в течение 1 — 2 минут.
Ручное перемещение виртуальной машины
Представим ситуацию, что у нас произошел сбой одного из узлов кластера, но при этом виртуальная машина не переехала на рабочую ноду. Например, если сервер был отправлен в перезагрузку, но не смог корректно загрузиться. В консоли управления нет возможности мигрировать виртуалку с неработающего сервера. Поэтому нам понадобиться командная строка.
И так, открываем SSH-консоль сервера, на любой работающем сервере Proxmox. Переходим в каталог qemu-server той ноды, которая не работает:
cd /etc/pve/nodes/pve1/qemu-server
* мы предполагаем, что у нас вышел из строя сервер pve1.
Смотрим содержимое каталога:
ls
Мы должны увидеть конфигурационные файлы запущенных виртуальных машин, например:
100.conf
* в нашем примере у нас запущена только одна виртуальная машина с идентификатором 100.
mv 100.conf ../../pve2/qemu-server/
* где pve2 — имя второй ноды, на которой мы запустим виртуальный сервер.
Командой:
qm list
… проверяем, что виртуальная машина появилась в системе. В противном случае, перезапускаем службы:
ha-manager set vm:100 --state disabled
ha-manager set vm:100 --state started
* в данном примере мы сбросили состояние для виртуальной машины с идентификатором 100. Если это не сделать, то при запуске виртуалки ничего не будет происходить.
После виртуальную машину можно запустить:
qm start 100
Репликация виртуальных машин
Если у нас нет общего дискового хранилища, мы можем настроить репликацию виртуальных машин между нодами. В таком случае мы получим, относительно, отказоустойчивую среду — в случае сбоя, у нас будет второй сервер, на котором есть аналогичный набор виртуальных машин.
Настройка ZFS
Репликация может выполняться только на тома ZFS. Подробная работа с данной файловой системой выходит за рамки данной инструкции, однако, мы разберем основные команды, с помощью которых можно создать необходимы том.
Пул ZFS необходимо создавать из командной строки, например:
zpool create -f zpool1 /dev/sdc
* в данном примере мы создадим пул с названием zpool1 из диска /dev/sdc.
Теперь открываем панель управления Proxmox. Переходим в Датацентр — Хранилище — ZFS:
Задаем настройки для создания хранилища из созданного ранее пула ZFS:
* в данном примере мы создаем хранилище из пула zpool1; название для хранилище задаем zfs-pool, также ставим галочку Дисковое резервирование. Остальные настройки оставляем по умолчанию.
После этого мы должны либо перенести виртуальную машину на хранилище ZFS, либо создать в нем новую машину.
Настройка репликации
Переходим к хосту, где находится виртуальная машина, для которой мы хотим настроить клонирование (она должна также находится на хранилище ZFS) — Репликация:
Задаем настройки для репликации виртуальной машины:
* в данном примере мы указываем системе проверять и реплицировать изменения каждые 15 минут для виртуальной машины с идентификатором 100. Репликация должна проводиться на сервер pve2.
Нажимаем Создать — теперь ждем репликации по расписанию или форсируем событие, кликнув по Запустить сейчас:
Удаление ноды из кластера
Удаление узла из рабочего кластера выполняется из командной строки. Список всех нод можно увидеть командой:
pvecm nodes
Мы увидим, примерно, следующее:
Membership information
----------------------
Nodeid Votes Name
1 1 pve1 (local)
2 1 pve2
3 1 pve3
* где pve1, pve2, pve3 — узлы кластера; local указываем на ноду, с которой мы выполняем команду pvecm.
Для удаления узла, например, pve2 вводим:
pvecm delnode pve2
Ждем немного времени, пока не пройдет репликация. В консоли управления Proxmox удаленный сервер должен пропасть
Удаление кластера
Рассмотрим процесс удаления нод из кластера и самого кластера. Данные действия не могут быть выполнены из веб-консоли — все операции делаем в командной строке.
Подключаемся по SSH к одной из нод кластера. Смотрим все узлы, которые присоединены к нему:
pvecm nodes
Мы получим список нод — удалим все, кроме локальной, например:
pvecm delnode pve2
pvecm delnode pve3
* в данном примере мы удалили ноды pve2 и pve3.
Необходимо подождать, минут 5, чтобы прошла репликация между нодами. После останавливаем следующие службы:
