كيفية أتمتة تصحيح أخطاء Apache Spark على Amazon EMR باستخدام AWS DevOps Agent

غالباً ما يتطلب تصحيح أخطاء إطار عمل Apache Spark على خدمة Amazon EMR قضاء ساعات طويلة في فحص سجلات المنفذين، وملفات تعريف الذاكرة، والأكواد البرمجية المعقدة. ومع تزايد تعقيد مسارات البيانات، يصبح ربط هذه المقاييس عبر خدمات متعددة عبئاً تشغيلياً كبيراً. تعمل أداة AWS DevOps Agent الآن على أتمتة هذه العملية الشاقة من خلال التكامل مع وكيل استكشاف أخطاء Apache Spark، مما يتيح لك تحديد تسريبات الذاكرة وأخطاء الأكواد في غضون دقائق باستخدام أمر نصي واحد.

في السابق، لم تكن أدوات واجهة برمجة التطبيقات الأصلية لشركة AWS قادرة على الوصول إلى العناصر الداخلية لإطار عمل Spark. كانت تكتفي بوصف الأعراض، مثل خروج المنفذ برمز الخطأ 1، لكنها تفشل في تحديد النمط البرمجي الخاطئ الذي تسبب في الانهيار. ومن خلال الاستفادة من بروتوكول سياق النموذج (Model Context Protocol)، يمكن للمشغلين الآن سد هذه الفجوة دون تعريض بيانات التشخيص الحساسة للإنترنت العام.

يُعد بروتوكول سياق النموذج (Model Context Protocol) معياراً مفتوحاً يحدد كيفية اكتشاف وكلاء الذكاء الاصطناعي للأدوات الخارجية واستدعائها. تدعم أداة AWS DevOps Agent الاتصال بخوادم MCP المخصصة، مما يتيح لك إضافة قدرات جديدة دون تعديل الأداة الأساسية نفسها. عند الاتصال، تكتشف الأداة تلقائياً الأدوات المتاحة، وتفهم مخططاتها، وتستدعيها أثناء سير عمل التحقيق الخاص بها.

بالنسبة لهذا التكامل تحديداً، لا تحتاج إلى بناء خادم MCP من الصفر. يعمل وكيل استكشاف أخطاء Apache Spark لخدمة Amazon EMR كخادم MCP مُدار تستضيفه شركة AWS في نقطة نهاية إقليمية. وتتمثل مهمتك الأساسية في تسجيل نقطة النهاية هذه مع أداة AWS DevOps Agent وتفويضها باستخدام دور إدارة الهوية والوصول (IAM) لتوقيع الطلبات بالإصدار الرابع.

تضمن هذه البنية عدم مرور حركة المرور عبر الإنترنت العام أبداً. حيث تتدفق الطلبات من أداة AWS DevOps Agent إلى سحابة Amazon VPC الخاصة بك عبر اتصال خاص، وتُوجّه من خلال نقطة نهاية واجهة VPC مباشرة إلى وكيل استكشاف الأخطاء المُدار.

عادةً ما يكمن السبب الجذري الفعلي لفشل إطار عمل Spark في مناطق لا يمكن لواجهات برمجة التطبيقات القياسية، مثل Amazon CloudWatch Logs Insights أو AWS CloudTrail، الوصول إليها. يقرأ وكيل استكشاف أخطاء Apache Spark مباشرة من المصادر الداخلية الحرجة لتقديم رؤى قابلة للتنفيذ.

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

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

قبل نشر الحل، تأكد من امتلاكك لحساب AWS نشط مع صلاحيات لنشر حزم AWS CloudFormation. ستنشئ هذه الحزم أدوار IAM الضرورية وموارد Amazon VPC المطلوبة للاتصال الخاص.

يجب أن يكون لديك أيضاً أحدث إصدار من واجهة سطر أوامر AWS (AWS CLI)، ومكتبتي Boto3 وBotocore مثبتة. تأكد من تكوين هذه الأدوات ببيانات الاعتماد لنفس حساب AWS والمنطقة التي تخطط لنشر بيئة استكشاف الأخطاء فيها.

للبدء، تحتاج إلى استنساخ مستودع أمثلة AWS الرسمي الذي يحتوي على قالب CloudFormation، ونص PySpark البرمجي، وبيانات Parquet المستخدمة في هذا العرض التوضيحي.

git clone https://github.com/aws-samples/sample-aws-data-processing-and-analytics.git

بعد ذلك، انشر حزمة CloudFormation باستخدام واجهة سطر أوامر AWS. توفر هذه الحزمة سحابة Amazon VPC مخصصة، ونقطة نهاية واجهة VPC، وعبء عمل PySpark يفشل عمداً ويعمل على خدمة Amazon EMR Serverless.

cd sample-aws-data-processing-and-analytics/blogs/devops-agent-spark-mcp-integration

aws cloudformation create-stack \
  --stack-name spark-troubleshooting-demo \
  --template-body file://cloudformation/spark-troubleshooting-devops-agent-blog.yaml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-1

تستغرق الحزمة حوالي 4 إلى 6 دقائق للوصول إلى حالة اكتمال الإنشاء (CREATE_COMPLETE). بمجرد الانتهاء، استخرج مخرجات الحزمة، والتي تتضمن معرف VPC الخاص بك، ومعرفات الشبكات الفرعية، ومعرف مجموعة الأمان، وعنوان URL لنقطة نهاية MCP.

aws cloudformation describe-stacks \
  --region us-east-1 \
  --stack-name spark-troubleshooting-demo \
  --query "Stacks[0].Outputs" --output table

أخيراً، انسخ النص البرمجي التجريبي وبيانات Parquet إلى حاوية Amazon S3 المنشأة حديثاً باستخدام الأوامر التالية.

DEMO_BUCKET=$(aws cloudformation describe-stacks --stack-name spark-troubleshooting-demo --region us-east-1 --query 'Stacks[0].Outputs[?OutputKey==`DemoBucket`].OutputValue' --output text)

aws s3 cp scripts/customer_events_aggregator.py s3://$DEMO_BUCKET/customer_events_aggregator.py

aws s3 cp data/ s3://$DEMO_BUCKET/data/ --recursive

تحدد مساحة الوكيل حساب AWS والمنطقة التي تراقبها أداة AWS DevOps Agent، ودور IAM الذي تفترضه، وموفري القدرات الذين يمكنها استدعاؤهم. أنشئ مساحة وكيل جديدة في وحدة تحكم AWS باستخدام المعلمات التالية:

• الاسم: data-pipeline-troubleshooting
• المنطقة: us-east-1
• دور مساحة الوكيل: اختر إنشاء دور DevOps Agent جديد تلقائياً (Auto-create a new DevOps Agent role).

بمجرد وصول مساحة الوكيل إلى الحالة النشطة، يجب عليك إنشاء الاتصال الخاص لأداة AWS DevOps Agent. يسمح هذا الاتصال للأداة بالوصول الآمن إلى سحابة Amazon VPC الخاصة بك.

• الاسم: spark-private
• سحابة VPC: استخدم قيمة DemoVpcId من مخرجات الحزمة الخاصة بك.
• الشبكات الفرعية: استخدم كلا معرفي الشبكة الفرعية من DemoSubnetIds.
• مجموعة الأمان: استخدم قيمة SMUSVpcEndpointSecurityGroupId.
• نطاقات منافذ TCP: 443
• عنوان المضيف: sagemaker-unified-studio-mcp.us-east-1.api.aws
• تحليل DNS: داخل VPC (نظام أسماء النطاقات الخاص)

مع تنشيط الاتصال الخاص، سجّل خادم MCP كموفر قدرات في وحدة تحكم AWS DevOps Agent. قم بتسمية الموفر spark-troubleshooting، وأدخل عنوان MCPEndpointURL من مخرجات الحزمة الخاصة بك، وحدد خيار الاتصال باستخدام اتصال خاص.

بعد ذلك، أضف خادم MCP المسجل إلى مساحة عمل الوكيل الخاصة بك حتى تتمكن الأداة من استخدام أدواته أثناء التحقيق.

1. انتقل إلى قسم خادم MCP في مساحة الوكيل الخاصة بك واختر إضافة (Add).
2. في مربع حوار إضافة قدرة (Add a capability)، حدد موقع spark-troubleshooting واختر إضافة (Add).
3. في صفحة تحديد أدوات خادم MCP (Select MCP server tools)، حدد المربعات لكل من analyze_spark_workload وanalyze_spark_history_server_endpoint، ثم اختر حفظ (Save).

ستعرض مساحة الوكيل الآن أن كلتا الأداتين متصلتان ومتاحتان في كتالوج الأداة الخاص بك، وجاهزتان لتشخيص أعطال إطار عمل Spark.

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

aws emr-serverless start-job-run \
  --region us-east-1 \
  --application-id  \
  --execution-role-arn  \
  --name daily-customer-events-rollup \
  --job-driver '{"sparkSubmit":{"entryPoint":"s3:///customer_events_aggregator.py","entryPointArguments":[""],"sparkSubmitParameters":"--conf spark.executor.cores=2 --conf spark.executor.memory=1g --conf spark.executor.pyspark.memory=256m --conf spark.executor.instances=2"}}' \
  --configuration-overrides '{"monitoringConfiguration":{"s3MonitoringConfiguration":{"logUri":"s3:///logs/"}}}'

ستنتقل المهمة إلى حالة الفشل (FAILED) في غضون أربع دقائق تقريباً، مما يؤدي إلى تشغيل إنذار Amazon CloudWatch المسمى FailedJobs. بمجرد انطلاق الإنذار، افتح مساحة AWS DevOps Agent الخاصة بك، وانتقل إلى الحوادث (Incidents)، وابدأ تحقيقاً باستخدام الأمر النصي التالي:

إنذار CloudWatch في us-east-1 دخل للتو في حالة ALARM. حقق في السبب واقترح إصلاحاً

ستقوم الأداة بربط أدوات واجهة برمجة تطبيقات AWS الأصلية للعثور على تشغيل المهمة الفاشلة، ثم تستدعي أداة analyze_spark_workload عبر بروتوكول MCP. ستعرض علامة تبويب السبب الجذري (Root Cause) الناتجة السطر الدقيق من الكود الذي تسبب في تضخم الذاكرة، واستراتيجية إعادة التقسيم غير الفعالة، وإصلاحات التكوين الملموسة.

لتجنب الرسوم المستمرة، يجب عليك حذف الموارد التي تم إنشاؤها أثناء هذا البرنامج التعليمي. ابدأ بإزالة التكوينات داخل وحدة تحكم AWS DevOps Agent لمنع فشل حذف الحزمة.

1. في وحدة تحكم AWS DevOps Agent، افتح مساحة الوكيل الخاصة بك، وحدد قسم خادم MCP، وقم بإزالة spark-troubleshooting.
2. احذف مساحة الوكيل data-pipeline-troubleshooting بالكامل.
3. قم بإلغاء تسجيل موفر القدرات spark-troubleshooting.
4. احذف الاتصال الخاص smus-spark-private.

أخيراً، احذف حزمة AWS CloudFormation باستخدام واجهة سطر أوامر AWS لإزالة سحابة Amazon VPC، وأدوار IAM، وحاويات Amazon S3.

aws cloudformation delete-stack \
  --region us-east-1 \
  --stack-name spark-troubleshooting-demo

يمثل دمج بروتوكول سياق النموذج (Model Context Protocol) في أداة AWS DevOps Agent تحولاً جذرياً في كيفية تعامل فرق هندسة البيانات مع الاستجابة للحوادث. لسنوات، اعتمد تصحيح أخطاء الأنظمة الموزعة مثل إطار عمل Apache Spark بشكل كبير على تجميع السجلات والبحث بالكلمات الرئيسية. كان على المهندسين تجميع أعطال JVM، والقياس عن بُعد لعامل Python، ومقاييس CloudWatch يدوياً. من خلال السماح لوكلاء الذكاء الاصطناعي بالوصول الآمن إلى العناصر الداخلية مثل خادم سجلات Spark وخطط الاستعلام، تنقل شركة AWS الصناعة من استرجاع السجلات الأساسي إلى التحليل الدلالي للأسباب الجذرية.

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

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