Маніторынг стаў вельмі важным кампанентам растучых хмарных рашэнняў з ростам складанасці размеркаваных сістэм. Ён неабходны для разумення іх паводзін. Патрэбны якія маштабуюцца прылады, якія змогуць сабраць дадзеныя са ўсіх сэрвісаў — і падаць адмыслоўцам адзіны інтэрфейс з аналізам прадукцыйнасці, дэманстрацыяй памылак, даступнасцю і часопісамі.
Гэтыя ж прылады павінны быць эфектыўнымі і прадукцыйнымі. У гэтым артыкуле мы разгледзім два папулярных стэка тэхналогій: EFK (Elasticsearch) і PLG (Loki) і разбяром іх архітэктуры і адрозненні.
Стэк EFK
Магчыма, вы ўжо чулі пра вельмі папулярны ELK ці EFK. Стэк складаецца з некалькіх асобных частак: Elasticsearch (аб'ектнае сховішча), Logstash або FluentD (збор і агрэгацыя часопісаў) і Kibana для візуалізацыі.
Тыповая схема працы выглядае так:
Elasticsearch - размеркаванае аб'ектнае сховішча з пошукам і аналітыкай у рэальным часе. Выдатнае рашэнне для часткова структураваных дадзеных, напрыклад часопісаў. Інфармацыя захоўваецца ў выглядзе дакументаў JSON, індэксуецца ў рэжыме рэальнага часу і размяркоўваецца па вузлах кластара. Ужываецца інвертаваны азначнік, утрымоўвальны ўсе ўнікальныя словы і злучаныя з імі дакументы для паўнацёкавага пошуку, які ў сваю чаргу заснаваны на пошукавым рухавічку Apache Lucene.
FluentD - Гэта зборшчык дадзеных, які выконвае уніфікацыю дадзеных пры іх зборы і спажыванні. Ён імкнецца ўпарадкаваць дадзеныя ў JSON наколькі гэта магчыма. Яго архітэктура пашыраецца, існуе больш , якія падтрымліваюцца супольнасцю, на ўсе выпадкі жыцця.
Kibana - сродак візуалізацыі дадзеных для Elasticsearch з рознымі дадатковымі магчымасцямі, напрыклад, аналізам часавых шэрагаў, графаў, машынным навучаннем і іншым.
Архітэктура Elasticsearch
Дадзеныя кластара Elasticsearch захоўваюцца размазанымі па ўсіх яго вузлах. Кластар складаецца з некалькіх вузлоў для паляпшэння даступнасці і ўстойлівасці. Любы вузел можа выконваць усе ролі кластара, але ў буйных якія маштабуюцца разгортвання вузлам звычайна прызначаюць асобныя задачы.
Тыпы вузлоў кластара:
- мaster 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. Графана - Інструмент візуалізацыі на аснове дадзеных з Loki.
Loki пабудаваны на тых жа прынцыпах, што і Prometheus, таму ен добра падыходзіць для захоўвання і аналізу часопісаў Kubernetes.
Архітэктура Loki
Loki можа быць запушчаны як у рэжыме аднаго працэсу, так і ў выглядзе некалькіх працэсаў, што забяспечвае гарызантальнае маштабаванне.
Таксама ён можа працаваць, як у выглядзе маналітнага дадатку, так і ў выглядзе мікрасэрвісу. Запуск у выглядзе аднаго працэсу можа спатрэбіцца для лакальнай распрацоўкі ці ж для дробнага маніторынгу. Для прамысловага ўкаранення і якая маштабуецца нагрузкі рэкамендуецца ўжываць мікрасэрвісны варыянт. Шляхі запісу і чытання дадзеных падзелены, так што яго можна дастаткова тонка наладзіць і маштабаваць па неабходнасці.
Давайце паглядзім на архітэктуру сістэмы збору часопісаў без дэталізацыі:
А тут – апісанне (мікрасэрвісная архітэктура):
Складовыя часткі:
Promtail - агент, які ўсталёўваецца на вузлы (у выглядзе набору сэрвісаў), ён здымае часопісы з задач і звяртаецца да API Kubernetes для атрымання метададзеных, якімі будуць пазначаныя часопісы. Затым ён адпраўляе часопіс да асноўнага сэрвісу Loki. Для параўнання метададзеных падтрымліваюцца тыя ж правілы для маркіроўкі, што і ў Prometheus.
Дыстрыб'ютар - сэрвіс-размеркавальнік, які працуе як буфер. Для апрацоўкі мільёнаў запісаў ён вырабляе пакаванне ўваходных дадзеных, сціскаючы іх блокамі па меры іх паступлення. Адначасова працуе некалькі прымачоў дадзеных, але часопісы, прыналежныя аднаму струменю ўваходных дадзеных павінны апынуцца толькі ў адным з іх для ўсіх яго блокаў. Гэта арганізавана ў выглядзе кольца прымачоў і паслядоўнага хэшавання. Для адмоваўстойлівасці і надмернасці яно робіцца n разоў (3, калі не наладжваць).
Ingester - сэрвіс-прымач. Блокі дадзеных прыходзяць сціснутымі з дададзенымі часопісамі. Як толькі блок аказваецца дастатковага памеру, робіцца скід блока ў базу дадзеных. Метададзеныя ідуць у індэкс, а дадзеныя ад блока з часопісам трапляюць у 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.
А зараз давайце абмяркуем архітэктуру абедзвюх сістэм, а таксама параўнаем іх магчымасці паміж сабой.
параўнанне
Мова запытаў
У 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 вельмі эфектыўны эканамічна з-за таго, што ён не робіць індэксацыю дадзеных, а толькі метададзеных. Такім чынам дасягаецца і памяці (кэшы), паколькі аб'ектнае сховішча танней блочнага, якое выкарыстоўваецца ў кластарах Elasticsearch.
Заключэнне
Стэк EFK можа выкарыстоўвацца для розных мэт, забяспечваючы максімальную гнуткасць і шматфункцыянальны інтэрфейс Kibana для аналітыкі, візуалізацыі і запытаў. Ён дадаткова можа быць палепшаны магчымасцямі машыннага навучання.
Стэк Loki карысны ў экасістэме Kubernetes з-за механізму выяўлення метададзеных. Можна лёгка супаставіць дадзеныя для маніторынгу на аснове часавых шэрагаў у Grafana і часопісах.
Калі гаворка ідзе аб кошце і працяглым захоўванні часопісаў, Loki з'яўляецца выдатным выбарам для ўваходу ў хмарныя рашэнні.
На рынку ёсць больш альтэрнатыў - некаторыя могуць быць лепш для вас. Напрыклад, для GKE ёсць інтэграцыя Stackdriver, якая забяспечвае выдатнае рашэнне для маніторынгу. Мы не ўключылі іх у наш аналіз у гэтым артыкуле.
спасылкі:
Артыкул перакладзены і падрыхтаваны для Хабра супрацоўнікамі - Інтэнсіўы, відэакурсы і карпаратыўнае навучанне ад практыкуючых спецыялістаў (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Крыніца: habr.com