В связи с известными обстоятельствами многим понадобилось живое общение посредством камеры. Один из вариантов – установка сервера видеоконференций Jitsi. Jitsi – это набор проектов с открытым исходным кодом, который позволяет легко создавать и развертывать безопасные решения для видеоконференций.
Вот основные составные части Jitsi:
Jitsi Meet – безопасная, простая и масштабируемая платформа видеоконференции, которую можно использовать в качестве автономного приложения
Jitsi Videobridge – механизм медиасервера (также известный как Selective Forwarding Unit (SFU)), который поддерживает все многосторонние видеоконференции Jitsi
Jigasi – сервис шлюза, который соединяет SIP-телефонию с конференцией Jitsi Videobridge
Jibri – вещатель и рекордер, используемые для сохранения записей видеозвонков и потоковой передачи на YouTube Live
Jidesha – расширение для Chrome и Firefox для расшаривания экрана
Установка достаточно простая, требуется установленный сервер Ubuntu/Debian с внешним ip-адресом.
Сначала установите ключ репозитория Jitsi на вашу систему:
sudo sh -c "echo 'deb https://download.jitsi.org stable/' > /etc/apt/sources.list.d/jitsi-stable.list"
Обновим список пакетов.
sudo apt-get -y update
Установка полной версии Jitsi
sudo apt-get -y install jitsi-meet
В процессе установки у вас запросят доменное имя данного сервера. Под него будет сгенерирован самоподписанный сертификат, который, впрочем, после окончания установки лучше заменить на нормальный.
Для работы сервера Jitsi необходимо открыть следующие порты: tcp 443, tcp 4443, udp 10000.
Установка сертификата Let’s Encrypt
Если все заработало, то следующий шаг – установка сертификата. В противном случае не смогут подключатся пользователи Android и iOS. Есть уже готовый скрипт: /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh
После запуска у вас попросят указать свой адрес электронной почты на который будут приходить сообщения о проблемах с сертификатом. Весь остальной процесс автоматизирован.
Что делать если сервер Jitsi находится за NAT ?
Если сервер находится за NAT, необходимо внести изменения в файл /etc/jitsi/videobridge/sip-communicator.properties:
net use Z: https://cloud.admin812.ru/remote.php/dav/files/clouduser/ /persistent:YES /user:youruser yourpassword
Выделенное красным меняем на свои данные.
Если команда не выполняется и выдает ошибку: “Системная ошибка 67. Не найдено сетевое имя.”, проверьте состояние службы Web-клиент. Некоторые обновления Windows самостоятельно меняют тип запуска службы на “Вручную”. Установите ” Автоматически”.
В последнее время 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, куда можно понаписать всего, что угодно. Надо тоже разбираться по месту и удалять то, что мешает обновлению. Но в общем и целом, обновление проходит штатно и лично у меня никогда не было с ним проблем.
