> ## 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.

# أفضل الممارسات والاستطلاع الدوري

> حسّن إعداد Monitor لديك من أجل الموثوقية والأداء وكفاءة التسليم.

## التكرار في الوقت الفعلي

يتحكم المعامل `frequency_minute` في عدد مرات فحص Monitor.

| الإعداد             | السلوك                                                     | حالة الاستخدام                             |
| ------------------- | ---------------------------------------------------------- | ------------------------------------------ |
| **`0` (الافتراضي)** | **في الوقت الفعلي** — يتم رصد الإشارات وتسليمها فور ظهورها | معظم أنواع Monitor — أسرع تسليم ممكن       |
| `1 - 60`            | فاصل زمني ثابت بالدقائق                                    | عندما تريد وتيرة متوقعة                    |
| `60 - 1440`         | من كل ساعة إلى يومي                                        | ملخصات على شكل موجز، إشارات ذات أولوية أقل |

<Tip>
  عند ضبط `frequency_minute: 0`، يرصد Pubrio الإشارات ويسلّمها فور ظهورها — دون استطلاع دوري ودون تأخير.
</Tip>

***

## إعداد إعادة المحاولة

عند فشل تسليم Webhook، تساعد إعادة المحاولة على التعافي تلقائيًا.

| المعامل                 | النطاق | القيمة الافتراضية | التوصية                                      |
| ----------------------- | ------ | ----------------- | -------------------------------------------- |
| `max_retry_per_trigger` | 0 - 3  | 1                 | اضبطها على 2-3 لأنواع Monitor الحرجة         |
| `retry_delay_second`    | 1 - 5  | 1                 | استخدم 3-5 ثوانٍ للسماح بحل المشكلات المؤقتة |

<Note>
  تُعيد إعادة المحاولة تسليم الحمولة نفسها — لا تُعيد تشغيل رصد الإشارة ولا تستهلك رصيد بحث إضافيًا.
</Note>

***

## إعادة محاولة العملية (Process Retry)

تتيح لك نقطة النهاية [إعادة محاولة العملية](/ar/api-reference/endpoint/monitors/process_retry) إعادة محاولة تسليم فاشل محدد. الفوائد الرئيسية:

* **لا رسوم على الإخفاقات** — لا يُخصم منك رصيد عند فشل التسليم. يُستهلك الرصيد فقط عند نجاح التسليم.
* **استكشاف الأخطاء وإصلاحها** — أعد محاولة إدخال سجل فاشل لتشخيص مشكلات Webhook دون إنشاء عمليات تفعيل جديدة.
* **خيار الوجهة الأصلية** — استخدم `is_use_original_destination` لإعادة المحاولة باستخدام لقطة الوجهة من السجل الأصلي، وهو مفيد إذا كنت قد حدّثت رابط Webhook بعد الفشل.

اعثر على عمليات التسليم الفاشلة عبر [سجلات الإحصاءات](/ar/api-reference/endpoint/monitors/statistics_logs) وأعد محاولتها واحدة تلو الأخرى.

***

## معالجة الإخفاقات

يتحكم المعامل `max_failure_trigger` (النطاق: 1-10، الافتراضي: 5) في عدد إخفاقات التسليم المتتالية المسموح بها قبل أن يتوقف Monitor تلقائيًا.

**النهج الموصى به:**

1. اضبط `notification_email` لتلقّي تنبيهات عند حدوث إخفاقات
2. أبقِ `max_failure_trigger` بين 3-5 لأنواع Monitor في بيئة الإنتاج
3. استخدم [سجلات الإحصاءات](/ar/api-reference/endpoint/monitors/statistics_logs) لتشخيص الإخفاقات — تحقق من `error_message` و`response_status_code`
4. بعد إصلاح المشكلة، أعد التفعيل عبر [تحديث Monitor](/ar/api-reference/endpoint/monitors/update)
5. استخدم [إعادة محاولة العملية](/ar/api-reference/endpoint/monitors/process_retry) لإعادة محاولة عمليات تسليم فاشلة محددة

***

## الاستطلاع الدوري عبر نقاط نهاية الإحصاءات

بينما تتولى Webhooks التسليم في الوقت الفعلي، توفر نقاط نهاية الإحصاءات إمكانات المراقبة وتصحيح الأخطاء والتدقيق.

### استطلاع النظرة العامة

استخدم [إحصاءات Monitor](/ar/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>

يعيد مقاييس إجمالية: إجمالي عدد أنواع Monitor، وعدد التفعيلات اليوم مقابل الأمس، ومعدلات النجاح، ومعدلات المقارنة.

### الاستطلاع القائم على السجلات

استخدم [سجلات الإحصاءات](/ar/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>
  اجمع بين تسليم Webhook والاستطلاع الدوري للسجلات لتحقيق أقصى موثوقية: تتولى Webhooks المعالجة في الوقت الفعلي، بينما يلتقط الاستطلاع الدوري للسجلات أي عمليات تسليم فائتة ويوفر مسارًا للتدقيق.
</Tip>

***

## توصيات التوسّع

<AccordionGroup>
  <Accordion title="أنواع Monitor المركّزة مقابل الفلاتر الواسعة">
    **يُفضَّل استخدام أنواع Monitor مركّزة بدلًا من أنواع واسعة النطاق.** يسهُل تصحيح أخطاء Monitor يتتبع "وظائف الذكاء الاصطناعي في شركات المؤسسات الأمريكية" مقارنةً بـ "كل الوظائف في كل مكان". كما تتيح لك أنواع Monitor المركّزة توجيه أنواع مختلفة من الإشارات إلى نقاط نهاية Webhook مختلفة.
  </Accordion>

  <Accordion title="موثوقية نقطة نهاية Webhook">
    ينبغي أن تقوم نقطة نهاية Webhook لديك بما يلي:

    * الاستجابة خلال 30 ثانية
    * إعادة الرمز `200` فورًا ومعالجة البيانات بشكل غير متزامن
    * التعامل مع الحمولات المكررة بسلاسة (idempotency)
    * تسجيل جميع الحمولات الواردة لأغراض تصحيح الأخطاء
  </Accordion>

  <Accordion title="إدارة عدد كبير من أنواع Monitor">
    استخدم [الحصول على قائمة Monitor](/ar/api-reference/endpoint/monitors/monitors) مع التصفية:

    * صفِّ حسب `detection_mode` و`destination_type`
    * رتِّب حسب `last_modified` أو `last_trigger_at`
    * ابحث بالاسم باستخدام `search_term`

    استخدم [إحصاءات Monitor](/ar/api-reference/endpoint/monitors/statistics) للتعرف بسرعة على أنواع Monitor ذات الأداء الضعيف.
  </Accordion>
</AccordionGroup>