November 5, 2026
|
5 min read
تزويد SCIM: لماذا يُعد إلغاء التزويد الجزء الذي يخطئ فيه الجميع
Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
ما هو SCIM في الواقع
SCIM هو اختصار لـ "نظام إدارة الهوية عبر النطاقات". وهو معيار مفتوح — المخطط في RFC 7643، والبروتوكول في RFC 7644 — يحدد واجهة برمجة تطبيقات REST لنقل بيانات الهوية بين الأنظمة. الإصدار 2.0 هو ما يطبقه كل مزود هوية رئيسي.
النموذج الذهني أبسط من الاختصار نفسه. مزود الهوية (IdP) هو العميل، والتطبيق التابع هو الخادم. يحتفظ مزود الهوية بقائمة من الأشخاص والمجموعات، وعندما تتغير هذه القائمة، يقوم بإجراء طلب HTTP للإعلان عن ذلك.
يحدد SCIM مجموعتين من الموارد، ويستند البروتوكول بأكمله إليهما:
وتتوافق دورة الحياة مع أفعال HTTP العادية:
الصف قبل الأخير هو الأهم. يمتلك SCIM طريقة قياسية ومباشرة لقول لم يعد لهذا الشخص حق الوصول — وتلك الإشارة تنبع من المكان الذي يتم فيه تسجيل مغادرة أي شخص بالفعل، وهو نظام الهوية المعتمد على الموارد البشرية، وليس جدول بيانات يديره قسم تكنولوجيا المعلومات.
SCIM ليس SSO، والفرق جوهري
يجيب SSO على سؤال واحد عند تسجيل الدخول: هل هذا الشخص هو من يدعي أنه هو، في هذه اللحظة؟ يصل تأكيد SAML أو رمز OIDC، ويتحقق التطبيق منه، ثم تبدأ الجلسة.
يجيب SCIM على سؤال بشكل مستمر: هل يجب أن يكون هذا الشخص موجوداً هنا على الإطلاق؟ يعمل البروتوكول وفق جدول زمني خاص به، بغض النظر عما إذا كان هناك شخص ما يقوم بتسجيل الدخول أم لا.
الفجوة بين هذين الأمرين هي جوهر المشكلة. إذا قمت بتشغيل SSO مع إنشاء الحسابات في الوقت الفعلي (JIT) دون أي شيء آخر، فإن مزود الهوية الخاص بك يحمي الباب الأمامي بينما تتراكم الحسابات خلفه إلى الأبد. صحيح أن إلغاء تفعيل شخص ما في مزود الهوية يمنع عمليات تسجيل الدخول الجديدة، لكن كائن الحساب يظل موجوداً، ومرتبطاً بكل الأدوار والعضويات، والأهم من ذلك — وهو ما يمثل خطورة على منصات الذكاء الاصطناعي — بكل مفاتيح واجهة برمجة التطبيقات ورموز الخدمة التي جمعها.
لماذا يعد إلغاء التزويد الجزء الذي يخطئ فيه الجميع
عملية الإلحاق (Onboarding) فشلها واضح ومزعج، بينما عملية إنهاء الخدمة (Offboarding) فشلها صامت. هذا التباين يفسر تقريباً كل نتائج مراجعات الوصول التي رأيناها على الإطلاق.
لا أحد يشتكي من صلاحيات وصول لا ينبغي أن يمتلكها. عندما يتعطل توفير الوصول، يرسل مهندس جديد تنبيهاً عبر القناة خلال عشرين دقيقة. أما عندما يتعطل إلغاء التوفير، يكون المستفيد قد غادر المؤسسة بالفعل. لا توجد حلقة تغذية راجعة، لذا يظل الخلل قائماً حتى يكتشفه المدقق أثناء الفحص.
قوائم التحقق اليدوية لإنهاء الخدمة تتقادم وتفقد فعاليتها. تُكتب قائمة التحقق عندما تكون الشركة تستخدم ثماني أدوات برمجية (SaaS). وبعد عامين، يصبح لديها ستون أداة، بينما لا تزال القائمة تحتوي على ثماني فقط.
فترة بقاء الحسابات المعلقة طويلة جداً. ولأن المشكلة لا تظهر للسطح، تُقاس فترة بقاء الحسابات المهجورة عادةً بالأشهر، ولا يتم اكتشافها إلا أثناء التدقيق أو وقوع حادث أمني — وهما أسوأ توقيتين لاكتشافها.
في منصات الذكاء الاصطناعي، الحساب المهجور يعني أكثر من مجرد تسجيل دخول. يمكن ربط سجل مستخدم قديم ببيانات اعتماد مزود النموذج، أو الوصول إلى خادم MCP، أو أحمال العمل المنشورة، أو مفاتيح API طويلة الأمد. تنتهي جلسات المتصفح تلقائياً، لكن بيانات الاعتماد البرمجية لا تنتهي. ولهذا السبب يجب أن تكون مصادقة API والتحكم في الوصول المستند إلى الأدوار (RBAC) في بوابة الذكاء الاصطناعي مدركة للهوية بدلاً من الاكتفاء بإدراك المفاتيح؛ فالمفتاح الذي لا يملك صاحباً هو مفتاح لن يقوم أحد بإلغائه أبداً.
يعمل بروتوكول SCIM على إزالة التدخل البشري. يتم تسجيل المغادرة مرة واحدة في مزود الهوية (IdP)، ثم تنتشر العملية تلقائياً إلى الخارج.
SCIM مقابل JIT مقابل الدعوات فقط: أي نمط توفير يجب استخدامه؟
تدعم TrueFoundry ثلاثة أنماط لتوفير الوصول، ويستخدم المستأجر نمطاً واحداً فقط في كل مرة. هذا هو القرار الذي تحاول معظم الفرق اتخاذه فعلياً عندما تبحث عن SCIM.
هناك ثلاث نقاط رئيسية يمكن استخلاصها من هذا الجدول.
نمط JIT ليس مجرد نسخة خفيفة من SCIM. إنه يمثل نصف SCIM فقط — النصف المرئي. فهو يتعامل مع حاجة شخص جديد لحساب بشكل جيد وبدون أي إعدادات. لكنه لا يفعل شيئاً حيال مغادرة الموظف. إذا كان سبب اختيارك لـ JIT هو "سنتعامل مع إلغاء التوفير يدوياً"، فحدد بوضوح من المسؤول عن هذه الخطوة وكيف سيتم تدقيقها.
خيار "الدعوات فقط" ليس خياراً أسوأ، بل هو خيار مختلف. بالنسبة لمقاول في شركة شريكة ليس له سجل في مزود الهوية الخاص بك، فإن الدعوة هي الآلية الصحيحة. المشكلة تكمن في استخدامها للموظفين الذين هم موجودون بالفعل في مزود الهوية الخاص بك، لأن ذلك يجعل مسؤولي النظام لديك مجرد نسخة يدوية من نظام تدفع ثمنه بالفعل.
مزامنة المجموعات هي العنصر الذي يقلل الناس من أهميته. يؤدي إنشاء المستخدمين تلقائياً إلى توفير بضع دقائق عند تعيين كل موظف جديد. أما مزامنة المجموعات فهي ما يضمن دقة الصلاحيات بمرور الوقت، وهي تكلفة مستمرة وليست لمرة واحدة.
أخطاء تقع فيها الفرق
التعامل مع تسجيل الدخول الموحد (SSO) كأداة لإلغاء التوفير. هذا هو الخطأ الأكثر شيوعاً، وهو أمر مفهوم لأن تعطيل مستخدم في مزود الهوية (IdP) يمنع عمليات تسجيل الدخول الجديدة. لكن ما لا يفعله هو حذف الحساب أو عضوياته في المجموعات أو أي بيانات اعتماد يمتلكها. فإغلاق الباب الأمامي ليس كإغلاق الحساب تماماً.
أسماء المجموعات التي تفشل في المزامنة دون تنبيه. لكل نظام توفير قيود على التسمية، وعادة ما يتم تسمية مجموعات مزود الهوية من قبل أشخاص لم يقرأوا هذه القيود. فالمجموعة المسماة "ML Platform — Prod (EMEA)" تحتوي على مسافة وشرطة طويلة وأقواس، ولن تصبح فريقاً صالحاً في الأنظمة التابعة. يحدث الفشل بصمت: تتم مزامنة المستخدمين بينما لا تتم مزامنة المجموعة، ولا يلاحظ أحد ذلك حتى يسأل أحدهم عن سبب خلو الفريق.
افتراض أن بروتوكول SCIM يصل إلى كل صلاحية يمتلكها الشخص. يقوم SCIM بمزامنة المستخدمين وعضويات المجموعات، لكنه لا يعرف شيئاً عن الأذونات الممنوحة مباشرة خارج أي مجموعة على مورد معين. إذا قمت بإزالة شخص ما من فريق، فستظل الصلاحيات الممنوحة له مباشرة قائمة. وهذا هو التفسير الأكثر شيوعاً لسؤال "لماذا لا يزال هذا الشخص قادراً على رؤية ذلك".
تخزين رمز SCIM بشكل غير آمن، أو عدم تخزينه على الإطلاق. يتم عرض رمز الحامل (Bearer token) مرة واحدة فقط. تقوم الفرق بلصقه في مزود الهوية ثم تغلق علامة التبويب دون الاحتفاظ بنسخة منه. يمكن تدارك الأمر بإنشاء رمز جديد، لكن القيام بذلك سيؤدي إلى إبطال الرمز القديم، مما يوقف عملية التوفير حتى يتم تحديث مزود الهوية أيضاً. احفظ الرمز في مدير كلمات المرور الخاص بك قبل إغلاق علامة التبويب.
كيف يعمل توفير SCIM في TrueFoundry
تدعم TrueFoundry بروتوكول SCIM مع تكوينات SSO من نوع OIDC و SAML v2. قبل تكوين التوفير، يجب أن يكون SSO يعمل بشكل صحيح؛ حيث يوجد رابط SCIM والرمز الخاص به بجانب تكوين SSO، وليس في تكامل منفصل.
الخطوة 1 — تكوين SSO
انتقل إلى Platform → Settings → SSO، وقم بتفعيل Enabled، واختر مزود الخدمة الخاص بك، ثم اختر OIDC أو SAML v2.
بالنسبة لـ OIDC، يجب عليك توفير معرف العميل (Client ID)، وسر العميل (Client Secret)، ورابط جهة الإصدار (Issuer URL)؛ علماً بأن رابط الاستجابة (callback URL) في جانب مزود الهوية (IdP) هو دائماً https://login.truefoundry.com/oauth2/callback. أما بالنسبة لـ SAML، فيجب عليك توفير رابط SSO الخاص بمزود الهوية وشهادة توقيع X.509، ثم العودة بعد الحفظ للحصول على رابط الاستجابة (Callback URL) و جهة الإصدار (Issuer) اللذين تنشئهما TrueFoundry، وقم بلصقهما في مزود الهوية الخاص بك.
نصيحة توفر عليك الوقت لاحقاً: قم بتهيئة مزود الهوية (IdP) الخاص بك لإصدار مطالبات (claims) تحمل الأسماء email و sub و groups. هذه هي الإعدادات الافتراضية في TrueFoundry، وتعيين هذه السمات في جانب مزود الهوية يعني أنك لن تحتاج إلى تعديل الحقول المتقدمة.
الخطوة 2 — تفعيل SCIM
انتقل إلى الإعدادات ← الأمان والوصول ← التزويد (Settings → Security & Access → Provisioning) واختر SCIM. هنا توجد أوضاع التزويد الثلاثة، واختيار أحدها هو الطريقة التي تحدد بها نموذج دورة حياة المستأجر.
الخطوة 3 — نسخ رابط SCIM الأساسي (SCIM Base URL)
قم بتوسيع إعدادات SSO المحفوظة لعرض رابط SCIM وبقية البيانات الوصفية. هذه هي القيمة التي يستدعيها مزود الهوية (IdP) الخاص بك.
الخطوة 4 — إنشاء رمز SCIM المميز
انقر على أيقونة المفتاح بجوار إعدادات SSO لإنشاء رمز مصادقة SCIM.
تعامل معه ككلمة مرور. يتم عرضه فقط عند الإنشاء؛ إذا فقدته، يمكنك إنشاء رمز بديل وسيتوقف الرمز السابق عن العمل.
الخطوة 5 — توجيه مزود الهوية (IdP) الخاص بك إليه
في إعدادات توفير الخدمة (provisioning) الخاصة بمزود الهوية، اضبط رابط القاعدة (Base URL) (تسميه بعض مزودات الهوية رابط المستأجر) على رابط SCIM، واضبط المصادقة على رمز حامل (Bearer Token)، والصق رمز SCIM كقيمة للرمز. بعد ذلك، قم بتعيين المستخدمين والمجموعات في مزود الهوية وابدأ عملية التوفير. في غضون دقائق قليلة، سيظهر المستخدمون والفرق في TrueFoundry.
مجموعات مزود الهوية تصبح فرقاً — هذا هو الجزء الأهم
تتوقف معظم شروحات SCIM عند مزامنة المستخدمين. مزامنة المستخدمين هي النصف السهل. السبب وراء تشغيل SCIM على منصة كهذه هو مزامنة المجموعات، لأن المجموعات هي المكان الذي تكمن فيه صلاحيات الوصول.
عند تهيئة المستأجر لـ SCIM، تصبح كل مجموعة يدفع بها مزود الهوية الخاص بك فريقاً في TrueFoundry تلقائياً. أضف شخصاً إلى مجموعة مزود الهوية وسينضم إلى الفريق؛ قم بإزالته وسيغادر الفريق.
الفرق التي تتم مزامنتها هي فرق عادية من جميع النواحي الأخرى. يمكنك منحها حق الوصول إلى الموارد، وتعيين أدوار على مستوى المستأجر، وإضافة تعيينات مطالبات مزود الهوية.
كن دقيقاً بشأن تقسيم المهام، فمن السهل المبالغة في التخصيص. لا يقرر بروتوكول SCIM ما يمكن للفريق القيام به، بل يقوم المسؤول بمنح الفريق أدواراً محددة عن قصد. يعمل SCIM على أتمتة العضوية، وبما أن الأذونات مرتبطة بالفريق، فإن العضوية الحالية تعني مجموعة أذونات فعالة حالية. صمم نظام التفويض مرة واحدة، واترك لمزود الهوية التعامل مع التغييرات.
هناك قيد في التسمية يجب مراعاته. يصبح اسم مجموعة مزود الهوية هو اسم الفريق، لذا يجب أن يحتوي فقط على أحرف أبجدية رقمية، وشرطات، وشرطات سفلية، وبحد أقصى 36 حرفاً. قم بتغيير أسماء المجموعات في مزود الهوية قبل تفعيل التزويد، وليس بعده.
مثال عملي: متعاقد في فريق منصة تعلم الآلة (ML).
إليك دورة الحياة كاملة من البداية إلى النهاية، مع تحديد الخطوات اليدوية.
الإعداد لمرة واحدة (يدوي). يقوم المسؤول بإنشاء مجموعة في مزود الهوية باسم ml-platform-contractors — أحرف صغيرة، شرطات، 23 حرفاً، وهو اسم آمن. يقوم SCIM بدفع هذه البيانات ويظهر فريق يحمل نفس الاسم في TrueFoundry. يمنح المسؤول ذلك الفريق ما يحتاجه: حساب مزود النموذج ذي الصلة، ووصول المستخدم على خادمي MCP، ولا شيء آخر. هذا هو تصميم التفويض، يتم مرة واحدة فقط.
الإلحاق (تلقائي). يبدأ متعاقد عمله. تضيفه عملية التزويد في الموارد البشرية إلى مجموعة ml-platform-contractors. يقوم SCIM بإنشاء مستخدم TrueFoundry الخاص به وإضافته إلى الفريق. يسجل المتعاقد دخوله عبر SSO بنفس صلاحيات الوصول التي يمتلكها الفريق بالضبط. لم يضطر أحد لفتح تذكرة دعم.
تغيير النطاق (تلقائي). بعد ثلاثة أشهر، ينتقل المتعاقد إلى مشروع مختلف. يقوم شخص ما بإزالته من مجموعة ml-platform-contractors وإضافته إلى مجموعة أخرى. يقوم SCIM بتعديل كلا الفريقين. يختفي وصوله إلى مزود النموذج مع انتهاء عضويته في الفريق، دون أن يتدخل أي مسؤول في TrueFoundry.
إنهاء الخدمة (تلقائي). ينتهي العقد. يتم إلغاء تنشيط سجل مزود الهوية. يضع SCIM مستخدم TrueFoundry في حالة "غير نشط"، ويتم رفض المستخدم غير النشط أثناء عملية المصادقة. يتوقف الحساب عن العمل تماماً، دون الحاجة لأن يتذكر أحد أن TrueFoundry كان ضمن القائمة.
الشيء الوحيد الذي لا يزال يدوياً. إذا تم منح ذلك المتعاقد صلاحية مباشرة أيضاً — كمجموعة سرية واحدة مثلاً، خارج أي فريق — فإن هذا المنح يظل قائماً، لأنه لم يأتِ من مزود الهوية (IdP). يؤدي إلغاء التنشيط إلى حظر تسجيل الدخول بغض النظر عن ذلك، لكن سجل المنح يظل موجوداً حتى يقوم شخص ما بإزالته. ضع هذا في اعتبارك عند مراجعة الوصول. هذا هو النمط نفسه الذي يظهر عبر التحكم في الوصول إلى MCP للمؤسسات: تتحد الأذونات الموروثة والمباشرة، وإزالة إحداهما لا تؤدي إلى إزالة الأخرى.
تنبيهات جديرة بالمعرفة
بالنسبة لـ Entra ID وOkta، يتطلب بروتوكول SCIM استخدام SAML. تدرج مصفوفة القدرات تقنية SSO كمجرد خيار موصى به لـ SCIM بشكل عام، ولكن بالنسبة لأكثر مزودي الهوية (IdP) استخداماً على نطاق واسع، تعتمد أدلة التزويد على إعدادات SAML. إذا قمت بإعداد OIDC مع Entra أو Okta ثم بحثت عن SCIM، فستحتاج إلى إعادة التكوين.
وضع تزويد واحد لكل مستأجر. لا يمكنك تشغيل SCIM للموظفين ودعوة المتعاقدين فقط في نفس المستأجر عن طريق تفعيل كلا الخيارين. إذا كنت بحاجة إلى إضافة شخص ليس موجوداً في مزود الهوية الخاص بك، فإن تدفق دعوة مستخدم الموجود في الوصول > المستخدمون لا يزال موجوداً — وعند استخدامه لمستخدم SSO، اترك مربع الاختيار إرسال بريد إلكتروني لتعيين كلمة المرور غير محدد، حيث لا توجد كلمة مرور يجب تعيينها.
إلغاء التنشيط والحذف عمليتان مختلفتان. يؤدي إلغاء التنشيط إلى حظر تسجيل الدخول وهو ما يقوم به SCIM. أما حذف المستخدم نهائياً فهو إجراء إداري منفصل، وترفض TrueFoundry تنفيذه حتى تتم إزالة المستخدم صراحةً من جميع الموارد والفرق. يمنع هذا الإجراء الوقائي حذف هوية بينما لا تزال هناك منح معلقة تشير إليها.
وصلت صفحة التزويد المخصصة في الإصدار v0.143. في الإصدارات الأقدم، يتم تكوين SCIM ضمن نموذج SSO. القيم هي نفسها، لكن الشاشات تختلف.
قراءات ذات صلة
- مصادقة واجهة برمجة التطبيقات (API) والتحكم في الوصول المستند إلى الأدوار (RBAC) في بوابة الذكاء الاصطناعي — كيف تنتقل الهوية إلى طلبات البوابة
- التحكم في الوصول إلى بروتوكول MCP: تأمين وكلاء الذكاء الاصطناعي باستخدام بوابة MCP — ما الذي يتم منحه صلاحيات الوصول فعلياً عبر فرق SCIM
- التحكم في الوصول إلى MCP للمؤسسات — المنح المباشر مقابل المنح الموروث على مستوى المؤسسة
- إطار عمل حوكمة الذكاء الاصطناعي — أين يقع التزويد ضمن مجموعة الضوابط الأوسع
- أمن بروتوكول MCP — نموذج التهديد الكامن وراء سلامة الهوية الصارمة
الخلاصة
غالباً ما يتم تسويق تزويد SCIM بناءً على سهولة انضمام المستخدمين، لأن عروض الانضمام تبدو جذابة. لكن العائد الحقيقي يكمن في الجانب الآخر. فإلغاء التزويد هو نقطة الفشل التي تفتقر إلى حلقة تغذية راجعة — فلا توجد تذكرة دعم، ولا شكوى، ولا تنبيه — والحل الدائم الوحيد هو جعل عملية المغادرة تنتقل تلقائياً من النظام الوحيد الذي يمتلك هذه المعلومة بالفعل.
في TrueFoundry، يتطلب الأمر ثلاثة إعدادات وقرار تصميم واحد: تفعيل SCIM، ونسخ عنوان URL الأساسي، وإنشاء الرمز المميز، ثم تحديد صلاحيات كل مجموعة مرة واحدة. بعد ذلك، يتولى الهيكل التنظيمي إدارة نموذج الوصول الخاص بك نيابة عنك، وتتوقف الحسابات التي لا ينبغي أن توجد عن الوجود تلقائياً — وهي عملية إلغاء التزويد الوحيدة التي تنجح مع نمو الشركة.
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
Built for Speed: ~10ms Latency, Even Under Load
Try now.
Start free
How Can You Prevent GenAI Costs From Spiraling at Scale?
Gartner Hype Cycle for Platform Engineering 2026
One Layer of Control for All AI
Discover More
No items found.
.webp)
No items found.
Recent Blogs
.webp)
.webp)
.png)
.png)
.png)
.png)
.png)
.png)
.webp)
.webp)
.png)
.png)
Frequently asked questions
ما هو تزويد SCIM؟
تزويد SCIM هو المزامنة التلقائية لحسابات المستخدمين وعضويات المجموعات من مزوّد الهوية إلى التطبيق وفق معيار SCIM 2.0. يستدعي مزوّد الهوية واجهة REST API في التطبيق لإنشاء المستخدمين وتحديث السمات وتعديل عضوية المجموعات وتعطيل الحسابات عند مغادرة الأشخاص. وتُجرى تغييرات الهوية مرة واحدة في مزوّد الهوية وتنتشر إلى كل مكان، بدل تكرارها يدوياً في كل أداة.
ما الفرق بين تزويد SCIM وتزويد JIT؟
JIT ينشئ المستخدم عند أول تسجيل دخول له عبر SSO، ولا يفعل شيئاً آخر. أما SCIM فيعمل باستمرار وبمعزل عن تسجيلات الدخول، ولذلك يتولى أيضاً التحديثات وعضوية المجموعات والتعطيل. JIT يحل مسألة الانضمام، وSCIM يحل دورة الحياة كاملة. ومع JIT يبقى إلغاء التزويد عملية يدوية يجب أن يتولاها أحد.
كيف أُعدّ تزويد SCIM في TrueFoundry؟
أعدّ SSO أولاً، ثم فعّل SCIM من Settings → Security & Access → Provisioning. وسّع إعدادات SSO لنسخ SCIM Base URL، وانقر أيقونة المفتاح لتوليد رمز Bearer، ثم الصق الاثنين في مزوّد الهوية لديك مع ضبط طريقة المصادقة على Bearer Token. عيّن المستخدمين والمجموعات في مزوّد الهوية وسيظهرون خلال دقائق قليلة. وفي Entra ID وOkta يعتمد SCIM على إعداد SSO بـ SAML.
هل يمكنني نشر TrueFoundry في VPC الخاصة بي أو محلياً؟
نعم. تعمل TrueFoundry في VPC الخاصة بك أو محلياً أو في بيئة معزولة عن الشبكة أو هجينة، فلا تغادر التعليمات والردود نطاقك أبداً حتى وأنت توجّه الطلبات عبر مزوّدين كثيرين.
هل تدعم TrueFoundry بروتوكول MCP ووكلاء الذكاء الاصطناعي عموماً؟
نعم. تتضمن MCP Gateway وAgent Gateway وMCP & Agents Registry مع تحكم في الوصول على مستوى الأدوات. ويمكن حوكمة الوكلاء المبنيين على LangGraph أو CrewAI أو AutoGen أو إطار عمل مخصص مركزياً.
هل يتكامل مع حزمة المراقبة الحالية لدي؟
نعم. البوابة متوافقة مع OpenTelemetry وتتكامل مع Grafana أو Datadog أو Prometheus أو حزمتك المفضلة. فهي تتتبع كل طلب من المطالبة إلى تنفيذ الأداة والنموذج، لتحصل على تسجيل موحد دون الحاجة إلى تغيير ما تستخدمه حاليًا.
