Մոնիտորինգը դարձել է աճող ամպային լուծումների շատ կարևոր բաղադրիչ, քանի որ բաշխված համակարգերի բարդությունը մեծանում է: Պետք է հասկանալ նրանց պահվածքը։ Մեզ անհրաժեշտ են լայնածավալ գործիքներ, որոնք կարող են հավաքել տվյալներ բոլոր ծառայություններից և մասնագետներին տրամադրել մեկ ինտերֆեյս՝ կատարողականի վերլուծությամբ, սխալների ցուցադրմամբ, հասանելիությամբ և տեղեկամատյաններով:
Այս նույն գործիքները պետք է լինեն արդյունավետ և արդյունավետ: Այս հոդվածում մենք կդիտարկենք երկու հանրաճանաչ տեխնոլոգիական կույտեր՝ EFK (Elasticsearch) և PLG (Loki) և կուսումնասիրենք դրանց ճարտարապետությունն ու տարբերությունները:
EFK բուրգ
Դուք կարող եք արդեն լսել շատ հայտնի ELK-ի կամ EFK-ի մասին: Կույտը բաղկացած է մի քանի տարբեր մասերից՝ Elasticsearch (օբյեկտների պահեստավորում), Logstash կամ FluentD (տեղեկամատյանների հավաքում և համախմբում) և Kibana՝ վիզուալիզացիայի համար:
Տիպիկ աշխատանքային հոսքը հետևյալն է.
Elasticsearch- ը - բաշխված օբյեկտների պահեստավորում որոնման և իրական ժամանակի վերլուծության միջոցով: Գերազանց լուծում կիսակառույց տվյալների համար, ինչպիսիք են տեղեկամատյանները: Տեղեկատվությունը պահվում է որպես JSON փաստաթղթեր, ինդեքսավորվում իրական ժամանակում և բաշխվում կլաստերի հանգույցներում: Օգտագործվում է շրջված ինդեքս, որը պարունակում է բոլոր եզակի բառերը և հարակից փաստաթղթերը ամբողջական տեքստի որոնման համար, որն իր հերթին հիմնված է Apache Lucene որոնման համակարգի վրա:
FluentD տվյալների հավաքող է, որը միավորում է տվյալները՝ դրանք հավաքելիս և սպառելիս: Այն փորձում է հնարավորինս կազմակերպել տվյալները JSON-ով։ Նրա ճարտարապետությունը ընդարձակելի է, կան ավելին հարյուրավոր տարբեր ընդարձակումներ, համայնքի աջակցությամբ, բոլոր առիթների համար:
Կիբանա - Elasticsearch-ի համար տվյալների վիզուալիզացիայի գործիք տարբեր լրացուցիչ հնարավորություններով, օրինակ՝ ժամանակային շարքերի վերլուծություն, գրաֆիկների վերլուծություն, մեքենայական ուսուցում և այլն:
Elastics որոնողական ճարտարապետություն
Elasticsearch կլաստերի տվյալները պահվում են տարածված նրա բոլոր հանգույցներում: Կլաստերը բաղկացած է բազմաթիվ հանգույցներից՝ մատչելիությունը և ճկունությունը բարելավելու համար: Ցանկացած հանգույց կարող է կատարել կլաստերի բոլոր դերերը, սակայն լայնածավալ տեղակայման դեպքում հանգույցներին սովորաբար հանձնարարվում են անհատական առաջադրանքներ:
Կլաստերային հանգույցների տեսակները.
վարպետ հանգույց - կառավարում է կլաստերը, առնվազն երեքն է անհրաժեշտ, մեկը միշտ ակտիվ է.
տվյալների հանգույց - պահում է ինդեքսավորված տվյալները և դրանցով կատարում տարբեր առաջադրանքներ.
ingest հանգույց - կազմակերպում է խողովակաշարեր տվյալների փոխակերպման համար նախքան ինդեքսավորումը.
մեքենայական ուսուցման հանգույց - մեքենայական ուսուցման առաջադրանքների մշակում:
Ստորև բերված դիագրամը ցույց է տալիս, թե ինչպես են տվյալները պահվում և կրկնօրինակվում հանգույցներում՝ տվյալների ավելի բարձր հասանելիության հասնելու համար:
Յուրաքանչյուր կրկնօրինակի տվյալները պահվում են շրջված ինդեքսում, ստորև ներկայացված դիագրամը ցույց է տալիս, թե ինչպես է դա տեղի ունենում.
Տեղակայում
Մանրամասները կարելի է դիտել այստեղ, ես կօգտագործեմ ղեկի աղյուսակը.
Մի զարմացեք, եթե չկարողանաք գտնել այս հապավումը, քանի որ այն ավելի հայտնի է որպես Գրաֆանա Լոկի: Ամեն դեպքում, այս բուրգը դառնում է ժողովրդականություն, քանի որ այն օգտագործում է ապացուցված տեխնիկական լուծումներ: Հնարավոր է, որ դուք արդեն լսել եք Grafana-ի՝ վիզուալիզացիայի հայտնի գործիքի մասին: Դրա ստեղծողները, ոգեշնչված Պրոմեթևսից, մշակեցին Loki-ն՝ հորիզոնական մասշտաբային, բարձր արդյունավետությամբ լոգերի ագրեգացման համակարգ: Loki-ն ինդեքսավորում է միայն մետատվյալները, այլ ոչ թե ամսագրերը, տեխնիկական լուծում, որը թույլ է տալիս այն հեշտ օգտագործելի և ծախսարդյունավետ:
Պրոմտեյլ - օպերացիոն համակարգից Loki կլաստեր տեղեկամատյաններ ուղարկելու գործակալ: Գրաֆանա Վիզուալիզացիայի գործիք է, որը հիմնված է Loki-ի տվյալների վրա:
Loki-ն կառուցված է նույն սկզբունքների վրա, ինչ Պրոմեթևսը, ինչը լավ է հարմարեցնում Kubernetes-ի տեղեկամատյանները պահելու և վերլուծելու համար:
Լոկիի ճարտարապետություն
Loki-ն կարող է գործարկվել կա՛մ որպես մեկ գործընթաց, կա՛մ որպես մի քանի պրոցես՝ թույլ տալով հորիզոնական մասշտաբավորում:
Այն կարող է նաև աշխատել որպես մոնոլիտ հավելված կամ որպես միկրոսերվիս: Որպես մեկ գործընթաց վարելը կարող է օգտակար լինել տեղական զարգացման կամ փոքր մոնիտորինգի համար: Արդյունաբերական իրականացման և ընդլայնվող ծանրաբեռնվածության համար խորհուրդ է տրվում օգտագործել microservice տարբերակը: Տվյալները գրելու և կարդալու ուղիներն առանձնացված են, այնպես որ դրանք կարող են մանրակրկիտ կարգավորվել և չափավորվել ըստ անհրաժեշտության:
Եկեք նայենք գերանների հավաքագրման համակարգի ճարտարապետությանը, առանց մանրամասնելու.
Եվ ահա նկարագրությունը (միկրոծառայության ճարտարապետություն).
Բաղադրիչներ:
Պրոմտեյլ — հանգույցների վրա տեղադրված գործակալ (որպես ծառայությունների մի շարք), այն հեռացնում է տեղեկամատյանները առաջադրանքներից և մուտք է գործում Kubernetes API՝ ստանալու մետատվյալներ, որոնք պիտակավորում են տեղեկամատյանները: Այնուհետև այն ուղարկում է գրանցամատյանը հիմնական Loki ծառայությանը: Մետատվյալների քարտեզագրումն աջակցում է պիտակավորման նույն կանոններին, ինչ Պրոմեթևսը:
Բաժանող — ծառայության դիստրիբյուտոր, որն աշխատում է որպես բուֆեր: Միլիոնավոր գրառումներ մշակելու համար այն փաթեթավորում է մուտքային տվյալները՝ սեղմելով դրանք բլոկներով, երբ այն հասնում է: Միաժամանակ աշխատում են մի քանի տվյալների ներդիր, սակայն մուտքային տվյալների մեկ հոսքին պատկանող տեղեկամատյանները պետք է հայտնվեն միայն դրանցից մեկում իր բոլոր բլոկների համար: Սա կազմակերպվում է լվացարանների օղակի և հաջորդական հեշինգի մեջ: Սխալների հանդուրժողականության և ավելորդության համար դա արվում է n անգամ (3, եթե կազմաձևված չէ):
Ինգեստեր - սպասարկման ընդունիչ: Տվյալների բլոկները գալիս են սեղմված՝ ավելացված տեղեկամատյաններով: Երբ բլոկը բավականաչափ չափի է, բլոկը լցվում է տվյալների բազա: Մետատվյալները գնում են ինդեքս, իսկ տեղեկամատյան բլոկի տվյալները՝ Chunks (սովորաբար օբյեկտների պահեստավորում): Վերակայումից հետո ստացողը ստեղծում է նոր բլոկ, որտեղ կավելացվեն նոր գրառումներ:
ինդեքս - տվյալների բազա, DynamoDB, Cassandra, Google BigTable և այլն:
Կտորներ — տեղեկամատյանների բլոկները սեղմված տեսքով, սովորաբար պահվում են օբյեկտների պահեստում, օրինակ՝ S3:
Հարցում - ընթերցանության ուղին, որն անում է բոլոր կեղտոտ աշխատանքը: Այն նայում է ժամանակային միջակայքին և ժամանակի դրոշմանը, այնուհետև նայում է ինդեքսին՝ համընկնումներ գտնելու համար: Այնուհետև այն կարդում է տվյալների բլոկները և զտում դրանք՝ արդյունք ստանալու համար:
Հիմա եկեք տեսնենք ամեն ինչ գործողության մեջ:
Տեղակայում
Kubernetes-ում տեղադրելու ամենահեշտ ձևը ղեկն օգտագործելն է: Մենք ենթադրում ենք, որ դուք արդեն տեղադրել և կարգավորել եք այն (և երրորդ տարբերակը!մոտ. թարգմանիչ)
Ստորև բերված է վահանակի օրինակ, որը ցույց է տալիս Prometheus-ի տվյալները Etcd չափումների համար և Loki-ից Etcd pod մատյանների համար:
Հիմա եկեք քննարկենք երկու համակարգերի ճարտարապետությունը, ինչպես նաև համեմատենք դրանց հնարավորությունները միմյանց հետ:
Համեմատություն
Հարցման լեզու
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)