Сервер отвечает, свободная память есть, а заказ в интернет-магазине оформляется слишком долго. Обычного графика нагрузки для объяснения такой проблемы недостаточно: нужно увидеть, как запрос проходит через приложение, базу данных и внешние сервисы. На этот уровень диагностики нацелена Zabbix 8.0 LTS, которую латвийский разработчик выпустил 5 ноября. В новой версии появились мониторинг производительности приложений через OpenTelemetry, хранение истории в ClickHouse, обработка связанных событий и подключение ИИ-помощников через MCP.
Обозначение LTS означает длительный срок сопровождения. Для 8.0 полная поддержка заявлена до 30 ноября 2029 года, ограниченная — до 30 ноября 2031-го. Программа распространяется по AGPLv3; коммерческое применение само по себе не требует покупки лицензии. Платные услуги сопровождения и управляемое облако — отдельный выбор.
Что OpenTelemetry добавляет к привычным графикам
APM, или мониторинг производительности приложений, помогает разбирать работу программ изнутри. OpenTelemetry задаёт открытый способ собирать такую телеметрию: числовые показатели, журналы и трассировки. Последние показывают путь отдельного запроса и длительность его этапов. Для администратора это возможность перейти от сообщения «сайт медленный» к поиску конкретного участка ожидания.
В Zabbix 8.0 эти данные можно просматривать в разделах APM: Traces, Metrics и Logs. Они читают телеметрию непосредственно из настроенного источника; создавать отдельный элемент данных для каждой записи не нужно. Если же результат запроса к телеметрии требуется использовать в графике или условии срабатывания, предусмотрен новый тип элемента Telemetry query.
При приёме телеметрии есть важное архитектурное ограничение: сервер Zabbix сам не принимает поток OpenTelemetry. Для этого нужен Zabbix proxy с включённым APM либо соответствующий коллектор OpenTelemetry, записывающий данные в источник. В документации новой версии таким источником выступает ClickHouse. Поэтому установка обновления не превратит любое приложение в наблюдаемое: нужно настроить передачу телеметрии и проверить, какие сведения она действительно содержит.
Например, трассировка может показать, что основная задержка заказа приходится на обращение к внешнему сервису, а не на процессор веб-сервера. Польза возникает, когда команда видит связанные этапы запроса, сопоставляет их с инфраструктурными показателями и может проверить гипотезу о причине задержки.
ClickHouse меняет работу с историей
История мониторинга быстро растёт: чем больше устройств и чем чаще опрос, тем больше значений нужно записывать и затем читать. В 8.0 ClickHouse можно использовать для хранения истории элементов данных. Для существующей базы MySQL или PostgreSQL разработчик публикует отдельные средства переноса истории. Это самостоятельный этап миграции, а не автоматическое последствие обновления Zabbix.
При переносе истории нужно учитывать несколько ограничений. Zabbix не рассчитывает и не хранит в ClickHouse trends — агрегированные исторические показатели. Обычная служба очистки Zabbix также не удаляет оттуда данные: срок хранения (TTL) задаётся в самом ClickHouse. В приведённой разработчиком схеме по умолчанию это 31 день. Если организации нужны месяцы подробной истории, это надо учесть при настройке и оценке ёмкости.
ClickHouse не поддерживается как хранилище обычной истории прокси, хотя прокси с APM может использовать его как источник телеметрии. Таким образом, ClickHouse заменяет лишь определённую часть хранения в распределённой системе. До перехода стоит определить, какие данные туда направляются, как долго живут и кто отвечает за их резервирование.
На странице новинок компания заявляет десятикратный рост производительности. Эффект в конкретной установке зависит от объёма истории, интервалов опроса, дисков и характера запросов. На своей нагрузке стоит проверить, сколько данных система принимает, как быстро открывает нужные графики и что происходит при отказе узла хранения.
Меньше отдельных тревог, больше контекста
Новый механизм CEP (complex event processing, комплексная обработка событий) обрабатывает события по правилам. Он может рассматривать их в заданном временном окне, группировать, добавлять контекст и менять серьёзность. Документация приводит, например, повышение серьёзности события при большом числе ответов 401 за минуту. Можно также объединять связанные события, обозначая первое как причину, а последующие как симптомы.
Для дежурной команды смысл прост: несколько уведомлений об одном развивающемся сбое желательно рассматривать вместе. Но порядок поступления событий сам по себе не доказывает действительную причину сбоя. Связь «причина — симптомы» здесь задаётся логикой обработки; полезность результата зависит от условий, временного окна и качества исходных событий. Подавление шума необходимо проверять так, чтобы вместе с повторениями не исчезало отдельное важное предупреждение.
MCP-сервер решает другую задачу: даёт ИИ-помощнику доступ к инструментам Zabbix через Model Context Protocol. Можно, например, запросить список неподтверждённых проблем или поручить подготовку изменения режима обслуживания. Доступ определяется учётной записью и правами Zabbix; сам факт подключения модели не делает её администратором.
Особенно важно, как подтверждаются изменения. Если MCP-клиент поддерживает form elicitation — форму запроса согласия, — пользователь видит конкретное изменение и одобряет его до отправки. Если такой поддержки нет, документация предупреждает о немедленном применении изменений без этого диалога. Поэтому для первого подключения разумен отдельный токен с минимальными правами и ограниченным набором инструментов.
Как готовить переход, а не просто менять пакеты
Документация допускает прямое обновление до 8.0.x с версий начиная с 2.0.x. Это совместимость пути обновления, а не разрешение пропустить промежуточные замечания. Для старой установки нужно прочитать изменения всех затрагиваемых версий и проверить внешние интеграции.
Минимальные требования выросли: для MySQL или Percona нужна версия 8.4.0, для MariaDB — 10.11, для PostgreSQL — 15.0; веб-интерфейсу требуется PHP 8.2. Конкретные верхние границы и сопутствующие компоненты перечислены в таблице требований. Отдельно проверяется совместимость прокси: полноценная работа предполагает ту же основную версию, что у сервера. Более старые поддерживаемые прокси работают с ограничениями, в том числе без обновления конфигурации. Прокси версий, выпущенных раньше предыдущей LTS-ветки, сервер уже не поддерживает.
В официальной инструкции для Debian и Ubuntu перед заменой пакетов предусмотрены остановка сервера и копирование базы данных, конфигурации, PHP-файлов и бинарных файлов. Для рабочей системы к этому нужен проверенный порядок восстановления. Размер базы влияет на длительность обновления. У SQLite-прокси есть отдельная особенность: при обнаружении старой схемы его база может быть пересоздана, что удалит накопленную в ней историю. Это нужно учесть до обслуживания удалённой площадки, а не после потери буфера.
Практичный первый шаг — воспроизвести переход на копии своей установки: проверить приём данных, уведомления, права, интеграции и восстановление из резервной копии. Новые APM, CEP и MCP затем можно подключать под отдельные задачи. Такой порядок позволяет отличить проблему самой миграции от ошибки в новом сценарии сбора или обработки данных.
Доступно русскоязычное сообщение о выпуске. Мобильное приложение пока только анонсировано и появится позже. Новая LTS-ветка расширяет наблюдение за приложениями, но требует заранее спланировать хранение истории и границы автоматизации.
Новинки Zabbix 8.0 · APM · ClickHouse · Обработка событий CEP · MCP-сервер
Переход на новую версию · Требования · Порядок обновления Debian/Ubuntu · Сроки поддержки · Лицензия
Изображения: Zabbix LLC; официальный обзор Zabbix 8.0.
🟦