Как я возвращаю Zabbix proxy в норму после потери связи с площадкой

Как я восстанавливаю картину разрыва

В наших внедрениях я начинаю не с настройки буфера, а с временной линии. Фиксирую, когда центральная сторона отметила proxy как unavailable, продолжались ли локальные проверки и какие timestamps имеют последние values до и после разрыва. Состояние unavailable означает, что server давно не видел ожидаемое взаимодействие, но не доказывает остановку самого процесса на площадке. Если локальная база принимала результаты, после возврата связи появится долг на передачу; если сбор тоже прекратился, никакая выгрузка не восстановит несуществующие измерения. Я сопоставляю интерфейс, историю нескольких items, журнал proxy и назначение hosts, не раскрывая имена заказчика. Так определяется граница между потерей транспорта, паузой мониторинга и последующим backlog.

Active и passive proxy дают разные следы

Active proxy сам инициирует соединения к адресу server, запрашивает monitoring configuration и отправляет собранные данные. Поэтому я проверяю исходящий TCP-маршрут, Server в локальной конфигурации, имя proxy и TLS-параметры, а входящее подключение от server для этого режима не ожидаю. Passive proxy, наоборот, принимает обращения server: центральная сторона передаёт ему конфигурацию и забирает данные, поэтому существенны ListenIP, ListenPort, доступ к площадке и адрес интерфейса proxy в frontend. Направление соединения нельзя угадывать по слову «прокси». Я сначала подтверждаю режим в объекте и конфигурации, затем читаю журнал соответствующей стороны. Ошибка режима способна выглядеть как вечная недоступность, хотя процессы работают и локальные цели отвечают.

Что именно находится в proxy buffer

Proxy history — это собранные результаты с исходными отметками времени, ожидающие передачи или уже подготовленные к ней; proxy buffer показывает состояние хранения и остаток очереди внутри proxy. Я не смешиваю его с Queue на server. Серверная queue delay относится к проверкам, которые не выполнены к запланированному моменту, тогда как timestamp freshness отвечает на другой вопрос: насколько давно измерено показанное значение. После восстановления старые history records могут успешно прибывать с прежними timestamps, а новые проверки уже идти вовремя. Поэтому график визуально заполняется не одним скачком. Я смотрю, сокращается ли накопление, принимаются ли новые записи и движется ли верхняя граница времени; требовать одновременного появления всех данных технически неверно.

Порядок возвращения обмена с server

Причинная цепочка для меня строга: сначала возвращается сетевой и криптографический доступ, затем подтверждается синхронизация конфигурации, после этого data sender передаёт buffered data, и лишь по мере приёма уменьшается возраст наблюдаемых values. У active proxy частоту запроса конфигурации задаёт применимый для версии механизм и параметр ConfigFrequency; у passive proxy конфигурацию инициирует server. Я не ускоряю этот этап произвольным универсальным интервалом. Новое назначение host должно оказаться на нужном proxy до оценки его проверок, но накопленная ранее история может отправляться параллельно с текущим сбором. Если sender занят, это само по себе не авария: важны прогресс отправки, ответы server, ресурсы локальной базы и отсутствие повторяющегося отказа соединения.

Нагрузка без магической ручки NVPS

NVPS я использую как показатель потока новых values в секунду и контекст для нагрузки. Он помогает понять, пополняется ли backlog быстрее, чем освобождается, и отличается ли восстановительный период от обычного профиля площадки. Однако увеличение или уменьшение NVPS не лечит транспорт, блокировку записи, медленный server либо переполненное хранение. Рядом я наблюдаю proxy buffer, занятость data sender, CPU, дисковую задержку и ошибки локальной СУБД. ProxyLocalBuffer и ProxyOfflineBuffer не назначаю по привычке: сначала сверяю, доступны ли они в установленной 7.0 LTS или 7.4, каков точный синтаксис и как выбранный режим buffer трактует эти параметры. Изменение retention без расчёта свободного места создаёт новый риск вместо восстановления.

Безопасное чтение журнала и исключение доступа

Оператору достаточно роли Zabbix с read-доступом к Monitoring и Administration/Proxies в пределах нужных объектов, а на ОС — права непривилегированно читать разрешённый журнал и активную конфигурацию proxy. Я выбираю узкое временное окно и строки про connection, configuration sync, history data, data sender, TLS handshake и ошибки базы. Полные PSK, закрытые ключи, пароли БД, секретные макросы и содержимое сертификатных ключей не копируются. До гипотезы о backlog я исключаю более простые альтернативы: доступность TCP в правильном направлении, DNS-ответ из namespace proxy, согласованность времени, соответствие identity для PSK либо цепочки TLS. Это read-only inspection; изменение firewall, перезапуск службы и вывод конфигурации целиком в такую проверку не входят.

Изолированный тест потери канала

Поведение при обрыве я воспроизвожу только с отдельным proxy, небоевым сегментом или captive network, где тестовые hosts не обслуживают продукцию. Сначала фиксирую обычный сбор и успешный sender, затем меняю одну переменную: например, изолирую только маршрут к server, сохраняя доступ proxy к тестовой цели. После появления нескольких локальных результатов возвращаю прежний канал и наблюдаю порядок: доступ, configuration synchronization, buffered transmission, timestamps. В одном прогоне нельзя одновременно менять режим active/passive, параметры TLS и assignment hosts — причинность исчезнет. Тест прекращается при неожиданном воздействии на соседний контур, росте дискового риска или попадании production-объекта. Полученный профиль сравниваю с инцидентом качественно, без выдуманного обязательного порога.

Поэтапный ввод и доказанный откат

После подтверждения причины я возвращаю площадку стадиями. Сначала разрешаю обмен одного proxy и убеждаюсь, что server узнаёт его ожидаемым способом. Затем проверяю получение актуальной конфигурации и только после этого оцениваю разгрузку history, не подгоняя её массовыми проверками. Новые значения должны продолжать поступать, пока старые записи догоняют центральную базу. Если задержка растёт, sender повторяет ошибки или ресурсы выходят из рабочего профиля, я выполняю контролируемый rollback: восстанавливаю старое соединение, прежнюю конфигурацию и исходное assignment тестовых hosts. После отката обязательно подтверждаю ожидаемое поведение sender и отсутствие непредусмотренной смены маршрута. Метод заканчивается наблюдением возраста values и остатка buffer, а не первым статусом available.

Отвергнутые альтернативы

• Считать NVPS способом очистить накоплениеNVPS описывает интенсивность поступления новых values и помогает оценивать нагрузку, но сам по себе не ускоряет data sender, сеть, запись server или обработку history.
• Сразу перезапустить proxy и serverОдновременный рестарт стирает диагностическую последовательность, может оборвать текущую отправку и не отвечает, на каком этапе возникла задержка.
• Немедленно менять ProxyLocalBuffer и ProxyOfflineBufferЭти параметры рассматриваются только после проверки их наличия, синтаксиса и семантики для установленной версии; они задают хранение, а не исправляют потерянный доступ.
• Принять восстановленный TCP-сеанс за полное восстановление данныхПосле транспорта ещё следуют обмен конфигурацией, выгрузка накопленной истории и уменьшение возраста значений, поэтому зелёное соединение не завершает проверку.
• Списать весь хвост на сеть площадкиДо изменения производительности я отдельно исключаю DNS, маршрут TCP, рассинхронизацию времени и несовпадение PSK/TLS; затем проверяю серверный приём и локальную базу proxy.

Конфигурация и сбор

В frontend используется роль с правами чтения Monitoring и Administration/Proxies для разрешённых proxy и hosts. На ОС требуется только непривилегированное чтение конкретного журнала и эффективных несекретных строк конфигурации; доступ к PSK, private keys, паролям базы и secret macros не нужен.

• Зафиксировать режим active или passive, статус unavailable, Last seen и назначение hosts без изменения объекта.
• Сопоставить proxy buffer, proxy history, NVPS, data sender и timestamps характерных values на одной временной шкале.
• Прочитать разрешённые строки Server, Hostname, ConfigFrequency, ListenIP, ListenPort и TLS-режима; значения секретов не выводить.
• Проверять ProxyLocalBuffer и ProxyOfflineBuffer только по документации установленной версии и активному варианту хранения.
• Отфильтровать релевантные log lines по узкому окну для connection, configuration и history, сохранив исходные файлы неизменными.

Контролируемая проверка и свидетельство

Тест проводится с изолированным proxy, captive network либо небоевым сегментом. За один проход меняется только одна переменная, после чего отдельно фиксируются доступ, синхронизация конфигурации, работа data sender, уменьшение buffer и возраст values. Production hosts к эксперименту не привязываются.

Фрагмент рабочего регламента

• Подтвердить active/passive режим и требуемое направление TCP, не выполняя переподключение.
• Сверить DNS, route, time и результат PSK/TLS negotiation без чтения или копирования секретного материала.
• Сопоставить unavailable, configuration sync, proxy history, buffer и data sender с отметками времени.
• Разделить server queue delay и freshness последних values, затем наблюдать их независимо.
• Записать версию Zabbix и проверить синтаксис каждого обсуждаемого параметра по её официальной документации.

Откат

До теста фиксируются старое соединение, режим proxy, несекретные параметры конфигурации и исходное assignment hosts. При отрицательной динамике возвращаются прежний сетевой путь и конфигурационная привязка одним обратным изменением. Затем подтверждаются ожидаемое направление соединения, успешный configuration exchange, нормальная работа data sender и поступление values от тестовых объектов.

Ограничения вывода

Подход не обещает восстановить measurements, которые proxy не собрал во время недоступности, и не задаёт общего интервала, размера buffer или порога NVPS. Скорость разгрузки зависит от версии, режима proxy, локальной СУБД, канала, центрального server, объёма history и текущего потока. Параметры 7.0 LTS и 7.4 могут различаться, поэтому имя, доступность и смысл настройки подтверждаются перед применением.