A megfigyelés a növekvő felhőmegoldások nagyon fontos összetevőjévé vált, ahogy az elosztott rendszerek összetettsége növekszik. Meg kell érteni a viselkedésüket. Skálázható eszközökre van szükségünk, amelyek minden szolgáltatásból adatokat gyűjtenek – és egyetlen felületet biztosítanak a szakembereknek teljesítményelemzéssel, hibabemutatóval, elérhetőséggel és naplókkal.
Ugyanezen eszközöknek hatékonynak és produktívnak kell lenniük. Ebben a cikkben megvizsgálunk két népszerű technológiai stacket: az EFK-t (Elasticsearch) és a PLG-t (Loki), és megvizsgáljuk ezek architektúráját és különbségeit.
EFK verem
Talán már hallottál a nagyon népszerű ELK-ról vagy EFK-ról. A verem több különálló részből áll: Elasticsearch (objektumtárolás), Logstash vagy FluentD (naplógyűjtés és összesítés), valamint Kibana a megjelenítéshez.
Egy tipikus munkafolyamat így néz ki:
Elasticsearch — elosztott objektumtárolás kereséssel és valós idejű elemzéssel. Kiváló megoldás félig strukturált adatokhoz, például naplókhoz. Az információkat JSON-dokumentumokként menti, valós időben indexeli, és elosztja a fürt csomópontjai között. A rendszer egy fordított indexet használ, amely az összes egyedi szót és kapcsolódó dokumentumot tartalmazza a teljes szöveges kereséshez, amely viszont az Apache Lucene keresőmotoron alapul.
FluentD egy adatgyűjtő, amely egyesíti az adatokat gyűjtése és fogyasztása során. Megpróbálja rendszerezni az adatokat JSON-ban, amennyire csak lehetséges. Építészete bővíthető, több is van , közösség által támogatott, minden alkalomra.
kibana - egy adatvizualizációs eszköz az Elasticsearch számára különféle kiegészítő képességekkel, például idősorelemzéssel, grafikonelemzéssel, gépi tanulással és még sok mással.
Elasticsearch építészet
Az Elasticsearch-fürt adatait az összes csomóponton szétszórva tárolják. Egy fürt több csomópontból áll a rendelkezésre állás és a rugalmasság javítása érdekében. Bármely csomópont képes ellátni a fürt összes szerepét, de a nagy léptékű telepítéseknél a csomópontokhoz általában egyedi feladatokat rendelnek.
Klaszter csomópontok típusai:
- master node - kezeli a fürtöt, legalább három szükséges, egy mindig aktív;
- adatcsomópont - indexelt adatokat tárol, és különféle feladatokat végez velük;
- beviteli csomópont – folyamatokat szervez az adatok átalakításához az indexelés előtt;
- csomópont koordinálása - útválasztási kérések, keresési feldolgozási fázis csökkentése, tömeges indexelés koordinálása;
- alerting node — riasztási feladatok indítása;
- gépi tanulási csomópont - gépi tanulási feladatok feldolgozása.
Az alábbi diagram bemutatja, hogyan történik az adatok tárolása és replikálása a csomópontok között a magasabb adatelérhetőség elérése érdekében.
Minden replika adatai egy fordított indexben vannak tárolva, az alábbi diagram bemutatja, hogyan történik ez:
Telepítés
A részletek megtekinthetők , sisakdiagramot fogok használni:
$ helm install efk-stack stable/elastic-stack --set logstash.enabled=false --set fluentd.enabled=true --set fluentd-elasticsPLG verem
Ne lepődjön meg, ha nem találja ezt a betűszót, mivel jobban ismert Grafana Loki néven. Mindenesetre ez a verem egyre népszerűbb, mert bevált technikai megoldásokat használ. Lehet, hogy már hallott a Grafanáról, egy népszerű vizualizációs eszközről. Alkotói a Prometheus ihlette kifejlesztették a Lokit, egy vízszintesen méretezhető, nagy teljesítményű naplógyűjtő rendszert. A Loki csak a metaadatokat indexeli, magukat a folyóiratokat nem, egy technikai megoldás, amely lehetővé teszi, hogy könnyen használható és költséghatékony legyen.
Promtail - egy ügynök, amely naplókat küld az operációs rendszerből a Loki-fürtbe. grafana a Loki adatain alapuló vizualizációs eszköz.
A Loki ugyanazokra az elvekre épül, mint a Prometheus, így kiválóan alkalmas Kubernetes naplók tárolására és elemzésére.
Loki építészet
A Loki egyetlen folyamatként vagy több folyamatként is futtatható, lehetővé téve a vízszintes skálázást.
Működhet monolitikus alkalmazásként vagy mikroszolgáltatásként is. Az egyetlen folyamatként való futtatás hasznos lehet a helyi fejlesztésekhez vagy kisebb ellenőrzésekhez. Ipari megvalósításhoz és méretezhető munkaterheléshez a mikroszolgáltatás opció használata javasolt. Az adatok írási és olvasási útvonalai el vannak választva, így azok igény szerint finoman hangolhatók és méretezhetők.
Nézzük meg a naplógyűjtő rendszer architektúráját anélkül, hogy részleteznénk:
És itt a leírás (mikroszolgáltatás architektúra):
Alkatrészek:
Promtail — a csomópontokra telepített ügynök (szolgáltatáskészletként), eltávolítja a naplókat a feladatokból, és hozzáfér a Kubernetes API-hoz, hogy megszerezze a naplókat címkéző metaadatokat. Ezután elküldi a naplót a fő Loki szolgáltatásnak. A metaadat-leképezés ugyanazokat a címkézési szabályokat támogatja, mint a Prometheus.
Elosztó — pufferként működő szolgáltatás-elosztó. Rekordok millióinak feldolgozásához csomagolja a bejövő adatokat, és blokkokba tömöríti, ahogy megérkeznek. Több adatnyelő fut egyszerre, de az egy bejövő adatfolyamhoz tartozó naplók csak az egyikben jelenjenek meg az összes blokkjában. Ez a nyelők gyűrűjébe és a szekvenciális hashelésbe van szervezve. A hibatűrés és a redundancia érdekében ez n-szer történik meg (3, ha nincs konfigurálva).
Ingester — szolgálati vevő. Az adatblokkok tömörítve, hozzáadott naplókkal érkeznek. Amint a blokk megfelelő méretű, a blokk az adatbázisba kerül. A metaadatok az indexbe, a naplóblokk adatai pedig a darabokba (általában objektumtárolóba) kerülnek. A visszaállítás után a vevő új blokkot hoz létre, amelybe új bejegyzések kerülnek hozzáadásra.
index - adatbázis, DynamoDB, Cassandra, Google BigTable stb.
Darabok — naplóblokkok tömörített formában, általában objektumtárolóban tárolva, például S3.
Querier - az olvasási út, amely minden piszkos munkát elvégz. Megnézi az időtartományt és az időbélyeget, majd az indexen keresi az egyezéseket. Ezután beolvassa az adatblokkokat, és kiszűri őket az eredmény eléréséhez.
Most pedig lássunk mindent működés közben.
Telepítés
A Kubernetes telepítésének legegyszerűbb módja a sisak használata. Feltételezzük, hogy már telepítette és konfigurálta ( kb. fordító)
Adjon hozzá egy tárat, és telepítsen egy veremet.
$ 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=falseAz alábbiakban látható egy példa irányítópult, amely a Prometheus for Etcd metrikák és a Loki for Etcd pod naplók adatait mutatja.
Most beszéljük meg mindkét rendszer architektúráját, és hasonlítsuk össze képességeiket egymással.
Сравнение
Lekérdezési nyelv
Az Elasticsearch a Query DSL-t és a Lucene lekérdezési nyelvet használja a teljes szöveges keresési lehetőségek biztosításához. Ez egy bejáratott, hatékony keresőmotor széles körű kezelői támogatással. Segítségével kontextus szerint kereshet, és relevancia szerint rendezhet.
A gyűrű másik oldalán a LogQL található, amelyet a PromQL (Prometheus lekérdezési nyelv) utódjában, a Lokiban használnak. Naplócímkéket használ a naplóadatok szűrésére és kiválasztására. Lehetőség van néhány operátor és aritmetika használatára a leírtak szerint , de képességeit tekintve elmarad az Elasztikus nyelv.
Mivel a Lokiban a lekérdezések címkékkel vannak társítva, könnyen korrelálhatók a mérőszámokkal, és ennek eredményeként könnyebb megszervezni velük a működési felügyeletet.
Méretezhetőség
Mindkét verem vízszintesen méretezhető, de a Loki ezt megkönnyíti, mert külön olvasási és írási útvonalakkal, valamint mikroszolgáltatási architektúrával rendelkezik. A Loki testreszabható az Ön igényei szerint, és nagyon nagy mennyiségű naplóadathoz használható.
Többbérlet
A cluster multitenancy gyakori téma az OPEX rövidítésben, mindkét verem többbérleti lehetőséget biztosít. Az Elasticsearch számára több is létezik kliens szétválasztás: külön index minden klienshez, kliens alapú útválasztás, egyedi kliens mezők, keresési szűrők. Lokinak van HTTP X-Scope-OrgID fejléc formájában.
Költség
A Loki meglehetősen költséghatékony, mivel nem indexeli az adatokat, csak a metaadatokat. Ez eléri és memória (gyorsítótár), mivel az objektumtárolás olcsóbb, mint az Elasticsearch-fürtökben használt blokktárolás.
Következtetés
Az EFK verem többféle célra használható, maximális rugalmasságot és funkciókban gazdag Kibana felületet biztosít az elemzésekhez, a vizualizációhoz és a lekérdezésekhez. Tovább fejleszthető a gépi tanulási képességekkel.
A Loki verem hasznos a Kubernetes ökoszisztémában a metaadat-felderítési mechanizmusa miatt. Könnyedén korrelálhatja az adatokat a megfigyeléshez a Grafana idősorai és a naplók alapján.
Ha a költségekről és a hosszú távú naplótárolásról van szó, a Loki kiváló belépési pont a felhőmegoldásokba.
Több alternatíva is van a piacon – néhány jobb lehet az Ön számára. Például a GKE rendelkezik egy Stackdriver integrációval, amely kiváló megfigyelési megoldást nyújt. Ebben a cikkben nem vettük figyelembe őket elemzésünkben.
referenciák:
A cikket az alkalmazottak fordították le és készítették el a Habr számára - intenzív tanfolyamok, videó tanfolyamok és vállalati képzés gyakorló szakemberektől (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)
Forrás: will.com