Как я настраиваю мониторинг Plesk в Zabbix и готовлю перенос сайтов

Введение

Когда панель Plesk открывается, это ещё не доказывает, что пользователь получает сайт. И наоборот: сайт может отвечать из кэша, пока control plane, почта, cron или резервное копирование уже требуют вмешательства. Поэтому я разделяю внешний результат и внутренние причины. Независимый Zabbix-проверяющий идёт по цепочке DNS → TLS → HTTP → приложение, а агент на Linux объясняет состояние web stack, PHP-FPM, базы, хранилища, почты и фоновых задач.

Я с командой использую эту же наблюдаемость для подготовки переноса. До копирования фиксируем состав subscriptions, PHP handlers, systemd units, mountpoints и внешние зависимости; после копирования теми же проверками сравниваем старый и новый origin. Такой подход не превращает Plesk control plane в главный индикатор доступности и не позволяет зелёному процессу скрыть ошибку пользователя.

Ниже — проектная спецификация, а не импортируемый шаблон. Я закрепляю документацию на Zabbix 7.0 LTS, но сначала подтверждаю фактически установленную поддерживаемую версию. Пути, unit names, MTA, СУБД и схема nginx/Apache различаются; все placeholders заменяются только после инвентаризации и проверки прав.

К разделу: Monitoring | Plesk Obsidian documentation; (Plesk for Linux) Monitoring Plesk Services With Watchdog | Plesk Obsidian documentation; Web monitoring items | Zabbix documentation 7.0; Introduction | Plesk Obsidian documentation

1. Начинаю с инвентаризации Plesk Obsidian for Linux

Я строю карту не по названию панели, а по обслуживаемым контрактам. Для каждой subscription фиксирую домены и aliases, document root, IP-привязку, сертификат, DNS ownership, PHP version и handler, базы и пользователей, почтовые домены, scheduled tasks, backup policy и внешние интеграции. Отдельно отмечаю server-wide настройки: repositories, firewall, fail2ban, custom service configuration, extensions и всё, что не относится к переносимому контенту subscription.

На Linux я сверяю реальные процессы и units. В одном окружении домен идёт nginx → Apache → PHP-FPM, в другом nginx обслуживает FPM напрямую; dedicated FPM создаёт отдельные pools. Наличие nginx или Apache в списке процессов само по себе не раскрывает маршрут конкретного vhost. Я связываю domain → listener → vhost → upstream/socket → handler и только затем создаю items.

Безопасная первичная сверка выполняется командами чтения: plesk version; plesk bin subscription --list; plesk bin php_handler --list; systemctl --type=service --state=running; findmnt --output TARGET,SOURCE,FSTYPE,OPTIONS; df -hT; df -ih. Вывод может содержать внутренние имена, поэтому в статью и историю item его целиком не отправляю. Команды не меняют конфигурацию, но требуют разрешённого административного scope.

К разделу: System Services | Plesk Obsidian documentation; Choosing the PHP Handler | Plesk Obsidian documentation; subscription: Subscriptions | Plesk Obsidian CLI Reference for Linux; php_handler: PHP Handlers | Plesk Obsidian CLI Reference for Linux

2. Развожу внешний контроль, Plesk Monitoring и Watchdog

Plesk Monitoring полезен для ресурсов сервера, а Watchdog на Plesk for Linux способен наблюдать службы и диски, уведомлять и при настройке перезапускать службы. Я рассматриваю их как локальные инструменты, а не как замену независимому Zabbix. Если сервер, сеть или сама панель недоступны, внешний наблюдатель всё равно должен увидеть пользовательский отказ.

Control plane получает отдельную проверку панели: DNS/TLS/HTTP с разрешённой точки и без попыток входа. Сайты получают собственные web scenarios. Зависимость события панели от узловой недоступности может убрать шум, но событие публичного сайта я не делаю симптомом панели: неисправность Plesk не обязана означать outage сайта, а исправная панель не подавляет пользовательскую недоступность.

Автоматический restart в Watchdog включаю только после отдельного решения: понятна причина, ограничена частота, есть журналирование и исключён restart loop. Для Zabbix в этой схеме базовый режим — оповещение и диагностика. Изменяющие действия не маскируют первичный сигнал и не запускаются из примеров статьи.

К разделу: Monitoring | Plesk Obsidian documentation; (Plesk for Linux) Monitoring Plesk Services With Watchdog | Plesk Obsidian documentation; Web monitoring items | Zabbix documentation 7.0

3. Узел, файловые системы и systemd: сначала данные, затем пороги

Для каждого значимого mountpoint собираю bytes и inode отдельно. Штатные agent keys vfs.fs.size[{#FSNAME},free], vfs.fs.size[{#FSNAME},pused], vfs.fs.inode[{#FSNAME},pfree] дают разные типы и единицы; я не смешиваю байты, проценты и количество inode. Discovery фильтрую по реально используемым локальным и сетевым файловым системам и отмечаю назначения: web, mail, database, logs, backup repository и временное пространство Migrator.

Для Agent 2 использую подтверждённую схему systemd.unit.info[<unit>,ActiveState]: item имеет тип значения Text и получает строку. Для ActiveState документация перечисляет active, reloading, inactive, failed, activating, deactivating; только их включаю в value map, оставляя неизвестную строку видимой для диагностики. Это не числовой state из JSON ключа systemd.unit.get. Unit names сначала получаю из inventory; nginx.service — пример, а не универсальное имя. Проверка zabbix_agent2 -t 'systemd.unit.info[nginx.service,ActiveState]' допустима только после подтверждения бинарника и unit, ничего не меняет.

Collection interval и freshness — разные условия. Значение может быть последним известным и выглядеть нормальным после остановки collector. Поэтому отдельно проверяю supported state/item error и nodata() с macro, превышающей нормальный интервал и допустимую задержку proxy. Порог диска задаю парой абсолютного остатка и процента, а окно и значения macros получаю из baseline роста, политики capacity и времени на реакцию, без универсальной магической цифры.

К разделу: Zabbix agent | Zabbix documentation 7.0; Zabbix agent 2 | Zabbix documentation 7.0

4. Внешняя цепочка DNS → TLS → HTTP → приложение

IT Fresh

Web scenario запускаю с независимого Zabbix server или proxy, который не находится на самом Plesk-узле. Для каждого шага фиксирую URL, expected status codes, required string и timeout. Сохраняю стандартные items сценария: response time, response code и failed step. 200 без устойчивого маркера может быть страницей заглушки, ошибкой неверного vhost или ответом CDN; required string выбираю стабильную и не содержащую персональные данные.

TLS не отключаю. Для проверки нового origin до DNS switch использую документированный curl --resolve: curl --fail-with-body --show-error --silent --resolve 'www.example.test:443:192.0.2.20' 'https://www.example.test/health-page'. www.example.test и 192.0.2.20 — placeholders. URL сохраняет hostname, поэтому curl передаёт правильный Host и SNI и проверяет сертификат; -k/--insecure не применяю. Endpoint выбираю read-only, а ответ проверяю по status и содержимому.

Accepted DNS change не равен фактическому маршруту. Я отдельно наблюдаю authoritative answers, несколько recursive perspectives, A и AAAA. IPv6 способен оставить часть пользователей на старом origin, даже когда A уже изменён. External outage остаётся самостоятельным событием: зависимости могут приглушить вторичные PHP/DB симптомы, но не должны скрывать сам пользовательский отказ.

К разделу: Web monitoring items | Zabbix documentation 7.0; curl man page — --resolve

5. Web stack и PHP-FPM: процесс жив, приложение не отвечает

IT Fresh

Я проверяю варианты маршрута отдельно: nginx → Apache → PHP-FPM и nginx → PHP-FPM. Для каждого домена подтверждаю Plesk PHP handler. Переключение handler или схемы обслуживания — изменение конфигурации вне диагностики; его сначала проверяют на изолированном новом origin. При nginx-served FPM отдельно тестирую правила, которые раньше зависели от .htaccess, потому что nginx их не интерпретирует.

Уровень процесса включает ActiveState units, proc count и ресурсы, но пользовательский контракт подтверждает только HTTP. Если включён локально защищённый FPM status endpoint, собираю active processes, idle processes, текущий listen queue и накопительный max children reached: последний равен нулю, пока лимит процессов ни разу не достигался, и становится не меньше единицы после достижения. Из Text/JSON master зависимыми items извлекаю неотрицательные Numeric values. Для накопительного счётчика строю delta/rate или тревогу по приросту за окно, а не вечное условие >0; уменьшение после рестарта pool считаю reset и не трактую как отрицательную нагрузку. Не делаю curl напрямую к Unix socket FPM: это FastCGI, не HTTP. Status endpoint публиковать наружу нельзя; доступ ограничивается loopback или доверенным collector через правильно настроенный web-server location.

Диагностическая корреляция выглядит так: процесс active, но required string отсутствует; одновременно растут HTTP latency и FPM listen queue — вероятно насыщение или застрявшие workers. Если FPM спокойно отвечает, а DB latency растёт, иду к базе. Это не автоматический диагноз: событие показывает совпавшие сигналы, а operator проверяет логи и изменения.

К разделу: Choosing the PHP Handler | Plesk Obsidian documentation; Zabbix agent 2 | Zabbix documentation 7.0; PHP: Status Page - Manual

6. База данных: официальный template и минимальные права

Для MySQL/MariaDB или PostgreSQL выбираю официальный Zabbix integration/template, совместимый именно с Zabbix 7.0 LTS, Agent 2/plugin и установленной СУБД. MySQL и MariaDB не считаю полностью взаимозаменяемыми без проверки требований template. Мониторинговая учётная запись получает только права, перечисленные официальным template; сетевой доступ ограничивается нужным host/socket, а секрет хранится в защищённой конфигурации или secret macro, не в item key, argv или статье.

Минимальная карта включает availability, лёгкий read-only connect/query, connections и лимит, running threads, slow/long queries и locks по поддерживаемой схеме, размер данных и признаки I/O. Репликационные items добавляю только при реальной репликации. Data type и units задаю явно: connections — unsigned count, latency — seconds или milliseconds с одним соглашением, utilization — numeric float в процентах.

До переноса фиксирую engines, encodings/collations, extensions и server modes. Число баз и таблиц — контроль полноты, но не доказательство согласованности. Живой datadir через rsync не копирую: для БД применяю поддерживаемый механизм Plesk Migrator или согласованный backup/replication workflow с точкой консистентности и отдельной проверкой восстановления.

К разделу: MySQL monitoring and integration with Zabbix; PostgreSQL monitoring and integration with Zabbix

7. Почта и cron: считаю не только очередь, но и возраст

Plesk for Linux может использовать разные поддерживаемые MTA/IMAP-компоненты, а почта домена может быть внешней. Поэтому я сначала определяю реальный authoritative mail route, MX и владельца сервиса. Для локальной почты наблюдаю systemd units, SMTP/IMAP TLS с разрешённых точек, queue count, oldest message age и ошибки доставки. Большая очередь после рассылки и одна старая застрявшая запись — разные ситуации; count без oldest age недостаточен.

Парсер очереди — custom item, если официального штатного ключа нет. Я прямо помечаю custom.mail.queue.count и custom.mail.queue.oldest_age как проектные ключи обёртки, фиксирую MTA/version, код возврата, тип Numeric (unsigned) и единицы messages/seconds. Обёртка работает с минимальными правами, не печатает адреса и темы и становится unsupported при ошибке разбора, а не возвращает ложный ноль.

Для каждого критичного cron/scheduled task нужен контракт run/result/freshness. Custom wrapper сохраняет timestamp последнего запуска, нормализованный неотрицательный exit status и timestamp последнего успеха в защищённом state-файле; Zabbix читает только эти поля. custom.cron.last_run, custom.cron.last_result, custom.cron.last_success_age — проектные custom keys, не штатные agent items. nodata() проверяет доставку, а age — давность успеха; это разные тревоги.

К разделу: System Services | Plesk Obsidian documentation; Zabbix agent | Zabbix documentation 7.0

8. Резервные копии: last success не заменяет restore proof

Я собираю результат последней backup job, время успешного завершения, возраст, ожидаемое назначение и доступность repository. Custom collector не объявляю штатным ключом Zabbix. Если он читает логи или метаданные Plesk, схема фиксируется для конкретной версии, ошибки парсинга переводят item в unsupported, а чувствительные имена не уходят в history.

Файл ожидаемого размера и статус success подтверждают только этап создания. Доказательство восстановления — отдельная периодическая restore verification в изолированное место: открыть выбранные файлы, восстановить тестовую базу под другим именем, выполнить read-only проверки и удалить тестовые ресурсы по одобренной процедуре. Статья не даёт production-команд restore, потому что они зависят от хранилища и могут перезаписать данные.

Для миграционного gate я требую свежий успешный backup и актуальное restore proof, но не обещаю, что backup автоматически покрывает server-wide конфигурацию, внешнюю почту или DNS. Эти области входят в inventory и отдельный план восстановления.

К разделу: Backing Up and Restoration | Plesk Obsidian documentation; Zabbix agent | Zabbix documentation 7.0

9. Карта items, freshness и триггеров Zabbix

Ниже я фиксирую интерфейс мониторинга. Строки custom.* — проектные ключи, которые нужно реализовать и проверить отдельно; остальные сопоставляю с документацией Zabbix 7.0. Макросы порогов и окон заполняю по baseline конкретной системы. Items supported и freshness проверяются отдельно от значения, чтобы ошибка collector не стала нулём.

Примеры выражений используют placeholder host PLESK-LINUX; при переносе их заменяет реальное имя template/host. Выражение внешнего outage не ставлю в зависимость от Plesk panel. Симптомы PHP/DB можно сделать зависимыми от доказанной недоступности узла или collector: пока parent в PROBLEM, dependent trigger не переоценивается, его состояние не меняется, actions не выполняются и notifications не отправляются; после выхода parent из PROBLEM нужна новая метрика dependent item, поэтому обновление может быть не мгновенным. Такая dependency не исправляет данные и не должна скрывать самостоятельный внешний outage сайта.

Матрица элементов

Матрица триггеров

К разделу: Trigger expression | Zabbix documentation 7.0; Trigger dependencies | Zabbix documentation 7.0; Web monitoring items | Zabbix documentation 7.0

10. Pre-check Migrator и матрица совместимости

До первого копирования я запускаю предусмотренный Plesk Migrator pre-check и разбираю каждое предупреждение. Сверяю поддерживаемые source/target platforms, версии Plesk, ОС, extensions, PHP versions/handlers, databases, disk capacity, network reachability и требуемые credentials. Новый сервер держу изолированным от публичного трафика и исходящей почты, пока проверки не завершены.

Migrator переносит выбранные accounts/subscriptions и их контент, а для некоторых пар Plesk также предлагает отдельные категории server-wide settings, но не является клоном сервера. По документации отдельно фиксирую выбранные категории и проверяю непереносимые настройки и прочие исключения: установленные PHP handlers, Fail2Ban, ModSecurity, firewall, сторонние приложения/расширения, настройки вне выбранных объектов и внешние зависимости. Не формулирую собственный универсальный список — итоговый scope беру из параметров запуска, отчёта pre-check и документации для конкретной пары платформ.

Матрица содержит domain/subscription, PHP handler и extensions, web routing, DB engine/version/collation, mail location, DNS owner/A/AAAA/MX, certificates, scheduled tasks, mountpoints, backup target, external APIs и наблюдаемые проверки. Строка получает owner, evidence и решение: compatible, remediated, consciously excluded или blocker.

К разделу: Introduction | Plesk Obsidian documentation; Migrating via the Plesk Interface | Plesk Obsidian documentation; Choosing the PHP Handler | Plesk Obsidian documentation

11. Основная копия, final delta и один writer

Первичный перенос выполняю средствами Plesk Migrator в изолированную цель. После него сравниваю inventory и запускаю сайт через --resolve, не меняя публичный DNS. Повторная синхронизация Migrator полезна для изменившегося контента, но я не называю её транзакционной гарантией: отдельно планирую базы, uploads, mailboxes и очереди.

Для выбранного файлового каталога безопасная репетиция выглядит так: rsync -aHAXn --itemize-changes /source/path/ user@new-host:/destination/path/. -n означает dry-run; --delete отсутствует. Пути, trailing slash, ACL/xattrs и права проверяются заранее. Команду нельзя применять к datadir работающей СУБД, и она не обещает консистентность изменяемых файлов.

Перед final delta я закрываю новые writes согласованным способом: maintenance/read-only gate приложения, остановка только утверждённых workers или другой механизм владельца сервиса. В каждый момент writer один. Затем выполняется поддерживаемая дельта БД/файлов, отдельная mail delta с учётом очереди и доставки, контрольные суммы/счётчики по допустимой схеме и gate. Публичное переключение запрещено, если старый и новый узлы способны независимо принимать несогласованные записи.

К разделу: Migrating via the Plesk Interface | Plesk Obsidian documentation; rsync(1) manual page

12. Переключение DNS и проверка фактического маршрута

TTL уменьшаю заранее у authoritative DNS owner и жду прежний TTL перед cutover. Низкий TTL не делает обновление мгновенным: caches, клиенты и промежуточные системы могут удерживать старые ответы. Я документирую владельца зоны и точный набор записей, включая A, AAAA, CNAME, MX и связанные mail-настройки. Изменение принимает только уполномоченный владелец DNS.

Decision gate проверяет: pre-check закрыт; final delta завершена; один writer подтверждён; новый origin проходит TLS без отключения проверки, HTTP status/required string/time, PHP/DB/storage/mail/cron checks; backup свежий и restore proof актуален; rollback route согласован. Только после этого владелец меняет DNS.

После accepted change я проверяю authoritative answer и несколько recursive resolvers, но главным доказательством остаётся фактический traffic. На старом и новом origin наблюдаю access logs, writes, mail queue и ошибки. Остаточный трафик на старом сервере ожидаем до истечения caches; старый узел не выключаю и не делаю вторым writer.

К разделу: BIND 9 Administrator Reference Manual — Configuration Reference; curl man page — --resolve; Appendix A: Post-Migration Checks | Plesk Obsidian documentation

13. Откат после divergence — это работа с данными, а не только DNS

IT Fresh

Критерии rollback определяю до переключения: неустранимый пользовательский outage, нарушение целостности данных, критическая несовместимость или невозможность удержать единственного writer. Если новых записей на новом узле ещё нет, возврат проще: остановить новые writes, подтвердить отсутствие divergence, вернуть writer ownership старому и только затем вернуть маршрут.

Если новые записи уже появились, безопасного автоматического отката DNS нет. Сначала останавливаю writes на новом, диагностирую различия, выбираю согласованную reverse delta или reconciliation для БД, uploads и mail, проверяю полноту и только затем назначаю writer старому узлу. Два активных writer запрещены. Иногда безопаснее устранить неисправность на новом сервере, чем возвращать трафик с потерей данных.

Возврат DNS также проверяю по authoritative/recursive answers, A и AAAA и остаточному traffic. Старый сервер сохраняет мониторинг, конфигурацию и данные до завершения окна приёмки; его удаление не является частью rollback и выполняется позже отдельным change.

К разделу: BIND 9 Administrator Reference Manual — Configuration Reference; Appendix A: Post-Migration Checks | Plesk Obsidian documentation; rsync(1) manual page

14. Приёмка: теми же сигналами доказываю результат

После переключения мы с командой идём снаружи внутрь: authoritative и recursive DNS; TLS/SNI и redirect chain; web scenario со status, required string, response time и failed step; новый origin через --resolve; web stack и PHP-FPM; read-only DB check; bytes/inodes; mail delivery и queue count/oldest age; cron run/result/freshness; backup job и restore evidence. Затем сверяем post-migration checks Plesk по сайтам, почте, DNS, базам и системным пользователям.

Параллельно проверяю здоровье самого мониторинга: Agent 2 items supported, нет неожиданных nodata, clocks/proxy queue в допустимом состоянии, custom parsers возвращают ошибки как unsupported, а не как нули. Dependencies уменьшают каскад уведомлений, но корневые события пользователя, единственного writer и свежести данных остаются видимыми.

Для меня качественный перенос завершён не в момент изменения DNS, а когда новый маршрут, данные и побочные системы подтверждены, старый traffic сошёл, а команда может выполнить согласованный rollback без split-brain. Если не получается самостоятельно настроить мониторинг Plesk в Zabbix или подготовить безопасный перенос сайтов, обращайтесь ко мне: [Telegram @ITfresh_Boss](https://t.me/ITfresh_Boss), [+7 903 729-62-41](tel:+79037296241), [ITfresh.ru](https://itfresh.ru/).

К разделу: Appendix A: Post-Migration Checks | Plesk Obsidian documentation; Trigger dependencies | Zabbix documentation 7.0