راه اندازی ELK و Grafana Loki برای لاگ مرکزی و مانیتورینگ با Prometheus

راهنمای مانیتورینگ و لاگ (ELK و Grafana)

Grafana Loki با Promtail یا Grafana Alloy؟

بیشتر آموزش های Grafana Loki برای ارسال لاگ از Promtail استفاده می کنند، ولی Grafana توسعه Promtail را متوقف کرده و Grafana Alloy را جایگزین آن معرفی کرده است. Alloy همان جمع آوری لاگ را انجام می دهد و متریک و trace را هم می تواند بفرستد. به همین دلیل روی نصب های جدید از Alloy استفاده می کنیم و Promtailهای موجود را با برنامه منتقل می کنیم.

نکته مهم تر از خود ابزار، labelهاست. Loki لاگ ها را بر اساس label دسته بندی می کند و گذاشتن مقادیر پرتنوع مثل شناسه کاربر، IP یا request_id در label، تعداد streamها را بسیار زیاد و Loki را کند می کند. این مقادیر باید داخل متن لاگ بمانند و هنگام جست وجو با LogQL فیلتر شوند.

Grafana Loki با Docker Compose برای شروع کافی است؟

برای حجم کم تا متوسط لاگ، Loki در حالت monolithic که همه اجزا را در یک فرایند اجرا می کند، همراه Grafana و Prometheus در یک فایل Docker Compose به خوبی کار می کند. دو شرط دارد: داده ها روی volume پایدار باشند و retention در compactor فعال شود، وگرنه لاگ ها هیچ وقت پاک نمی شوند و دیسک پر می شود.

وقتی حجم لاگ روزانه زیاد شد یا به دسترس پذیری بالا نیاز داشتید، Loki را با ذخیره سازی سازگار با S3 مثل MinIO و به شکل توزیع شده روی کوبرنتیز اجرا می کنیم. شروع با Compose مسیر رشد را نمی بندد.

اشتباهات رایج در داشبورد مانیتورینگ و هشدار

رایج ترین مشکل، هشدار روی علت به جای علامت است. CPU بالای 90 درصد به خودش مشکل نیست؛ افزایش زمان پاسخ یا نرخ خطای 5xx مشکل است. قاعده هشداری که بند for ندارد، با هر جهش کوتاه پیام می فرستد و تیم را به نادیده گرفتن هشدارها عادت می دهد.

در Prometheus، labelهای پرتنوع حافظه را سریع پر می کنند و retention پیش فرض 15 روز برای مقایسه ماه به ماه کافی نیست. سرور مانیتورینگی هم که روی همان میزبان تحت پایش نصب شده، با از کار افتادن آن خاموش می شود؛ هشدار Watchdog که همیشه فعال است و قطع شدنش خبر می دهد، این شکاف را پوشش می دهد.

منابع لازم برای راه اندازی ELK و مانیتورینگ به چه عواملی بستگی دارد؟

حجم لاگ روزانه و مدت نگهداری، اندازه دیسک را تعیین می کنند. Elasticsearch رم زیادی هم می خواهد؛ heap آن معمولاً حدود نیمی از رم سرور و کمتر از حدود 31 گیگابایت تنظیم می شود و بقیه رم برای cache فایل سیستم می ماند.

در بخش متریک، تعداد سری های زمانی فعال مهم است که از تعداد سرورها، exporterها و labelها به دست می آید. عوامل دیگر نیاز به دسترس پذیری بالا برای خود سیستم مانیتورینگ، راه اندازی tracing با OpenTelemetry و تعداد تیم هایی است که دسترسی و داشبورد جداگانه می خواهند.