> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Лучшие практики и опрос (polling)

> Оптимизируйте настройку монитора для надёжности, производительности и эффективной доставки.

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

Параметр `frequency_minute` управляет тем, как часто ваш монитор сканирует данные.

| Настройка              | Поведение                                                                    | Сценарий использования                               |
| ---------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------- |
| **`0` (по умолчанию)** | **Реальное время** — сигналы обнаруживаются и доставляются по мере появления | Большинство мониторов — максимально быстрая доставка |
| `1 - 60`               | Фиксированный интервал в минутах                                             | Когда нужна предсказуемая периодичность              |
| `60 - 1440`            | От часового до суточного                                                     | Дайджест-сводки, сигналы низкого приоритета          |

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

***

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

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

| Параметр                | Диапазон | По умолчанию | Рекомендация                                                   |
| ----------------------- | -------- | ------------ | -------------------------------------------------------------- |
| `max_retry_per_trigger` | 0 - 3    | 1            | Установите 2-3 для критически важных мониторов                 |
| `retry_delay_second`    | 1 - 5    | 1            | Используйте 3-5 секунд, чтобы дать временным сбоям разрешиться |

<Note>
  Повторные попытки заново доставляют тот же payload — они не перезапускают обнаружение сигнала и не расходуют дополнительные кредиты поиска.
</Note>

***

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

Эндпоинт [Process Retry](/ru/api-reference/endpoint/monitors/process_retry) позволяет повторно попытаться выполнить конкретную неудавшуюся доставку. Ключевые преимущества:

* **Нет платы за сбои** — с вас не списываются кредиты, если доставка не удалась. Кредиты расходуются только при успешной доставке.
* **Диагностика** — повторите неудавшуюся запись журнала, чтобы диагностировать проблемы с вебхуком без создания новых триггеров.
* **Опция исходного назначения** — используйте `is_use_original_destination`, чтобы повторить попытку с снимком назначения из исходной записи журнала — это полезно, если вы обновили URL вебхука после сбоя.

Находите неудавшиеся доставки через [Statistic Logs](/ru/api-reference/endpoint/monitors/statistics_logs) и повторяйте их по отдельности.

***

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

Параметр `max_failure_trigger` (диапазон: 1-10, по умолчанию: 5) определяет, сколько последовательных сбоев доставки допускается, прежде чем монитор автоматически приостановится.

**Рекомендуемый подход:**

1. Установите `notification_email`, чтобы получать оповещения при возникновении сбоев
2. Держите `max_failure_trigger` на уровне 3-5 для продакшн-мониторов
3. Используйте [Statistic Logs](/ru/api-reference/endpoint/monitors/statistics_logs), чтобы диагностировать сбои — проверяйте `error_message` и `response_status_code`
4. После устранения проблемы реактивируйте монитор через [Update Monitor](/ru/api-reference/endpoint/monitors/update)
5. Используйте [Process Retry](/ru/api-reference/endpoint/monitors/process_retry), чтобы повторить попытку для конкретных неудавшихся доставок

***

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

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

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

Используйте [Monitor Statistics](/ru/api-reference/endpoint/monitors/statistics) для проверки состояния на уровне дашборда:

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{ "profile_id": 1 }'
  ```
</CodeGroup>

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

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

Используйте [Statistic Logs](/ru/api-reference/endpoint/monitors/statistics_logs), чтобы просмотреть историю триггеров:

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics/logs \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{
      "profile_id": 1,
      "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "page": 1,
      "per_page": 10
    }'
  ```
</CodeGroup>

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

<Tip>
  Сочетайте доставку через вебхук с периодическим опросом журналов для максимальной надёжности: вебхуки обеспечивают обработку в реальном времени, а опрос журналов улавливает любые пропущенные доставки и предоставляет журнал аудита.
</Tip>

***

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

<AccordionGroup>
  <Accordion title="Точечные мониторы vs широкие фильтры">
    **Предпочитайте точечные мониторы избыточно широким.** Монитор, отслеживающий «вакансии в сфере ИИ в крупных компаниях США», проще отлаживать, чем «все вакансии повсюду». Точечные мониторы также позволяют направлять разные типы сигналов на разные эндпоинты вебхуков.
  </Accordion>

  <Accordion title="Надёжность эндпоинта вебхука">
    Ваш эндпоинт вебхука должен:

    * Отвечать в течение 30 секунд
    * Немедленно возвращать `200` и обрабатывать данные асинхронно
    * Корректно обрабатывать дублирующиеся payload'ы (идемпотентность)
    * Логировать все входящие payload'ы для отладки
  </Accordion>

  <Accordion title="Управление большим числом мониторов">
    Используйте [Get Monitor List](/ru/api-reference/endpoint/monitors/monitors) с фильтрацией:

    * Фильтруйте по `detection_mode` и `destination_type`
    * Сортируйте по `last_modified` или `last_trigger_at`
    * Ищите по имени с помощью `search_term`

    Используйте [Monitor Statistics](/ru/api-reference/endpoint/monitors/statistics), чтобы быстро находить неэффективные мониторы.
  </Accordion>
</AccordionGroup>