Что проверить, когда Zabbix ломается после апдейта

После обновления Zabbix я сначала проверяю связь агента с сервером, затем журнал миграции базы и только после этого — пороги триггеров. Так проще отличить реальный сбой от несовпавших настроек TLS, неподходящей версии PHP или истёкшего API-токена. Ни REINDEX, ни очистка веб-файлов не должны быть первым движением.

Агент не подключается: проверьте направление и TLS

Я начинаю не с фразы «после обновления Zabbix включил обязательный TLS», а с реальных настроек. Это утверждение неверно. Если нужна отдельная настройка мониторинга Zabbix, я начинаю с версии и агента, а не с переустановки. В документации Zabbix 6.4 для агента без дополнительных параметров шифрование по умолчанию не используется. TLSConnect задаёт шифрование исходящих активных проверок, а TLSAccept — входящих пассивных. На стороне узла в интерфейсе Zabbix тоже должен быть выбран совместимый режим. Сверяю обе стороны отдельно: один и тот же PSK или согласованные сертификаты, тот же тип проверки и совпадающие параметры. Смешать активную и пассивную схему легко; после этого агент может быть «жив», но данные не приходят.

Для условной сети «Вертикаль» я беру 30 узлов и начинаю с одного тестового: сверяю параметры, проверяю доступность, затем переношу подтверждённую конфигурацию на остальные 29. У стандартных настроек разные направления: при пассивной проверке сервер подключается к агенту на TCP 10050; при активной агент сам обращается к серверу или прокси, обычно на TCP 10051. Открывать оба порта во все стороны не нужно — сначала определите режим и разрешите только нужный поток. Итог пилота — список конкретных настроек и правило межсетевого экрана для этого режима. Порт — это направление движения, а не талисман от ошибок.

Пользовательские метрики проверяю отдельно от TLS. В конфигурации агента параметр UserParameter связывает ключ с командой, например UserParameter=<key>,<shell command>; дополнительные файлы можно подключить через Include и шаблон пути. Так команды остаются в отдельной конфигурации, а главный файл проще сравнить до и после обновления пакета. Путь к файлу Include зависит от установки, поэтому я не копирую /etc/zabbix/zabbix_agentd.conf как универсальный адрес. Сначала сверяю, какой конфигурационный файл читает именно установленная служба, затем проверяю ключ на одном узле и только после этого обновляю шаблон мониторинга.

При обновлении пакета я также фиксирую точную версию агента и проверяю, какой конфигурационный файл читает запущенная служба. Одного наличия файла с нужной строкой недостаточно: Include может указывать на другой каталог, шаблон пути может не совпасть ни с одним файлом, а служебный пользователь может не иметь права его прочитать. Команда из UserParameter выполняется в контексте агента, поэтому скрипт, который рассчитывал на интерактивную оболочку или права root, после переноса может вести себя иначе. Проверяю это на тестовом хосте и записываю фактический результат ключа до раскатки.

• Сверьте TLSConnect для активных проверок.
• Сверьте TLSAccept для пассивных проверок.
• Проверьте режим шифрования узла в интерфейсе.
• Сравните UserParameter и подключённые файлы Include.

PostgreSQL: дождитесь миграции и читайте журнал

Обновление сервера Zabbix может сопровождаться обновлением схемы базы. Для штатного перехода сервер применяет обязательные изменения схемы при запуске, когда старая версия схемы ниже требуемой; порядок пакетов и исходников различается, поэтому я сверяюсь с процедурой именно для выбранного способа установки. Перед работой делаю копию базы и проверяю, что её действительно можно восстановить. Затем сверяю версии сервера, PostgreSQL и дополнительных расширений, если они используются. Запуск обновлённого сервера — часть миграции, а не доказательство, что база уже готова: даю ей завершиться и проверяю журнал сервера на сообщение об окончании и на первую ошибку.

Здесь особенно опасно лечить незнакомую ошибку знакомой командой. В штатной процедуре обновления Zabbix нет универсального шага REINDEX DATABASE, а эта команда не меняет схему Zabbix и не возвращает потерянные значения истории. Если PostgreSQL сообщает об ошибке индекса, сначала сохраняю точный текст, версию базы, состояние диска и сведения о том, какая операция выполнялась. После этого выбираю адресное восстановление по документации PostgreSQL и планирую его с учётом нагрузки. SELECT * FROM dbversion и поиск файла в одном жёстко заданном каталоге логов не заменяют проверку фактической версии, хода миграции и журналов на конкретной системе. REINDEX не кнопка «починить всё».

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

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

• Перед обновлением проверьте восстановление копии базы.
• Следуйте процедуре для способа установки и ветки Zabbix.
• Дождитесь завершения миграции и сохраните журнал сервера.
• Не запускайте REINDEX без конкретной ошибки индекса.

Триггеры шумят: проверяйте значение, а не догадку

После обновления я не предполагаю, что функция last() внезапно поменяла смысл. Она возвращает самое новое значение элемента; отсутствие периода не превращает его в ноль. Запись last(#3) означает третье по свежести значение, а не «последние три». Поэтому при неожиданном алерте я открываю историю элемента, смотрю время и само полученное значение, затем читаю выражение триггера целиком. Если элемент перешёл в неподдерживаемое состояние или данные давно не приходили, это отдельная проблема сбора; подменять её порогом CPU или отключением уведомлений нельзя. Если интересует отдельный разбор ложного порядка подавления связанных событий, см. гонку зависимостей Zabbix 7.4.

Дальше сравниваю версию шаблона, выражение триггера и фактические макросы на узле. Значение макроса может быть переопределено на уровне хоста или группы; поэтому я ищу не только глобальный {$CPU_WARN}, но и источник итогового значения. При массовом обновлении экспортирую шаблоны до изменения и сравниваю их с импортируемыми, а не полагаюсь на память администратора. Зависимость триггеров уместна, если один подтверждённый сбой действительно объясняет другой; она не исправляет сбор метрики. Severity обозначает важность события, но не является фильтром шума. Если сигналов стало меньше только потому, что всё выключили, мониторинг просто перестал рассказывать новости. Для другой ситуации — когда значение регулярно повторяется без изменения, — полезен разбор heartbeat при неизменном значении. Это соседняя настройка сбора, а не повод менять порог триггера.

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

Для оценки после обновления я беру один понятный элемент, нахожу его реальные значения в истории и вручную прохожу по ним выражение триггера. Затем сравниваю расчёт с состоянием события и с тем, что получает адресат уведомления. Если цифры совпадают, а писем всё равно слишком много, смотрю уже условия действий и список получателей, не подменяя диагностику снижением Severity. Если цифры не совпадают, возвращаюсь к элементу, его времени сбора и итоговому макросу. Такая проверка разделяет три разные задачи: сбор данных, вычисление события и доставку оповещения; исправление каждой начинается в своём месте.

• Откройте историю значения и время последней проверки.
• Проверьте итоговое значение макроса на хосте.
• Сравните выражения и версии шаблонов.
• Добавляйте зависимость только между связанными событиями.

Веб-интерфейс не отвечает: проверьте связку компонентов

Сообщение «Zabbix server is not running» само по себе не доказывает, что виноваты статические файлы. Веб-интерфейс — отдельная часть установки: ему нужны подходящие веб-сервер и PHP, а серверу мониторинга — доступная база данных. Проверяю состояние каждого компонента и его журнал, затем убеждаюсь, что веб-часть обращается к нужному экземпляру Zabbix Server. Путь к журналу, каталогу файлов и имя службы зависят от способа установки и дистрибутива; копировать одну строку из чужой инструкции в рабочую систему опасно. Кеш браузера проверяю позже, если факты указывают именно на выдачу старых статических файлов.

В исходном тексте было написано, будто Zabbix 6.4 требует PHP 8.2 и что PHP 7.4 не совместим. Это неверно: таблица требований Zabbix 6.4 указывает диапазон PHP 7.4.0–8.3.x, причём поддержка PHP 8.3 добавлена начиная с 6.4.11. Это пример для конкретной ветки, а не общая рекомендация обновить PHP до той же цифры на любом Zabbix. Я открываю таблицу требований именно установленной ветки и сверяю с ней PHP и расширения. После этого проверяю связь frontend с сервером и базой, а не удаляю содержимое каталога вроде /usr/share/zabbix/assets/*: такая команда может снести файлы, но не исправит недоступный сервер или неверное подключение к базе.

Я не меняю одновременно PHP, права каталогов, конфигурацию веб-сервера и кеш: после четырёх изменений невозможно понять, какое из них помогло, а какое добавило новую неисправность. Сначала сохраняю текущие настройки и определяю, отвечает ли сам сервер Zabbix и может ли frontend к нему подключиться. Затем проверяю версию PHP вместе с необходимыми расширениями и только после этого меняю один компонент за раз. Перезапуск имеет смысл, если изменён его конфиг или пакет; перезапуск всего набора служб «на всякий случай» не объясняет первопричину. Имя службы и путь к журналу беру из фактической установки, а не из чужой команды для другого дистрибутива.

Я записываю точное время ошибки в интерфейсе и сопоставляю его с журналом той части системы, которая её обслуживала. Сообщение в браузере, ошибка PHP и остановка процесса Zabbix Server — не один и тот же симптом, даже если на экране они выглядят одинаково тревожно. После изменения проверяю ту же страницу и тот же запрос, а результат фиксирую до следующего шага. Если веб-часть заработала после перезапуска, это подтверждает восстановление, но ещё не объясняет первопричину; её нужно записать отдельно, иначе следующий пакетный апдейт повторит историю. Не превращаю успешный рестарт в доказательство, что виноват кеш.

• Проверьте версии Zabbix, PHP и веб-сервера по одной матрице.
• Читайте журналы frontend, PHP и Zabbix Server.
• Проверьте адрес подключения frontend к серверу и базе.
• Очищайте кеш только после подтверждения его роли.

API-токены и AllowRoot: проверьте, что именно они разрешают

API-токен в Zabbix назначен конкретному пользователю и наследует его роль и разрешения. У токена может быть срок действия; потерянный или истёкший токен действительно потребует отдельной проверки. Но отсутствие ограничения по IP не объясняет автоматическую недействительность после обновления: сначала смотрю, включён ли токен, не истёк ли он, кому назначен пользователь, какие у него права и разрешён ли нужный метод API. Если токен приходится заменить, фиксирую, какие интеграции его используют: после генерации нового значения старое перестаёт работать. Права проверяю на тестовом запросе с минимально достаточной ролью, а не выдачей Super admin «на пять минут» — такие пять минут любят задерживаться.

Параметр AllowRoot в конфигурации сервера тоже трактовали неправильно. Он определяет, разрешён ли процессу Zabbix работать от root; значение по умолчанию — 0. Если сервер запускают от root при AllowRoot=0, он пытается перейти на системного пользователя zabbix. Это настройка учётной записи процесса, а не способ получить доступ к базе данных «через root» и не замена отдельной роли PostgreSQL. Я сверяю пользователя службы, DBName, DBPassword и права базы независимо друг от друга. После обновления отдельно проверяю API и вход в интерфейс; успешный вход под Super admin не доказывает, что обычные рабочие роли сохранились.

API-токен нельзя посмотреть повторно после закрытия формы создания, поэтому новое значение сразу сохраняю в хранилище секретов, а не в заметке или истории терминала. Для интеграций я предпочитаю отдельную техническую учётную запись с минимально необходимой ролью и доступом только к нужным объектам. Перед заменой токена проверяю, где он используется, обновляю секрет на стороне интеграции и делаю контрольный вызов; старое значение отзываю после проверки или немедленно, если оно утекло. Так ошибка авторизации превращается в конкретную проверку учётной записи и секрета, а не в массовый сброс прав всем пользователям.

Перед проверкой интеграций составляю короткий список: назначенный пользователь, роль, срок токена, имя системы-получателя и ответственное лицо. У каждой интеграции должен быть понятный владелец; общий токен Super admin скрывает, какая именно система делает запрос и какие права ей действительно нужны. Сначала выполняю безопасную проверку чтения, затем — только нужную рабочую операцию. Если создаю замену, проверяю её отдельно, обновляю секрет в системе-получателе и отмечаю, когда отозвал старое значение. Так можно быстро вернуть одну интеграцию и не устраивать массовую ротацию токенов, которая ломает сразу несколько связей.

• Проверьте статус, срок и владельца API-токена.
• Сверьте роль пользователя и разрешения нужного API-метода.
• Проверьте пользователя службы и DBName/DBPassword отдельно.
• Выполните контрольный запрос с минимальными правами.

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