Յուրի Բուշլևի «Փոցխի քարտեզ գերանների հավաքման և առաքման ոլորտում» - զեկույցի սղագրություն

Տեղեկամատյանները համակարգի կարևոր մասն են, ինչը թույլ է տալիս հասկանալ, որ այն աշխատում է (կամ չի աշխատում) ինչպես սպասվում էր: Միկրոծառայության ճարտարապետության պայմաններում գերանների հետ աշխատանքը դառնում է Հատուկ օլիմպիադայի առանձին առարկա։ Կան բազմաթիվ խնդիրներ, որոնք պետք է լուծվեն.

• ինչպես գրել տեղեկամատյաններ հավելվածից;
• որտեղ գրել տեղեկամատյաններ;
• ինչպես փոխանցել տեղեկամատյանները պահպանման և մշակման համար.
• ինչպես մշակել և պահել տեղեկամատյանները:

Ներկա պահին հայտնի կոնտեյներացման տեխնոլոգիաների օգտագործումը ավազ է ավելացնում փոցխի վերևում՝ խնդիրների լուծման տարբերակների ոլորտում:

Այս մասին Յուրի Բուշլևի «Փոցխի քարտեզը գերանների հավաքման և առաքման ոլորտում» զեկույցի սղագրությունն է։

Ո՞վ է մտածում, խնդրում եմ կատվի տակ:

Ես Յուրի Բուշլևն եմ։ Ես աշխատում եմ Lazada-ում: Այսօր ես կխոսեմ այն ​​մասին, թե ինչպես ենք պատրաստել մեր գերանները, ինչպես ենք դրանք հավաքել և ինչ ենք գրում այնտեղ:

որտեղի՞ց ենք մենք։ Ո՞վ ենք մենք։ Lazada-ն թիվ 1 առցանց մանրածախ առևտուրն է Հարավարևելյան Ասիայի վեց երկրներում: Այս բոլոր երկրները բաշխված են տվյալների կենտրոնների միջև: Այժմ ընդհանուր առմամբ կա 4 տվյալների կենտրոն: Ինչո՞ւ է սա կարևոր: Որովհետև որոշ որոշումներ պայմանավորված էին նրանով, որ կենտրոնների միջև շատ թույլ կապ կա։ Մենք ունենք միկրոսերվիսային ճարտարապետություն: Ես զարմացա, երբ հայտնաբերեցի, որ մենք արդեն ունենք 80 միկրոսերվիս: Երբ ես սկսեցի առաջադրանքը լոգերի հետ, դրանք ընդամենը 20-ն էին, բացի այդ, կա PHP-ի բավականին մեծ ժառանգություն, որի հետ ես նույնպես պետք է ապրեմ և համակերպվեմ: Այս ամենը մեզ համար այս պահին առաջացնում է ավելի քան 6 միլիոն հաղորդագրություն մեկ րոպեում ընդհանուր համակարգի համար: Այնուհետև ես ցույց կտամ, թե ինչպես ենք մենք փորձում ապրել դրա հետ և ինչու է դա այդպես:

Այս 6 միլիոն հաղորդագրություններով պետք է ինչ-որ կերպ ապրել։ Ի՞նչ անենք նրանց հետ։ Անհրաժեշտ է 6 միլիոն հաղորդագրություն.

• ուղարկել հավելվածից
• ընդունել առաքման համար
• առաքել վերլուծության և պահպանման համար:
• վերլուծել
• ինչ-որ կերպ պահել:

Երբ երեք միլիոն հաղորդագրություն կար, ես մոտավորապես նույն տեսքն ունեի: Քանի որ մենք սկսել ենք մի քանի կոպեկներով։ Հասկանալի է, որ այնտեղ գրված են հավելվածների տեղեկամատյանները։ Օրինակ, չկարողացա միանալ տվյալների շտեմարանին, կարող էր միանալ տվյալների շտեմարանին, բայց չկարողացա ինչ-որ բան կարդալ: Բայց բացի սրանից, մեր միկրոսերվիսներից յուրաքանչյուրը նաև մուտքի մատյան է գրում։ Յուրաքանչյուր հարցում, որը հասնում է միկրոսերվիսին, ընկնում է գրանցամատյանում: Ինչու ենք մենք դա անում: Մշակողները ցանկանում են, որ կարողանան հետևել: Յուրաքանչյուր մուտքի մատյան պարունակում է traceid դաշտը, ըստ որի հատուկ ինտերֆեյսը ապա արձակում է ամբողջ շղթան և գեղեցիկ ցուցադրում հետքը: Հետքը ցույց է տալիս, թե ինչպես է ընթացել հարցումը, և դա օգնում է մեր մշակողներին ավելի արագ վարվել ցանկացած անհայտ աղբի հետ:

Ինչպե՞ս ապրել դրա հետ: Այժմ ես համառոտ նկարագրելու եմ տարբերակների ոլորտը` ինչպես է ընդհանուր առմամբ լուծվում այս խնդիրը: Ինչպես լուծել գերանների հավաքման, փոխանցման և պահպանման խնդիրը:

Ինչպե՞ս գրել դիմումից: Հասկանալի է, որ կան տարբեր ճանապարհներ։ Մասնավորապես, կա լավագույն պրակտիկա, ինչպես մեզ ասում են նորաձեւ ընկերները։ Երկու տեսակի հին դպրոց կա, ինչպես պապերն էին ասում. Կան այլ ուղիներ:

Գերանների հավաքագրման դեպքում իրավիճակը մոտավորապես նույնն է. Կոնկրետ այս հատվածը լուծելու այնքան էլ շատ տարբերակներ չկան։ Դրանք ավելի շատ են, բայց դեռ այդքան շատ չեն։

Բայց առաքման և հետագա վերլուծության հետ մեկտեղ տատանումների քանակը սկսում է պայթել: Ես հիմա չեմ նկարագրի յուրաքանչյուր տարբերակ: Կարծում եմ՝ հիմնական տարբերակները քաջ հայտնի են բոլորին, ովքեր հետաքրքրված էին թեմայով։

Ես ձեզ ցույց կտամ, թե ինչպես մենք դա արեցինք Լազադայում և ինչպես սկսվեց ամեն ինչ:

Մեկ տարի առաջ ես եկա Լազադա և ուղարկվեցի լոգերի նախագծին: Այնտեղ այսպես էր. Հավելվածից գրանցամատյանը գրվել է stdout և stderr: Ամեն ինչ արված էր մոդայիկ ձևով։ Բայց հետո ծրագրավորողները դուրս շպրտեցին այն ստանդարտ հոսքերից, իսկ հետո ենթակառուցվածքի մասնագետները ինչ-որ կերպ կպարզեն դա: Ենթակառուցվածքի մասնագետների և ծրագրավորողների միջև կան նաև թողարկողներ, ովքեր ասում էին. «էհ... լավ, եկեք դրանք փաթաթենք մի ֆայլի մեջ պատյանով, և վերջ»: Եվ քանի որ այս ամենը կոնտեյների մեջ է, այն փաթաթեցին հենց կոնտեյների մեջ, քարտեզագրեցին տեղեկատուի ներսում ու դրեցին այնտեղ։ Կարծում եմ, որ բոլորի համար բավականին ակնհայտ է, թե ինչ է տեղի ունեցել:

Եկեք մի փոքր ավելի հեռու նայենք: Ինչպես մենք առաքեցինք այս տեղեկամատյանները: Ինչ-որ մեկը ընտրել է td-agent, որն իրականում սահուն է, բայց ոչ այնքան սահուն: Ես դեռ չեմ հասկանում այս երկու նախագծերի փոխհարաբերությունները, բայց դրանք կարծես թե նույն բանն են։ Եվ այս սահուն, գրված Ruby-ով, կարդում է տեղեկամատյանների ֆայլերը, դրանք վերլուծում JSON-ում՝ օգտագործելով որոշ կանոնավոր արտահայտություններ: Հետո նրանց ուղարկեցին Կաֆկա։ Ավելին, Կաֆկայում մենք ունեինք 4 առանձին թեմա յուրաքանչյուր API-ի համար։ Ինչու՞ 4: Քանի որ կա կենդանի, կա բեմադրություն, և քանի որ կա stdout և stderr: Մշակողները դրանք արտադրում են, իսկ ենթակառուցվածքի աշխատողները պետք է ստեղծեն դրանք Կաֆկայում: Ավելին, Կաֆկան վերահսկվում էր մեկ այլ գերատեսչության կողմից։ Ուստի անհրաժեշտ էր ստեղծել տոմս, որպեսզի այնտեղ ստեղծեին 4 թեմա յուրաքանչյուր api-ի համար։ Բոլորը մոռացել էին այդ մասին։ Ընդհանրապես, դա աղբ ու թափոն էր։

Ի՞նչ արեցինք հետո դրա հետ: Մենք ուղարկեցինք կաֆկային։ Կաֆկայից այն կողմ գերանների կեսը թռավ Լոգստաշ։ Գերանների մյուս կեսը կիսվել է: Ոմանք թռան մի Գրեյլոգ, ոմանք՝ մյուս Գրեյլոգ։ Արդյունքում այս ամենը թռավ մեկ Elasticsearch կլաստերի մեջ: Այսինքն՝ այս ամբողջ խառնաշփոթը վերջում ընկավ այնտեղ։ Պետք չէ դա անել։

Ահա թե ինչ տեսք ունի այն վերևից նայելիս. Պետք չէ դա անել: Այստեղ խնդրահարույց տարածքները անմիջապես նշվում են թվերով: Դրանք իրականում ավելի շատ են, բայց 6-ն իսկապես խնդրահարույց են, որոնց հետ պետք է ինչ-որ բան անել։ Նրանց մասին հիմա կպատմեմ առանձին։

Այստեղ (1,2,3) մենք գրում ենք ֆայլեր և, համապատասխանաբար, այստեղ միանգամից երեք փոցխ կա։

Առաջինը (1) այն է, որ մենք պետք է դրանք ինչ-որ տեղ գրենք: Միշտ չէ, որ ցանկալի է API-ին տալ ֆայլի վրա անմիջապես գրելու հնարավորություն: Ցանկալի է, որ API-ն մեկուսացված լինի կոնտեյներով, և նույնիսկ ավելի լավ, որ այն լինի միայն կարդալու համար: Ես համակարգի ադմինիստրատոր եմ, ուստի մի փոքր այլընտրանքային տեսակետ ունեմ այս բաների վերաբերյալ:

Երկրորդ կետը (2,3) այն է, որ մենք ունենք բազմաթիվ հարցումներ, որոնք գալիս են API-ին: API-ն շատ տվյալներ է գրում ֆայլում: Ֆայլերը մեծանում են։ Մենք պետք է պտտենք դրանք: Քանի որ հակառակ դեպքում դուք չեք կարողանա այնտեղ ոչ մի սկավառակ պահել: Նրանց պտտելը վատ է, քանի որ դրանք կեղևի միջոցով ուղղորդվում են գրացուցակ: Մենք ոչ մի կերպ չենք կարող պտտել այն: Դուք չեք կարող հավելվածին ասել, որ վերաբացի բռնակները: Որովհետև մշակողները ձեզ հիմարի պես կնայեն. «Ի՞նչ նկարագրիչներ: Մենք հիմնականում գրում ենք stdout-ին: Շրջանակները պատճենահանված են դարձնում logrotate, որը պարզապես ստեղծում է ֆայլի պատճենը և կոճղերը բնօրինակը: Համապատասխանաբար, այս պատճենահանման գործընթացների միջև սկավառակի տարածքը սովորաբար սպառվում է:

(4) Մենք ունեինք տարբեր ձևաչափեր տարբեր API-ներում: Նրանք մի փոքր տարբեր էին, բայց regexp-ը պետք է այլ կերպ գրվեր: Քանի որ այդ ամենը տնօրինում էր Տիկնիկը, դասերի մի մեծ խումբ կային իրենց սեփական ուտիճներով: Բացի այդ, td-agent-ը շատ ժամանակ կարող էր ուտել հիշողությունը, լինել հիմար, նա կարող էր պարզապես ձևացնել, թե աշխատում է և ոչինչ չանել: Արտաքնապես անհնար էր հասկանալ, որ նա ոչինչ չի անում։ Լավագույն դեպքում նա կընկնի, և ինչ-որ մեկը նրան ավելի ուշ կվերցնի։ Ավելի ճիշտ՝ ահազանգ կթռչի, մեկը կգնա ձեռքով կբարձրացնի։

(6) Եվ ամենաշատ աղբը և թափոնը դա էլաստիկ որոնումն էր: Որովհետև դա հին տարբերակ էր։ Որովհետև մենք այն ժամանակ չունեինք նվիրյալ վարպետներ։ Մենք ունեինք տարասեռ գերաններ, որոնց դաշտերը կարող էին համընկնել: Տարբեր հավելվածների տարբեր տեղեկամատյաններ կարող են գրվել դաշտերի նույն անուններով, բայց միևնույն ժամանակ ներսում կարող են լինել տարբեր տվյալներ: Այսինքն, մեկ տեղեկամատյան գալիս է ամբողջ թվով դաշտում, օրինակ՝ մակարդակ: Մեկ այլ տեղեկամատյան գալիս է մի տողով մակարդակի դաշտում: Ստատիկ քարտեզագրման բացակայության դեպքում այսպիսի հրաշալի բան է ստացվում. Եթե ​​ինդեքսի ռոտացիայից հետո elasticsearch-ում առաջինը տողով հաղորդագրություն է հայտնվել, ապա մենք նորմալ ենք ապրում։ Եվ եթե առաջինը հասել է Integer-ով, ապա String-ով ժամանած բոլոր հետագա հաղորդագրությունները պարզապես անտեսվում են: Քանի որ դաշտի տեսակը չի համընկնում:

Մենք սկսեցինք այս հարցերը տալ. Որոշեցինք մեղավորներին չփնտրել։

Բայց ինչ-որ բան պետք է անել: Ակնհայտ է, որ մենք պետք է չափորոշիչներ սահմանենք։ Մենք արդեն ունեինք որոշ չափորոշիչներ։ Ոմանք բերեցինք մի փոքր ուշ: Բարեբախտաբար, բոլոր API-ների համար մեկ գրանցամատյանի ձևաչափն արդեն հաստատված էր այդ ժամանակ: Այն ուղղակիորեն գրված է ծառայության փոխգործակցության ստանդարտների մեջ: Համապատասխանաբար, նրանք, ովքեր ցանկանում են տեղեկամատյաններ ստանալ, պետք է գրեն դրանք այս ձևաչափով։ Եթե ​​որևէ մեկը այս ձևաչափով տեղեկամատյաններ չի գրում, ապա մենք ոչինչ չենք երաշխավորում:

Ավելին, ես կցանկանայի ունենալ մեկ ստանդարտ տեղեկամատյանների գրանցման, առաքման և հավաքման մեթոդների համար: Իրականում, որտեղ գրել դրանք և ինչպես մատուցել դրանք: Իդեալական իրավիճակն այն է, երբ նախագծերն օգտագործում են նույն գրադարանը: Go-ի համար կա առանձին լոգերի գրադարան, PHP-ի համար կա առանձին գրադարան։ Բոլորը, որ ունենք, բոլորը պետք է օգտագործեն դրանք։ Այս պահին ես կասեի, որ մեզ մոտ 80 տոկոսով հաջողվում է։ Սակայն ոմանք շարունակում են կակտուսներ ուտել:

Եվ այնտեղ (սլայդի վրա) հազիվ է սկսում հայտնվել «SLA for log delivery»: Այն դեռ չկա, բայց մենք աշխատում ենք դրա վրա: Որովհետև շատ հարմար է, երբ infra-ն ասում է, որ եթե այսինչ ֆորմատով գրում ես այսինչ վայրում և ոչ ավելի, քան N հաղորդագրություն վայրկյանում, ապա մենք ամենայն հավանականությամբ այնտեղ կառաքենք։ Այն հեռացնում է շատ գլխացավեր: Եթե ​​կա SLA, ապա դա պարզապես հիանալի է:

Ինչպե՞ս սկսեցինք լուծել խնդիրը: Հիմնական փոցխը եղել է td-agent-ով։ Անհասկանալի էր, թե ուր են գնում մեր գերանները։ Արդյո՞ք դրանք առաքվում են: Գնու՞մ են։ Ո՞ւր են նրանք այնուամենայնիվ: Ուստի որոշվեց td-agent-ը փոխարինել առաջին կետով։ Ընտրանքներ, թե ինչով փոխարինել այն, ես հակիրճ նկարագրեցի այստեղ:

Սահուն. Նախ, ես հանդիպեցի նրան նախորդ աշխատանքի ժամանակ, և նա նույնպես պարբերաբար ընկնում էր այնտեղ: Երկրորդ, սա նույնն է, միայն պրոֆիլում:

ֆայլի հարված: Ինչո՞վ էր լավ մեզ համար: Այն, որ նա գտնվում է Գոյում, և մենք մեծ փորձ ունենք Գոյում: Համապատասխանաբար, եթե ինչ-որ բան, մենք կարող ենք ինչ-որ կերպ ավելացնել այն մեզ վրա: Դրա համար էլ չվերցրինք։ Որպեսզի նույնիսկ գայթակղություն չառաջանա՝ սկսելու այն վերաշարադրել ձեզ համար։

Sysadmin-ի ակնհայտ լուծումը այս քանակի բոլոր տեսակի syslog-ներն են (syslog-ng/rsyslog/nxlog):

Կամ գրեք ձեր սեփական ինչ-որ բան, բայց մենք այն դեն նետեցինք, ինչպես նաև ֆայլբիթ: Եթե ​​ինչ-որ բան ես գրում, ապա ավելի լավ է բիզնեսի համար օգտակար բան գրես։ Տեղեկամատյաններ առաքելու համար ավելի լավ է պատրաստի ինչ-որ բան վերցնել:

Հետևաբար, ընտրությունը իրականում հանգեցրեց syslog-ng-ի և rsyslog-ի միջև ընտրությանը: Ես թեքվեցի դեպի rsyslog պարզապես այն պատճառով, որ մենք արդեն ունեինք դասեր rsyslog-ի համար Puppet-ում, և ես ակնհայտ տարբերություն չգտա նրանց միջև: Ինչ է syslog, ինչ է syslog: Այո, որոշ փաստաթղթեր ավելի վատն են, որոշները՝ ավելի լավ: Նա գիտի այս ձևը, և ​​նա դա այլ կերպ է անում:

Եվ մի փոքր rsyslog-ի մասին: Նախ, դա հիանալի է, քանի որ այն ունի շատ մոդուլներ: Այն ունի մարդու կողմից ընթեռնելի RainerScript (ժամանակակից կոնֆիգուրացիայի լեզու): Հիանալի բոնուսն այն է, որ մենք կարող ենք ընդօրինակել td-agent-ի վարքագիծը իր ստանդարտ գործիքներով, և հավելվածների համար ոչինչ չի փոխվել: Այսինքն՝ td-agent-ը փոխում ենք rsyslog-ի, իսկ մնացած ամեն ինչին դեռ չենք դիպչում։ Եվ անմիջապես ստանում ենք աշխատանքային առաքում։ Հաջորդը, mmnormalize-ը rsyslog-ի ամենալավ բանն է: Այն թույլ է տալիս վերլուծել տեղեկամատյանները, բայց ոչ Grok-ի և regexp-ի հետ: Այն կազմում է վերացական շարահյուսական ծառ: Այն վերլուծում է տեղեկամատյանները մոտավորապես այնպես, ինչպես կոմպիլյատորը վերլուծում է աղբյուրի կոդը: Սա թույլ է տալիս շատ արագ աշխատել, ուտել քիչ պրոցեսոր, և, ընդհանուր առմամբ, դա պարզապես շատ հիանալի բան է: Կան մի շարք այլ բոնուսներ: Ես դրանց վրա չեմ անդրադառնա։

rsyslog-ը շատ ավելի շատ թերություններ ունի: Դրանք մոտավորապես նույնն են, ինչ բոնուսները: Հիմնական խնդիրներն այն են, որ դուք պետք է կարողանաք այն պատրաստել, և դուք պետք է ընտրեք տարբերակը:

Մենք որոշեցինք, որ մենք գրելու ենք տեղեկամատյանները unix վարդակից: Եվ ոչ /dev/log-ում, քանի որ այնտեղ մենք ունենք համակարգային տեղեկամատյանների խառնաշփոթ, այս խողովակաշարում կա ամսագիր: Այսպիսով, եկեք գրենք մաքսային վարդակից: Մենք այն կկցենք առանձին կանոնակարգի: Եկեք ոչ մի բանի չխանգարենք։ Ամեն ինչ կլինի թափանցիկ ու հասկանալի։ Այսպիսով, մենք իրականում արեցինք: Այս վարդակներով գրացուցակը ստանդարտացված է և փոխանցվում է բոլոր բեռնարկղերին: Տարաները կարող են տեսնել իրենց անհրաժեշտ վարդակը, բացել և գրել դրան:

Ինչու ոչ ֆայլ: Որովհետև բոլորը կարդացել են հոդված Բադուշեչկայի մասին, որը փորձեց ֆայլը փոխանցել docker-ին և պարզեց, որ rsyslog-ը վերագործարկելուց հետո ֆայլի նկարագրիչը փոխվում է, և docker-ը կորցնում է այս ֆայլը։ Նա բաց է պահում ուրիշ բան, բայց ոչ նույն վարդակից, որտեղ գրում են։ Մենք որոշեցինք, որ շրջանցելու ենք այս խնդիրը և, միաժամանակ, շրջանցելու ենք արգելափակման խնդիրը։

Rsyslog-ը կատարում է սլայդում նշված գործողությունները և տեղեկամատյաններ է ուղարկում կա՛մ ռելեին, կա՛մ Կաֆկային: Կաֆկան գնում է հին ճանապարհով. Rayleigh - Ես փորձեցի օգտագործել մաքուր rsyslog տեղեկամատյանները մատուցելու համար: Առանց հաղորդագրությունների հերթի, օգտագործելով ստանդարտ rsyslog գործիքներ: Հիմնականում այն ​​աշխատում է:

Բայց կան նրբերանգներ, թե ինչպես դրանք հետագայում լցնել այս մասում (Logstash/Graylog/ES): Այս մասը (rsyslog-rsyslog) օգտագործվում է տվյալների կենտրոնների միջև։ Ահա սեղմված tcp հղումը, որը թույլ է տալիս խնայել թողունակությունը և, համապատասխանաբար, ինչ-որ կերպ մեծացնել հավանականությունը, որ մենք այլ տվյալների կենտրոնից որոշ տեղեկամատյաններ կստանանք, երբ ալիքը լցվի: Որովհետև մենք ունենք Ինդոնեզիա, որտեղ ամեն ինչ վատ է։ Ահա թե որտեղ է մշտական ​​խնդիրը:

Մտածեցինք, թե իրականում ինչպես ենք մոնիթորինգ անում, ի՞նչ հավանականությամբ հավելվածից գրանցված տեղեկամատյանները հասնում են դրան։ Մենք որոշեցինք սկսել չափումները: Rsyslog-ն ունի իր վիճակագրության հավաքագրման մոդուլը, որն ունի ինչ-որ հաշվիչներ: Օրինակ, այն կարող է ցույց տալ ձեզ հերթի չափը կամ քանի հաղորդագրություն է մուտքագրվել այս կամ այն ​​գործողության համար: Դուք արդեն կարող եք նրանցից ինչ-որ բան վերցնել: Բացի այդ, այն ունի հատուկ հաշվիչներ, որոնք դուք կարող եք կարգավորել, և այն ցույց կտա ձեզ, օրինակ, որոշ API-ների գրանցած հաղորդագրությունների քանակը: Հաջորդը ես Python-ում գրեցի rsyslog_exporter, և մենք այդ ամենը ուղարկեցինք Պրոմեթևսին և գծեցինք: Մենք իսկապես ուզում էինք Graylog չափումներ, բայց մինչ այժմ մենք ժամանակ չենք ունեցել դրանք կարգավորելու համար:

Ի՞նչ խնդիրներ կան։ Խնդիրը ծագեց նրանից, որ մենք իմացանք (ՀԱԿԱԾ!), որ մեր Live API-ները վայրկյանում 50 հազար հաղորդագրություն են գրում: Սա միայն Live API է առանց բեմադրության: Իսկ Graylog-ը մեզ վայրկյանում ցույց է տալիս ընդամենը 12 հազար հաղորդագրություն։ Եվ ողջամիտ հարց առաջացավ՝ որտե՞ղ են մնացորդները։ Որից մենք եզրակացրինք, որ Graylog-ը պարզապես չի կարողանում հաղթահարել: Մենք նայեցինք, և, իրոք, Graylog-ը Elasticsearch-ով չէր տիրապետում այս հոսքին:

Հաջորդը, այլ բացահայտումներ, որոնք մենք արել ենք ճանապարհին:

Գրառումները վարդակից արգելափակված են: Ինչպե՞ս դա տեղի ունեցավ: Երբ ես օգտագործեցի rsyslog-ը առաքման համար, ինչ-որ պահի մենք կոտրեցինք ալիքը տվյալների կենտրոնների միջև: Առաքումը բարձրացավ մի տեղ, առաքումը բարձրացավ մեկ այլ վայրում: Այս ամենը հանգել է API-ներով մեքենա, որը գրում է rsyslog վարդակից: Հերթ էր գոյացել։ Այնուհետև լրացվեց unix վարդակից գրելու հերթը, որը լռելյայն կազմում է 128 փաթեթ: Իսկ հաջորդ գրել() հավելվածի բլոկներում։ Երբ մենք նայեցինք գրադարանը, որն օգտագործում ենք Go հավելվածներում, այնտեղ գրված էր, որ վարդակից գրելը տեղի է ունենում ոչ արգելափակման ռեժիմում։ Մենք վստահ էինք, որ ոչինչ արգելափակված չէ։ Որովհետև մենք կարդացել ենք հոդված Բադուշեչկայի մասինով գրել է այդ մասին: Բայց մի պահ կա. Այս զանգի շուրջ նույնպես անսահման մի օղակ կար, որի ժամանակ անընդհատ փորձ էր արվում հաղորդագրություն հրել վարդակից: Մենք նրան չնկատեցինք։ Ես ստիպված էի վերաշարադրել գրադարանը: Այդ ժամանակվանից այն մի քանի անգամ փոխվել է, բայց հիմա մենք ազատվել ենք բոլոր ենթահամակարգերի կողպեքներից։ Հետեւաբար, դուք կարող եք դադարեցնել rsyslog-ը, և ոչինչ չի ընկնի:

Հարկավոր է վերահսկել հերթերի չափը, որն օգնում է այս փոցխի վրա չոտնահարել։ Նախ, մենք կարող ենք հետևել, թե երբ ենք սկսում կորցնել հաղորդագրությունները: Երկրորդ, մենք կարող ենք հետևել, որ հիմնականում խնդիրներ ունենք առաքման հետ:

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

Ինչպե՞ս լուծել elasticsearch-ի խնդիրը: Եթե ​​Ձեզ անհրաժեշտ է մեկ տեղում արագ հավաքել տեղեկամատյանները, որպեսզի չվազեք բոլոր մեքենաների վրա և չհավաքեք դրանք այնտեղ, օգտագործեք ֆայլերի պահեստավորում: Սա երաշխավորված է աշխատելու: Այն կատարվում է ցանկացած սերվերից: Պարզապես պետք է սկավառակներ կպցնել այնտեղ և տեղադրել syslog: Դրանից հետո դուք երաշխավորված եք բոլոր տեղեկամատյանները մեկ տեղում: Այնուհետև հնարավոր կլինի դանդաղ կարգավորել elasticsearch-ը, graylog-ը կամ այլ բան: Բայց դուք արդեն կունենաք բոլոր տեղեկամատյանները, և, ավելին, կարող եք դրանք պահել այնքանով, որքանով կան բավականաչափ սկավառակների զանգվածներ:

Իմ զեկույցի ժամանակ սխեման սկսեց այսպիսի տեսք ունենալ. Մենք գործնականում դադարեցինք գրել ֆայլին: Հիմա, ամենայն հավանականությամբ, մենք կանջատենք մնացորդները։ API-ով աշխատող տեղական մեքենաներում մենք կդադարենք գրել ֆայլերին: Նախ, կա ֆայլերի պահեստավորում, որը շատ լավ է աշխատում: Երկրորդ, այս մեքենաների տարածքը անընդհատ սպառվում է, դուք պետք է անընդհատ վերահսկեք այն:

Այս հատվածը Logstash-ի և Graylog-ի հետ իսկապես ճախրում է: Հետեւաբար, դուք պետք է ձերբազատվեք դրանից: Դուք պետք է ընտրեք մեկը:

Մենք որոշեցինք թողնել Logstash-ը և Kibana-ն: Որովհետև մենք անվտանգության բաժին ունենք։ Ի՞նչ կապ կա: Կապն այն է, որ Kibana-ն առանց X-Pack-ի և առանց Shield-ի թույլ չի տալիս տարբերակել մուտքի իրավունքները դեպի տեղեկամատյաններ: Հետեւաբար, նրանք վերցրեցին Graylog-ը: Այն ունի այդ ամենը: Ինձ դուր չի գալիս, բայց աշխատում է: Մենք գնեցինք նոր սարքավորումներ, այնտեղ տեղադրեցինք թարմ Graylog և խիստ ձևաչափերով բոլոր տեղեկամատյանները տեղափոխեցինք առանձին Graylog: Նույն ոլորտների տարբեր տեսակների խնդիրը կազմակերպչականորեն լուծել ենք։

Թե կոնկրետ ինչ է ներառված նոր Graylog-ում։ Մենք պարզապես ամեն ինչ գրել ենք նավահանգստում: Մենք վերցրեցինք մի փունջ սերվերներ, թողարկեցինք Կաֆկայի երեք օրինակ, 7 Graylog սերվերների 2.3 տարբերակը (որովհետև ես ուզում էի Elasticsearch 5-րդ տարբերակը): Այս ամենը բարձրացվել է HDD-ի արշավանքների վրա: Մենք տեսանք վայրկյանում մինչև 100 հազար հաղորդագրությունների ինդեքսավորման արագություն: Մենք տեսանք այն ցուցանիշը, որ շաբաթական 140 տերաբայթ տվյալներ:

Եվ նորից փոցխ։ Մեզ սպասվում է երկու վաճառք: Մենք առաջ ենք անցել 6 միլիոն գրառումից: Մենք Graylog-ը ժամանակ չունենք ծամելու։ Ինչ-որ կերպ պետք է նորից գոյատևես:

Այսպես մենք ողջ մնացինք։ Ավելացվեց ևս մի քանի սերվեր և SSD: Այս պահին մենք այսպես ենք ապրում. Այժմ մենք արդեն ծամում ենք վայրկյանում 160 հազար հաղորդագրություն։ Մենք դեռ չենք հասել սահմանին, ուստի անհասկանալի է, թե որքանով կարող ենք իրատեսորեն դուրս գալ դրանից:

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

Հավաքեք չափումներ Graylog-ից:

Սահմանեք տոկոսադրույքը, որպեսզի մենք ունենանք մեկ խելահեղ API, որը չի սպանում մեզ թողունակությունը և մնացած ամեն ինչ:

Եվ վերջապես, ստորագրեք ինչ-որ SLA ծրագրավորողների հետ, որպեսզի կարողանանք այդքան սպասարկել։ Եթե ​​ավելին գրեք, ապա կներեք։

Եվ գրեք փաստաթղթեր:

Մի խոսքով, այն ամենի արդյունքները, ինչ մենք ապրել ենք։ Նախ, ստանդարտները. Երկրորդ, syslog-ը տորթ է: Երրորդ, rsyslog-ն աշխատում է ճիշտ այնպես, ինչպես գրված է սլայդի վրա: Եվ անցնենք հարցերին։

Հարցեր.

ՀարցԻնչո՞ւ որոշեցին չվերցնել ... (filebeat?)

Պատասխան: Պետք է գրել ֆայլ: Ես իսկապես չէի ուզում։ Երբ ձեր API-ն վայրկյանում հազարավոր հաղորդագրություններ է գրում, նույնիսկ եթե դուք պտտվում եք ժամում մեկ անգամ, սա դեռ տարբերակ չէ: Դուք կարող եք գրել խողովակին: Ինչին ծրագրավորողները ինձ հարցրին. «Ի՞նչ կլինի, եթե այն գործընթացը, որում մենք գրում ենք, ընկնի»: Ես ուղղակի չգտա, թե ինչ պատասխանեմ նրանց և ասացի. «Դե լավ, արի այդպես չանենք»։

ՀարցԻնչու՞ պարզապես տեղեկամատյաններ չեք գրում HDFS-ում:

ՊատասխանA: Սա հաջորդ քայլն է: Մենք դրա մասին մտածել ենք հենց սկզբից, բայց քանի որ այս պահին դրա հետ կապված ռեսուրսներ չկան, դա կախված է մեր երկարաժամկետ լուծման մեջ:

ՀարցԱվելի հարմար կլինի սյունակի ձևաչափը:

Պատասխան: Ես հասկանում եմ. Երկու ձեռքով «կողմ» ենք։

ՀարցԴուք գրում եք rsyslog-ին: Այնտեղ հասանելի են և՛ TCP, և՛ UDP: Բայց եթե UDP, ապա ինչպե՞ս եք երաշխավորում առաքումը:

ՊատասխանՊատասխան. Երկու կետ կա. Նախ, ես անմիջապես ասում եմ բոլորին, որ մենք չենք երաշխավորում գերանների առաքումը: Որովհետև երբ ծրագրավորողները գալիս են և ասում. «Եկեք սկսենք այնտեղ ֆինանսական տվյալներ գրել, և դուք դրանք ինչ-որ տեղ կտեղադրեք մեզ համար, եթե ինչ-որ բան պատահի», մենք պատասխանում ենք նրանց՝ «Հիանալի է: Եկեք սկսենք արգելափակել վարդակից գրելը, և դա անել գործարքների ժամանակ, որպեսզի դուք երաշխավորված լինեք այն մեզ համար դնել վարդակից և համոզվեք, որ մենք այն ստացել ենք մյուս կողմից: Եվ այս պահին բոլորը միանգամից դառնում են ավելորդ։ Իսկ եթե ոչ, ապա ի՞նչ հարցեր ունենք։ Եթե ​​դուք չեք ցանկանում երաշխավորել վարդակից գրելը, ապա ինչու՞ երաշխավորենք առաքումը: Մենք գործադրում ենք լավագույն ջանքերը։ Մենք իսկապես փորձում ենք մատուցել հնարավորինս շատ և հնարավորինս լավ, բայց 100% երաշխիք չենք տալիս: Հետեւաբար, այնտեղ ֆինանսական տվյալներ գրելու կարիք չկա։ Դրա համար կան գործարքային տվյալների բազաներ:

ՀարցԵրբ API-ն ինչ-որ հաղորդագրություն է ստեղծում գրանցամատյանում և կառավարումը փոխանցում միկրոսերվիսներին, հանդիպե՞լ եք խնդրի, որ տարբեր միկրոծառայությունների հաղորդագրությունները սխալ հերթականությամբ են գալիս: Սրա պատճառով առաջանում է շփոթություն։

Պատասխան- Նորմալ է, որ այլ հերթականությամբ են գալիս: Դուք պետք է պատրաստ լինեք դրան: Քանի որ ցանկացած ցանցային առաքում չի երաշխավորում ձեզ պատվերը, կամ դուք պետք է հատուկ միջոցներ ծախսեք դրա վրա: Եթե ​​մենք վերցնում ենք ֆայլերի պահեստներ, ապա յուրաքանչյուր API պահում է տեղեկամատյանները իր ֆայլում: Ավելի շուտ, rsyslog-ը դրանք տարրալուծում է այնտեղ գտնվող դիրեկտորիաների: Յուրաքանչյուր API այնտեղ ունի իր սեփական տեղեկամատյանները, որտեղ կարող եք գնալ և նայել, այնուհետև կարող եք համեմատել դրանք՝ օգտագործելով այս մատյանում նշված ժամանակի դրոշմը: Եթե ​​նրանք գնան Graylog-ում փնտրելու, ապա այնտեղ դրանք կտեսակավորվեն ըստ ժամանակի դրոշմակնիքի: Այնտեղ ամեն ինչ լավ կլինի։

ՀարցԺամացույցը կարող է տարբերվել միլիվայրկյաններով:

ՊատասխանԺամանակի դրոշմը ստեղծվում է հենց API-ի կողմից: Սա, ըստ էության, ամբողջ խնդիրն է։ Մենք ունենք NTP. API-ն ստեղծում է ժամանակի դրոշմ արդեն իսկ հաղորդագրության մեջ: Այն չի ավելացվել rsyslog-ի կողմից:

ՀարցՏվյալների կենտրոնների միջև փոխգործակցությունը այնքան էլ պարզ չէ: Տվյալների կենտրոնի շրջանակներում պարզ է, թե ինչպես են հավաքագրվել և մշակվել տեղեկամատյանները։ Ինչպե՞ս է փոխգործակցությունը տվյալների կենտրոնների միջև: Թե՞ յուրաքանչյուր տվյալների կենտրոն ապրում է իր կյանքով:

Պատասխան: Գրեթե. Մենք ունենք յուրաքանչյուր երկիր, որը գտնվում է մեկ տվյալների կենտրոնում: Մենք ներկայումս չունենք տարածում, որպեսզի մեկ երկիր տեղադրվի տվյալների տարբեր կենտրոններում։ Հետեւաբար, դրանք համատեղելու կարիք չկա։ Յուրաքանչյուր կենտրոնի ներսում կա Log Relay: Սա Rsyslog սերվեր է: Փաստորեն, երկու կառավարման մեքենա: Դրանք տեղադրվում են նույն ձևով: Բայց առայժմ երթևեկությունը պարզապես անցնում է դրանցից մեկով: Նա գրանցում է ամեն ինչ ագրեգատներով: Այն ունի սկավառակի հերթ՝ ամեն դեպքում։ Նա սեղմում է տեղեկամատյանները և դրանք ուղարկում տվյալների կենտրոնական կենտրոն (Սինգապուր), որտեղ հետագայում նրանք արդեն թունավորվել են Գրեյլոգում: Եվ յուրաքանչյուր տվյալների կենտրոն ունի իր ֆայլերի պահեստը: Կապը կորցնելու դեպքում մենք այնտեղ ունենք բոլոր տեղեկամատյանները: Նրանք կմնան այնտեղ։ Դրանք կպահվեն այնտեղ։

ՀարցԱննորմալ իրավիճակներում այնտեղից գերաններ ե՞ք ստանում:

ՊատասխանԴուք կարող եք գնալ այնտեղ (ֆայլերի պահեստ) և նայել:

ՀարցԻնչպե՞ս եք հետևում, որ տեղեկամատյանները չկորցնեք:

ՊատասխանՄենք իրականում կորցնում ենք դրանք, և մենք հետևում ենք դրան: Մոնիտորինգը սկսվել է մեկ ամիս առաջ։ Գրադարանը, որն օգտագործում են Go API-ները, ունի չափումներ: Նա կարող է հաշվել, թե քանի անգամ չի կարողացել գրել վարդակից: Այնտեղ այս պահին կա բարդ էվրիստիկա: Այնտեղ բուֆեր կա։ Այն փորձում է դրանից հաղորդագրություն գրել վարդակից: Եթե ​​բուֆերը լցվում է, այն սկսում է գցել դրանք: Եվ նա հաշվում է, թե քանիսն է դրանք բաց թողել։ Եթե ​​այնտեղ հաշվիչներն սկսեն լցվել, մենք կիմանանք այդ մասին։ Նրանք այժմ նաև գալիս են դեպի Պրոմեթևս, և դուք կարող եք տեսնել գրաֆիկները Grafana-ում: Դուք կարող եք նախազգուշացումներ ստեղծել: Բայց դեռ պարզ չէ, թե ում ուղարկել դրանք։

Հարցelasticsearch-ում դուք պահպանում եք տեղեկամատյանները ավելորդությամբ: Քանի՞ կրկնօրինակ ունեք:

ՊատասխանՄեկ կրկնօրինակ:

Հարց: Դա միայն մեկ տող է:

ՊատասխանՍա վարպետն ու կրկնօրինակն է: Տվյալները պահվում են կրկնօրինակով:

ՀարցԴուք ինչ-որ կերպ կարգավորե՞լ եք rsyslog բուֆերի չափը:

ՊատասխանՄենք գրում ենք datagrams անհատական ​​unix վարդակից: Սա անմիջապես մեզ վրա դնում է 128 կիլոբայթի սահմանափակում։ Մենք չենք կարող ավելին գրել դրա մասին: Մենք սա գրել ենք ստանդարտում: Ով ուզում է մտնել պահեստ, նրանք գրում են 128 կիլոբայթ: Գրադարանները, ընդ որում, կտրում են, դրոշակ են դնում, որ հաղորդագրությունը կտրված է։ Բուն հաղորդագրության ստանդարտում մենք ունենք հատուկ դաշտ, որը ցույց է տալիս՝ այն կտրվել է ձայնագրման ժամանակ, թե ոչ։ Այսպիսով, մենք հնարավորություն ունենք հետևելու այս պահին:

ՀարցԴու գրում ես ջարդված JSON?

ՊատասխանԿոտրված JSON-ը կհեռացվի կամ փոխանցման ժամանակ, քանի որ փաթեթը չափազանց մեծ է: Կամ Graylog-ը կհեռացվի, քանի որ այն չի կարողանա վերլուծել JSON-ը: Բայց այստեղ կան նրբերանգներ, որոնք պետք է շտկվեն, և դրանք հիմնականում կապված են rsyslog-ի հետ։ Այնտեղ արդեն մի քանի համար եմ լրացրել, որոնց վրա դեռ պետք է աշխատել։

ՀարցԻնչու՞ Կաֆկա: Դուք փորձե՞լ եք RabbitMQ: Graylog-ը նման բեռների տակ չի՞ ավելանում:

ՊատասխանGraylog-ի հետ չի ստացվում: Եվ Graylog-ը ձևավորվում է: Դա իրոք խնդրահարույց է նրա համար։ Նա մի տեսակ բան է: Եվ, ըստ էության, դա պետք չէ։ Գերադասում եմ գրել rsyslog-ից ուղիղ elasticsearch-ին, հետո նայել Kibana-ին: Բայց մենք պետք է հարցը կարգավորենք անվտանգության աշխատակիցների հետ։ Սա մեր զարգացման հնարավոր տարբերակն է, երբ մենք դուրս ենք նետում Graylog-ը և օգտագործում ենք Kibana-ն: Logstash-ը իմաստ չի ունենա: Քանի որ ես կարող եմ նույնը անել rsyslog-ի հետ: Իսկ elasticsearch-ին գրելու մոդուլ ունի։ Graylog-ի հետ մենք փորձում ենք ինչ-որ կերպ ապրել։ Մենք նույնիսկ մի փոքր շտկեցինք այն: Բայց դեռ բարելավման տեղ կա։

Կաֆկայի մասին. Պատմականորեն այդպես է եղել։ Երբ ես հասա, այն արդեն այնտեղ էր, և դրա վրա արդեն տեղեկամատյաններ էին գրում։ Մենք պարզապես բարձրացրինք մեր կլաստերը և տեղեկամատյանները տեղափոխեցինք դրա մեջ: Մենք նրան կառավարում ենք, գիտենք, թե նա ինչ է զգում։ Ինչ վերաբերում է RabbitMQ-ին... մենք խնդիրներ ունենք RabbitMQ-ի հետ: Իսկ RabbitMQ-ն զարգանում է մեզ համար: Մենք ունենք այն արտադրության մեջ, և դրա հետ կապված խնդիրներ կային։ Հիմա, մինչ վաճառքը, նրան շամանացնելու էին, և նա կսկսեր նորմալ աշխատել։ Բայց մինչ այդ ես պատրաստ չէի այն թողարկել արտադրության։ Կա ևս մեկ կետ. Graylog-ը կարող է կարդալ AMQP 0.9 տարբերակը, իսկ rsyslog-ը՝ գրել AMQP 1.0 տարբերակը: Եվ չկա մեկ լուծում, որը կարող է երկուսն էլ անել մեջտեղում: Կա կամ մեկը, կամ մյուսը: Այսպիսով, առայժմ միայն Կաֆկան։ Բայց կան նաև նրբերանգներ. Քանի որ rsyslog-ի տարբերակի omkafka-ն, որը մենք օգտագործում ենք, կարող է կորցնել հաղորդագրությունների ամբողջ բուֆերը, որը նա հավաքել է rsyslog-ից: Քանի դեռ համակերպվում ենք դրա հետ։

ՀարցԴուք օգտագործում եք Կաֆկան այն պատճառով, որ այն ունեցել եք: Չե՞ք օգտագործվում որևէ այլ նպատակի համար:

ՊատասխանԿաֆկա, որն օգտագործվել է Data Science թիմի կողմից: Սա բոլորովին առանձին նախագիծ է, որի մասին, ցավոք, ոչինչ չեմ կարող ասել։ Ես չգիտեմ. Նա ղեկավարվում էր Data Science թիմի կողմից: Երբ գերանները սկսեցին, նրանք որոշեցին օգտագործել այն, որպեսզի չդնեն իրենցը: Այժմ մենք թարմացրել ենք Graylog-ը և կորցրել ենք համատեղելիությունը, քանի որ կա Կաֆկայի հին տարբերակը։ Մենք պետք է մերը սարքեինք։ Միևնույն ժամանակ, մենք ազատվեցինք այս չորս թեմաներից յուրաքանչյուր API-ի համար: Մենք պատրաստեցինք մեկ լայն վերնաշապիկ բոլոր կենդանիների համար, մեկ լայն լայն վերնաշապիկ բոլոր բեմադրության համար, և մենք պարզապես այնտեղ նկարում ենք ամեն ինչ: Graylog-ը այս ամենը զուգահեռաբար դուրս է բերում:

ՀարցՄեզ ինչի՞ն է պետք վարդակներով այս շամանիզմը։ Փորձե՞լ եք օգտագործել բեռնարկղերի համար syslog log driver-ը:

ՊատասխանԺամանակին, երբ այս հարցը տվեցինք, մենք լարված հարաբերություններ ունեինք նավահանգստի հետ։ Դա docker 1.0 կամ 0.9 էր: Դոկերն ինքնին տարօրինակ էր: Երկրորդ, եթե դուք նաև տեղեկամատյաններ եք խցնում դրա մեջ... Ես չստուգված կասկած ունեմ, որ այն անցնում է բոլոր տեղեկամատյանները իր միջով, դոկեր դեյմոնի միջով: Եթե ​​մենք ունենք մեկ API, որը խելագարվում է, ապա մնացած API-ները կբախվեն այն փաստի հետ, որ նրանք չեն կարող ուղարկել stdout և stderr: Ես չգիտեմ, թե սա ուր կտանի։ Ես կասկած ունեմ զգալու մակարդակով, որ անհրաժեշտ չէ այս վայրում օգտագործել docker syslog դրայվերը։ Մեր ֆունկցիոնալ փորձարկման բաժինն ունի իր սեփական Graylog կլաստերը՝ տեղեկամատյաններով: Նրանք օգտագործում են docker log drivers, և այնտեղ ամեն ինչ կարծես թե լավ է: Բայց Գրեյլոգին միանգամից GELF են գրում։ Այն պահին, երբ մենք սկսեցինք այս ամենը, դա մեզ անհրաժեշտ էր, որպեսզի պարզապես աշխատենք։ Երեւի հետո, երբ մեկը գա ու ասի, որ հարյուր տարի նորմալ է աշխատում, փորձենք։

ՀարցԴուք առաքում եք տվյալների կենտրոնների միջև՝ օգտագործելով rsyslog: Ինչու ոչ Կաֆկայի վրա:

ՊատասխանՄենք դա անում ենք, և դա իրականում այդպես է: Երկու պատճառով. Եթե ​​ալիքը լիովին մեռած է, ապա մեր բոլոր տեղեկամատյանները, նույնիսկ սեղմված տեսքով, չեն բարձրանա դրա միջով: Իսկ կաֆկան թույլ է տալիս նրանց պարզապես պարտվել այդ ընթացքում։ Այս կերպ մենք ազատվում ենք այս գերանների կպչունությունից։ Մենք ուղղակիորեն օգտագործում ենք Կաֆկային այս դեպքում: Եթե ​​մենք ունենք լավ ալիք և ցանկանում ենք ազատել այն, ապա մենք օգտագործում ենք նրանց rsyslog-ը։ Բայց իրականում դուք կարող եք կարգավորել այն այնպես, որ այն բաց թողնի այն, ինչ չի անցել: Այս պահին մենք պարզապես օգտագործում ենք rsyslog առաքումը ուղղակիորեն ինչ-որ տեղ, ինչ-որ տեղ Կաֆկա:

Source: www.habr.com