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

# Edge Functions — تتبّع الطلبات

> نطاق واحد لكل طلب، ونطاقات fetch الخارجية وقاعدة بيانات Supabase، وأخذ العينات، والتتبّع خلف كل خطأ — لدوال الحافة.

## مقدمة

بعد [التثبيت](/ar/frameworks/edge/installation)، فعّل تتبّع الطلبات لترى كل
استدعاء لدالتك ضمن **الطلبات** في لوحة التحكم، مع مساره ومدته واستدعاءات
قاعدة البيانات والطلبات الخارجية. ويمكنك أيضاً فتح الطلب الذي تسبّب في أي
خطأ. راجع [تتبّع الطلبات](/ar/modules/request-tracing) لما تعرضه لوحة التحكم.

## التفعيل

```ts theme={"dark"}
const lerix = Lerix.init({
  apiKey: Deno.env.get('LERIX_KEY')!,
  projectId: Deno.env.get('LERIX_PROJECT_ID')!,
  app: { id: 'orders' },
  tracing: { enabled: true },
});

Deno.serve(lerix.wrap(handler));
```

التتبّع معطَّل افتراضياً. وعندما يكون معطَّلاً لا تُعدَّل `fetch` ولا يُصَفّ أي
شيء.

## ما الذي يُسجَّل

* **نطاق خادم واحد لكل طلب مغلَّف**، باسم `METHOD /route`. المسار هو مسار
  الرابط بعد استبدال المقاطع التي تشبه القيم (`GET /orders/:id`). تُواصَل
  ترويسة W3C `traceparent` الواردة، فيظهر الطلب القادم من تطبيقك (أو من دالة
  أخرى) كتتبّع واحد.
* **`fetch` الخارجي**: يصبح كل استدعاء داخل الطلب نطاق `client` باسم
  `METHOD host` ويحمل ترويسة `traceparent`. تُتجاهل الاستدعاءات إلى Lerix API
  نفسها.
* **استدعاءات قاعدة بيانات Supabase**: تُسمّى الطلبات التي ترسلها supabase-js
  إلى PostgREST كنطاقات قاعدة البيانات: `select orders` و`insert orders`
  و`upsert orders` و`update orders` و`delete orders` و`rpc apply_discount`.
  المرشّحات (filters) موجودة في سلسلة الاستعلام ولا تُسجَّل أبداً.

عطّل خطاف `fetch` عبر
`tracing: { enabled: true, instrumentations: { fetch: false } }`.

وتتبّع أي شيء آخر يدوياً:

```ts theme={"dark"}
const pdf = await lerix.trace('render invoice', () => renderInvoice(order));
```

تضيف `lerix.trace()` نطاقاً فرعياً للطلب الحالي؛ وخارج الطلب المتتبَّع تكتفي
بتنفيذ الدالة.

## أخذ العينات

| الخيار | الافتراضي | الوصف |
| - | - | - |
| `sampleRate` | `0.1` | نسبة الطلبات الناجحة التي يُحفظ تتبّعها كاملاً |
| `slowThresholdMs` | `2000` | الطلبات الأبطأ من هذا تُحفظ كاملةً دائماً |
| `maxSpansPerRequest` | `1000` | النطاقات الفرعية التي تتجاوز هذا العدد تُسقط |
| `flushIntervalMs` | `10000` | المدة التي قد تنتظرها النطاقات الجذرية غير المشمولة بالعينة لتُرسل مع طلب لاحق |

يُتخذ قرار أخذ العينة مرة واحدة عند بدء التتبّع، وينتقل لاحقاً عبر
`traceparent`. الطلبات التي تفشل أو تتباطأ أو تبلّغ عن خطأ تُحفظ كاملةً
دائماً. ويُرسل النطاق الجذر **لكل** طلب، فتغطي أعداد المسارات ومعدلات
الأخطاء والنسب المئوية كل الحركة.

النطاقات الجذرية للطلبات غير المشمولة بالعينة تغذّي تلك العدّادات فقط، لذا
يُحتفظ بها في العازل (isolate) وتُرسل مع طلب لاحق بدلاً من تصدير منفصل لكل
استدعاء. أما ما شملته العينة أو ما فشل فيُرسل مباشرة بعد استجابته.

## التتبّع خلف الخطأ

الخطأ المُبلَّغ عنه داخل طلب متتبَّع يحمل معرّف تتبّعه. ترتبط صفحته في لوحة
التحكم بشلال الطلب، ويُحفظ ذلك التتبّع حتى لو كان أخذ العينات قد أسقطه.

## عنوان العميل

يُسجَّل عنوان العميل وفق إعدادات التتبّع في المشروع (مُقنَّعاً افتراضياً).
يوفّر `Deno.serve` وCloudflare (`cf-connecting-ip`) عنوان المتصل مباشرةً. أما
Supabase وVercel فيمرّرانه في ترويسة تمرير فقط: اضبط تلك الترويسة وعدد الوكلاء
(proxies) الموثوقين في إعدادات المشروع، وإلا فلن يُسجَّل أي عنوان.

## القيود

* تحتاج النطاقات الفرعية إلى `AsyncLocalStorage` لتجد طلبها. في Cloudflare
  فعّل `nodejs_compat`. وفي Vercel Edge تعتمد النطاقات الفرعية على إتاحة بيئة
  التشغيل `AsyncLocalStorage` كمتغير عام. وبدونه تحصل مع ذلك على نطاق الخادم لكل
  طلب، وتبقى الأخطاء مرتبطة به.
* لا تتقدّم الساعات في Cloudflare Workers إلا عبر عمليات الإدخال/الإخراج، لذا
  يظهر العمل الحسابي الخالص (CPU) هناك بمدة صفرية.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.