Skip to main content

​
Частота в реальном времени

Параметр frequency_minute управляет тем, как часто ваш монитор сканирует данные.
При frequency_minute: 0 Pubrio обнаруживает и доставляет сигналы по мере их появления — без опроса, без задержек.

​
Настройка повторных попыток

Когда доставка вебхука завершается ошибкой, повторные попытки помогают восстановиться автоматически.
Повторные попытки заново доставляют тот же payload — они не перезапускают обнаружение сигнала и не расходуют дополнительные кредиты поиска.

​
Повтор обработки (Process Retry)

Эндпоинт Process Retry позволяет повторно попытаться выполнить конкретную неудавшуюся доставку. Ключевые преимущества:
  • Нет платы за сбои — с вас не списываются кредиты, если доставка не удалась. Кредиты расходуются только при успешной доставке.
  • Диагностика — повторите неудавшуюся запись журнала, чтобы диагностировать проблемы с вебхуком без создания новых триггеров.
  • Опция исходного назначения — используйте is_use_original_destination, чтобы повторить попытку с снимком назначения из исходной записи журнала — это полезно, если вы обновили URL вебхука после сбоя.
Находите неудавшиеся доставки через Statistic Logs и повторяйте их по отдельности.

​
Обработка сбоев

Параметр max_failure_trigger (диапазон: 1-10, по умолчанию: 5) определяет, сколько последовательных сбоев доставки допускается, прежде чем монитор автоматически приостановится. Рекомендуемый подход:
  1. Установите notification_email, чтобы получать оповещения при возникновении сбоев
  2. Держите max_failure_trigger на уровне 3-5 для продакшн-мониторов
  3. Используйте Statistic Logs, чтобы диагностировать сбои — проверяйте error_message и response_status_code
  4. После устранения проблемы реактивируйте монитор через Update Monitor
  5. Используйте Process Retry, чтобы повторить попытку для конкретных неудавшихся доставок

​
Опрос через эндпоинты статистики

Пока вебхуки обеспечивают доставку в реальном времени, эндпоинты статистики предоставляют возможности мониторинга, отладки и аудита.

​
Опрос сводки

Используйте Monitor Statistics для проверки состояния на уровне дашборда:
Возвращает агрегированные метрики: общее число мониторов, количество триггеров сегодня и вчера, показатели успешности и сравнительные показатели.

​
Опрос на основе журналов

Используйте Statistic Logs, чтобы просмотреть историю триггеров:
Каждая запись журнала включает статус, расход кредитов, количество сигналов/компаний/людей, время обработки и детали ошибок.
Сочетайте доставку через вебхук с периодическим опросом журналов для максимальной надёжности: вебхуки обеспечивают обработку в реальном времени, а опрос журналов улавливает любые пропущенные доставки и предоставляет журнал аудита.

​
Рекомендации по масштабированию

Предпочитайте точечные мониторы избыточно широким. Монитор, отслеживающий «вакансии в сфере ИИ в крупных компаниях США», проще отлаживать, чем «все вакансии повсюду». Точечные мониторы также позволяют направлять разные типы сигналов на разные эндпоинты вебхуков.
Ваш эндпоинт вебхука должен:
  • Отвечать в течение 30 секунд
  • Немедленно возвращать 200 и обрабатывать данные асинхронно
  • Корректно обрабатывать дублирующиеся payload’ы (идемпотентность)
  • Логировать все входящие payload’ы для отладки
Используйте Get Monitor List с фильтрацией:
  • Фильтруйте по detection_mode и destination_type
  • Сортируйте по last_modified или last_trigger_at
  • Ищите по имени с помощью search_term
Используйте Monitor Statistics, чтобы быстро находить неэффективные мониторы.