‏AWS DevOps Agent با MCP سفارشی به مغز نودهای EKS رسید

AWS DevOps Agent می‌تونه خودش یه عالمه حادثهٔ تولید رو بررسی کنه: crash‌های CrashLoopBackOff رو تشخیص بده، حذف ConfigMap رو تو لاگ‌های آدیت ردیابی کنه، و متریک‌های CloudWatch رو با رویدادهای کلاستر جفت کنه. ولی یه مرز دید داره: وقتی داده‌ای که لازم داره روی سیستم‌عامل خود نود باشه، پشت یه ابزار مانیتورینگ شخص‌ثالث یا داخل دیاگنوستیک‌های داخلی یه دیتابیس، ایجنت گیر می‌کنه و فقط می‌تونه علائم رو توصیف کنه، نه ریشهٔ مشکل رو پیدا کنه.

راه‌حلی که تیم AWS تو این پست نشون می‌ده، ساخت یه سرور Model Context Protocol (MCP) سفارشیه. MCP یه استاندارد بازه که مشخص می‌کنه ایجنت‌های هوش مصنوعی چطور ابزارهای بیرونی رو کشف و صدا بزنن؛ وقتی یه سرور MCP به AWS DevOps Agent وصل می‌شه، خود ایجنت ابزارهای جدید رو خودکار کشف و اسکیماشون رو می‌فهمه، بدون این‌که خود ایجنت نیاز به تغییر داشته باشه. سه اصل طراحی این کار رو امن نگه می‌داره: خروجی‌ها باید داده‌های ساخت‌یافته با سطح شدت و شناسهٔ ثابت باشن نه متن خام، ایجنت هیچ‌وقت به شل مستقیم دسترسی نداره، و ابزارها باید به هم زنجیر بشن تا خروجی یکی ورودی بعدی بشه.

نمونهٔ عملی این الگو، ریپازیتوری sample-eks-node-diagnostics-mcpـه که یه سرور MCP پشت Amazon Bedrock AgentCore Gateway می‌سازه. وقتی ایجنت یه ابزار جمع‌آوری رو با شناسهٔ یه اینستنس صدا می‌زنه، سرور یه اجرای SSM Automation با رانبوک رسمی AWSSupport-CollectEKSInstanceLogs رو روی همون نود اجرا می‌کنه، بیش از ۲۰ منبع لاگ — از journal کامل kubelet و لاگ‌های containerd گرفته تا قوانین iptables، جدول مسیریابی، پیام‌های dmesg و وضعیت IPAMD — رو جمع می‌کنه، توی یه باکت S3 آپلود می‌کنه، و بعد یه پایپ‌لاین پردازش خطاها رو با سطح شدت و شناسهٔ ثابت ایندکس می‌کنه.

برای نشون دادن کارایی‌اش، نویسنده‌ها یه سناریوی واقعی شبیه‌سازی کردن: یه قانون iptables تزریق کردن که ترافیک DNS پادها به سمت kube-dns رو قطع می‌کنه — درحالی‌که kubectl get pods همه‌چیز رو Running نشون می‌ده، پس هیچ رویداد یا وضعیت پادی توی کوبرنتیز به این مشکل اشاره نمی‌کنه. وقتی مهندس از AWS DevOps Agent می‌خواد بررسی کنه، ایجنت هم‌زمان لاگ‌های نود رو جمع می‌کنه، سلامت کلاستر رو چک می‌کنه، و بعد چهار بررسی موازی رو اجرا می‌کنه: کندوکاو تو iptables و مسیرها، جست‌وجوی خطاهای شبکه تو لاگ‌ها، مقایسه با یه نود سالم، و چک کردن OOM Kill و وضعیت پاد.

نتیجه، ریشهٔ دقیق مشکل رو لو می‌ده: دو تا قانون DROP تزریقی تو زنجیرهٔ FORWARD (یکی برای ترافیک پاد-به-پاد، یکی برای بازهٔ CIDR سرویس‌ها) به‌علاوه یه مسیر blackhole برای 10.96.0.0/12 که فقط روی نود مشکل‌دار وجود داره. مقایسه با نود سالم این تشخیص رو تأیید می‌کنه: تعداد ورودی‌های conntrack دوازده برابر بیشتره، خطاهای هماهنگ‌سازی IPAMD پنج برابره، و شمارندهٔ زنجیرهٔ FORWARD روی نود مشکل‌دار ۲٫۴ میلیارد بسته رو ثبت کرده، در برابر صفر روی نود تازه‌راه‌اندازی‌شده. آخرش ایجنت به این جمع‌بندی می‌رسه که یه فضای نام آزمایش هرج‌ومرج (chaos experiment) روی کلاستر، این تغییرات شبکه رو عمداً تزریق کرده.

به گفتهٔ نویسنده‌ها، همین الگو به هر سیستمی که SSM Agent روش فعاله تعمیم پیدا می‌کنه — از اینستنس‌های EC2 و کانتینرهای ECS گرفته تا سرورهای on-premise ثبت‌شده با SSM Hybrid Activations؛ حتی می‌شه با API مدیریتی دستگاه‌های شبکه، کوئری‌های فقط-خواندنی دیتابیس، یا API ابزارهای APM شخص‌ثالث هم گسترشش داد. با این‌حال تأکید می‌کنن این جایگزین مانیتورینگ پیوسته یا الزامات نگه‌داری لاگ نیست، و پیاده‌سازی مرجع فعلاً یه Proof of Concept‌ـه که باید قبل از استفادهٔ تولیدی، تو محیط غیرتولیدی تست بشه.

نکات کلیدی:

• AWS DevOps Agent به داده‌های سطح سیستم‌عامل نود مثل iptables، containerd و dmesg دسترسی مستقیم نداره
• یه سرور MCP سفارشی، از طریق AWS Systems Manager Automation، بیش از ۲۰ منبع لاگ نود رو در اختیار ایجنت می‌ذاره
• تو دمو، ایجنت یه اختلال DNS ناشی از قوانین iptables تزریقی رو با مقایسهٔ نود سالم پیدا کرد
• ایجنت هیچ‌وقت به شل مستقیم دسترسی نداره؛ همه‌چیز از طریق SSM Automation قابل‌ممیزیه
• همین الگو به EC2، ECS، سرورهای on-premise و حتی دیتابیس‌ها و ابزارهای APM هم قابل‌تعمیمه