Как мы 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.2 до 5.4
17 мая 2021 года состоялся релиз версии 5.4 популярной системы мониторинга Zabbix. В своей статье я расскажу, как обновиться до новой версии Zabbix 5.4 с предыдущего релиза 5.2. В качестве операционных систем, на которых будет выполняться обновление выступят Centos 8, Debian 10, Ubuntu 20. Напомню, что Zabbix Server больше не поддерживает Centos 7.
Что нового в Zabbix 5.4?
Дальше изменения на мой взгляд не столь значительные, так что не буду их комментировать, просто перечислю:
Ну и много других более мелких изменений. Я пробежался глазами по release_notes и перевел то, что показалось наиболее интересным. В общем, Zabbix не стоит на месте, развивается. Свою нишу в мониторинге удерживает твердо. Если кто-то не читал мою статью про сравнение Zabbix vs Prometheus, можете ознакомиться. Описал своими словами отличия.
Рекомендую мою статью по установке и настройке Zabbix 5. Там я разбираю различные варианты установки, выполняю первоначальную настройку и делюсь своим опытом эксплуатации данной системы мониторинга.
Как я уже сказал в самом начале, в этой версии появился новый синтаксис запросов в триггерах и некоторых других местах, так что обновление знаковое. Нужно будет ставить и разбираться. Весь старый синтаксис будет автоматически преобразован в новый, вручную ничего делать не придется.
Также отдельно обращаю внимание, что с большой долей вероятности сломается интеграция с Grafana, если в метриках использовали Applications, так как их в 5.4 отменили и заменили полностью триггерами. Будете получать ошибку: Method not found. Incorrect API «application».
Подготовка к обновлению
Важная информация перед обновлением. Версия 5.4 без длительной поддержки. Через пол года к ней перестанут выходить обновления, так что вам обязательно придется обновляться на следующую версию. Если для вас не критичны нововведения этого релиза, пропускайте его и ждите новой LTS версии.
Если у вас версия ниже 5.2, то предварительно обновите ее до указанной. У меня есть цикл статей на тему обновления Zabbix:
Перед обновлением, сделаем на всякий случай бэкап базы данных. Для этого предварительно остановим сервер с агентом.
У меня что-то активно писалось в базу, поэтому сервер выключался долго. Я проверил лог zabbix-server, чтобы убедиться в корректном выключении. Там все нормально было, сервер штатно завершил работу, дописав то, что у него там накопилось. Так что бэкапим.
На всякий случай сохраним php скрипты админки, чтобы можно было оперативно запустить старую версию в случае нештатной ситуации. Хотя лично я сделал снепшот виртуалки перед обновлением, чтобы откатиться назад в случае проблем.
Centos 8
Подключаем репозиторий версии zabbix 5.4:
Старый репозиторий от версии 5.2 будет автоматически удален.
Очищаем и пересоздаем кэш dnf:
Debian 10
Удаляем пакет текущего репозитория:
Обновляем информацию о репозиториях:
Ubuntu 20
Удаляем пакет текущего репозитория:
Обновляем информацию о репозиториях:
Если у вас другие версии систем, то простой найдите ссылки пакетов под свою версию в официальном репозитории — https://repo.zabbix.com/zabbix/5.4/ Дальнейшее обновление не будет отличаться от текущего.
К обновлению подготовились, можно приступать.
Установка обновления zabbix 5.2 до 5.4
Centos 8
Для начала проверим список установленных пакетов zabbix в системе.
Устанавливаем обновление zabbix на сервер Centos 8, выбирая установленные у вас пакеты:
После завершения обновления, запускаем zabbix-server.
Проверяем лог сервера. Необходимо дождаться обновления базы данных. Важно не трогать в этот момент сервер, не прерывать обновление, не пытаться его перезапустить. Если база большая, обновление может длиться очень долго. Рекомендую сначала где-то протестировать этот процесс, прежде чем обновлять прод.
В конце должны получить примерно следующее сообщение:
Есть ненулевой шанс, что будет какая-то ошибка с базой. Чаще всего возникают проблемы с какой-то нестандартной записью в таблице. Туда может попасть какой-то необычный символ, или с кодировкой проблемы. В этих случаях удаляйте проблемные записи, меняйте кодировку базы zabbix.
После обновления переходите в web интерфейс и проверяйте версию Zabbix. Должна быть 5.4.
На этом обновления Zabbix до 5.4 на Centos завершено.
Debian / Ubuntu
Проверяем, какие пакеты Zabbix у нас установлены на сервере:
Устанавливаем обновление zabbix server и остальных пакетов на Debian или Ubuntu следующей командой:
После завершения обновления, запускаем сервер:
В момент запуска произойдет обновление базы данных. Для маленькой базы (1-2 гб) это не займет много времени. Вы можете даже не заметить процесса. Если база больше, то надо подождать, пока не закончится обновление. Следить за ним можно с помощью просмотра лог файла zabbix сервера.
После завершения обновления базы, сервер запустится. После этого можно запустить и агент.
В логах агента и сервера можно посмотреть версию запущенных сервисов.
Теперь можно идти в веб интерфейс и смотреть на обновленную версию zabbix server. Перед этим почистите кэш браузера и удалите куки от страницы заббикса. Если этого не сделать, то могут быть проблемы и ошибки, с чем я не раз сталкивался. Если у вас в качестве веб сервера используется nginx, не забудьте поменять владельца директории /etc/zabbix/web на nginx, в том случае, если веб сервер работает от него. После обновления он будет принадлежать apache, а web интерфейс не заработает.
Теперь можете лицезреть обновленную версию web интерфейса в браузере.
