ورود به سیستم Kubernetes: EFK در مقابل PLG

ورود به سیستم Kubernetes: EFK در مقابل PLG

با افزایش پیچیدگی سیستم های توزیع شده، نظارت به یک جزء بسیار مهم در راه حل های ابری در حال رشد تبدیل شده است. درک رفتار آنها ضروری است. ما به ابزارهای مقیاس‌پذیری نیاز داریم که بتوانند داده‌ها را از همه سرویس‌ها جمع‌آوری کنند - و متخصصان را با یک رابط واحد با تجزیه و تحلیل عملکرد، نمایش خطا، در دسترس بودن و گزارش‌ها ارائه دهند.

همین ابزارها باید کارآمد و مولد باشند. در این مقاله به دو پشته فناوری محبوب EFK (Elasticsearch) و PLG (Loki) می پردازیم و معماری و تفاوت آنها را بررسی می کنیم.

پشته EFK

ممکن است قبلاً در مورد ELK یا EFK بسیار محبوب شنیده باشید. پشته از چندین بخش متمایز تشکیل شده است: Elasticsearch (ذخیره سازی اشیاء)، Logstash یا FluentD (جمع آوری و تجمیع log) و Kibana برای تجسم.

یک گردش کار معمولی به صورت زیر است:

ورود به سیستم Kubernetes: EFK در مقابل PLG

ارزیابی جستجو - ذخیره سازی اشیاء با جستجو و تجزیه و تحلیل بلادرنگ. راه حل عالی برای داده های نیمه ساختار یافته مانند سیاهههای مربوط. اطلاعات به‌عنوان اسناد JSON ذخیره می‌شوند، در زمان واقعی فهرست‌بندی می‌شوند و در گره‌های خوشه‌ای توزیع می‌شوند. از یک نمایه معکوس استفاده می شود که شامل تمام کلمات منحصر به فرد و اسناد مرتبط برای جستجوی متن کامل است که به نوبه خود بر اساس موتور جستجوی آپاچی لوسن است.

FluentD یک گردآورنده داده است که داده ها را هنگام جمع آوری و مصرف یکپارچه می کند. سعی می کند تا حد امکان داده ها را در JSON سازماندهی کند. معماری آن قابل توسعه است، موارد بیشتری وجود دارد صدها پسوند مختلف، با حمایت جامعه، برای همه موارد.

کیبانا - یک ابزار تجسم داده برای Elasticsearch با قابلیت های مختلف اضافی، به عنوان مثال، تجزیه و تحلیل سری های زمانی، تجزیه و تحلیل نمودار، یادگیری ماشین و غیره.

معماری Elasticsearch

داده های خوشه ای Elasticsearch در همه گره های آن ذخیره می شود. یک خوشه از چندین گره برای بهبود در دسترس بودن و انعطاف پذیری تشکیل شده است. هر گره ای می تواند تمام نقش های خوشه را انجام دهد، اما در استقرارهای بزرگ مقیاس، معمولاً به گره ها وظایف فردی اختصاص داده می شود.

انواع گره های خوشه ای:

  • گره اصلی - خوشه را مدیریت می کند، حداقل سه مورد نیاز است، یکی همیشه فعال است.
  • گره داده - داده های فهرست شده را ذخیره می کند و وظایف مختلفی را با آن انجام می دهد.
  • ingest node - خطوط لوله را برای تبدیل داده ها قبل از نمایه سازی سازماندهی می کند.
  • هماهنگی گره - درخواست های مسیریابی، کاهش مرحله پردازش جستجو، هماهنگی فهرست سازی انبوه.
  • گره هشدار - راه اندازی وظایف هشدار؛
  • گره یادگیری ماشین - پردازش وظایف یادگیری ماشین.

نمودار زیر نشان می‌دهد که چگونه داده‌ها در گره‌ها ذخیره و تکثیر می‌شوند تا دسترسی به داده‌های بالاتری حاصل شود.

ورود به سیستم Kubernetes: EFK در مقابل PLG

داده های هر ماکت در یک شاخص معکوس ذخیره می شود، نمودار زیر نشان می دهد که چگونه این اتفاق می افتد:

ورود به سیستم Kubernetes: EFK در مقابل PLG

نصب

جزئیات قابل مشاهده است اینجا، من از نمودار فرمان استفاده خواهم کرد:

$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elastics

پشته PLG

اگر نتوانستید این مخفف را پیدا کنید تعجب نکنید، زیرا بیشتر با نام Grafana Loki شناخته می شود. در هر صورت، این پشته در حال افزایش محبوبیت است زیرا از راه حل های فنی اثبات شده استفاده می کند. شاید قبلاً نام Grafana، یک ابزار تجسم محبوب را شنیده باشید. سازندگان آن، با الهام از پرومتئوس، Loki را توسعه دادند، یک سیستم جمع‌آوری گزارش با عملکرد بالا و مقیاس‌پذیر افقی. Loki فقط ابرداده ها را نمایه می کند، نه خود مجلات را، یک راه حل فنی که امکان استفاده آسان و مقرون به صرفه را فراهم می کند.

Promtail - عاملی برای ارسال گزارش از سیستم عامل به خوشه Loki. گرافانا یک ابزار تجسم بر اساس داده های لوکی است.

ورود به سیستم Kubernetes: EFK در مقابل PLG

Loki بر اساس همان اصول Prometheus ساخته شده است و آن را برای ذخیره و تجزیه و تحلیل سیاهه های Kubernetes مناسب می کند.

معماری لوکی

Loki را می توان به عنوان یک فرآیند واحد یا به صورت چندین فرآیند اجرا کرد که امکان مقیاس بندی افقی را فراهم می کند.

ورود به سیستم Kubernetes: EFK در مقابل PLG

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

بیایید بدون پرداختن به جزئیات به معماری سیستم جمع آوری لاگ نگاه کنیم:

ورود به سیستم Kubernetes: EFK در مقابل PLG

و در اینجا توضیحات (معماری میکروسرویس):

ورود به سیستم Kubernetes: EFK در مقابل PLG

اجزاء:

Promtail - یک عامل نصب شده بر روی گره ها (به عنوان مجموعه ای از خدمات)، گزارش ها را از وظایف حذف می کند و به API Kubernetes دسترسی پیدا می کند تا ابرداده هایی را به دست آورد که گزارش ها را برچسب گذاری می کند. سپس گزارش را به سرویس اصلی Loki ارسال می کند. نقشه برداری ابرداده از قوانین برچسب گذاری مشابه Prometheus پشتیبانی می کند.

توزیع کننده - یک توزیع کننده خدمات که به عنوان یک بافر کار می کند. برای پردازش میلیون‌ها رکورد، داده‌های دریافتی را بسته‌بندی می‌کند و به محض رسیدن، آن‌ها را در بلوک‌هایی فشرده می‌کند. چندین سینک داده به طور همزمان در حال اجرا هستند، اما گزارش‌های متعلق به یک جریان داده ورودی فقط باید در یکی از آنها برای همه بلوک‌های آن ظاهر شوند. این به حلقه‌ای از سینک و هش متوالی سازماندهی شده است. برای تحمل خطا و افزونگی، این کار n بار انجام می شود (اگر پیکربندی نشده باشد 3).

مصرف کننده - گیرنده خدمات بلوک های داده فشرده شده با لاگ های اضافه شده وارد می شوند. هنگامی که بلوک از اندازه کافی برخوردار شد، بلوک به پایگاه داده منتقل می شود. ابرداده به فهرست می‌رود و داده‌های بلوک گزارش به Chunks (معمولاً ذخیره‌سازی اشیا) می‌رود. پس از تنظیم مجدد، گیرنده یک بلوک جدید ایجاد می کند که در آن ورودی های جدید اضافه می شود.

ورود به سیستم Kubernetes: EFK در مقابل PLG

شاخص - پایگاه داده، DynamoDB، Cassandra، Google BigTable و غیره

تنه - بلوک های ورود به سیستم به صورت فشرده، معمولاً در ذخیره سازی اشیاء، به عنوان مثال، S3 ذخیره می شوند.

پرس و جو - مسیر خواندن که همه کارهای کثیف را انجام می دهد. به محدوده زمانی و مُهر زمانی نگاه می‌کند و سپس برای یافتن موارد منطبق به فهرست نگاه می‌کند. در مرحله بعد، بلوک های داده را می خواند و آنها را فیلتر می کند تا به نتیجه برسد.

حالا بیایید همه چیز را در عمل ببینیم.

نصب

ساده ترین راه برای نصب در Kubernetes استفاده از هل است. ما فرض می کنیم که شما قبلا آن را نصب و پیکربندی کرده اید (و نسخه سوم! تقریبا مترجم)

یک مخزن اضافه کنید و یک پشته نصب کنید.

$ helm repo add loki https://grafana.github.io/loki/charts
$ helm repo update
$ helm upgrade --install loki loki/loki-stack --set grafana.enabled=true,prometheus.enabled=true,prometheus.alertmanager.persistentVolume.enabled=false,prometheus.server.persistentVolume.enabled=false

در زیر یک داشبورد نمونه وجود دارد که داده‌های Prometheus را برای معیارهای Etcd و Loki برای گزارش‌های pod Etcd نشان می‌دهد.

ورود به سیستم Kubernetes: EFK در مقابل PLG

حال بیایید معماری هر دو سیستم را مورد بحث قرار دهیم و همچنین قابلیت های آنها را با یکدیگر مقایسه کنیم.

مقایسه

زبان پرس و جو

Elasticsearch از Query DSL و زبان جستجوی Lucene برای ارائه قابلیت های جستجوی متن کامل استفاده می کند. این یک موتور جستجوی قوی و مستقر با پشتیبانی گسترده اپراتور است. با آن، می توانید بر اساس زمینه جستجو کنید و بر اساس ارتباط مرتب کنید.

در طرف دیگر حلقه LogQL است که در Loki، جانشین PromQL (زبان پرس و جو Prometheus) استفاده می شود. از تگ های گزارش برای فیلتر کردن و انتخاب داده های گزارش استفاده می کند. می توان از برخی عملگرها و محاسباتی که توضیح داده شد استفاده کرد اینجا، اما از نظر قابلیت ها از زبان الاستیک عقب است.

از آنجایی که پرس و جوها در Loki با برچسب ها مرتبط هستند، به راحتی با معیارها مرتبط می شوند و در نتیجه، سازماندهی نظارت عملیاتی با آنها آسان تر است.

مقیاس پذیری

هر دو پشته به صورت افقی مقیاس پذیر هستند، اما Loki این کار را آسان تر می کند زیرا دارای مسیرهای خواندن و نوشتن جداگانه و معماری میکروسرویس است. Loki را می توان مطابق با نیازهای شما سفارشی کرد و می توان از آن برای حجم بسیار زیادی از داده های گزارش استفاده کرد.

چند اجاره ای

چند اجاره ای خوشه ای یک موضوع رایج در مخفف OPEX است، هر دو پشته چند اجاره ای را ارائه می دهند. چندین مورد برای Elasticsearch وجود دارد راه ها جداسازی مشتری: فهرست جداگانه برای هر مشتری، مسیریابی مبتنی بر مشتری، فیلدهای مشتری منحصر به فرد، فیلترهای جستجو. لوکی دارد پشتیبانی در قالب یک هدر HTTP X-Scope-OrgID.

هزینه

Loki بسیار مقرون به صرفه است، زیرا داده ها را فهرست نمی کند، فقط ابرداده ها را فهرست می کند. این به دست می آورد صرفه جویی در ذخیره سازی و حافظه (کش)، از آنجایی که ذخیره سازی شی ارزان تر از ذخیره سازی بلوکی است که در خوشه های Elasticsearch استفاده می شود.

نتیجه

پشته EFK را می توان برای اهداف مختلفی مورد استفاده قرار داد که حداکثر انعطاف پذیری و یک رابط Kibana غنی از ویژگی ها برای تجزیه و تحلیل، تجسم و پرس و جو ارائه می کند. با قابلیت های یادگیری ماشینی می توان آن را بیشتر تقویت کرد.

پشته Loki در اکوسیستم Kubernetes به دلیل مکانیسم کشف ابرداده آن مفید است. شما به راحتی می توانید داده ها را برای نظارت بر اساس سری های زمانی در Grafana و گزارش ها به هم مرتبط کنید.

هنگامی که صحبت از هزینه و ذخیره سازی طولانی مدت گزارش می شود، Loki یک نقطه ورود عالی به راه حل های ابری است.

جایگزین های بیشتری در بازار وجود دارد - برخی ممکن است برای شما بهتر باشند. به عنوان مثال، GKE دارای یک ادغام Stackdriver است که یک راه حل نظارت عالی را ارائه می دهد. ما آنها را در تحلیل خود در این مقاله لحاظ نکردیم.

لینک ها:

مقاله توسط کارمندان برای هابر ترجمه و تهیه شده است مرکز آموزش اسلرم - دوره های فشرده، دوره های ویدیویی و آموزش شرکتی از متخصصان مجرب (Kubernetes، DevOps، Docker، Ansible، Ceph، SRE، Agile)

منبع: www.habr.com

اضافه کردن نظر