Влизане в Kubernetes: EFK срещу PLG

Мониторингът се превърна във много важен компонент на нарастващите облачни решения с нарастващата сложност на разпределените системи. Необходимо е да се разбере тяхното поведение. Имаме нужда от мащабируеми инструменти, които могат да събират данни от всички услуги - и да предоставят на специалистите единен интерфейс с анализ на ефективността, демонстрация на грешки, наличност и регистрационни файлове.

Същите тези инструменти трябва да бъдат ефективни и продуктивни. В тази статия ще разгледаме два популярни технологични стека: EFK (Elasticsearch) и PLG (Loki) и ще анализираме техните архитектури и разлики.

EFK стек

Може би вече сте чували за много популярните ELK или EFK. Стекът се състои от няколко отделни части: Elasticsearch (съхранение на обекти), Logstash или FluentD (събиране и агрегиране на регистрационни файлове) и Kibana за визуализация.

Типичен работен процес изглежда така:

Elasticsearch — разпределено съхранение на обекти с търсене и анализ в реално време. Отлично решение за полуструктурирани данни като регистрационни файлове. Информацията се съхранява като JSON документи, индексирани в реално време и разпределени между възлите на клъстера. Използва се обърнат индекс, съдържащ всички уникални думи и свързани документи за пълнотекстово търсене, което от своя страна е базирано на търсачката Apache Lucene.

FluentD е колектор на данни, който обединява данните, докато се събират и консумират. Той се опитва да организира данните в JSON колкото е възможно повече. Архитектурата му е разширяема, има още стотици различни разширения, поддържан от общността, за всички поводи.

Kibana е инструмент за визуализация на данни за Elasticsearch с различни допълнителни функции, като анализ на времеви редове, графики, машинно обучение и др.

Архитектура на Elasticsearch

Данните на клъстера Elasticsearch се съхраняват разпределени във всички негови възли. Клъстерът се състои от множество възли за подобряване на наличността и устойчивостта. Всеки възел може да изпълнява всички роли на клъстера, но при големи, мащабируеми внедрявания на възлите обикновено се възлагат отделни задачи.

Типове клъстерни възли:

• главен възел - управлява клъстера, трябват ви поне три, единият винаги е активен;
• възел за данни - съхранява индексирани данни и изпълнява различни задачи с тях;
• възел за поглъщане - организира конвейери за трансформиране на данни преди индексиране;
• координиращ възел - маршрутизиране на заявка, намаляване на фазата на обработка на търсенето, координиране на групово индексиране;
• възел за предупреждение - стартиране на задачи за уведомяване;
• възел за машинно обучение - обработка на задачи за машинно обучение.

Диаграмата по-долу показва как данните се поддържат и репликират между възли, за да се постигне по-висока наличност на данни.

Данните на всяка реплика се съхраняват в обърнат индекс, диаграмата по-долу показва как се случва това:

Инсталация

Подробностите могат да се видят тук, ще използвам диаграма на кормилото:

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

PLG стек

Не се изненадвайте, ако не можете да намерите това съкращение, тъй като е по-известно като Grafana Loki. Във всеки случай този стек набира популярност, защото използва добре нагласени технически решения. Може би вече сте чували за Grafana, популярен инструмент за визуализация. Неговите създатели, вдъхновени от Prometheus, разработиха Loki, хоризонтално мащабируема, високопроизводителна система за агрегиране на журнали. Loki индексира само метаданните, а не самите журнали, това техническо решение го прави лесен за използване и рентабилен.

Promtail - агент за изпращане на логове от операционната система към клъстера Loki. Графана е инструмент за визуализация, базиран на данни от Loki.

Loki е изграден на същите принципи като Prometheus, така че е много подходящ за съхранение и парсване на регистрационни файлове на Kubernetes.

Архитектура на Локи

Loki може да се изпълнява като един процес или като множество процеси, което позволява хоризонтално мащабиране.

Може да работи както като монолитно приложение, така и като микроуслуга. Изпълнението като един процес може да бъде полезно за местно развитие или за фин мониторинг. За индустриално внедряване и мащабируемо работно натоварване се препоръчва използването на опцията за микросервиз. Пътищата за писане и четене на данни са разделени, така че да могат да бъдат фино настроени и мащабирани според нуждите.

Нека да разгледаме архитектурата на системата за събиране на регистрационни файлове без подробности:

И ето описанието (архитектура на микросервизи):

Компоненти:

Promtail - агент, инсталиран на възли (като набор от услуги), той премахва регистрационни файлове от задачи и осъществява достъп до Kubernetes API, за да получи метаданни, които ще се използват за маркиране на регистрационните файлове. След това изпраща дневника до основната услуга на Loki. За съвпадение на метаданни се поддържат същите правила за маркиране като в Prometheus.

Дистрибутор - сервиз-дистрибутор, работещ като буфер. За да обработи милиони записи, той пакетира входящите данни, като ги компресира в блокове, когато пристигнат. Множество приемници на данни работят едновременно, но регистрационните файлове, принадлежащи към един и същ входящ поток от данни, трябва да завършват само в един от тях за всички негови блокове. Това е организирано като пръстен от приемници и последователно хеширане. За устойчивост на грешки и резервиране се прави n пъти (3, ако не е конфигурирано).

поглъщам — сервизен приемник. Блоковете с данни идват компресирани с добавени регистрационни файлове. Веднага щом блокът стане с достатъчен размер, той се изхвърля в базата данни. Метаданните отиват в индекса, а данните от лог блока отиват в Chunks (обикновено място за съхранение на обекти). След нулирането приемникът създава нов блок, където ще се добавят нови записи.

индекс - база данни, DynamoDB, Cassandra, Google BigTable и др.

Хапки - блокове от регистрационни файлове в компресирана форма, обикновено съхранявани в обектно хранилище, например S3.

Querier е пътека за четене, която върши цялата мръсна работа. Той преглежда времевия диапазон и времевия печат и след това преглежда индекса, за да търси съвпадения. След това чете блокове от данни и ги филтрира, за да получи резултата.

Сега нека видим всичко на работа.

Инсталация

Най-лесният начин за инсталиране на Kubernetes е да използвате helm. Предполагаме, че вече сте го инсталирали и конфигурирали (и третата версия! прибл. преводач)

Добавяме хранилище и поставяме стек.

$ 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 за регистрационни файлове на Etcd pod.

А сега нека обсъдим архитектурата на двете системи, както и да сравним техните възможности една с друга.

Сравнение

Език за заявки

Elasticsearch използва езика за заявки Query DSL и Lucene, за да предостави възможност за пълнотекстово търсене. Това е утвърдена мощна търсачка с широка поддръжка от оператори. С него можете да търсите по контекст и да сортирате по уместност.

От другата страна на пръстена е LogQL на Loki, наследник на PromQL (език за заявки Prometheus). Той използва етикети на регистрационни файлове за филтриране и избор на данни от регистрационни файлове. Възможно е да използвате някои оператори и аритметика, както е описано тук, но по отношение на възможностите изостава от езика Elastic.

Тъй като заявките в Loki са свързани с етикети, те лесно се свързват с показатели, в резултат на което е по-лесно да се организира оперативен мониторинг с тях.

Мащабируемост

И двата стека са хоризонтално мащабируеми, но с Loki е по-лесно, защото има отделни пътеки за четене и запис и има микросервизна архитектура. Loki може да бъде персонализиран според вашите нужди и може да се използва за много големи обеми от регистрационни данни.

Многонаемност

Мултинаемането на клъстер е често срещана тема за намаляване на OPEX, и двата стека осигуряват многонаемане. Има няколко за Elasticsearch начини разделяне на клиентите: отделен индекс за всеки клиент, базирано на клиента маршрутизиране, уникални полета за клиента, филтри за търсене. Локи има подкрепа като заглавка HTTP X-Scope-OrgID.

Цена

Loki е много ефективен поради факта, че не индексира данни, а само метаданни. По този начин, спестявания при съхранение и памет (кеш), тъй като съхранението на обекти е по-евтино от блоковото съхранение, което се използва в Elasticsearch клъстери.

Заключение

Стекът EFK може да се използва за различни цели, осигурявайки максимална гъвкавост и богат интерфейс на Kibana за анализи, визуализация и заявки. Може да бъде допълнително подобрен с възможности за машинно обучение.

Стекът Loki е полезен в екосистемата на Kubernetes поради механизма за откриване на метаданни. Можете лесно да корелирате данни за мониторинг въз основа на времеви редове в Grafana и регистрационни файлове.

Когато става въпрос за разходи и дългосрочно запазване на регистрационни файлове, Loki е отличен избор за навлизане в облака.

Има повече алтернативи на пазара - някои може да са по-добри за вас. Например, GKE има интеграция на Stackdriver, която предоставя страхотно решение за наблюдение. Ние не ги включихме в нашия анализ в тази статия.

за справка:

• https://github.com/grafana/loki/blob/master/docs/overview/comparisons.md
• https://www.elastic.co/blog/found-elasticsearch-from-the-bottom-up
• https://www.elastic.co/blog/found-elasticsearch-in-production/

Статията е преведена и подготвена за Habr от служители Център за обучение на Slurm — интензивни, видео курсове и корпоративно обучение от практици (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Източник: www.habr.com