Что изменится в Zabbix 8.0 и когда переходить

Zabbix 8.0 LTS ещё не вышел: по дорожной карте его планируют на ноябрь 2026 года, а 21 октября выпустили RC2. Я не советую переносить такую сборку в рабочий контур. Разбираю подтверждённые изменения, требования к обновлению и условия, при которых переход имеет смысл.

Когда выйдет Zabbix 8.0 и что известно сейчас

На 25 октября 2026 года Zabbix 8.0 LTS существует как предрелизная ветка: RC1 вышла 1 октября, RC2 — 21 октября. В дорожной карте вендор указывает ноябрь 2026 года как плановый срок релиза, но конкретного числа там нет. Поэтому даты вроде «15 ноября» или «30 декабря» я не переношу в календарь работ: официальная дата может измениться. Если вы сейчас обслуживаете мониторинг Zabbix, сначала стоит понять, что именно нового нужно вашей команде и есть ли для перехода практическая причина.

RC — кандидат в релиз, а не приглашение проверять его на рабочей базе. Он нужен, чтобы отловить несовместимости до стабильного выпуска. На сайте Zabbix уже есть пакеты RC2 и отдельные заметки к этой сборке; это подтверждает доступность тестовой версии, но не означает, что она готова к эксплуатации без проверки. Слово «кандидат» в названии не делает обновление безопасным само по себе. Перед установкой я смотрю дату сборки, перечень изменений, поддерживаемые компоненты и известные замечания именно для своей конфигурации. Практический смысл этого различия простой: пакет можно скачать и поставить на копию системы, но это не переводит его в категорию поддерживаемого рабочего релиза. В производственном мониторинге важны не только доступность файла и успешный запуск процесса. Нужно знать, что будет с базой при первом старте, какие службы потребуется перезапустить и как быстро команда заметит пропуск данных. Эти ответы получают на репетиции, а не из того, что установка прошла без ошибки.

Для тех, кто использует Zabbix 7.0 LTS, спешка особенно плохо обоснована сроками поддержки: полный этап поддержки этой версии заявлен до 30 июня 2027 года, ограниченный — до 30 июня 2029 года. Это не обещание, что каждый старый сервер можно оставить без внимания, но календарного давления «обновиться сегодня или остаться без поддержки» сейчас нет. Сначала проверьте фактическую версию, состояние пакетов и базу. Затем назначайте план перехода, а не наоборот. Статус LTS не освобождает от обновления в течение всего срока поддержки. Он даёт предсказуемый период сопровождения, чтобы можно было запланировать проверку без аварийной гонки. Я бы записал не только номер ветки, но и точную сборку сервера и агентов, тип backend-базы, используемый frontend и способ установки. Без этого «мы на 7.0» — слишком грубое описание для безопасного плана: один и тот же номер версии не раскрывает состояние зависимостей и интеграций.

Дорожная карта полезна как ориентир по крупным изменениям, а не как гарантия даты или состава финальной сборки. Вендор отмечает готовность отдельных функций, но перед производственным обновлением важнее release notes конкретного кандидата, инструкция перехода и таблица совместимости. Я разделяю три вещи: что уже доступно в RC2, что заявлено в дорожной карте 8.0 LTS и что подтверждено в окончательном выпуске. Пока последнего нет, обещать клиенту точный день и полный список функций — гадание с аккуратным шрифтом.

Что действительно нового в Zabbix 8.0

В заметках к RC2 есть конкретные изменения вокруг OpenTelemetry: поддержка приёма данных через коллектор и визуализация трассировок. В описании APM говорится о сборе телеметрии через прокси и отдельном представлении в веб-интерфейсе. Это полезно там, где команда уже собирает телеметрию приложений и хочет смотреть её рядом с привычным мониторингом. Но сама надпись OpenTelemetry не ускорит старые проверки и не отменит разбор схемы хранения: новый источник данных надо включить в архитектуру, оценить объём и определить, кто будет разбирать сигналы. Для использования этой возможности придётся проверить, откуда приходит телеметрия, через какой proxy она проходит и где будет храниться. В документации описаны OTLP/gRPC, прокси и источник данных ClickHouse; это уже несколько компонентов, а не галочка в настройке триггера. Если в офисе нет приложений, которые отдают такую телеметрию, эта часть релиза не меняет ежедневную работу администратора. Сначала определите конкретный сценарий, потом решайте, нужно ли расширять стек.

Ещё одна заявленная для 8.0 возможность — движок сложной обработки событий, или CEP. В базе знаний сайта отдельно зафиксировано появление этой функции в Zabbix 8.0. По дорожной карте CEP должен обрабатывать события по правилам: менять теги и важность, фильтровать и объединять события, закрывать устаревшие, учитывать временные окна и сопоставлять шаблоны. Это не тот же механизм, что обычный триггер, и не волшебный фильтр шума. Правило обработки нужно описать, проверить на копии событий и убедиться, что оно не скрывает ситуацию, ради которой дежурный вообще открыл Zabbix. Важно не подменять проверку названием функции. Пока релизная документация уточняется, я бы ограничил первое испытание небольшой выборкой событий и сохранил исходную схему оповещения как контроль. Сравните, какие события проходят дальше, какие объединяются и что увидит дежурный в интерфейсе. Если одинаковые сигналы перестали повторяться, это ещё не доказывает, что правило корректно обработало редкую комбинацию условий. Для таких правил нужны специально подобранные примеры, включая восстановление после проблемы.

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

В исходном черновике фигурировали «Smart-alert engine», Jinja2 в LLD, снижение нагрузки на базу на 30 %, поддержка HTTP/3 и особые ошибки RC. Я не нашёл этим утверждениям подтверждения в официальных материалах 8.0 и удалил их. Не надо приписывать релизу цифры, которые красиво смотрятся в сравнительной таблице. Если проблема сейчас в тяжёлых проверках, сначала разберите частоту опроса, историю и шаблоны; для этого есть отдельный разбор нагрузки на Zabbix. Сравнение функций должно отделять опубликованное поведение от ожиданий. Например, RC2 уже имеет собственные release notes, а дорожная карта описывает планы LTS и статус отдельных пунктов. Я оставил в статье только названия, которые можно проследить до первичных материалов, и не вывожу из них универсальный выигрыш в производительности. Быстрее ли станет ваша база, зависит от версии, типа хранилища, числа элементов и интервалов опроса; это измеряется на вашей нагрузке.

• OpenTelemetry: приём данных и просмотр трассировок
• CEP: обработка событий по правилам
• Мобильное приложение и уведомления
• Права доступа к прокси и группам прокси

Что проверить до обновления Zabbix

Проверка начинается не с кнопки обновления, а с инвентаризации. Запишите версии сервера, прокси, агентов, базы данных, PHP и веб-сервера; отдельно перечислите шаблоны, внешние скрипты, пользовательские параметры и интеграции уведомлений. В заметках по переходу с 7.4 на 8.0 отдельно указаны прекращение поддержки агентов старше версии 1.6 и повышение минимальных версий базы и PHP. Например, для этой ветки перечислены PHP 8.2, MySQL/Percona 8.4, MariaDB 10.11 и PostgreSQL 15. Состав требований зависит от исходной версии и выбранной базы, поэтому сравнивайте свою пару версий с таблицей, а не с чужой памяткой. В заметках для перехода с 7.0.x также указано прекращение поддержки Oracle DB. Если такая база используется, это не мелкая поправка в настройках, а отдельный пункт плана: сначала определить поддерживаемый вариант перехода и только затем выбирать окно. Не считайте требования из примера с 7.4 универсальными для всех исходных версий. Официальная инструкция содержит отдельные строки по веткам, и я сверяю нужную строку с фактическим источником и целевой версией.

Не забудьте о частях системы, которые обычно воспринимают как одну коробку. Zabbix хранит конфигурацию и историю в базе данных; веб-интерфейс отдельно требует PHP и поддерживаемый веб-сервер, например Apache или NGINX. Это второй полезный факт из экспертной базы: при подготовке перехода проверяют не только Zabbix Server, но также базу и веб-слой. Если сервер обновили, а frontend или используемые библиотеки остались несовместимыми, проблема будет выглядеть как «сломался Zabbix», хотя причина окажется на соседнем компоненте. Перед тестом выпишите также владельцев внешних интеграций и способ их проверки. Система может собирать значения, но перестать создавать заявку или отправлять сообщение из-за изменения API, сертификата либо конфигурации webhook. Отдельно проверьте свободное место для резервной копии и тестового восстановления: копия, которую некуда развернуть, пригодна только для успокоения. Zabbix — это сервер, база и интерфейс, но рабочий процесс обычно включает ещё получателей и сервисы вокруг них.

Проверьте собственные элементы обнаружения, сроки удаления потерянных объектов, зависимости триггеров и выражения, в которых используются агрегированные данные. Это не потому, что у RC2 подтверждены массовые дефекты LLD или trendavg: таких заявлений я не делаю. Просто эти места чувствительны к изменению поведения и чаще всего незаметно зависят от версии. В каталоге есть отдельные материалы о потерянных объектах LLD и функциях trendavg; используйте их для аудита текущей конфигурации, не выдавая за список багов версии 8.

Резервная копия должна быть не только создана, но и проверена восстановлением в отдельной среде. Выберите способ бэкапа под фактическую СУБД и её режим работы, сохраните конфигурацию сервера, прокси, frontend и пользовательские скрипты. Команды вроде mysqldump подходят не каждой установке и сами по себе не проверяют восстановление. Я также убрал из текста несуществующую рекомендацию запускать zabbix_server -R check_db_schema: такой проверки в официальном списке runtime-команд я не подтвердил. После восстановления проверьте, что приходят новые данные, история читается, триггеры вычисляются, а уведомления доходят до адресатов. Официальная инструкция предупреждает, что обновление базы до 8.0 может занять продолжительное время в зависимости от её размера. Поэтому нельзя честно обещать универсальные четыре или восемь часов для офиса с любым количеством истории. На тестовом восстановлении измерьте длительность подготовки, миграции и контрольных проверок, затем добавьте резерв на исправления. В производстве используйте ту же процедуру и те же пакеты, которые прошли прогон; импровизация в окно изменений быстро съедает запас времени.

Практический разбор: условная сеть «Юнона Групп»

Для разбора возьму условную сеть «Юнона Групп» из поля задания: 12 офисных серверов и 150 сетевых устройств под Zabbix 7.0 LTS. Это сценарий для планирования, не отчёт о реальном клиенте и не заявление, что я уже запускал RC2 на этой инфраструктуре. В исходных данных не указаны операционная система, тип базы и способ установки; я не буду дописывать за автора MySQL, PostgreSQL или Docker. Перед оценкой фиксирую точные версии этих компонентов и текущую сборку 7.0, иначе тест нельзя воспроизвести. При таком масштабе нет смысла строить испытательный кластер ради галочки, но отдельная копия системы нужна, чтобы проверить обновление базы, шаблоны и оповещения.

Сначала я фиксирую исходное состояние: сколько данных поступает в обычный и пиковый час, какие проверки самые частые, какие триггеры требуют ручного подтверждения, сколько места заняты историей и трендами. Затем составляю список серверов, сетевых устройств, прокси и нестандартных агентов. Для 150 устройств полезно выбирать тестовую группу по типам оборудования, а не брать первые десять хостов из списка: десять одинаковых коммутаторов не проверят шаблон маршрутизатора и пользовательский SNMP-профиль. Я фиксирую эти показатели до работ, чтобы после обновления сравнивать одно и то же с одним и тем же. Например, число устройств само по себе не показывает, насколько тяжёлый мониторинг: на двух одинаковых серверах могут отличаться интервалы опроса, число элементов и обработка логов. Для сетевой части в выборку попадут разные классы устройств, шаблоны и протоколы. Для серверной — обычные агенты и нестандартные проверки. Так тест отвечает на вопрос о конкретной конфигурации, а не о среднем Zabbix из чужой статьи.

Дальше поднимаю тестовую среду на поддерживаемых версиях компонентов, восстанавливаю копию базы и прохожу официальный путь обновления. На стенде сравниваю число активных хостов и элементов, свежесть последних значений, состояние очереди, открытые проблемы, графики и доставку тестовых уведомлений. Отдельно проверяю кастомные шаблоны и зависимости. Я не ищу «баги Zabbix 8» по заранее выдуманному списку; я проверяю, что важные функции именно этой системы после перехода дают тот же ожидаемый результат. В журнале испытания оставляю версии пакетов, время начала и конца каждого этапа, изменения конфигурации и результаты контрольных проверок. Если на стенде обнаружилась проблема, повторяю шаг на сохранённой копии и записываю условия воспроизведения; иначе невозможно понять, это ошибка перехода, особенности старого шаблона или случайный сбой тестовой среды. Так появляется полезный план для согласования окна и отката, а не фраза «вроде всё нормально» после одного входа в веб-интерфейс.

Результат разбора на 25 октября 2026 года — не переносить RC2 в рабочую среду и оставить Zabbix 7.0 LTS основным контуром. Для сценария окно проверки назначается после стабильного выпуска 8.0 и появления пакетов для фактической ОС; точную дату финального релиза официальный график пока не называет. В производственную среду переходим только после успешного восстановления копии, совместимости компонентов и согласованного времени работ. В исходной статье были придуманные потеря трендов и подавленный алерт о процессоре; я удалил эти результаты, потому что нет журналов теста и документации, которые подтверждали бы их.

• Снять исходные показатели и список компонентов
• Восстановить базу в тестовой среде
• Сверить хосты, данные, графики и оповещения
• Принять решение по результатам прогона

Когда переходить на Zabbix 8.0

Я бы не переводил рабочую систему на RC2. Для тестирования кандидат подходит; для продакшена дождитесь стабильного релиза, доступности нужных пакетов и документации по вашей схеме. После релиза не обязательно обновляться в первый же вечер: сначала сверьте список изменений и совместимость, затем проведите репетицию на копии. Это не суеверие про «первую патч-версию», а обычный контроль того, что база и внешние компоненты переживают изменение ожидаемо. Для первой стабильной версии я также смотрю, насколько быстро после выпуска появляются исправления и обновлённые пакеты для нужной операционной системы. Универсального правила «обязательно ждать номер .1» документация не задаёт, поэтому я не выдумываю дату и не обещаю отсутствие ошибок. Есть разница между технической возможностью обновиться и выгодой сделать это немедленно. Если команда понимает, что именно хочет получить, и прошла репетицию, решение принимается по риску и эффекту, а не по суффиксу версии.

Для Zabbix 7.0 LTS есть запас на планирование: полный срок поддержки заканчивается 30 июня 2027 года. Я бы использовал его, чтобы убрать устаревшие агенты, проверить базу и php-окружение, привести в порядок шаблоны и зафиксировать владельцев уведомлений. Если нужна возможность из восьмёрки для конкретного процесса, опишите этот сценарий заранее и оцените результат отдельно. Если новой функции никто не просил и действующая система исправно мониторит нужное, обновление ради номера версии просто добавит работы. Текущую систему можно использовать для подготовки ещё до выхода финала: собрать версии, проверить сроки хранения, освежить документацию на интеграции и проверить восстановление. Если видите агенты старых поколений, начните с них; если версия базы близка к минимально допустимой, заложите её обновление в общий план и отдельно проверьте её собственный путь. Иначе основное окно превратится в цепочку незапланированных изменений, а мониторинг станет последней проблемой в списке.

В рабочем окне сначала останавливают изменения конфигурации, проверяют доступность резервной копии и следуют процедуре для точного способа установки. После запуска новой версии контролируют журнал сервера, миграцию базы, значения ключевых элементов, открытые проблемы, работу прокси и отправку уведомлений. Переход считается завершённым не тогда, когда веб-страница открылась, а когда вернулись измеримые функции, ради которых система нужна. Если для отката пришлось бы просто вернуть старый бинарный файл, план не готов: после изменения схемы базы откат проектируют с учётом восстановления данных. Время простоя зависит от объёма и конфигурации хранилища, аппаратной площадки, числа компонентов и того, как устроен резервный контур. На стенде нужно не только засечь запуск, но и проверить, когда сервер снова принимает данные от proxy и agents и когда веб-интерфейс отражает новые значения. Это даёт обоснованное окно работ. Если проверка выявила необходимость восстановления, выполняйте именно согласованный сценарий восстановления базы и конфигурации; простая замена исполняемых файлов не вернёт прежнюю схему данных.

Мой выбор для большинства небольших систем на 7.0 LTS такой: сейчас — инвентаризация и проверка восстановления, после выхода стабильной 8.0 — тестовый прогон, затем отдельное окно для производства. Это достаточно решительно, чтобы не пропустить цикл поддержки, и достаточно спокойно, чтобы не оплачивать чужую спешку своими ночными дежурствами. Релиз — событие в календаре разработчика. Для администратора это начало проверки, а не команда нажать «обновить». Решение можно записать в двух строках: что выигрывает бизнес, если перейти, и что именно должно быть проверено до работ. Я считаю такую запись частью технического изменения, а не бюрократией: она не даёт спутать «вышел новый релиз» с «есть причина менять работающую систему». Если ответов пока нет, продолжаем подготовку и наблюдение за релизом. Когда ответы есть, назначаем ответственного, резервное время и проверку результата. Так даже короткое обновление становится управляемой задачей.

Частые вопросы