با رشد تعداد playbookهای Ansible و افزایش وظایف مستقل در هر کتاب راهنما، حجم کلی لاگ‌ها و شمار خطاها به شکل چشمگیری بالا می‌رود. تفکیک و اولویت‌بندی این خطاها به‌صورت دستی زمان‌بر، خطاپذیر و مقیاس‌پذیر نیست؛ مخصوصاً وقتی اتوماسیون گسترش می‌یابد. ⚠️

این مطلب به بررسی راهکاری برای نظارت بر گزارش‌های Ansible می‌پردازد و یک شروع سریع هوش مصنوعی (AI) را معرفی می‌کند که برای تسریع فرآیند تفکیک خطا طراحی شده است. شروع سریع هوش مصنوعی Red Hat مثال‌هایی عملی از کاربرد AI در محیط‌های واقعی را نشان می‌دهد. 🤖

چگونگی خودکارسازی جریان کار برای حل خطاهای Ansible: این سیستم قابلیت‌های زیر را فراهم می‌آورد:

– ورود گزارش پیوسته: جذب و تجزیه لاگ‌های playbook در زمان واقعی.
– تشخیص خطا و هشدار: شناسایی وظایف ناموفق و تولید هشدارها.
– مسیریابی خطا مبتنی بر نقش: هدایت خطاها به متخصص مناسب بر اساس سطح مجوز.
– تولید راه‌حل‌های خودکار: ایجاد راه‌حل‌های گام‌به‌گام با بهره‌گیری از پایگاه دانش و مکانیزم‌هایی مانند RAG.
– بهبود مستمر و مشاهده‌پذیری: فراهم کردن ابزار ارزیابی و مشاهده برای درک و بهینه‌سازی کل فرآیند.
– رابط کاربری: نمایش بصری پیشنهادات و معیارهای مرتبط.

شکل 1: معماری سطح بالا.

ورود Ansible log: برای وارد کردن گزارش‌ها به موارد زیر نیاز دارید: مکانی برای ذخیره‌سازی لاگ اجرای playbook، سرویسی برای جذب گزارش‌ها و تبدیل آن‌ها به قالب مشخص، و یک پایگاه‌داده گزارش. در این نمونه از Red Hat Ansible Automation Platform برای ذخیره اجراهای playbook استفاده شده است؛ این پلتفرم به تعریف، مدیریت و اجرای اتوماسیون Ansible کمک می‌کند.

برای جذب گزارش‌ها در زمان واقعی، از Alloy استفاده می‌کنیم؛ ابزاری برای جمع‌آوری stdout هر کار از Ansible Automation Platform. هنگام انتقال، از عبارات منظم (regex) برای تعریف ورودی‌ها و برچسب‌گذاری آن‌ها بهره می‌بریم.

نمونه‌ای از لاگ اجرای Ansible playbook به شکل زیر است:

TASK [: ]دوشنبه 04 اوت 2025 07:52:22 +0000 (0:00:01.388) 1:12:32.151 ********* ok: [host_name]
TASK [: ]دوشنبه 04 اوت 2025 07:52:22 +0000 (0:00:00.019) 1:12:32.170 ********* failed: [host_name]

ابتدا، هر playbook را به ورودی‌های کار مجزا تقسیم کنید؛ می‌توان از جداسازهایی مانند nn برای این منظور استفاده کرد:

nn

سپس به هر ورودی گزارش، متادیتا و برچسب اختصاص دهید. به‌عنوان نمونه می‌توان وضعیت وظیفه را بر اساس ok، failed یا fatal برچسب‌گذاری کرد. یک مثال از عبارت منظم مورد استفاده:

(?Pok|failed|fatal):s+[(?P[^]]+)]

پس از مصرف و برچسب‌گذاری گزارش‌ها، مرحله بعد ذخیره و فراهم‌کردن قابلیت جستجوست. در اینجا از Loki به‌عنوان پایگاه داده‌ای برای ذخیره و جست‌وجوی لاگ‌ها بر اساس برچسب‌ها استفاده می‌کنیم. با LogQL می‌توانید فیلترهایی مانند status=’failed’ اعمال کرده یا regex را به‌عنوان مکانیزم جستجوی تکمیلی استفاده کنید.

وقتی فایل گزارش به TASKهای منفرد تجزیه، برچسب‌گذاری و ذخیره شد، نوبت به نحوه برخورد با گزارش‌های خطا می‌رسد. گردش کار عامل (agent) پس از ذخیره گزارش‌ها در پایگاه داده آغاز می‌شود — در ادامه گام‌ها را مرحله به مرحله می‌بینیم.

شکل 2: راه‌حل جریان کار عامل.

مرحله 1 — تعریف الگوی خطا: بسیاری از گزارش‌ها از الگوهای مشابه پیروی می‌کنند. برای گروه‌بندی آن‌ها، هر گزارش با استفاده از یک sentence encoder از پیش‌آموزش‌دیده embed می‌شود و سپس تعبیه‌ها با آموزش یک مدل خوشه‌بندی از ابتدا گروه‌بندی می‌شوند؛ هر خوشه نشان‌دهنده یک الگوی گزارش است. به‌عنوان مثال، دو گزارش با مضمون «خطا: شناسه کاربری X از قبل وجود دارد» در یک الگو قرار می‌گیرند و از تولید راه‌حل‌های تکراری جلوگیری می‌شود.

مرحله 2 — خلاصه‌سازی و کلاس‌بندی: برای هر گزارش، یک رابط کاربری تخصصی برای خلاصه‌نویسی و کلاس‌بندی فراهم می‌شود. کاربران می‌توانند خطاها را بر اساس سطح مجوز فیلتر کنند؛ برای مثال یک تحلیلگر با احراز هویت AWS می‌تواند فقط خلاصه‌های مربوط به AWS را ببیند.

مرحله 3 — ایجاد راه‌حل گام‌به‌گام: از یک روتر استفاده می‌کنیم تا تعیین کند آیا اطلاعات بیشتری لازم است یا نه. اگر زمینه بیشتری مورد نیاز باشد، عاملی فعال می‌شود که با استفاده از ابزارهای زیر، زمینه لازم را جمع‌آوری می‌کند:

– MCP (Model Context Protocol) و سرور MCP: تجزیه و تحلیل گزارش را با جستجو در پایگاه داده Loki غنی می‌کنند تا زمینه اضافی واکشی شود.
– ابزارهایی مانند get_play_recap برای بازگرداندن خلاصه‌ای از اجرای playbook و وضعیت وظایف.
– get_lines_above برای واکشی مجموعه‌ای از خطوطی که قبل از یک لاگ خاص رخ داده‌اند.

نمونه‌ای از PLAY RECAP:

PLAY RECAP *********************************************************************
host_name : ok=  change=  unreachable=  failed=  skipped=  rescued=  ignored=
==============================================================================

برای اطمینان از اینکه عامل هنگام تولید راه‌حل از سابقه و تخصص تاریخی استفاده می‌کند، یک پایگاه دانش از مشکلات تکرارشونده و راه‌حل‌های آن‌ها نگهداری می‌شود. تحلیلگران این موارد را ایجاد و حاشیه‌نویسی می‌کنند و عامل می‌تواند با استفاده از Retrieval-Augmented Generation (RAG) آن‌ها را در صورت نیاز بازیابی کند. این پایگاه دانش پایه قابل گسترش و افزودن مشکلات جدید توسط تحلیلگران است.

مرحله 4 — ذخیره نتایج تولیدی: هر خروجی تولید شده برای گزارش در یک رکورد در PostgreSQL ذخیره می‌شود. در آموزش و استنتاج، الگوریتم از رویکرد آموزش دسته‌ای استفاده می‌کند و مدل خوشه‌بندی به‌صورت دوره‌ای (مثلاً هر شب) دوباره آموزش داده می‌شود تا الگوهای جدید شناسایی شوند.

اما چگونه متوجه شویم عامل دچار خطا شده؟ شناسایی نقاط شکست عامل به تنظیم رفتار آن برای انطباق با انتظارات کمک می‌کند. برای مشاهده هر مرحله عامل می‌توان از مکانیزم ردیابی استفاده کرد که ورودی‌ها و خروجی‌های میانی عامل را نمایش می‌دهد. در اینجا از Phoenix، یک راه‌حل متن‌باز برای نظارت و tracing استفاده شده است.

شکل 3: نمای ردیابی Phoenix.

با این روش می‌توانید ورودی و خروجی هر مرحله را ببینید و دقیقاً مشخص کنید عامل در کدام بخش دچار اشکال شده است — ورودی اصلی، خروجی‌های تولیدی سیستم و نتایج ارزیابی کنار هم قرار می‌گیرند تا تحلیلگران حوزه بتوانند رفتار سیستم را کامل ارزیابی کنند. از طریق این رابط تحلیلگران می‌توانند خروجی مورد انتظار (golden) را برای هر گزارش خطا تعریف کنند و سپس ارزیابی‌هایی اجرا کنند تا تطابق خروجی عامل با خروجی طلایی را بسنجند.

شکل 4: نمای بازخورد رابط حاشیه‌نویسی.

پس از تعریف خروجی طلایی، یک ارزیابی اجرا می‌شود تا میزان سازگاری خروجی عامل با معیارهای تخصصی مشخص گردد.

شکل 5: ارزیابی و خروجی تولید شده برای ورودی.

این چرخه امکان تعریف انتظارات، اجرای ارزیابی‌ها، شناسایی شکست‌ها و بهبود گردش کار برای دستیابی به نتایج بهتر را فراهم می‌آورد. با اتصال این عامل به کلاستر Ansible Automation Platform، تحلیلگران می‌توانند به‌صورت مستقیم از طریق رابط Analyst عمل کنند؛ در این رابط تحلیلگر یک تخصص را انتخاب می‌کند و سپس می‌تواند خلاصه‌های مجاز برای آن تخصص را مشاهده کند.

شکل 6: انتخاب خبره و برچسب در رابط کاربری.

پس از انتخاب تخصص، تحلیلگر خلاصه خطاهایی را که مجاز به رسیدگی به آن‌هاست مشاهده می‌کند و با کلیک روی هر خلاصه می‌تواند راه‌حل گام‌به‌گام، مهرهای زمانی و برچسب‌های ایجادشده توسط سیستم را ببیند.

شکل 7: نمونه‌ای از الگوهای خطا برای متخصص AWS.

شکل 8: راه‌حل گام‌به‌گام تولیدشده برای یک خطای Ansible.

خلاصه: این مقاله Agent نظارت بر گزارش‌های Ansible مبتنی بر AI را معرفی کرد که به شما کمک می‌کند خطاهای اجرای Ansible را سریع‌تر شناسایی و رفع کنید. ما شرح دادیم چگونه سیستم راه‌حل‌های متنی و گام‌به‌گام تولید می‌کند، چگونه از رابط حاشیه‌نویسی برای تعریف خروجی‌های طلایی استفاده می‌شود و چگونه مکانیزم ارزیابی عملکرد عامل را می‌سنجد. ✨

حالا خودتان امتحان کنید: عیب‌یابی Ansible را با تحلیل هوشمند لاگ‌ها سرعت ببخشید. 🚀

به گزارش از وبسایت redhat