🥇Ierakstīšana Kubernetes: EFK pret PLG

Uzraudzība ir kļuvusi par ļoti svarīgu komponenti pieaugošajām mākoņa risinājumiem, palielinoties sadalīto sistēmu sarežģītībai. Tā ir nepieciešama, lai izprastu to uzvedību. Ir vajadzīgi skalojami rīki, kas var savākt datus no visām pakalpojumu sniedzējām - un nodrošināt speciālistiem vienotu interfeisu ar veiktspējas analīzi, kļūdu demonstrēšanu, pieejamību un žurnāliem.

Šiem rīkiem jābūt efektīviem un produktīviem. Šajā rakstā mēs apskatīsim divus populārus tehnoloģiju stekus: EFK (Elasticsearch) un PLG (Loki) un analizēsim to arhitektūru un atšķirības.

EFK steks

Iespējams, jūs jau esat dzirdējuši par ļoti populāro ELK vai EFK. Steks sastāv no vairākiem atsevišķiem komponentiem: Elasticsearch (objektu glabātuve), Logstash vai FluentD (žurnālu vākšana un agregācija) un Kibana vizualizācijai.

Tipiska darbības shēma izskatās šādi:

Elasticsearch — sadalīta objektu glabātuve ar reāllaika meklēšanu un analīzi. Lieliska risinājums daļēji strukturētiem datiem, piemēram, žurnāliem. Informācija tiek saglabāta JSON dokumentu veidā, tiek indeksēta reāllaikā un sadalīta pa klastera mezgliem. Tiek izmantota apgriezta indeksēšana, kas satur visus unikālos vārdus un ar tiem saistītos dokumentus pilnteksta meklēšanai, kas, savukārt, balstīta uz Apache Lucene meklēšanas dzinēju.

FluentD — ir datu vācējs, kas veic datu unifikāciju to vākšanas un patēriņa procesā. Tas cenšas sakārtot datus JSON formātā, cik vien iespējams. Tās arhitektūra ir paplašināma, un ir pieejami vairāk nekā simti dažādu paplašinājumu, ko atbalsta kopiena, visām vajadzībām.

Kibana — datu vizualizācijas rīks Elasticsearch ar dažādām papildu iespējām, piemēram, laika rindu analīzi, grafiem, mašīnmācīšanos un citiem.

Elasticsearch arhitektūra

Elasticsearch klastera dati tiek glabāti izkliedēti visos tā mezglos. Klasteris sastāv no vairākiem mezgliem, lai uzlabotu pieejamību un izturību. Ikviens mezgls var veikt visas klastera lomas, taču lielos skalojamos izvietojumos mezgliem parasti piešķir atsevišķas uzdevumu lomas.

Klastera mezglu tipi:

master node — pārvalda klasteri, nepieciešami vismaz trīs, viena ir vienmēr aktīva;
data node — glabā indeksētos datus un veic ar tiem dažādus uzdevumus;
ingest node — organizē konveijerus datu transformēšanai pirms indeksēšanas;
coordinating node — pieprasījumu maršrutēšana, meklēšanas apstrādes fāzes saīsināšana, masveida indeksēšanas koordinācija;
alerting node — uzsāk uzdevumus brīdinājumam;
machine learning node — apstrādā mašīnmācīšanās uzdevumus.

Zemāk redzamajā diagrammā parādīts, kā dati tiek glabāti un replikēti starp mezgliem, lai nodrošinātu lielāku datu pieejamību.

Katras replikas dati tiek glabāti apgrieztajā indeksā, diagramma zemāk parāda, kā tas notiek:

Uzstādīšana

Detaļas var apskatīt šeit, es izmantosiu helm chart:

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

PLG steks

Nav brīnums, ja jūs nevarat atrast šo akronīmu, jo to labāk zina kā Grafana Loki. Katrā ziņā, šis steks kļūst populārs, jo izmanto precizētus tehniskos risinājumus. Iespējams, ka jūs jau esat dzirdējuši par Grafana, populāru vizualizācijas rīku. Tās radītāji, iedvesmojoties no Prometheus, izstrādāja Loki, horizontāli skalojamu augstas veiktspējas žurnālu agregācijas sistēmu. Loki indeksē tikai metadatus, bet ne pašus žurnālus, šis tehniskais risinājums ļāva tam kļūt par viegli lietojamu un ekonomiski izdevīgu risinājumu.

Promtail — aģents žurnālu sūtīšanai no operētājsistēmas uz Loki klasteri. Grafana — vizualizācijas rīks, kas balstīts uz datiem no Loki.

Loki ir veidots uz tiem pašiem principiem kā Prometheus, tāpēc tas ir labi piemērots Kubernetes žurnālu glabāšanai un analīzei.

Loki arhitektūra

Loki var darboties gan viena procesa režīmā, gan vairākos procesos, kas nodrošina horizontālo mērogojamību.

Tas var darboties arī kā monolīta lietojumprogramma, gan kā mikroserviss. Palaidīšana kā viena procesa režīmā var būt noderīga vietējai izstrādei vai nelielai monitorēšanai. Rūpnieciskajai ieviešanai un mērogojamiem slodzes apstākļiem ieteicams izmantot mikroservisa variantu. Ceļi datu ierakstīšanai un lasīšanai ir nošķirti, lai tos varētu pietiekami smalki konfigurēt un skalot pēc vajadzības.

Apskatīsim žurnālu vākšanas sistēmas arhitektūru bez detalizācijas:

Un šeit ir apraksts (mikroservisa arhitektūra):

Sastāvdaļas:

Promtail — aģents, kas tiek instalēts mezglos (kā pakalpojumu kopums), tas noņem žurnālus no uzdevumiem un izmanto Kubernetes API, lai iegūtu metadatus, ar kuriem tiks marķēti žurnāli. Pēc tam tas nosūta žurnālu galvenajam pakalpojumam Loki. Metadatu salīdzināšanai tiek izmantoti tie paši marķēšanas noteikumi kā Prometheus.

Izplatītājs — pakalpojums-izplatītājs, kas darbojas kā buferis. Lai apstrādātu milijonus ierakstu, tas veic ienākošo datu iepakošanu, saspiest tos blokos to piegādes laikā. Tajā pašā laikā strādā vairāki datu pieņēmēji, bet žurnāli, kas pieder vienai ienākošo datu straumei, nedrīkst būt vairākos no tiem visiem tās blokiem. Tas ir organizēts kā pieņēmēju gredzens un secīga heshēšana. Lai nodrošinātu drošību un liekās kapacitātes, tas tiek veikts n reizes (3, ja netiek konfigurēts).

Iegūstot — pakalpojums-pieņēmējs. Datu bloki ierodas saspiestā veidā ar pievienotiem žurnāliem. Tiklīdz bloks ir pietiekami liels, tiek veikta blokā iekļautā datu nosūtīšana uz datubāzi. Metadati iet uz indeksu, bet žurnāla bloka dati nonāk Chunks (parasti tas ir objektu krātuve). Pēc nosūtīšanas pieņēmējs izveido jaunu bloku, kurā tiks pievienoti jauni ieraksti.

Index — datubāze, DynamoDB, Cassandra, Google BigTable un citi.

Chunks — žurnālu bloki saspiestā veidā, parasti tiek glabāti objektu krātuvē, piemēram, S3.

Vaicātājs — lasīšanas ceļš, kas veic visu melno darbu. Tas apskata laika diapazonu un marķējumu, pēc tam skatās indeksu, lai meklētu atbilstības. Turklāt tas lasa datu blokus un filtrē tos, lai iegūtu rezultātu.

Tagad aplūkosim visu darbībā.

Uzstādīšana

Lai instalētu Kubernetes, visvieglāk ir izmantot helm. Pieņemam, ka jūs to jau esat uzstādījis un konfigurējis (un trešajai versijai! piezīme tulkotājam)

Pievienojam repozitoriju un uzstādām steku.

$ 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

Tālāk ir sniegts piemērs paneļa, kurā redzami dati no Prometheus par Etcd metrikām un Loki par Etcd podu žurnāliem.

Tagad apskatīsim abu sistēmu arhitektūru un salīdzināsim to iespējas.

Salīdzinājums

Vaicājumu valoda

Elasticsearch izmanto Query DSL un Lucene vaicājuma valodu, kas nodrošina iespēju veikt pilnteksta meklēšanu. Tas ir nostiprinājies spēcīgs meklēšanas dzinējs ar plašu operatoru atbalstu. Ar tā palīdzību var meklēt kontekstā un kārtot pēc attiecīguma.

Ringā ir LogQL, kas tiek izmantots Loki, kas ir PromQL (Prometheus vaicājuma valodas) mantinieks. Tas izmanto žurnālu atzīmes datu filtrēšanai un atlasei. Ir iespēja izmantot dažus operatorus un aritmētiku, kā aprakstīts, šeit, taču tā iespējas atpaliek no Elastic valodas.

Kopš vaicājumi Loki ir saistīti ar atzīmēm — tos ir viegli salīdzināt ar metriku, rezultātā ir vieglāk organizēt operatīvo uzraudzību.

Mērogojamība

Abi steki ir horizontāli mērogojami, bet ar Loki tas ir vienkāršāk, jo tam ir atdalīti lasīšanas un rakstīšanas ceļi, kā arī tam ir mikroservisu arhitektūra. Loki var konfigurēt atbilstoši jūsu īpatnībām un var tikt izmantots ļoti lieliem žurnālu datu apjomiem.

Multi-rentabilitāte

Klusteru multi-rentabilitāte ir kopēja tēma OPEX samazināšanai, abi steki nodrošina multi-rentabilitāti. Elasticsearch ir vairāki veidi kā sadalīt klientus: atsevišķs indekss katram klientam, maršrutēšana, pamatojoties uz klientu, unikālas klienta lauki, meklēšanas filtrus. Loki ir pieejami, atbalsts izmantojot HTTP galvene X-Scope-OrgID.

Cena

Loki ir ļoti izmaksu efektīvs, jo tas neveic datu indeksēšanu, bet tikai metadatu indeksēšanu. Tā rezultātā tiek panākta uzglabāšanas un atmiņas (kešatmiņas) ekonomija, jo objektu uzglabāšana ir lētāka nekā blokveida, kas tiek izmantota Elasticsearch klasteros.

Secinājums

EFK steku var izmantot dažādiem mērķiem, nodrošinot maksimālu elastību un daudzfunkcionālu Kibana saskarni analītikā, vizualizācijā un vaicājumos. To papildus var uzlabot ar mašīnmācīšanās iespējām.

Loki steks ir noderīgs Kubernetes ekosistēmā, ņemot vērā metadatu atklāšanas mehānismu. Datus ir viegli saskaņot uzraudzībai, pamatojoties uz laika rindām Grafana un žurnāliem.

Runājot par izmaksām un ilgu žurnālu glabāšanu, Loki ir lielisks izvēles variants, lai ienāktu mākoņu risinājumos.

Tirgū ir vairāk alternatīvu — dažas no tām var būt labākas tieši jums. Piemēram, GKE nodrošina Stackdriver integrāciju, kas ir lieliska risinājums uzraudzībai. Mūsu analīzē šis risinājums nav iekļauts.

Saites:

Raksts ir tulkots un sagatavots Habrā no Sloerm apmācību centra darbiniekiem — intensīvie kursi, video kursi un korporatīvās apmācības no praktizējošiem speciālistiem (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Avots: habr.com