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

با بالغ شدن معماری‌های Cloud Native، مشاهده‌پذیری از یک قابلیت اختیاری به ضرورتی اساسی تبدیل شده است. OpenTelemetry در حال گسترش جامعه مشارکت‌کنندگان خود است و به یکی از پروژه‌های پرسرعت در CNCF بدل شده و عملاً به o11y دنیای Kubernetes تبدیل می‌شود ☁️.

با رشد استفاده از OpenTelemetry، یک پرسش معماری همواره مطرح است: تله‌متری را باید با یک OpenTelemetry Collector جمع‌آوری کرد، از یک Agent استفاده کرد یا ترکیبی از هر دو به‌کار برد؟ در این راهنما این دو رویکرد را شفاف می‌کنیم، نحوهٔ تطابق هر کدام با معماری OpenTelemetry را توضیح می‌دهیم و کمک می‌کنیم تا راه‌حل مناسب برای ایجاد خطوط لوله قابل مشاهده، کارا و مقیاس‌پذیر انتخاب کنید 🧭.

اجزای اصلی معماری OpenTelemetry چیست؟ قبل از مقایسه Collector و Agent، ضروری است بدانید این مؤلفه‌ها چه نقشی در معماری کل بازی می‌کنند.

OpenTelemetry Collector چیست؟ Collector به‌عنوان یک سرویس متمرکز برای مدیریت تله‌متری عمل می‌کند. هنگام مقایسه OpenTelemetry Collector در مقابل Agent، Collector معمولاً نقش هاب پردازش مرکزی را برای خطوط لوله تله‌متری ایفا می‌کند: ردیابی‌ها، metrics و logs را جمع‌آوری، پردازش و سپس به ابزارهای مشاهده‌پذیری یا backendهای شما صادر می‌کند.

گردآورنده: هاب مرکزی برای تجمیع، تبدیل و صادرات تله‌متری.

چه چیزی Collector را مفید می‌کند؟

🔹 جمع‌آوری داده‌ها: Collector می‌تواند از منابع متنوعی از طریق receivers تله‌متری دریافت کند، از جمله OpenTelemetry SDK، agentها و دیگر ابزارهای مشاهده‌پذیری.

🔹 پردازش داده‌ها: امکان پاک‌سازی، فیلتر کردن، نمونه‌برداری، تبدیل و افزودن metadata قبل از ارسال به مقصد را فراهم می‌کند تا داده‌ها برای ذخیره‌سازی و تحلیل آماده شوند.

🔹 صادر کردن داده‌ها: پس از پردازش، از exporters برای ارسال داده‌ها به پلتفرم‌های ذخیره‌سازی و تحلیل استفاده می‌شود؛ مزیت این است که داده‌ها می‌توانند با هر پشته مشاهده‌پذیری شما هماهنگ شوند.

Agent OpenTelemetry چیست؟ Agent یک فرایند سبک‌وزن است که کنار برنامه اجرا می‌شود و تله‌متری را به‌صورت محلی و با کمترین سربار جمع‌آوری می‌کند. می‌توان آن را به‌عنوان یک سایدکار یا daemon سبک در کنار برنامه تصور کرد که داده‌ها را مستقیماً از منبع می‌گیرد.

عامل: سایدکار سبک‌وزن برای ضبط تله‌متری در سطح برنامه.

عامل معمولاً تمرکز بر جمع‌آوری محلی دارد، پردازش حداقلی انجام می‌دهد تا سربار اجرایی پایین بماند و تأثیر بر عملکرد برنامه کاهش یابد. این رویکرد برای محیط‌های کانتینری و میکروسرویس‌ها مناسب است، جایی که استقرار یک agent کنار هر سرویس دید دقیق‌تری فراهم می‌کند.

در اکوسیستم OpenTelemetry، Agent، Collector و SDKها با ابزارهایی مانند Prometheus، Jaeger و Grafana ادغام می‌شوند و با هم یک خط لوله کامل برای metrics، logs و traces در Kubernetes و محیط‌های ابری ترکیبی فراهم می‌آورند ⚙️.

مقایسه کلیدی: تفاوت اصلی در حوزه عملکرد است — Agent داده‌ها را محلی می‌گیرد و سربار کمی دارد، در حالی که Collector داده‌ها را از منابع متعدد دریافت، پردازش و به backendها صادر می‌کند. در عمل این تفاوت‌ها در مدل استقرار، توانایی‌های پردازشی، مدیریت داده و تأثیر بر عملکرد نمود پیدا می‌کند.

نکته کلیدی: وقتی به کنترل متمرکز، پردازش و مقیاس‌پذیری نیاز دارید از Collector استفاده کنید. اگر هدف جمع‌آوری محلی با کمترین سربار و نزدیکی به منبع است، Agent انتخاب مناسب‌تری است.

توصیه نهایی: انتخاب بین OpenTelemetry Collector و Agent بستگی به اندازه و نیازهای مشاهده‌پذیری شما دارد. معمولاً ترکیب هر دو — Agent برای جمع‌آوری محلی و Collector برای تجمیع و تبدیل متمرکز — بهترین تعادل میان کارایی و مقیاس‌پذیری را ارائه می‌دهد.