10-Jul-2026 5 دقائق قراءة

AWS تطلق محركاً جديداً لتحليلات السجلات في OpenSearch لخفض تكاليف المراقبة

تطرح AWS محركاً محسناً لخدمة Amazon OpenSearch بهدف تقليل تكلفة الاحتفاظ ببيانات القياس والتشغيل، مع دعم أطول للاحتفاظ بالسجلات ورفع كفاءة البحث والتحليلات داخل نفس الاستعلام.

أعلنت AWS عن محرك جديد مخصص لتحليلات السجلات ضمن خدمة Amazon OpenSearch Service، في خطوة تستهدف معالجة الارتفاع الكبير في حجم بيانات القياس والتشغيل التي تولدها تطبيقات الذكاء الاصطناعي والوكلاء البرمجيون. وتقول الشركة إن المحرك الجديد قد يخفض تكاليف التخزين بنسبة تصل إلى 70%، مع الحفاظ على مستوى جيد من الأداء في عمليات البحث والتحليل.

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

محرك جديد لبيئات السجلات والتحليلات

المحرك الجديد مصمم للعمل ضمن بيئة OpenSearch نفسها، ما يعني أن العملاء يمكنهم الاستمرار في استخدام لوحة الإدارة ذاتها وواجهات البرمجة الأمنية والشبكية نفسها، بدل الانتقال إلى منصة مختلفة بالكامل. ووفق AWS، يعتمد المحرك على تخزين البيانات بصيغة Apache Parquet، مع الإبقاء على فهارس Lucene للحقول القابلة للبحث.

كما أوضحت الشركة أن المحرك يستخدم Apache Calcite لتحليل الاستعلامات وتحسينها قبل توزيعها بين مكونين رئيسيين: Apache DataFusion للعمليات التحليلية وLucene لبنود البحث. والنتيجة، بحسب AWS، هي القدرة على تنفيذ البحث والتجميع التحليلي داخل الاستعلام نفسه، بدل فصل كل مهمة عن الأخرى داخل أنظمة متعددة.

ويدعم المحرك الجديد لغتي SQL وPiped Processing Language، ما يمنح الفرق التقنية قدراً من المرونة في التفاعل مع البيانات دون تغيير كامل لأساليب العمل المعتادة.

ضغوط التكلفة مع تضخم بيانات الذكاء الاصطناعي

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

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

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

فرصة لتمديد فترات الاحتفاظ بالبيانات

الميزة الأبرز في المحرك الجديد هي احتمالية تمكين المؤسسات من الاحتفاظ بكمية أكبر من بيانات التتبع والسجلات دون رفع الإنفاق بالمستوى نفسه. وإذا تحققت وفورات التخزين المعلنة، فقد يساعد ذلك على إطالة فترات الاحتفاظ، وتحسين الامتثال، ورفع جودة التحقيقات بعد الحوادث.

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

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

الترحيل والتوافق قد يحدان من سرعة التبني

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

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

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

ما الذي يعنيه ذلك لفرق السحابة والمراقبة

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

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

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