🥇Логване в Kubernetes: EFK срещу PLG

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

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

Стек EFK

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

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

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

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

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

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

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

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

master node — управлява кластера, нужно е минимум три, един е активен винаги;
data node — съхранява индексирани данни и извършва различни задачи с тях;
ingest node — организира конвейери за преобразуване на данни преди индексиране;
coordinating node — маршрутизиране на заявки, намаляване на фазата на обработка на търсене, координация на масова индексация;
alerting node — стартиране на задачи за уведомяване;
machine learning node — обработка на задачи за машинно обучение.

На диаграмата по-долу е показано как данните се съхраняват и репликират по възли за постигане на по-висока наличност на данните.

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

Инсталиране

Подробностите можете да видите тук., ще използвам helm chart:

$ 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. Grafana — инструмент за визуализация, основан на данни от Loki.

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

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

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

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

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

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

Съставни части:

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

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

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

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

Chunks — блокове на журналите в компресиран вид, обикновено съхранявани в обектно хранилище, например, S3.

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

А сега нека видим всичко в действие.

Инсталиране

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

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

$ 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.

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

Сравнение

Език на запитванията

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

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

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

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

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

Мултиарендност

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

Цена

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

Заключение

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

Стекът Loki е полезен в екосистемата на Kubernetes заради механизма за откритие на метаданни. Лесно може да се съпоставят данни за наблюдение, базирани на времеви редове в Grafana и журналите.

Когато става въпрос за разходите и дългосрочното съхранение на журналите, Loki е отличен избор за вход в облачните решения.

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

Връзки:

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

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