Մուտք գործել Kubernetes. EFK vs PLG

Մուտք գործել Kubernetes. EFK vs PLG

Մոնիտորինգը դարձել է աճող ամպային լուծումների շատ կարևոր բաղադրիչ, քանի որ բաշխված համակարգերի բարդությունը մեծանում է: Պետք է հասկանալ նրանց պահվածքը։ Մեզ անհրաժեշտ են լայնածավալ գործիքներ, որոնք կարող են հավաքել տվյալներ բոլոր ծառայություններից և մասնագետներին տրամադրել մեկ ինտերֆեյս՝ կատարողականի վերլուծությամբ, սխալների ցուցադրմամբ, հասանելիությամբ և տեղեկամատյաններով:

Այս նույն գործիքները պետք է լինեն արդյունավետ և արդյունավետ: Այս հոդվածում մենք կդիտարկենք երկու հանրաճանաչ տեխնոլոգիական կույտեր՝ EFK (Elasticsearch) և PLG (Loki) և կուսումնասիրենք դրանց ճարտարապետությունն ու տարբերությունները:

EFK բուրգ

Դուք կարող եք արդեն լսել շատ հայտնի ELK-ի կամ EFK-ի մասին: Կույտը բաղկացած է մի քանի տարբեր մասերից՝ Elasticsearch (օբյեկտների պահեստավորում), Logstash կամ FluentD (տեղեկամատյանների հավաքում և համախմբում) և Kibana՝ վիզուալիզացիայի համար:

Տիպիկ աշխատանքային հոսքը հետևյալն է.

Մուտք գործել Kubernetes. EFK vs PLG

Elasticsearch- ը - բաշխված օբյեկտների պահեստավորում որոնման և իրական ժամանակի վերլուծության միջոցով: Գերազանց լուծում կիսակառույց տվյալների համար, ինչպիսիք են տեղեկամատյանները: Տեղեկատվությունը պահվում է որպես JSON փաստաթղթեր, ինդեքսավորվում իրական ժամանակում և բաշխվում կլաստերի հանգույցներում: Օգտագործվում է շրջված ինդեքս, որը պարունակում է բոլոր եզակի բառերը և հարակից փաստաթղթերը ամբողջական տեքստի որոնման համար, որն իր հերթին հիմնված է Apache Lucene որոնման համակարգի վրա:

FluentD տվյալների հավաքող է, որը միավորում է տվյալները՝ դրանք հավաքելիս և սպառելիս: Այն փորձում է հնարավորինս կազմակերպել տվյալները JSON-ով։ Նրա ճարտարապետությունը ընդարձակելի է, կան ավելին հարյուրավոր տարբեր ընդարձակումներ, համայնքի աջակցությամբ, բոլոր առիթների համար:

Կիբանա - Elasticsearch-ի համար տվյալների վիզուալիզացիայի գործիք տարբեր լրացուցիչ հնարավորություններով, օրինակ՝ ժամանակային շարքերի վերլուծություն, գրաֆիկների վերլուծություն, մեքենայական ուսուցում և այլն:

Elastics որոնողական ճարտարապետություն

Elasticsearch կլաստերի տվյալները պահվում են տարածված նրա բոլոր հանգույցներում: Կլաստերը բաղկացած է բազմաթիվ հանգույցներից՝ մատչելիությունը և ճկունությունը բարելավելու համար: Ցանկացած հանգույց կարող է կատարել կլաստերի բոլոր դերերը, սակայն լայնածավալ տեղակայման դեպքում հանգույցներին սովորաբար հանձնարարվում են անհատական ​​առաջադրանքներ:

Կլաստերային հանգույցների տեսակները.

  • վարպետ հանգույց - կառավարում է կլաստերը, առնվազն երեքն է անհրաժեշտ, մեկը միշտ ակտիվ է.
  • տվյալների հանգույց - պահում է ինդեքսավորված տվյալները և դրանցով կատարում տարբեր առաջադրանքներ.
  • ingest հանգույց - կազմակերպում է խողովակաշարեր տվյալների փոխակերպման համար նախքան ինդեքսավորումը.
  • համակարգող հանգույց - հարցումների երթուղիացում, որոնման մշակման փուլի կրճատում, զանգվածային ինդեքսավորման համակարգում;
  • ազդանշանային հանգույց — ազդանշանային առաջադրանքների գործարկում;
  • մեքենայական ուսուցման հանգույց - մեքենայական ուսուցման առաջադրանքների մշակում:

Ստորև բերված դիագրամը ցույց է տալիս, թե ինչպես են տվյալները պահվում և կրկնօրինակվում հանգույցներում՝ տվյալների ավելի բարձր հասանելիության հասնելու համար:

Մուտք գործել Kubernetes. EFK vs PLG

Յուրաքանչյուր կրկնօրինակի տվյալները պահվում են շրջված ինդեքսում, ստորև ներկայացված դիագրամը ցույց է տալիս, թե ինչպես է դա տեղի ունենում.

Մուտք գործել Kubernetes. EFK vs PLG

Տեղակայում

Մանրամասները կարելի է դիտել այստեղ, ես կօգտագործեմ ղեկի աղյուսակը.

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

PLG բուրգ

Մի զարմացեք, եթե չկարողանաք գտնել այս հապավումը, քանի որ այն ավելի հայտնի է որպես Գրաֆանա Լոկի: Ամեն դեպքում, այս բուրգը դառնում է ժողովրդականություն, քանի որ այն օգտագործում է ապացուցված տեխնիկական լուծումներ: Հնարավոր է, որ դուք արդեն լսել եք Grafana-ի՝ վիզուալիզացիայի հայտնի գործիքի մասին: Դրա ստեղծողները, ոգեշնչված Պրոմեթևսից, մշակեցին Loki-ն՝ հորիզոնական մասշտաբային, բարձր արդյունավետությամբ լոգերի ագրեգացման համակարգ: Loki-ն ինդեքսավորում է միայն մետատվյալները, այլ ոչ թե ամսագրերը, տեխնիկական լուծում, որը թույլ է տալիս այն հեշտ օգտագործելի և ծախսարդյունավետ:

Պրոմտեյլ - օպերացիոն համակարգից Loki կլաստեր տեղեկամատյաններ ուղարկելու գործակալ: Գրաֆանա Վիզուալիզացիայի գործիք է, որը հիմնված է Loki-ի տվյալների վրա:

Մուտք գործել Kubernetes. EFK vs PLG

Loki-ն կառուցված է նույն սկզբունքների վրա, ինչ Պրոմեթևսը, ինչը լավ է հարմարեցնում Kubernetes-ի տեղեկամատյանները պահելու և վերլուծելու համար:

Լոկիի ճարտարապետություն

Loki-ն կարող է գործարկվել կա՛մ որպես մեկ գործընթաց, կա՛մ որպես մի քանի պրոցես՝ թույլ տալով հորիզոնական մասշտաբավորում:

Մուտք գործել Kubernetes. EFK vs PLG

Այն կարող է նաև աշխատել որպես մոնոլիտ հավելված կամ որպես միկրոսերվիս: Որպես մեկ գործընթաց վարելը կարող է օգտակար լինել տեղական զարգացման կամ փոքր մոնիտորինգի համար: Արդյունաբերական իրականացման և ընդլայնվող ծանրաբեռնվածության համար խորհուրդ է տրվում օգտագործել microservice տարբերակը: Տվյալները գրելու և կարդալու ուղիներն առանձնացված են, այնպես որ դրանք կարող են մանրակրկիտ կարգավորվել և չափավորվել ըստ անհրաժեշտության:

Եկեք նայենք գերանների հավաքագրման համակարգի ճարտարապետությանը, առանց մանրամասնելու.

Մուտք գործել Kubernetes. EFK vs PLG

Եվ ահա նկարագրությունը (միկրոծառայության ճարտարապետություն).

Մուտք գործել Kubernetes. EFK vs PLG

Բաղադրիչներ:

Պրոմտեյլ — հանգույցների վրա տեղադրված գործակալ (որպես ծառայությունների մի շարք), այն հեռացնում է տեղեկամատյանները առաջադրանքներից և մուտք է գործում Kubernetes API՝ ստանալու մետատվյալներ, որոնք պիտակավորում են տեղեկամատյանները: Այնուհետև այն ուղարկում է գրանցամատյանը հիմնական Loki ծառայությանը: Մետատվյալների քարտեզագրումն աջակցում է պիտակավորման նույն կանոններին, ինչ Պրոմեթևսը:

Բաժանող — ծառայության դիստրիբյուտոր, որն աշխատում է որպես բուֆեր: Միլիոնավոր գրառումներ մշակելու համար այն փաթեթավորում է մուտքային տվյալները՝ սեղմելով դրանք բլոկներով, երբ այն հասնում է: Միաժամանակ աշխատում են մի քանի տվյալների ներդիր, սակայն մուտքային տվյալների մեկ հոսքին պատկանող տեղեկամատյանները պետք է հայտնվեն միայն դրանցից մեկում իր բոլոր բլոկների համար: Սա կազմակերպվում է լվացարանների օղակի և հաջորդական հեշինգի մեջ: Սխալների հանդուրժողականության և ավելորդության համար դա արվում է n անգամ (3, եթե կազմաձևված չէ):

Ինգեստեր - սպասարկման ընդունիչ: Տվյալների բլոկները գալիս են սեղմված՝ ավելացված տեղեկամատյաններով: Երբ բլոկը բավականաչափ չափի է, բլոկը լցվում է տվյալների բազա: Մետատվյալները գնում են ինդեքս, իսկ տեղեկամատյան բլոկի տվյալները՝ Chunks (սովորաբար օբյեկտների պահեստավորում): Վերակայումից հետո ստացողը ստեղծում է նոր բլոկ, որտեղ կավելացվեն նոր գրառումներ:

Մուտք գործել Kubernetes. EFK vs PLG

ինդեքս - տվյալների բազա, DynamoDB, Cassandra, Google BigTable և այլն:

Կտորներ — տեղեկամատյանների բլոկները սեղմված տեսքով, սովորաբար պահվում են օբյեկտների պահեստում, օրինակ՝ S3:

Հարցում - ընթերցանության ուղին, որն անում է բոլոր կեղտոտ աշխատանքը: Այն նայում է ժամանակային միջակայքին և ժամանակի դրոշմանը, այնուհետև նայում է ինդեքսին՝ համընկնումներ գտնելու համար: Այնուհետև այն կարդում է տվյալների բլոկները և զտում դրանք՝ արդյունք ստանալու համար:

Հիմա եկեք տեսնենք ամեն ինչ գործողության մեջ:

Տեղակայում

Kubernetes-ում տեղադրելու ամենահեշտ ձևը ղեկն օգտագործելն է: Մենք ենթադրում ենք, որ դուք արդեն տեղադրել և կարգավորել եք այն (և երրորդ տարբերակը! մոտ. թարգմանիչ)

Ավելացրե՛ք պահոց և տեղադրե՛ք կույտ:

$ 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 մատյանների համար:

Մուտք գործել Kubernetes. EFK vs PLG

Հիմա եկեք քննարկենք երկու համակարգերի ճարտարապետությունը, ինչպես նաև համեմատենք դրանց հնարավորությունները միմյանց հետ:

Համեմատություն

Հարցման լեզու

Elasticsearch-ն օգտագործում է Query DSL և Lucene հարցումների լեզուն՝ ամբողջական տեքստի որոնման հնարավորություններ ապահովելու համար: Այն կայացած, հզոր որոնման համակարգ է օպերատորի լայն աջակցությամբ: Դրա միջոցով դուք կարող եք որոնել ըստ համատեքստի և տեսակավորել ըստ համապատասխանության:

Մատանու մյուս կողմում LogQL-ն է, որն օգտագործվում է Loki-ում՝ PromQL-ի (Պրոմեթևսի հարցման լեզու) իրավահաջորդը: Այն օգտագործում է տեղեկամատյանների պիտակները՝ զտելու և մատյանների տվյալները ընտրելու համար: Հնարավոր է օգտագործել որոշ օպերատորներ և թվաբանություն, ինչպես նկարագրված է այստեղ, բայց հնարավորությունների առումով հետ է մնում Էլաստիկ լեզվից։

Քանի որ Loki-ում հարցումները կապված են պիտակների հետ, դրանք հեշտ է փոխկապակցվել չափումների հետ, և արդյունքում ավելի հեշտ է կազմակերպել գործառնական մոնիտորինգը:

Մասշտաբայնություն

Երկու կույտերն էլ հորիզոնական մասշտաբավոր են, բայց Loki-ն հեշտացնում է այն, քանի որ այն ունի առանձին կարդալու և գրելու ուղիներ և միկրոծառայության ճարտարապետություն: Loki-ն կարող է հարմարեցվել ձեր կարիքներին համապատասխան և կարող է օգտագործվել տեղեկամատյանների շատ մեծ ծավալների համար:

Բազմավարձակալություն

Կլաստերների բազմավճարը OPEX հապավումում տարածված թեմա է, երկու կույտերն էլ ապահովում են բազմավճար: Elasticsearch-ի համար կան մի քանիսը ուղիները հաճախորդի տարանջատում. յուրաքանչյուր հաճախորդի համար առանձին ինդեքս, հաճախորդի վրա հիմնված երթուղի, եզակի հաճախորդի դաշտեր, որոնման զտիչներ: Լոկին ունի աջակցություն HTTP X-Scope-OrgID վերնագրի տեսքով:

Արժենալ

Loki-ն բավականին ծախսարդյունավետ է, քանի որ այն չի ինդեքսավորում տվյալները, միայն մետատվյալները: Սա հասնում է խնայողություններ պահեստավորման վրա և հիշողություն (քեշ), քանի որ օբյեկտների պահեստավորումն ավելի էժան է, քան բլոկային պահոցը, որն օգտագործվում է Elasticsearch կլաստերներում։

Ամփոփում

EFK փաթեթը կարող է օգտագործվել տարբեր նպատակների համար՝ ապահովելով առավելագույն ճկունություն և Kibana-ի հարուստ ինտերֆեյս՝ վերլուծությունների, վիզուալիզացիայի և հարցումների համար: Այն կարող է ավելի ընդլայնվել մեքենայական ուսուցման հնարավորություններով:

Loki ստեկը օգտակար է Kubernetes էկոհամակարգում իր մետատվյալների հայտնաբերման մեխանիզմի պատճառով: Դուք կարող եք հեշտությամբ փոխկապակցել տվյալները մոնիտորինգի համար՝ հիմնված ժամանակային շարքերի վրա Grafana-ում և տեղեկամատյաններում:

Երբ խոսքը գնում է ծախսերի և երկարաժամկետ տեղեկամատյանների պահպանման մասին, Loki-ն հիանալի մուտքի կետ է ամպային լուծումների մեջ:

Շուկայում ավելի շատ այլընտրանքներ կան. որոշները կարող են ավելի լավ լինել ձեզ համար: Օրինակ, GKE-ն ունի Stackdriver ինտեգրում, որն ապահովում է մոնիտորինգի գերազանց լուծում: Մենք դրանք չենք ներառել այս հոդվածում մեր վերլուծության մեջ:

Հղումներ.

Հոդվածը թարգմանվել և պատրաստվել է Հաբրի համար աշխատակիցների կողմից Slurm ուսումնական կենտրոն — ինտենսիվ դասընթացներ, վիդեո դասընթացներ և կորպորատիվ ուսուցում գործող մասնագետներից (Kubernetes, DevOps, Docker, Ansible, Ceph, SRE, Agile)

Source: www.habr.com

Добавить комментарий