‏گیت‌وی OpenTelemetry روی EKS که خودش رو می‌پاد

تو بلاگ AWS اومده که خط لولهٔ تله‌متری معمولاً سریع‌تر از توان مانیتور کردنش بزرگ می‌شه؛ تیم‌ها برای دیدن trace و متریک و لاگ اپلیکیشن کلی خرج می‌کنن ولی کمتر می‌پرسن کی حواسش به خودِ این خط لوله هست. وقتی پایپ‌لاین به‌خاطر backpressure یا خطای شبکه یا کانفیگ غلط بی‌صدا داده رو می‌ندازه دور، درست همون‌جا کور می‌شی که بیشتر از همیشه به دیدن نیاز داری. نویسنده اسم این الگو رو می‌ذاره «مانیتور کردن خط لولهٔ مانیتورینگ».

کالکتور OpenTelemetry سه الگوی استقرار روی کوبرنتیز داره: Agent به‌شکل DaemonSet با یه پاد روی هر نود، Sidecar کنار هر پاد اپلیکیشن که ساده‌ست ولی تعداد کانتینرها رو دو برابر می‌کنه و تنظیم CPU و حافظهٔ هر پاد رو دستی می‌کنه، و Gateway که یه Deployment مستقل با یه اندپوینت OTLP مشترکه. به گفتهٔ نویسنده، تو مقیاس بالا اگه هر ورک‌لود مستقیم به CloudWatch صادر کنه، credential تکراری و بچ‌های نازک می‌گیری و هیچ نقطهٔ مرکزی‌ای برای سمپلینگ و فیلتر و کنترل هزینه نداری.

این راهنما الگوی agent-to-gateway رو پیاده می‌کنه: ورک‌لودها OTLP رو به ایجنت نود خودشون می‌دن، ایجنت با متادیتای کوبرنتیز (نیم‌اسپیس، پاد، نود، دیپلویمنت) غنی‌سازی و بچ می‌کنه و به گیت‌وی می‌سپره؛ گیت‌وی هم با OTLP روی HTTP و امضای SigV4 به اندپوینت بومی CloudWatch صادر می‌کنه و پردازشگر batch هر ارسال رو روی ۱۰۰۰ دیتاپوینت سقف می‌ذاره تا از محدودیت درخواست رد نشه. کنار اینا افزونهٔ CloudWatch Observability لایهٔ زیرین یعنی متریک نود و پاد و لاگ کانتینر رو می‌فرسته تا بفهمی خرابی از پایپ‌لاینه یا از خود نودها.

خودِ گیت‌وی یه پایپ‌لاین جدا به اسم metrics/internal داره که هر ۱۰ ثانیه اندپوینت تله‌متری داخلیش رو scrape می‌کنه. متریک‌های کلیدی otelcol_receiver_accepted_metric_points (داده‌ای که وارد شده)، otelcol_receiver_refused_metric_points (هر مقدار غیرصفر یعنی داده داره از دست می‌ره)، otelcol_exporter_send_failed_metric_points و نسبت otelcol_exporter_queue_size به ظرفیت صف هستن. شاخص اصلی نسبت ارسال‌شده به پذیرفته‌شده‌ست که باید نزدیک ۱.۰ بمونه؛ همون رو مثل یه SLO بذار و باهاش آلارم بساز:

sum(rate(otelcol_exporter_sent_metric_points[5m])) / sum(rate(otelcol_receiver_accepted_metric_points[5m])) < 0.99

برای چند کلاستر لازم نیست هر کدوم گیت‌وی خودش رو داشته باشه؛ نویسنده پیشنهاد می‌ده گیت‌وی رو به یه لایهٔ مشترک پشت یه NLB داخلی ببری و ایجنت همهٔ کلاسترها رو به همون اندپوینت وصل کنی. برای VPCهای جدا، از VPC peering یا Transit Gateway استفاده می‌شه و برای اکانت‌های مختلف از PrivateLink یا metrics centralization استفاده می‌شه که خود AWS متریک‌ها رو تو یه اکانت مقصد جمع می‌کنه. یادت باشه داشبورد و آلارم و ingest متریک تو CloudWatch هزینه داره، پس بعد از تست منابع رو پاک کن.

نکات کلیدی:

• الگوی agent-to-gateway: ایجنت روی هر نود جمع و غنی‌سازی می‌کنه، گیت‌وی مرکزی بچ و احراز هویت و export رو به عهده داره
• گیت‌وی تنها نقطهٔ خروجی به CloudWatch می‌شه، پس سمپلینگ و فیلتر و کنترل هزینه یه جا جمع می‌شه
• پشتیبانی بومی CloudWatch از OTLP یعنی دیگه اکسپورتر اختصاصی هر vendor لازم نیست
• پایپ‌لاین metrics/internal هر ۱۰ ثانیه سلامت خود گیت‌وی رو گزارش می‌ده و با PromQL تو Query Studio می‌شه کوئریش کرد
• نسبت sent به accepted شاخص اصلیه؛ اشباع صف و رشد refused یعنی داره داده گم می‌شه