تتبع Cloudflare Workers يكشف استدعاء RPC البطيء

في 17 سبتمبر 2026، سهّلت Cloudflare تحديد المسؤول عن بطء طلب العميل: أصبح تتبع Cloudflare Workers قادراً على متابعة استدعاء JavaScript RPC إلى Worker آخر أو Durable Object بدلاً من التوقف عند الجهة المستدعية. وهكذا يمكنك معرفة الخدمة والدالة اللتين أخّرتا الطلب قبل إضافة مقاطع تتبع يدوية أو تحميل المنظومة بأكملها المسؤولية.

ما الذي تغيّر في تتبع Cloudflare Workers؟

قد يبدو RPC أعقد مما هو عليه فعلاً. في Cloudflare Workers، يعني استدعاء الإجراء عن بُعد أن يستدعي Worker دالة JavaScript عامة في Worker آخر أو Durable Object عبر ارتباط (binding). يبدو الاستدعاء في الشيفرة كأنه دالة محلية، لكن التنفيذ يجري في مكان آخر.

التتبّع هو الخط الزمني لطلب واحد، وكل جزء محدد التوقيت داخله يُسمى مقطعاً زمنياً (span). قبل هذا الإصدار، كان الخط الزمني يتوقف عندما تعبر الجهة المستدعية حدود JavaScript RPC. كان بإمكانك رؤية Worker A وهو يبدأ الاستدعاء، من دون ربطه بوضوح بالعمل الذي يجري في Worker B أو داخل Durable Object.

يسد إصدار Cloudflare في 17 سبتمبر هذه الفجوة. يستطيع التتبّع نفسه الآن عرض الجلسة من جهة المستدعي، وكل استدعاء لدالة، وتشغيل الجهة المستقبِلة، والاستدعاءات المتداخلة، واستدعاءات المعاودة إلى Worker آخر. وتُسجّل Cloudflare هذه المقاطع تلقائياً بعد تفعيل التتبّع. لا حاجة إلى إضافة SDK للمراقبة أو تعديل شيفرة التطبيق كي تعمل هذه المراقبة المدمجة في المنصة.

يعمل مقطع الجلسة كحاوية لجلسة RPC لدى الجهة المستدعية، وتظهر داخله الاستدعاءات التي تعيد استخدام الجلسة. تحمل مقاطع الاستدعاءات الفردية مسار الدالة أو الخاصية، بينما تحصل الجهة المستقبِلة على مقطع تشغيل مستقل. ويبيّن تغيّر الألوان موضع انتقال التنفيذ بين Workers أو دخوله إلى Durable Object.

وبذلك تتحول نقطة الانقطاع المبهمة إلى خريطة واضحة للمسؤولية.

تتبّع طلب إتمام شراء واحد

لنفترض أن أحد العملاء أرسل الطلب POST /checkout.

يصل الطلب أولاً إلى Worker مسؤول عن إتمام الشراء. يستدعي هذا الـWorker الدالة inventory.reserve() في Worker المخزون، ثم يستدعي order.commit() في Durable Object للطلبات. لا يرى العميل سوى عملية شراء واحدة بطيئة، مع أن الانتظار قد يكون في أي من 3 مواضع داخل التطبيق.

قبل هذا التغيير، كان تتبّع عملية الشراء قد ينتهي عند استدعاء RPC. وكان استكمال الصورة يتطلب سجلات من كل خدمة، ومعرّفات متطابقة، أو مقاطع تتبع مخصصة.

أما الآن، فيمكن إبقاء الطلب كاملاً ضمن تتبّع واحد. تستطيع توسيع جلسة RPC، والعثور على مقطعي الدالتين reserve وcommit، ورؤية عمليات التشغيل اللاحقة، ثم مقارنة موضع استهلاك الزمن الفعلي. ويمكن للمقاطع الجذرية أيضاً أن تعرض Cloudflare Ray ID واسم Worker ونقطة الدخول والنتيجة ووقت CPU والزمن الفعلي، ما يمنح مسؤول الاستجابة للحوادث مفاتيح عملية للوصول إلى الطلب الصحيح.

لا تثبت الواجهة الجديدة سبب بطء الدالة، لكنها تحدد أين ينبغي أن تبدأ التحقيق. إذا استحوذ تشغيل المخزون على معظم الانتظار، فافحص التخزين أو التبعية الخارجية لديه. وإذا كان مقطع Durable Object هو الأعرض، فراجع معالج ذلك الكائن وعمليات التخزين التي ينفذها. أما إذا ظهر البطء لدى الجهة المستدعية قبل بدء أي استدعاء RPC، فلا ينبغي أن تكون الخدمات اللاحقة موضع الاشتباه الأول.

من سيستفيد من هذا التغيير؟

مؤسس منفرد يدير بنية خلفية موزعة

يستطيع مؤسس وزّع إتمام الشراء والمخزون وحالة الطلبات على Workers منفصلة أن يعيد إنتاج عملية شراء بطيئة واحدة ويتابعها عبر مسار Cloudflare كاملاً. والنتيجة هي تضييق نطاق الإصلاح: يجري التحقيق في Worker أو Durable Object الذي يملك موضع التأخير بدلاً من إعادة فتح كل خدمة.

قائد فريق الأنظمة الخلفية لمنتج ذي حالة

قد يمرر تطبيق تعاوني إجراءً داخل غرفة من Worker طرفي إلى Durable Object خاص بالغرفة. يستطيع قائد الفريق الخلفي فصل الوقت المستهلك لدى الجهة المستدعية عن الوقت داخل الكائن ذي الحالة، ثم تسليم التتبّع إلى الفريق المسؤول عن تلك الحدود.

مهندس منصات يدير خدمات داخلية على Workers

قد يدير فريق المنصة عدة Workers مترابطة عبر service bindings، بينما تصنع كائنات stub المعادة واستدعاءات المعاودة مساراً يصعب استخلاصه من السجلات. توضّح مقاطع الجلسة والدوال أي الاستدعاءات أعادت استخدام الجلسة، وأي Worker نفّذ كل جزء، وأين دخل استدعاء متداخل إلى المسار.

مسؤول دعم يحوّل البلاغ إلى دليل

يستطيع فريق الدعم مطالبة الهندسة بإعادة إنتاج المسار نفسه بينما لا تزال تفاصيل الحادثة حاضرة. يمنح التتبّع الناتج عملية التسليم اسماً واضحاً للخدمة وحدوداً محددة للدالة بدلاً من عبارة «إتمام الشراء كان بطيئاً». وتظل هذه المعلومة مفيدة حتى إن احتاج الحل النهائي إلى سجلات أو أداة لتحليل الأداء أو خطة تنفيذ لاستعلام قاعدة بيانات.

نفّذ اختبار يوم الاثنين

أفضل بداية عملية هي مسار طلب واحد، لا تفعيل الميزة دفعة واحدة في كل Workers ضمن بيئة الإنتاج.

1. 1

   اختر مساراً يراه العميل

   اختر طلباً يعبر بالفعل حدود RPC من Worker إلى Worker أو من Worker إلى Durable Object، وله حالة بطء يمكن تكرارها. دوّن المسار، واستدعاءات الدوال اللاحقة المتوقعة، والوقت الذي ستعيد فيه إنتاج الحالة.

2. 2

   فعّل التتبّع في Wrangler

   أضف الإعداد الذي توثقه Cloudflare إلى ملف إعداد Wrangler الخاص بالـWorker الذي يتولى ذلك المسار:

   {
     "$schema": "./node_modules/wrangler/config-schema.json",
     "observability": {
       "traces": {
         "enabled": true
       }
     }
   }

   انشر هذا الإعداد عبر مسار الإصدار المعتاد لديك. يفعّل هذا المفتاح مقاطع Cloudflare التلقائية، ولا يتطلب SDK داخل Worker.

3. 3

   أعد إنتاج طلب بطيء واحد

   نفّذ الطلب نفسه مرة واحدة ضمن ظروف مضبوطة. احتفظ بالمسار والطابع الزمني وCloudflare Ray ID إذا كان مسار الدعم أو التسجيل لديك يلتقطه بالفعل. تكون البيئة المضبوطة أوضح لأن معدل أخذ عينات التتبّع الافتراضي هو 1، أي إن 100% من الطلبات الواردة تُتتبّع ما لم تحدد معدلاً آخر.

4. 4

   اقرأ التتبّع من الخارج إلى الداخل

   في Cloudflare، انتقل إلى Workers & Pages، واختر Worker، ثم افتح Observability. اعثر على الطلب الذي أعدت إنتاجه ووسّع التتبّع الخاص به. ابدأ بالطلب الجذري، ثم اتبع جلسة RPC، ومقطع الدالة لدى المستدعي، وتشغيل الجهة المستقبِلة، وأي استدعاء متداخل إلى Durable Object. استخدم عرض المقطع وحقول الزمن الفعلي لتحديد الحدود التي تستحق التحقيق التالي.

5. 5

   قِس التكلفة قبل التوسع

   سجّل عدد المقاطع التي أنشأها التتبّع المعاد إنتاجه. بعد ذلك، قدّر أحداث التتبّع الشهرية وفق المعادلة sampled requests × average spans per sampled trace. أضف أحداث السجلات التي تستخدم حصة المراقبة نفسها بالفعل. عدد المقاطع المقاس هو المدخل الذي تحتاج إليه لاتخاذ قرار أخذ العينات في الإنتاج.

التكلفة لكل مقطع، لا لكل طلب

تتبّع Workers مجاني خلال فترة beta الأولية. سيتغير ذلك في 1 أكتوبر 2026؛ فمن ذلك التاريخ، يُحتسب كل مقطع كحدث مراقبة واحد ويشارك Workers Logs الحصة والتسعير نفسيهما.

على فرق Enterprise مراجعة عقودها. أما بقية المستخدمين، فعليهم الانتباه إلى وحدة الفوترة: قد ينتج طلب عميل واحد مقطعاً جذرياً، ومقطع جلسة RPC، ومقاطع لاستدعاءات الدوال، وعمليات تشغيل لدى الجهة المستقبِلة، ومقاطع binding متداخلة. لذلك لا يكفي عدد الطلبات وحده لتقدير فاتورة التتبّع.

تنص وثائق التتبّع لدى Cloudflare على أن القيمة الافتراضية لـhead_sampling_rate هي 1، أي 100%. ويستخدم مثال الزيارات الكثيفة القيمة 0.05، التي تتتبّع 5 طلبات من كل 100 طلب وارد. هذه القيمة وسيلة تحكم في المثال وليست جواباً عاماً يصلح للجميع.

يكشف أخذ العينات من بداية الطلب عن المفاضلة بوضوح. فالمعدل الأصغر يخفض حجم الأحداث، لكن القرار يُتخذ عند بدء الطلب. لذلك قد لا تُختَر حالة بطء نادرة. استخدم أخذ العينات الكامل عند إعادة الإنتاج في ظروف مضبوطة أو ضمن بيئة معزولة بما يكفي، ثم اختر معدل الإنتاج بناءً على الزيارات الفعلية وعدد المقاطع المقاس في كل تتبّع.

تغيّر مدة الاحتفاظ سير عمل الحوادث أيضاً. تستمر تتبّعات الخطة المجانية 3 أيام، وتتبّعات الخطة المدفوعة 7 أيام. إذا وصلت بلاغات العملاء بعد انتهاء هذه النافذة، فقد يكون التتبّع المطلوب قد اختفى. القاعدة التشغيلية بسيطة: أعد إنتاج المشكلة وافحصها ما دام الدليل موجوداً، أو صدّر التتبّعات إلى نظام يوفر مدة الاحتفاظ التي تتطلبها إجراءاتك.

الحدود الفعلية للميزة

لا يزال تتبّع Workers في مرحلة beta المفتوحة. قد تتغير أسماء المقاطع والسمات، وتقول Cloudflare إن بعض السمات لا تزال غير مكتملة.

قد تعرض بعض المقاطع التي لا تتضمن I/O القيمة 0 ms حتى عندما يستغرق العمل وقتاً أطول. لا يحدّث Workers Runtime الوقت إلا عند وقوع حدث I/O، لذا لا تثبت القيمة الصفرية أن تنفيذ جزء من JavaScript لم يستهلك وقتاً.

ويتوقف الربط التلقائي للتتبّع خارج Cloudflare. فعند تصدير تتبّعات Workers، لا تمرر Cloudflare معرّفات التتبّع إلى الخدمات الخارجية بعد. لذلك لن ينضم استدعاء إلى مزود دفع أو قاعدة بيانات مستضافة في مكان آخر تلقائياً إلى الخط الزمني لدى Workers من جهة المزود.

أخيراً، نطاق هذا الإصدار محدد. لن يحصل Worker منفرد بلا حدود JavaScript RPC على رؤية جديدة عابرة للخدمات. قد يظل تتبّع Workers العام مفيداً مع fetches وbindings وhandlers، لكن تغيير 17 سبتمبر يهم بالدرجة الأولى التطبيقات الموزعة بالفعل بين Workers أو Durable Objects.

ماذا ينبغي أن تفعل الآن؟

تحرك هذا الأسبوع إذا كانت طلبات العملاء تعبر service bindings أو Durable Objects، وكان فريقك يجمع حالياً عدة سجلات للوصول إلى موضع البطء. ابدأ بالمسار الذي يخلق أعلى تكلفة في أعمال الدعم أو معالجة الحوادث.

انتظر إذا كان التطبيق لا يزال يعمل على Worker واحد، أو إذا كان موضع التأخير المشتبه به يقع بالكامل لدى مزود خارجي. فهذا الإصدار لا ينشئ تتبّعاً موحداً خارج Cloudflare.

إذا كان التتبّع مفعلاً بالفعل، فافحص مقاطع RPC الجديدة قبل إضافة مراقبة مخصصة. لا تضف مقاطع مخصصة إلا بعد أن يكشف التتبّع التلقائي فجوة ذات معنى داخل الدالة التي تديرها.

خطوة يوم الاثنين صغيرة: فعّل observability.traces.enabled لمسار طلب حقيقي واحد، وأعد إنتاج الطلب البطيء، وافحص جلسة RPC ومقاطع الدوال، ثم دوّن معدل أخذ العينات ومتوسط عدد المقاطع في كل تتبّع ومدة الاحتفاظ والاستخدام المتوقع للحصة قبل توسيع النشر.

إذا كنت تريد ملاحظة تشغيلية واحدة وواضحة عندما يغيّر تحديث للمنصة طريقة العمل أو الفاتورة، فانضم إلى النشرة البريدية.