Zabbix выпустила Zabbix 8.0 LTS: теперь платформа принимает данные приложений через OpenTelemetry, поддерживает ClickHouse для хранения истории и телеметрии, а также умеет связывать события и предоставлять доступ ИИ-агентам через MCP-сервер. Об этом сообщает Linuxiac со ссылкой на источник. Для команды, которая держит отдельно мониторинг серверов и наблюдаемость приложений, это повод проверить, какие данные теперь разумно анализировать вместе. Но не повод переносить всю историю и включать все функции за одно окно работ.
Что именно появилось в Zabbix 8.0 LTS
Главное изменение для эксплуатации — встроенный сбор трассировок, метрик и журналов приложений через OpenTelemetry. Приложение или существующий коллектор передаёт телеметрию прокси Zabbix по OTLP/gRPC. В веб-интерфейсе появился раздел APM для анализа этих данных, а новый тип элемента данных для запросов к телеметрии позволяет использовать результаты в графиках и триггерах. Трассировка здесь — запись пути запроса через компоненты приложения; она помогает понять, где именно возникла задержка, которую обычный график загрузки процессора не объясняет.
ClickHouse можно использовать как хранилище исторических значений мониторинга и телеметрии приложений. Разработчики заявляют ускорение до десяти раз за счёт новой схемы хранения и оптимизаций сервера, а также снижение нагрузки на процессор, дискового ввода-вывода и потребности в месте. Это заявленный результат, а не коэффициент, который стоит подставлять в бюджет своего ЦОД: выигрыш проверяют на собственном профиле данных.
Появился и механизм обработки связанных событий. Правила, в том числе с сопоставлением на JavaScript, позволяют анализировать события в заданном временном окне, группировать причины и симптомы и сокращать повторяющиеся оповещения. Через новый MCP-сервер совместимый ИИ-агент может получать данные мониторинга, изучать историю проблем, подтверждать оповещения, менять серьёзность проблемы и управлять периодами обслуживания. Действия ограничены правами пользователя Zabbix, назначенными API-токену агента.
Из менее заметного, но полезного в ежедневной работе: настраиваемые таблицы узлов, шаблонов и проблем; импорт и экспорт панелей в YAML, JSON и XML; новые шаблоны, включая Kubernetes, Proxmox VE и Microsoft Hyper-V. Для безопасности существенно, что доступ к API у ролей пользователей по умолчанию выключен, пока его явно не разрешат. Полная поддержка версии заявлена до 30 ноября 2029 года, ограниченная — до 30 ноября 2031 года. Анонсированное мобильное приложение для Android и iOS выйдет позже: в текущий план внедрения его закладывать рано.
Сценарий из эксплуатации: жалоба есть, причины пока нет
Представим обычную смену. Пользователи сообщают, что операция в приложении выполняется медленно. На панели инфраструктуры видны метрики сервера и сети, в системе журналов — ошибки приложения, а трассировки команда открывает отдельно. Дежурный вручную сопоставляет время, проверяет компоненты и получает несколько оповещений об одной цепочке неполадок. Даже когда данные собраны правильно, на их сопоставление уходит время.
В Zabbix 8.0 LTS можно проверить другую схему работы: прокси принимает телеметрию приложения, оператор смотрит её рядом с привычными показателями инфраструктуры, а правило обработки событий помогает отделить вероятную причину от сопутствующих симптомов. Здесь важно не обещать автоматический диагноз. Если приложение не передаёт пригодные трассировки или часы компонентов расходятся, единый интерфейс не устранит пробел в данных. Если правило корреляции слишком широкое, оно может скрыть отдельную проблему за общей группой.
Для ИТ-директора это вопрос не только удобства интерфейса. Когда одну и ту же неисправность разбирают несколько команд, полезно заранее договориться, кто отвечает за телеметрию приложения, кто — за Zabbix и кто утверждает правила подавления дублей. Для закупщика смысл в другом: новая функциональность способна изменить профиль нагрузки на серверы мониторинга и хранения. Решение о дополнительном оборудовании лучше принимать после пилота, а не по обещанию ускорения «до десяти раз».
Пилот, который даст ответ до закупки
Начните с инвентаризации потока данных. Зафиксируйте, какие приложения уже отправляют данные через OpenTelemetry, где стоят коллекторы, какие прокси Zabbix доступны и какие метрики инфраструктуры действительно нужны при расследовании инцидента. Выберите один типичный сервис и один сценарий отказа или замедления. Так проще увидеть пользу трассировок, не превращая пилот в перенос всей системы наблюдаемости.
- Проверьте приём. Передайте телеметрию через OTLP/gRPC на прокси Zabbix и убедитесь, что в APM видны нужные данные, а запросы к телеметрии дают результат для графиков и триггеров. Отдельно проверьте временные метки, полноту данных и поведение при разрыве связи. Размещение прокси и сетевые разрешения согласуйте с принятой в организации схемой доступа.
- Снимите базовые показатели хранения. До решения о ClickHouse измерьте объём поступающих данных, скорость записи, время выполнения рабочих запросов, нагрузку на процессор, дисковый ввод-вывод и фактический расход места. Сравнивайте одинаковые наборы данных и сроки хранения. Иначе улучшение может оказаться следствием того, что в пилоте просто собирали меньше телеметрии.
- Испытайте правила событий. Возьмите известную цепочку инцидента и проверьте, какие оповещения стали причиной, а какие — симптомами. Посмотрите не только на число сообщений дежурному, но и на то, не исчезло ли самостоятельное событие. Правила с JavaScript держите под контролем изменений: у них должен быть владелец и понятный способ проверки после правок.
- Разведите права. Проверьте роли и API-токены до подключения MCP-сервера. Начните с доступа к данным без права менять состояние проблем; подтверждение оповещений, смену серьёзности и периоды обслуживания разрешайте лишь там, где это действительно необходимо. Проверьте, как действия отражаются в аудите и кто сможет их пересмотреть.
- Проведите репетицию обновления. На испытательном контуре проверьте используемые шаблоны, собственные проверки, панели, прокси и интеграции. Подготовьте резервные копии, порядок переключения и критерии отката. Сохраните рабочие запросы и типовые инциденты для сравнения до и после перехода.
Для организаций в Казахстане к техническому пилоту стоит добавить обычную дисциплину закупки: сверить спецификации предлагаемых серверов и дисковой подсистемы с выбранной схемой хранения, запросить документацию по совместимости, условия гарантии и подтверждение сроков поставки. Требования к ресурсам формулируйте по результатам измерений, включая запас под рост данных и восстановление после отказа. Если пилот покажет, что нужна отдельная вычислительная ёмкость, конфигурации можно сопоставить в разделе серверов; выбирать модель до расчёта нагрузки преждевременно.
Где легко принять полезную функцию за готовое решение
ClickHouse не отменяет проектирование хранения. Определите, какие значения и телеметрию собираетесь хранить, на какой срок, как будете делать резервные копии и проверять восстановление. Отдельно испытайте запросы, которыми операторы пользуются во время аварии. Быстрая запись сама по себе не доказывает, что расследование останется быстрым при вашей структуре данных.
Корреляция событий зависит от качества правил. Группировка причин и симптомов полезна, пока дежурный может открыть исходные события и понять, почему они связаны. Проверяйте правила на случаях, где несколько неисправностей происходят одновременно. Если настройка даёт красивую тихую панель, но затрудняет поиск первопричины, её нужно пересмотреть.
ИИ-агент — ещё один пользователь с правами, а не эксперт без последствий. Возможность менять серьёзность и периоды обслуживания влияет на работу смены. Ограничивайте права токена, защищайте его хранение, фиксируйте ответственного за интеграцию и заранее решите, какие действия требуют участия человека. Выключенный по умолчанию доступ к API для ролей — хороший повод пересмотреть разрешения, а не механически включить их всем ради нового подключения.
Новые шаблоны и интерфейс тоже требуют проверки. Готовый шаблон сокращает ручную настройку, но его показатели и оповещения надо сверять с тем, как команда эксплуатирует конкретный узел. Панели теперь можно переносить в YAML, JSON и XML; после импорта проверьте привязки и права доступа. Мобильное приложение не используйте как обязательный канал дежурных оповещений при планировании перехода: его выпуск ожидается после версии 8.0.
Сначала измерить, потом объединять
Zabbix 8.0 LTS даёт практичный путь связать состояние инфраструктуры с данными приложений, но ценность этого пути покажет разбор реального инцидента на пилотном контуре. Проверьте поток телеметрии, нагрузку хранения, качество корреляции и права интеграций — после этого можно решать, что переносить в рабочую среду и какое оборудование потребуется. Если полезны такие разборы без рекламных обещаний, подписывайтесь на блог.