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

# تتبّع الطلبات

> اطّلع على كل طلب عالجه خادمك — مساره ومدته واستعلامات قاعدة البيانات والاستدعاءات الخارجية — وافتح الطلب الذي تسبّب في أي خطأ.

## ما الذي يقدّمه

يلتقط تتبّع الطلبات رحلة طلب HTTP عبر خدمة الخادم لديك: الطلب نفسه وكل
عملية أطلقها (استعلامات قاعدة البيانات، استدعاءات HTTP الخارجية، وما
تتتبّعه بنفسك)، مع توقيت وحالة كل خطوة. متاح لحزم SDK الخادم:
[NestJS](/ar/frameworks/nestjs/request-tracing) و[Python](/ar/frameworks/python/request-tracing)
و[ASP.NET](/ar/frameworks/aspnet/request-tracing).

الغاية ليست بيانات التوقيت بحد ذاتها، بل أن تفتح خطأً في لوحة التحكم فترى
فوراً الطلب الذي أنتجه — أي استعلام كان بطيئاً، وأي استدعاء خارجي فشل.

* **قوالب المسارات لا المسارات الخام.** يُسجَّل الطلب إلى `/users/42` باسم
  `GET /users/:id` (`/users/{user_id}` في Python و`/users/{id:int}` في
  ASP.NET). عشرة آلاف معرّف مختلف هي مسار واحد لا عشرة آلاف.
* **استعلامات قاعدة البيانات كنطاقات.** يُختزل SQL إلى قالب
  (`SELECT * FROM users WHERE id = ?`) قبل أن يصبح اسم نطاق؛ لا تُسجَّل
  معاملات الاستعلام ولا صفوفه أبداً.
* **الاستدعاءات الخارجية تحمل التتبّع.** تحصل استدعاءات HTTP إلى خدمة أخرى
  على ترويسة `traceparent` وفق معيار W3C؛ والخدمة اللاحقة التي تشغّل Lerix
  تواصل التتبّع نفسه، فيظهر الطلب العابر لخدمتين كشلال واحد.
* **الأخطاء ترتبط بطلبها.** كل تقرير خطأ يُرسل داخل طلب يحمل تتبّع ذلك
  الطلب، وتتبّع الطلب يربط بدوره إلى الخطأ.

## في لوحة التحكم

ضمن مشروع خادم، تعرض صفحة **الطلبات**:

| اللوحة | الغرض |
| - | - |
| **المسارات** | عدد الطلبات وعدد الأخطاء وزمن الاستجابة p50 / p95 / p99 لكل مسار خلال آخر ساعة أو يوم أو أسبوع. يُحسب **كل** طلب مهما كانت نسبة أخذ العينات. |
| **أكثر عناوين العملاء نشاطاً** | الطلبات لكل عنوان عميل (مقنَّع أو مُجزَّأ، انظر أدناه) لرصد إساءة الاستخدام. |
| **التتبعات المُعيَّنة** | أحدث الطلبات المحفوظة. افتح أحدها لترى **الشلال**: شجرة النطاقات بترتيب البدء مع أشرطة المدة؛ انقر نطاقاً لترى سماته. |

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

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

الاحتفاظ بكل نطاق من كل طلب غير ممكن عند الأحجام الكبيرة، لذا تحتفظ حزمة
SDK افتراضياً بـ **10% من الطلبات الناجحة** كاملةً، وتحتفظ **دائماً** بأي
طلب فشل أو تجاوز عتبة البطء (ثانيتان افتراضياً) أو أبلغ عن خطأ. يُتخذ القرار
مرة واحدة عند بدء الطلب ويرثه كل نطاق فرعي وكل خدمة لاحقة — فالتتبّع إما
كامل أو غائب، لا نصف ناقص.

مهما كانت النسبة، يُرسل النطاق الجذر لكل طلب مع علامة "غير مُعيَّن"، لذا
تحسب لوحة المسارات 100% من الحركة.

## مدة الاحتفاظ

تُحفظ النطاقات الخام 7 أيام، والتجميعات لكل مسار 90 يوماً.

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

عنوان عميل كل طلب بيانات شخصية، لذا فإن ما يحتفظ به Lerix منه خيار لكل
مشروع ضمن **إعدادات المشروع ← التتبّع**:

| الوضع | ما يُخزَّن |
| - | - |
| **مقنَّع** (الافتراضي) | تصفّر حزمة SDK آخر خانة من IPv4 ‏(`203.0.113.0`) أو تقتطع IPv6 إلى /64 **قبل الإرسال**. العنوان الحقيقي لا يغادر خدمتك أبداً. |
| **مُجزَّأ** | تجزئة مملَّحة يتغيّر ملحها يومياً: العميل نفسه يُميَّز خلال اليوم، لا عبر الأيام، ولا يمكن عكسه. |
| **كامل** | العنوان الحقيقي، يُحفظ 72 ساعة. تفعيله إجراء صريح يُسجَّل في سجل تدقيق مؤسستك مع مَن فعّله ومتى. |

كما تُضبط هناك طريقة قراءة العنوان: **عدد الوكلاء الموثوقين** (كم وكيلاً
يقف بين الإنترنت وخدمتك؛ 0 يعني أن النظير المباشر هو العميل) و**الترويسة**
التي يكتبونها (`X-Forwarded-For` افتراضياً). لا تُوثَق السلسلة كاملةً أبداً —
المدخلات اليسرى هي ما اختار العميل إرساله.

<Note>
  التتبّع **معطَّل افتراضياً** في كل حزم SDK ولا يُفعَّل إلا بخيار صريح. ترقية
  حزمة SDK لا تغيّر شيئاً لخدمة لم تفعّله.
</Note>


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