Как реализовать джобы с разной частотой выгрузки данных из Zabbix

Что проверяют

Умеете ли вы работать с Zabbix API без лишней нагрузки на сервер мониторинга и строить планировщик, где задачи не наслаиваются и не теряют данные. Следом спрашивают, как не получить дыр и дублей после перезапуска джоба.

Как отвечать

Сначала разделите задачи по природе данных, от этого зависит и частота, и метод API:

• сырые значения за короткий период: history.get с time_from и time_till, параметр history задаёт тип значения (число, строка, лог);
• агрегаты за час: trend.get, он легче для дашбордов и отчётов за недели;
• проблемы и события: problem.get, event.get;
• справочники (хосты, элементы данных): host.get, item.get раз в сутки или по изменению, с узким output вместо extend.

Авторизация: API-токен из интерфейса Zabbix вместо логина паролем на каждом запуске. В свежих версиях токен передают заголовком Authorization: Bearer, а параметр user в user.login давно заменён на username. Удобная обёртка: официальная библиотека zabbix_utils, у неё есть и асинхронный клиент.

Планировщик: APScheduler 3.x с IntervalTrigger и CronTrigger, у каждой задачи max_instances=1, coalesce=True и misfire_grace_time. Список джобов лучше держать в конфиге: имя, метод, параметры, интервал. Если сервис запущен в нескольких экземплярах, нужна блокировка или отдельный планировщик: Celery beat, Airflow, CronJob в Kubernetes.

Главное в каждой задаче это водяной знак: храните clock последней выгруженной записи и начинайте следующий запуск с него, с небольшим перекрытием и идемпотентной записью по ключу «элемент, время».

Где спотыкаются

Вызывают history.get без окна по времени и без фильтра по элементам. Запрос ложится на базу Zabbix и тормозит сам мониторинг.

Логинятся на каждый запуск и не делают user.logout. Сессии копятся, а пароль лежит в коде.

Используют библиотеку schedule в одном потоке: долгая выгрузка блокирует все остальные задачи, а после падения процесса пропущенные запуски никто не восполнит.