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

پروژه‌های CNCF که در این مطلب برجسته شده‌اند، به همراه رشد استفاده از OpenTelemetry در محیط‌های تولیدی، باعث ظهور یک چالش جدید شده‌اند: چگونه می‌توان به‌صورت امن و از راه دور صدها یا حتی میلیون‌ها عامل (agent) جمع‌آوری تله‌متری را مدیریت، پیکربندی و به‌روزرسانی کرد؟ پاسخ مهمی که در این زمینه مطرح شده، پروتکل مدیریت عامل باز OpAMP است که امکان مدیریت متمرکز و خودکار عوامل را فراهم می‌کند.

در یک قسمت از برنامه OpenObservability Talks، نگهدارنده OpAMP، اندی کلر، که مهندس ارشد در BindPlane است، به توضیح نحوه کار OpAMP و نقش آن در ساده‌سازی استقرار قابلیت مشاهده در مقیاس بزرگ پرداخت و همچنین به‌روزرسانی‌های مهمی را که در KubeCon مطرح شد، بیان کرد. 🚀

چرا OpAMP لازم است؟ با گسترش OpenTelemetry، سازمان‌ها با مجموعه‌ای از استقرارهای پیچیده و ناهمگن روبه‌رو شده‌اند. پیش از OpAMP، راهکارها پراکنده و متنوع بودند: پیاده‌سازی‌هایی مبتنی بر HTTP long-polling، WebSockets، پروتوباف (protobufs) یا حتی JSON وجود داشت که همه این‌ها در مقیاس و تنوع استقرارها مشکل‌ساز می‌شد.

اندی به تجربیات قبلی اشاره کرد؛ تیم‌ها چندین پروتکل متفاوت برای مدیریت توسعه دادند و هرکدام محدودیت‌های خود را داشتند. وقتی صحبت از استقرارها از دروازه‌های بزرگ تا دستگاه‌های تعبیه‌شده می‌شود، هر مدل عملیاتی نیازهای مدیریتی خاصی دارد و اغلب تیم‌های مسؤول مدیریت کلکتورها با تیم‌های مشاهده‌پذیری که باید پیکربندی‌ها را اعمال کنند، متفاوت هستند—این جدایی می‌تواند اصطکاک عملیاتی ایجاد کند. 🔧

مقیاس این مسئله چشمگیر است: از ده‌ها تا میلیون‌ها کلکتور. در حوزه‌های IoT و دستگاه‌های تعبیه‌شده، تعداد عامل‌ها می‌تواند به ارقام بسیار بزرگ برسد، که مدیریت متمرکز و کارآمد را ضروری می‌سازد.

OpAMP چیست؟ OpAMP (Open Agent Management Protocol) یک پروتکل استاندارد برای مدیریت از راه دور عوامل مشاهده‌پذیری است، که عمدتاً برای OpenTelemetry Collector طراحی شده اما فراتر از آن نیز قابل استفاده است. این پروتکل به یک بک‌اند مرکزی اجازه می‌دهد عوامل را پیکربندی کند، به‌روزرسانی‌ها را فشار دهد، سلامت آن‌ها را نظارت کند و وضعیت را در زمان واقعی از طریق اتصالات WebSocket یا HTTP جمع‌آوری نماید.

نکته مهم این است که OpAMP فراتر از مدیریت پیکربندی ساده رفته و روی سلامت عامل و اجزا نیز تمرکز دارد؛ به بیان دیگر، مشاهده‌پذیری برای «خودِ» زیرساخت مشاهده‌پذیری نیز ضروری است. OpAMP با فراهم کردن دید بلادرنگ از سلامتکلکتور، وضعیت پیکربندی و عملکرد عملیاتی، این نیاز را برطرف می‌کند. 🌐

معماری و اجزای OpAMP: مشخصات پروتکل در مخزن opamp-spec تحت OpenTelemetry قرار دارد و پیاده‌سازی مرجع opamp-go در زبان Go ارائه شده است. معماری شامل مؤلفه‌هایی مانند OpAMP extension (یک مؤلفه فقط‌خواندنی که پیکربندی جاری و وضعیت سلامت را گزارش می‌دهد) و یک ناظر یا supervisor است که در کنار collector اجرا می‌شود و قابلیت خواندن و نوشتن را فراهم می‌آورد. رویکرد supervisor ایمن‌سازی‌هایی مانند نوشتن پیکربندی جدید روی دیسک، تلاش برای راه‌اندازی مجدد با پیکربندی جدید و بازگردانی به آخرین پیکربندی شناخته‌شده در صورت خطا را فراهم می‌کند تا خطوط لوله تله‌متری از راه دور خراب نشوند.

OpAMP تنها برای OpenTelemetry Collector کاربرد ندارد: بار پیکربندی در پروتکل عمداً عمومی و به صورت یک map از جفت‌های نام-مقدار تعریف شده است، بنابراین می‌تواند هر عاملی را مدیریت کند. روش‌هایی برای مدیریت استقرارهای Kubernetes (با استفاده از یک OpAMP bridge که بین پلتفرم مدیریت و مکانیزم‌های بومی Kubernetes مانند OpenTelemetry Operator و CRDها قرار می‌گیرد) و حتی SDKها وجود دارد؛ مثلاً OpenTelemetry Java SDK می‌تواند پیکربندی راه دور دریافت کند. این امکان‌ها موارد استفاده‌ای مانند تغییر نرخ نمونه‌برداری سراسری یا فعال/غیرفعال کردن logging debug در سرویس‌های مشخص را فراهم می‌کنند. 🔁

تغییر پیکربندی SDKها نیازمند مدل‌های عملیاتی متفاوتی است، زیرا نمی‌توان برنامه‌های کاربردی را برای اعمال پیکربندی مجدداً راه‌اندازی کرد؛ بنابراین SDKها باید از قابلیت‌های hot-reload پشتیبانی کنند. همچنین پروژه‌هایی برای مدیریت fleet از عوامل مانند Fluent Bit (و در آینده Fluentd) در حال توسعه‌اند—مخازن GitHub و پست‌های وبلاگ مرتبط اطلاعات بیشتری ارائه می‌دهند.

یکی از پیشرفت‌های مهم اخیر، OpAMP Gateway Extension است که در حوالی KubeCon Europe 2026 معرفی شده است. این افزونه که به صورت یک OpenTelemetry Collector اجرا می‌شود، به‌عنوان یک مالتی‌پلکسر عمل می‌کند: پیام‌های OpAMP را از هزاران کلکتور لبه جمع‌آوری کرده و آن‌ها را از طریق تعداد کمتری اتصال به پلتفرم‌های مدیریت بالا منتقل می‌کند. این راهکار محدودیت‌های اتصال WebSocket را برطرف می‌کند، سربار اتصال را کاهش می‌دهد و برای محیط‌های شبکه‌ای تقسیم‌بندی‌شده یا استقرارهای در مقیاس IoT بسیار حیاتی است. این افزونه در حالت آلفا منتشر شده است و مستندات راه‌اندازی در وبلاگ مربوطه در دسترس است. 🛡️

نقشه راه OpAMP: پروتکل هم‌اکنون در مرحله بتا قرار دارد و اجزای مختلفی با سطوح بلوغ متفاوت در حال توسعه‌اند. از جمله اولویت‌ها می‌توان به ارسال تغییرات پیکربندی به‌جای ارسال کامل پیکربندی (delta updates)، پشتیبانی بهتر از hot-reload بدون نیاز به راه‌اندازی مجدد کامل، و پیش‌برد OTEP مربوط به telemetry policy اشاره کرد. OTEP قصد دارد سیاست‌ها را به‌عنوان مفهومی مجزا از پیکربندی مطرح کند تا اهداف ارتباطی (مثل «این نوع پیام‌ها را فیلتر کن» یا «این ویژگی را فعال کن») بیان شوند و سپس SDK یا collector بسته به قابلیت‌ها، آن سیاست‌ها را پیاده‌سازی کنند.

انتظار می‌رود در آینده SDKهای بیشتری از OpAMP پشتیبانی کنند تا توانایی‌های مدیریت از راه دور به زبان‌ها و پلتفرم‌های بیشتری گسترش یابد. برای آشنایی بیشتر، می‌توانید قسمت OpenObservability Talks با موضوع عملیات OpenTelemetry در مقیاس با OpAMP را دنبال کنید.