Michael Johnsonأعلنت AWS عن CloudWatch Omni في 22 سبتمبر 2026، وأدرجته بوصفه متاحًا عمومًا في 23 سبتمبر. يشير التاريخان إلى حدثين مختلفين: الإعلان وبدء الإتاحة العامة. يجمع Omni إمكانية رصد التطبيقات ووكلاء الذكاء الاصطناعي ضمن تجربة واحدة، بواجهة ويب مستقلة وامتدادات لبيئات التطوير المتكاملة، إلى جانب تكامله مع CloudWatch. أعلنت AWS عن CloudWatch Omni
يعالج هذا الجمع نقطة عمياء في بيئات الإنتاج: فقد يكتمل طلب الوكيل من دون خطأ تقليدي في الخدمة، ومع ذلك ينتج إجابة رديئة أو يختار أداة غير مناسبة. وتتمثل الفكرة التي تطرحها AWS في تمكين الفرق من فحص آثار الوكلاء وتقييماتهم إلى جانب بيانات قياس التطبيقات. أما السؤال العملي فهو ما إذا كانت هذه الإشارات ستكون مفيدة في مساحة عمل مشتركة، وما البيانات والصلاحيات والتكاليف المصاحبة لتوجيهها إليها.
المنتج أوسع من آثار الوكلاء
Omni امتداد لـ CloudWatch وليس بديلًا عنه. وتقول AWS إن تنبيهات CloudWatch الحالية ولوحات المعلومات وواجهات برمجة التطبيقات وسير العمل عبر وحدة التحكم ستواصل عملها. ويمكن أن تظهر بيانات القياس المرسلة بالفعل إلى CloudWatch في Omni من دون إعادة ضبط؛ أما أعباء العمل الأخرى المزوّدة بأدوات الرصد، فيمكنها إرسال البيانات عبر بروتوكول OpenTelemetry (OTLP). وتصف AWS أيضًا اكتشاف الخدمات ورسم خرائط الاعتماديات، مع مساحات يمكنها جمع بيانات القياس عبر الحسابات والمناطق عند إعدادها لهذا الغرض. وثائق CloudWatch Omni
لا تقتصر التجربة على وحدة تحكم AWS الإدارية. توفر AWS واجهة ويب مستقلة مع تسجيل دخول موحد، إضافة إلى امتدادات لبيئات VS Code وCursor وKiro. وتدرج ملاحظة الإصدار الصادرة في 23 سبتمبر الإتاحة العامة في شرق الولايات المتحدة (شمال فرجينيا) وغرب الولايات المتحدة (أوريغون) وأوروبا (أيرلندا). وينبغي للفرق التحقق من دعم مناطقها قبل اعتماد Omni ضمن تصميم الإنتاج.
بالنسبة إلى الوكلاء، تصف AWS استكشاف الآثار والتقييم والتجريب عبر أطر عمل تشمل OpenAI Agents SDK وLangGraph وCrewAI وVercel AI SDK وStrands. أما في التحقيقات المتعلقة بالتطبيقات، فيمكن للمستخدمين طرح الأسئلة بلغة طبيعية أو استكشاف بيانات القياس مباشرة؛ وتقول AWS إن ميزات التحقيق المدعومة بالذكاء الاصطناعي تعتمد على DevOps Agent. كما تشير مقالة إطلاق ميزات التطبيقات إلى أن DevOps Agent مفعّل افتراضيًا في كل جلسة تحقيق عبر Omni، وهو سلوك ينبغي للمسؤولين فهمه عند تقييم سير العمل.
لماذا قد يكون جمع الإشارات مهمًا
يمكن أن توضح أدوات المراقبة التقليدية ما إذا كانت الخدمة تستجيب، ومدة استجابتها، وما إذا كانت تُرجع أخطاء. لكنها قد لا تكشف أن الوكيل أساء فهم طلب، أو اختار أداة غير ملائمة، أو قدّم إجابة غير صحيحة. وقد يساعد النظر إلى نتيجة التقييم جنبًا إلى جنب مع الأثر وإشارات التطبيق الفريق على تتبع مشكلة الجودة عبر خطوات تنفيذ الوكيل.
هذه فائدة تشغيلية محتملة، وليست نتيجة أداء مثبتة. تصف مواد إطلاق AWS سير العمل الموحّد، لكنها لا تثبت أنه يحل الحوادث أسرع من الأدوات الحالية. وستحتاج الفرق إلى اختبار مدى فائدة تقييمات Omni وتحقيقاته في أعباء العمل الخاصة بها.
قد يسهّل OpenTelemetry إرسال بيانات القياس من الأدوات الحالية، لكن استخدام بروتوكول مشترك لا يجعل منصات الرصد قابلة للتبادل. تحدد مواصفات OTLP كيفية نقل بيانات القياس؛ ومع ذلك، لا يزال على الفرق التحقق من الإشارات والاستعلامات والميزات الخاصة بالمنصة التي تعتمد عليها سير العمل لديها.
المركزة تتطلب إعدادًا
يمكن لـ Omni جمع البيانات عبر الحسابات والمناطق، لكن لا ينبغي للفرق افتراض أن تفعيل واجهته يجمع تلقائيًا بيانات القياس من كل حساب. تصف وثائق إعداد AWS إنشاء النطاقات والمساحات، ثم تهيئة طريقة جلب بيانات القياس من حسابات متعددة إلى مساحة واحدة. ويمكن عرض بيانات CloudWatch الحالية من دون إعادة تهيئة أدوات الرصد، لكن على المؤسسة مع ذلك إعداد الصلاحيات وتدفق البيانات المطلوبين. تعليمات إعداد Omni
لهذا التمييز أهمية في النشر والتكلفة معًا. تفصل صفحة تسعير AWS الرسوم الخاصة بإدخال بيانات القياس وتخزينها وتحليلها. كما توضح وجود رسوم على النسخ المركزية الإضافية، بينما تكون النسخة المركزية الأولى مجانية وفق الأسعار المنشورة. وتعتمد تكاليف الاستعلام على حجم البيانات التي جرى فحصها والحدود المشمولة؛ أما تقييمات الوكلاء فتُحاسب وفق أسعار Amazon Bedrock AgentCore Evaluations. لذلك، يتطلب إعداد تقدير مفيد مراعاة حجم البيانات وفترة الاحتفاظ وأنماط الاستعلام والنسخ وتواتر التقييم، لا عدد الوكلاء فحسب.
ينبغي مراجعة محتوى الآثار والصلاحيات
قد تتضمن آثار الوكلاء المطالبات والردود والمستندات المسترجعة والمعلومات الشخصية. وتقول AWS إن Omni لا يكتشف معلومات التعريف الشخصية ولا يحجبها تلقائيًا. وتوصي إرشادات البيانات الحساسة باختيار موضع إجراء التصفية؛ إذ إن الحجب عند الالتقاط هو الخيار الذي يمنع المحتوى الحساس من مغادرة التطبيق.
وتقول AWS أيضًا إن Omni لا يستخدم محتوى العملاء لتدريب النماذج الأساسية أو تحسين Omni نفسه. لكن هذا لا يعني أن المحتوى لا تتم معالجته في أماكن أخرى: فبعض الميزات ترسل البيانات إلى خدمات مثل Bedrock أو AgentCore، وتوثّق AWS الاستدلال عبر المناطق لميزات الذكاء الاصطناعي. وتظل البيانات مخزنة في منطقة المساحة، لكن قد تُعالج طلبات الذكاء الاصطناعي في مكان آخر ضمن المنطقة الجغرافية نفسها. ينبغي للفرق مراجعة سياسة استخدام البيانات لدى AWS وتفاصيل الاستدلال عبر المناطق، ولا سيما إذا كانت سياساتها تقيّد أماكن معالجة محتوى الآثار.
تستحق ضوابط الوصول التدقيق نفسه الذي يستحقه مسار بيانات القياس. وتقول AWS إن أعضاء المساحة يمكنهم افتراضيًا قراءة كل بيانات القياس فيها؛ ويمكن لنطاقات البيانات تضييق صفوف السجلات والآثار التي يراها العضو. لكن هذه النطاقات لا تخفي الحقول داخل الصف الواحد، لذا فهي ليست بديلًا عن حجب المحتوى الذي يجب ألا يراه المستخدمون مطلقًا. كيفية تقييد ما يراه أعضاء المساحة
نهج مدروس لتقييم Omni
بالنسبة إلى الفرق التي تستخدم CloudWatch بالفعل، يمكن لاختبار محدود أن يوضح ما إذا كان عرض Omni المشترك للتطبيقات والوكلاء يساعد في سير عمل حقيقي. وقبل إرسال آثار الإنتاج، حدد الإشارات المطلوبة، واضبط التصفية، وحدد صلاحيات الوصول للحسابات والمناطق، وقدّر تكاليف إدخال البيانات وتخزينها وتحليلها وتقييمها. ثم قارن التحقيقات التي ينشئها النظام ونتائج التقييم بإجراءات التعامل الحالية مع الحوادث.
أما المؤسسات التي تستخدم منصات رصد أخرى، فالإطلاق سبب لتقييم سير العمل، لا سببًا كافيًا للانتقال بحد ذاته. يقرّب Omni إشارات جودة الوكلاء من عمليات التطبيقات، لكن قيمته ستعتمد على فائدة التحقيقات وملاءمة ضوابطه واقتصاديات تدفق البيانات.
