مراقبة التطبيقات بدون خوادم في السعودية: تتبع Lambda وCloud Run وAzure Functions من البداية إلى النهاية

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

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

مراقبة AWS Lambda. تجمع Datadog Lambda Extension سجلات الدوال عبر Lambda Telemetry API، فلا تحتاج إلى المرور عبر CloudWatch أولًا، ويصف Datadog مقاييسها المحسّنة بأنها بدقة بضع ثوانٍ. وتضيف المكتبة التتبعات والمقاييس المخصصة. ولدوال Python وNode.js يوثّق Datadog نقل سياق التتبع عبر API Gateway وSQS وSNS وKinesis وEventBridge وDynamoDB وS3 وStep Functions، فتبقى السلسلة غير المتزامنة مقروءة طلبًا واحدًا. أما بيئات التشغيل الأخرى، أو الحالات التي لا يمكن فيها نقل السياق، فيربط Datadog التتبعات المرتبطة بعضها ببعض بدل دمجها. ونتحقق من الحالة التي تنطبق على دوالكم قبل أن نعدكم بعرض واحد.

روابط ذات صلةصفحة التتبع الموزّعصفحة Datadog APM

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

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

على منصة بدون خوادم، الإصدار الذي يضيف 300 ملّي ثانية إلى دالة يضيف تكلفة إلى كل استدعاء. وعلى Lambda يعطي مقياس estimated_cost المحسّن في Datadog التكلفة التقديرية لكل استدعاء بالدولار الأمريكي، فتُعرض التكلفة إلى جانب المدة وحجم الطلبات. وهذا تقدير من Datadog، وليس فاتورة AWS. ولكل المنصات يستطيع Datadog Cloud Cost Management قراءة ملفات تصدير التكلفة التي تكتبها كل سحابة، فيظهر الإنفاق الفعلي إلى جانب الاستخدام.

والعروض المفيدة بسيطة: الدوال العشر الأعلى تكلفة لكل استدعاء، والدوال التي ارتفعت تكلفتها بعد نشر جديد، وإعادات المحاولة وتجاوزات المهلة التي تُدفع تكلفتها ولا تقدّم شيئًا.

لبيانات المراقبة سؤال إقامة خاص بها. فـ Datadog منصة SaaS، وحتى نوفمبر 2026 تقع مواقعها الموثّقة في الولايات المتحدة وألمانيا واليابان وأستراليا والمملكة المتحدة، ولا موقع منها في الشرق الأوسط. وقد تحمل محتويات الطلبات والسجلات والوسوم بيانات شخصية، لذلك تتفق إنتركي مع فريق الأمن لديكم على ما يُجمع، وأي البيانات تُحذف قبل أن يخرج أي شيء من الدالة. ويأتي الدعم من مهندسي إنتركي في الرياض، بالعربية والإنجليزية.

تتحدد فاتورة Datadog بعدد الدوال النشطة المراقَبة، والاستدعاءات التي تُتتبَّع، وحجم التتبعات والسجلات التي تُفهرس وتُحفظ، والمنتجات التي تضيفونها. ويشرح دليل أسعار Datadog لدينا كيف يُحتسب كل منها.

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

روابط ذات صلةدليل أسعار Datadog لدينا