Հաջորդ HighLoad++ համաժողովը կանցկացվի 6 թվականի ապրիլի 7-ին և 2020-ին Սանկտ Պետերբուրգում Մանրամասներ և տոմսեր . HighLoad++ Մոսկվա 2018. Դահլիճ «Մոսկվա». նոյեմբերի 9-ին, ժամը 15:00-ին։ Թեզեր և .
* Մոնիտորինգ - առցանց և վերլուծություն:
* ZABBIX պլատֆորմի հիմնական սահմանափակումները:
* Անալիտիկ պահեստավորման մասշտաբային լուծում:
* ZABBIX սերվերի օպտիմիզացում:
* UI օպտիմիզացում:
* Համակարգի շահագործման փորձը ավելի քան 40 հազար NVPS բեռների տակ:
* Համառոտ եզրակացություններ.
Միխայիլ Մակուրով (այսուհետ՝ Մ.Մ.). - Բարեւ բոլորին!
Մաքսիմ Չեռնեցով (այսուհետ՝ MCH). - Բարի օր!
ՄՄ: – Ներկայացնեմ Մաքսիմին։ Մաքսը տաղանդավոր ինժեներ է, լավագույն ցանցագործը, որը ես գիտեմ: Maxim-ը ներգրավված է ցանցերի և ծառայությունների, դրանց մշակման և շահագործման մեջ:
MCH: - Եվ ես կցանկանայի ձեզ պատմել Միխայիլի մասին: Միխայիլը C ծրագրավորող է: Նա մեր ընկերության համար գրել է բարձր բեռնվածության երթևեկության մշակման մի քանի լուծումներ: Մենք ապրում և աշխատում ենք Ուրալում, կոշտ տղամարդկանց քաղաքում՝ Չելյաբինսկում, Ինտերսվյազ ընկերությունում։ Մեր ընկերությունը ինտերնետի և կաբելային հեռուստատեսության ծառայությունների մատակարար է 16 քաղաքներում մեկ միլիոն մարդու համար:
ՄՄ: – Եվ արժե ասել, որ Intersvyaz-ը շատ ավելին է, քան պարզապես մատակարար, այն ՏՏ ընկերություն է: Մեր լուծումների մեծ մասը կատարվում է մեր ՏՏ բաժնի կողմից:
A: տրաֆիկ մշակող սերվերներից մինչև զանգերի կենտրոն և բջջային հավելված: ՏՏ բաժինն այժմ ունի մոտ 80 մարդ՝ շատ ու շատ տարբեր իրավասություններով:
Zabbix-ի և նրա ճարտարապետության մասին
MCH: – Իսկ հիմա ես կփորձեմ անձնական ռեկորդ սահմանել և մեկ րոպեում ասել, թե ինչ է Zabbix-ը (այսուհետ՝ «Zabbix»):
Zabbix-ը իրեն ներկայացնում է որպես ձեռնարկատիրական մակարդակի արտաքին մոնիտորինգի համակարգ: Այն ունի բազմաթիվ առանձնահատկություններ, որոնք հեշտացնում են կյանքը՝ առաջադեմ էսկալացիայի կանոններ, ինտեգրման API, հոսթինգների և չափումների խմբավորում և ավտոմատ հայտնաբերում: Zabbix-ն ունի այսպես կոչված scaling գործիքներ՝ proxies: Zabbix-ը բաց կոդով համակարգ է:
Համառոտ ճարտարապետության մասին. Կարելի է ասել, որ այն բաղկացած է երեք բաղադրիչներից.
- Սերվեր. Գրված է Ք. Թելերի միջև տեղեկատվության բավականին բարդ մշակմամբ և փոխանցմամբ: Ամբողջ մշակումը տեղի է ունենում դրա մեջ՝ ստանալուց մինչև պահպանում մինչև տվյալների բազա:
- Բոլոր տվյալները պահվում են տվյալների բազայում: Zabbix-ն աջակցում է MySQL-ին, PostreSQL-ին և Oracle-ին:
- Վեբ ինտերֆեյսը գրված է PHP-ով: Համակարգերի մեծ մասում այն գալիս է Apache սերվերով, բայց ավելի արդյունավետ է աշխատում nginx + php-ի հետ համատեղ:
Այսօր մենք ցանկանում ենք պատմել մեկ պատմություն մեր ընկերության կյանքից՝ կապված Zabbix-ի հետ...
Պատմություն Intersvyaz ընկերության կյանքից. Ի՞նչ ունենք և ի՞նչ է մեզ պետք:
5 կամ 6 ամիս առաջ. Աշխատանքից մեկ օր անց...
MCH: - Միշա, բարև: Ուրախ եմ, որ կարողացա բռնել քեզ, խոսակցություն կա: Մենք կրկին խնդիրներ ունեցանք մոնիտորինգի հետ կապված։ Խոշոր վթարի ժամանակ ամեն ինչ դանդաղ էր ընթանում, և ցանցի վիճակի մասին տեղեկություն չկար։ Ցավոք, սա առաջին անգամը չէ, որ տեղի է ունենում։ Ես ձեր օգնության կարիքն ունեմ. Եկեք այնպես անենք, որ մեր մոնիտորինգն աշխատի ցանկացած պարագայում:
ՄՄ: -Բայց նախ սինխրոնիզացնենք։ Ես այնտեղ չեմ նայել մի քանի տարի: Ինչքան հիշում եմ, մոտ 8 տարի առաջ մենք լքեցինք Նագիոսը և անցանք Զաբբիքս: Եվ հիմա մենք կարծես թե ունենք 6 հզոր սերվեր և մոտ մեկ տասնյակ վստահված սերվեր: Ես ինչ-որ բան շփոթում եմ:
MCH: - Գրեթե. 15 սերվեր, որոնցից մի քանիսը վիրտուալ մեքենաներ են: Ամենակարևորն այն է, որ դա մեզ չփրկի այն պահին, երբ մենք դրա կարիքն ունենք ամենաշատը։ Դժբախտ պատահարի պես՝ սերվերները դանդաղում են, և դուք ոչինչ չեք տեսնում: Մենք փորձեցինք օպտիմալացնել կոնֆիգուրացիան, բայց դա չապահովեց կատարողականի օպտիմալ բարձրացում:
ՄՄ: -Պարզ է: Ինչ-որ բան նայե՞լ եք, արդեն ինչ-որ բան պեղե՞լ եք դիագնոստիկայից։
MCH: – Առաջին բանը, որով դուք պետք է գործ ունենաք, տվյալների բազան է: MySQL-ն արդեն անընդհատ բեռնված է, նոր չափումներ է պահում, և երբ Zabbix-ը սկսում է մի շարք իրադարձություններ ստեղծել, տվյալների բազան բառացիորեն մի քանի ժամով անցնում է գերլարման: Ես արդեն ասացի ձեզ կոնֆիգուրացիայի օպտիմալացման մասին, բայց բառացիորեն այս տարի նրանք թարմացրին ապարատը. սերվերներն ունեն ավելի քան հարյուր գիգաբայթ հիշողություն և սկավառակի զանգված SSD RAID-ներում. իմաստ չկա այն գծայինորեն մեծացնել: Ի՞նչ ենք մենք անում։
ՄՄ: -Պարզ է: Ընդհանրապես MySQL-ը LTP տվյալների բազա է։ Ըստ երևույթին, այն այլևս հարմար չէ մեր չափերի չափումների արխիվը պահելու համար: Եկեք պարզենք այն:
MCH: - Եկեք!
Zabbix-ի և Clickhouse-ի ինտեգրումը հաքաթոնի արդյունքում
Որոշ ժամանակ անց մենք ստացանք հետաքրքիր տվյալներ.
Մեր տվյալների բազայի տարածքի մեծ մասը զբաղեցրել է չափումների արխիվը, և 1%-ից պակասն օգտագործվել է կազմաձևման, ձևանմուշների և կարգավորումների համար: Այդ ժամանակ մենք ավելի քան մեկ տարի աշխատում էինք Big data լուծումը, որը հիմնված էր Clickhouse-ի վրա: Շարժման ուղղությունը մեզ համար ակնհայտ էր. Մեր գարնանային Հեքըթոնում ես գրեցի Zabbix-ի ինտեգրումը Clickhouse-ի հետ սերվերի և ճակատի համար: Այն ժամանակ Zabbix-ն արդեն ուներ աջակցություն ElasticSearch-ի համար, և մենք որոշեցինք համեմատել դրանք։
Clickhouse-ի և Elasticsearch-ի համեմատությունը
ՄՄ: – Համեմատության համար մենք ստեղծեցինք նույն բեռը, ինչ տրամադրում է Zabbix սերվերը և նայեցինք, թե ինչպես կվարվեն համակարգերը: Մենք տվյալները գրել ենք 1000 տողերի խմբաքանակով՝ օգտագործելով CURL: Մենք նախօրոք ենթադրում էինք, որ Clickhouse-ն ավելի արդյունավետ կլինի բեռնման պրոֆիլի համար, որն անում է Zabbix-ը: Արդյունքները նույնիսկ գերազանցեցին մեր սպասելիքները.
Նույն փորձարկման պայմաններում Քլիքհաուսը երեք անգամ ավելի շատ տվյալներ է գրել։ Միևնույն ժամանակ, երկու համակարգերն էլ շատ արդյունավետ են սպառել (փոքր քանակությամբ ռեսուրսներ) տվյալները կարդալիս: Բայց Elastics-ը ձայնագրելիս պահանջում էր մեծ քանակությամբ պրոցեսոր.
Ընդհանուր առմամբ, Clickhouse-ը զգալիորեն գերազանցում էր Elastix-ին պրոցեսորի սպառման և արագության առումով: Միևնույն ժամանակ, տվյալների սեղմման շնորհիվ, Clickhouse-ը 11 անգամ ավելի քիչ է օգտագործում կոշտ սկավառակի վրա և կատարում է մոտավորապես 30 անգամ ավելի քիչ գործողություններ սկավառակի վրա.
MCH: – Այո, Clickhouse-ի աշխատանքը սկավառակի ենթահամակարգի հետ շատ արդյունավետ է իրականացվում: Դուք կարող եք օգտագործել հսկայական SATA սկավառակներ տվյալների բազաների համար և ստանալ վայրկյանում հարյուր հազարավոր տողերի գրելու արագություն: Ներառված համակարգն աջակցում է փոխանակմանը, կրկնօրինակմանը և շատ հեշտ է կարգավորել: Մենք ավելի քան գոհ ենք դրա օգտագործումից ողջ տարվա ընթացքում։
Ռեսուրսները օպտիմալացնելու համար դուք կարող եք տեղադրել Clickhouse-ը ձեր առկա հիմնական տվյալների բազայի կողքին և դրանով իսկ խնայել պրոցեսորի ժամանակն ու սկավառակի գործառնությունները: Մենք չափումների արխիվը տեղափոխել ենք գոյություն ունեցող Clickhouse կլաստերներ.
Մենք այնքան թուլացրինք MySQL-ի հիմնական տվյալների բազան, որ կարողացանք այն համատեղել մեկ մեքենայի վրա Zabbix սերվերի հետ և հրաժարվել MySQL-ի հատուկ սերվերից:
Ինչպե՞ս է գործում հարցումը Zabbix-ում:
4 ամիս առաջ
ՄՄ: – Լավ, կարելի՞ է մոռանալ բազայի հետ կապված խնդիրների մասին։
MCH: -Դա հաստատ! Մեկ այլ խնդիր, որը մենք պետք է լուծենք, տվյալների դանդաղ հավաքումն է: Այժմ մեր բոլոր 15 պրոքսի սերվերները ծանրաբեռնված են SNMP-ով և հարցումների գործընթացներով: Իսկ նոր և նոր սերվերներ տեղադրելուց բացի այլ տարբերակ չկա։
ՄՄ: - Հիանալի: Բայց նախ ասեք մեզ, թե ինչպես է աշխատում հարցումը Zabbix-ում:
MCH: – Մի խոսքով, կան 20 տեսակի չափումներ և դրանց ձեռքբերման տասնյակ եղանակներ: Zabbix-ը կարող է տվյալներ հավաքել կամ «հարցում-պատասխան» ռեժիմում, կամ սպասել նոր տվյալների «Trapper Interface»-ի միջոցով:
Հարկ է նշել, որ օրիգինալ Zabbix-ում այս մեթոդը (Trapper) ամենաարագն է։
Բեռի բաշխման համար կան վստահված սերվերներ.
Վստահված անձինք կարող են կատարել նույն հավաքագրման գործառույթները, ինչ Zabbix սերվերը՝ ստանալով առաջադրանքներ նրանից և ուղարկելով հավաքագրված ցուցանիշները Trapper ինտերֆեյսի միջոցով: Սա բեռը բաշխելու պաշտոնապես առաջարկված եղանակն է: Պրոքսիները նաև օգտակար են NAT-ի կամ դանդաղ ալիքի միջոցով գործող հեռավոր ենթակառուցվածքի մոնիտորինգի համար.
ՄՄ: – Ճարտարապետության հետ կապված ամեն ինչ պարզ է։ Պետք է նայենք աղբյուրներին...
Մի երկու օր անց
Պատմություն, թե ինչպես հաղթեց nmap fping-ը
ՄՄ: «Կարծում եմ՝ ինչ-որ բան եմ հանել»։
MCH: -Ասա՛ ինձ:
ՄՄ: – Ես հայտնաբերեցի, որ հասանելիությունը ստուգելիս Zabbix-ը միաժամանակ ստուգում է առավելագույնը 128 հոսթ: Ես փորձեցի այս թիվը հասցնել 500-ի և հեռացնել միջփաթեթների միջակայքը նրանց պինգում (պինգ) - սա կրկնապատկեց կատարումը: Բայց ես կցանկանայի ավելի մեծ թվեր:
MCH: – Իմ պրակտիկայում ես երբեմն ստիպված եմ լինում ստուգել հազարավոր հոսթների առկայությունը, և ես երբեք դրա համար ավելի արագ բան չեմ տեսել, քան nmap-ը: Համոզված եմ, որ սա ամենաարագ ճանապարհն է: Եկեք փորձենք այն: Մենք պետք է զգալիորեն մեծացնենք հոսթինգների թիվը մեկ կրկնության համար:
ՄՄ: – Հինգ հարյուրից ավել ստուգե՞լ: 600?
MCH: -Առնվազն մի երկու հազար։
ՄՄ: - ԼԱՎ. Ամենակարևորը, որ ուզում էի ասել, այն է, որ ես գտա, որ Zabbix-ում հարցումների մեծ մասը կատարվում է համաժամանակյա: Մենք անպայման պետք է այն փոխենք ասինխրոն ռեժիմի: Այնուհետև մենք կարող ենք կտրուկ ավելացնել հարցախույզների կողմից հավաքագրվող չափումների քանակը, հատկապես, եթե ավելացնենք չափումների քանակը մեկ կրկնության համար:
MCH: - Հիանալի! Եւ երբ?
ՄՄ: -Ինչպես միշտ, երեկ։
MCH: - Մենք համեմատեցինք fping-ի և nmap-ի երկու տարբերակները.
Սպասվում էր, որ մեծ թվով հոսթների վրա nmap-ը մինչև հինգ անգամ ավելի արդյունավետ կլինի: Քանի որ nmap-ը ստուգում է միայն հասանելիությունը և արձագանքման ժամանակը, մենք կորուստների հաշվարկը տեղափոխեցինք գործարկիչներ և զգալիորեն նվազեցրեցինք հասանելիության ստուգման միջակայքերը: Մենք գտանք, որ nmap-ի համար հոսթինգների օպտիմալ թիվը պետք է լինի մոտ 4 հազար մեկ կրկնության համար: Nmap-ը մեզ թույլ տվեց երեք անգամ նվազեցնել CPU-ի հասանելիության ստուգումների արժեքը և կրճատել միջակայքը 120 վայրկյանից մինչև 10:
Հարցումների օպտիմալացում
ՄՄ: «Այնուհետև մենք սկսեցինք հարցումներ անել: Մենք հիմնականում հետաքրքրված էինք SNMP-ի հայտնաբերմամբ և գործակալներով: Zabbix-ում հարցումը կատարվում է համաժամանակյա և հատուկ միջոցներ են ձեռնարկվել համակարգի արդյունավետությունը բարձրացնելու համար։ Սինխրոն ռեժիմում հոսթինգի անհասանելիությունը հանգեցնում է հարցումների զգալի դեգրադացիայի: Գոյություն ունի պետությունների մի ամբողջ համակարգ, կան հատուկ գործընթացներ՝ այսպես կոչված անհասանելի պոլերներ, որոնք աշխատում են միայն անհասանելի հոսթների հետ.
Սա մեկնաբանություն է, որը ցույց է տալիս վիճակի մատրիցը, անցումների համակարգի ողջ բարդությունը, որոնք անհրաժեշտ են, որպեսզի համակարգը մնա արդյունավետ: Բացի այդ, համաժամանակյա հարցումն ինքնին բավականին դանդաղ է ընթանում.
Այդ իսկ պատճառով տասնյակ վստահված անձանց վրա հազարավոր սոցիոլոգիական հոսքեր չկարողացան հավաքել մեզ համար անհրաժեշտ քանակությամբ տվյալներ: Ասինխրոն իրականացումը լուծեց ոչ միայն շղթաների քանակի հետ կապված խնդիրները, այլև զգալիորեն պարզեցրեց անհասանելի հոսթինգների պետական համակարգը, քանի որ մեկ հարցման մեջ ստուգված ցանկացած թվի համար սպասման առավելագույն ժամանակը 1 ժամանակ էր.
Բացի այդ, մենք փոփոխել և կատարելագործել ենք SNMP հարցումների հարցումների համակարգը: Փաստն այն է, որ մարդկանց մեծամասնությունը չի կարող միաժամանակ պատասխանել բազմաթիվ SNMP հարցումներին: Հետևաբար, մենք ստեղծել ենք հիբրիդային ռեժիմ, երբ նույն հոսթի SNMP հարցումը կատարվում է ասինխրոն.
Սա արվում է հյուրընկալողների ամբողջ փաթեթի համար: Այս ռեժիմը, ի վերջո, ոչ ավելի դանդաղ է, քան ամբողջովին ասինխրոնը, քանի որ մեկուկես հարյուր SNMP արժեքների հարցումը դեռ շատ ավելի արագ է, քան 1 ժամանակի ավարտը:
Մեր փորձերը ցույց են տվել, որ հարցումների օպտիմալ թիվը մեկ կրկնության մեջ մոտավորապես 8 հազար է SNMP հարցումով: Ընդհանուր առմամբ, ասինխրոն ռեժիմի անցումը թույլ տվեց մեզ արագացնել հարցումների կատարումը 200 անգամ, մի քանի հարյուր անգամ:
MCH: – Արդյունքում ստացված հարցումների օպտիմալացումները ցույց տվեցին, որ մենք կարող ենք ոչ միայն ազատվել բոլոր վստահված անձանցից, այլև կրճատել բազմաթիվ ստուգումների ընդմիջումները, և վստահված անձինք այլևս կարիք չեն ունենա որպես բեռը կիսելու միջոց:
Մոտ երեք ամիս առաջ
Փոխեք ճարտարապետությունը - ավելացրեք բեռը:
ՄՄ: -Լավ, Մաքս, ժամանակն է արդյոք արդյունավետ դառնալ: Ինձ պետք է հզոր սերվեր և լավ ինժեներ:
MCH: -Լավ, եկեք պլանավորենք: Վաղուց ժամանակն է տեղափոխվել վայրկյանում 5 հազար չափման մեռյալ կետից:
Առավոտյան թարմացումից հետո
MCH: - Միշա, մենք ինքներս մեզ թարմացրինք, բայց առավոտ ետ գլորվեցինք... Գուշակեք, թե ինչ արագության կարողացանք հասնել:
ՄՄ: – առավելագույնը 20 հազ.
MCH: - Այո, 25! Ցավոք, մենք ճիշտ այնտեղ ենք, որտեղ սկսել ենք:
ՄՄ: -Ինչո՞ւ: Դիագնոստիկա կատարե՞լ եք:
MCH: - Այո իհարկե! Ահա, օրինակ, հետաքրքիր վերնաշապիկ.
ՄՄ: - Եկեք դիտենք: Ես տեսնում եմ, որ մենք փորձել ենք մեծ թվով հարցումների թեմաներ.
Բայց միևնույն ժամանակ նրանք չկարողացան վերամշակել համակարգը նույնիսկ կիսով չափ.
Իսկ ընդհանուր կատարումը բավականին փոքր է՝ վայրկյանում մոտ 4 հազար մետրիկ.
Ուրիշ բան կա?
MCH: – Այո, հարցախույզներից մեկի հետքը.
ՄՄ: – Այստեղ պարզ երևում է, որ քվեարկության գործընթացը «սեմաֆորների» է սպասում։ Սրանք կողպեքներն են.
MCH: -Անհասկանալի:
ՄՄ: – Տեսեք, սա նման է մի իրավիճակի, երբ մի խումբ թելեր փորձում են աշխատել ռեսուրսների հետ, որոնց հետ միայն մեկը կարող է միաժամանակ աշխատել: Այնուհետև այն ամենը, ինչ նրանք կարող են անել, ժամանակի ընթացքում այս ռեսուրսով կիսվելն է.
Եվ նման ռեսուրսի հետ աշխատելու ընդհանուր կատարումը սահմանափակվում է մեկ միջուկի արագությամբ.
Այս խնդիրը լուծելու երկու ճանապարհ կա.
Թարմացրեք մեքենայի սարքաշարը, անցեք ավելի արագ միջուկների.
Կամ փոխեք ճարտարապետությունը և միևնույն ժամանակ փոխեք բեռը.
MCH: – Ի դեպ, փորձնական մեքենայի վրա մենք կօգտագործենք ավելի քիչ միջուկներ, քան մարտականի վրա, բայց դրանք 1,5 անգամ ավելի արագ են մեկ միջուկի հաճախականությամբ:
ՄՄ: -Պարզա՞ Դուք պետք է նայեք սերվերի կոդը:
Տվյալների ուղին Zabbix սերվերում
MCH: – Դա պարզելու համար մենք սկսեցինք վերլուծել, թե ինչպես են տվյալները փոխանցվում Zabbix սերվերի ներսում.
Հիասքանչ նկար, չէ՞: Քիչ թե շատ պարզ դարձնելու համար քայլ առ քայլ անցնենք: Կան թեմաներ և ծառայություններ, որոնք պատասխանատու են տվյալների հավաքագրման համար.
Նրանք հավաքագրված չափումները փոխանցում են վարդակի միջոցով Preprocessor-ի մենեջերին, որտեղ դրանք պահվում են հերթում.
«Նախապրոցեսորի կառավարիչը» տվյալները փոխանցում է իր աշխատողներին, որոնք կատարում են նախնական մշակման հրահանգները և վերադարձնում դրանք նույն վարդակից.
Դրանից հետո նախապրոցեսորի կառավարիչը դրանք պահում է պատմության քեշում.
Այնտեղից դրանք վերցնում են պատմության սինկերները, որոնք կատարում են բավականին շատ գործառույթներ՝ օրինակ՝ տրիգերների հաշվարկ, արժեքների քեշի լրացում և, ամենակարևորը, մետրերի պահպանում պատմության պահեստում։ Ընդհանուր առմամբ, գործընթացը բարդ է և շատ շփոթեցնող:
ՄՄ: – Առաջին բանը, որ տեսանք, այն էր, որ թելերի մեծ մասը մրցում է այսպես կոչված «կազմաձևման քեշի» համար (հիշողության տարածք, որտեղ պահվում են բոլոր սերվերի կազմաձևերը): Տվյալների հավաքման համար պատասխանատու շղթաները հատկապես շատ են արգելափակում.
...քանի որ կոնֆիգուրացիան պահպանում է ոչ միայն չափումները իրենց պարամետրերով, այլ նաև հերթեր, որոնցից հարցախույզները տեղեկատվություն են վերցնում հետագա անելիքների մասին: Երբ կան բազմաթիվ հարցումներ, և մեկը արգելափակում է կազմաձևումը, մյուսները սպասում են հարցումների.
Հարցախույզները չպետք է հակասեն
Հետևաբար, առաջին բանը, որ մենք արեցինք, հերթը բաժանեցինք 4 մասի և թույլ տվեցինք հարցախույզներին արգելափակել այս հերթերը, այս մասերը միևնույն ժամանակ, անվտանգ պայմաններում.
Սա վերացրեց կոնֆիգուրացիայի քեշի մրցակցությունը, և հարցախույզների արագությունը զգալիորեն ավելացավ: Բայց հետո մենք հանդիպեցինք այն փաստին, որ նախապրոցեսորի մենեջերը սկսեց կուտակել աշխատանքների հերթ.
Նախապրոցեսորի կառավարիչը պետք է կարողանա առաջնահերթություն սահմանել
Դա տեղի էր ունենում այն դեպքերում, երբ նա կատարում էր պակաս։ Այնուհետև նա կարող էր անել միայն տվյալների հավաքագրման գործընթացներից հարցումներ կուտակել և ավելացնել դրանց բուֆերը, մինչև այն սպառի ամբողջ հիշողությունը և խափանվեր.
Այս խնդիրը լուծելու համար մենք ավելացրեցինք երկրորդ վարդակից, որը հատուկ նվիրված էր աշխատողներին.
Այսպիսով, նախապրոցեսորի մենեջերը հնարավորություն ուներ առաջնահերթություն տալ իր աշխատանքին, և եթե բուֆերն աճում է, խնդիրն այն է դանդաղեցնել հեռացումը, աշխատողներին հնարավորություն տալով վերցնել այս բուֆերը.
Հետո մենք հայտնաբերեցինք, որ դանդաղման պատճառներից մեկը հենց աշխատողներն էին, քանի որ նրանք մրցում էին իրենց աշխատանքի համար բացարձակապես անկարևոր ռեսուրսի համար։ Մենք փաստաթղթավորեցինք այս խնդիրը որպես սխալի շտկում, և այն արդեն լուծվել է Zabbix-ի նոր տարբերակներում.
Մենք ավելացնում ենք վարդակների քանակը - մենք ստանում ենք արդյունքը
Ավելին, նախապրոցեսորի կառավարիչն ինքնին դարձավ խցան, քանի որ այն մեկ թեմա է: Այն հիմնված էր հիմնական արագության վրա՝ տալով վայրկյանում մոտ 70 հազար չափման առավելագույն արագություն.
Հետևաբար, մենք պատրաստեցինք չորս, չորս վարդակների հավաքածուով, բանվորներ.
Եվ դա մեզ թույլ տվեց արագությունը հասցնել մոտավորապես 130 հազար չափման.
Աճի ոչ գծային լինելը բացատրվում է նրանով, որ մրցակցություն է առաջացել պատմության քեշի համար։ Դրա համար մրցում էին նախապրոցեսորների 4 մենեջերներ և պատմության խորտակիչներ: Այս պահին փորձարկման մեքենայի վրա մենք ստանում էինք մոտավորապես 130 հազար չափումներ վայրկյանում՝ օգտագործելով այն պրոցեսորի մոտավորապես 95%-ի կողմից.
Մոտ 2,5 ամիս առաջ
snmp-համայնքից հրաժարվելը մեկուկես անգամ ավելացրել է NVP-ները
ՄՄ: - Մաքս, ինձ նոր փորձնական մեքենա է պետք: Մենք այլևս չենք տեղավորվում ներկայիսի մեջ։
MCH: -Ի՞նչ ունես հիմա:
ՄՄ: – Այժմ – 130 հազար NVP և դարակաշարերի պատրաստ պրոցեսոր:
MCH: -Վա՜յ: Հիասքանչ Սպասիր, ես երկու հարց ունեմ. Իմ հաշվարկներով՝ մեր կարիքը վայրկյանում 15-20 հազար մետր է։ Ինչու՞ մեզ ավելին է պետք:
ՄՄ: «Ես ուզում եմ ավարտել աշխատանքը». Ես կցանկանայի տեսնել, թե որքան կարող ենք քամել այս համակարգից։
MCH: -Բայց…
ՄՄ: «Բայց դա անօգուտ է բիզնեսի համար»:
MCH: -Պարզ է: Եվ երկրորդ հարցը՝ մենք կարո՞ղ ենք ինքնուրույն աջակցել այն, ինչ հիմա ունենք, առանց ծրագրավորողի օգնության։
ՄՄ: -Չեմ կարծում։ Կազմաձևման քեշի աշխատանքի եղանակը փոխելը խնդիր է: Այն ազդում է թելերի մեծ մասի փոփոխությունների վրա և բավականին դժվար է պահպանել: Ամենայն հավանականությամբ, այն պահպանելը շատ դժվար կլինի։
MCH: «Այդ դեպքում մեզ ինչ-որ այլընտրանք է պետք»:
ՄՄ: - Նման տարբերակ կա. Մենք կարող ենք անցնել արագ միջուկների՝ միաժամանակ հրաժարվելով կողպման նոր համակարգից: Մենք դեռ կստանանք 60-80 հազար չափման ցուցանիշ։ Միևնույն ժամանակ, մենք կարող ենք թողնել բոլոր մնացած ծածկագիրը: Clickhouse-ը և ասինխրոն հարցումը կաշխատեն: Եվ դա հեշտ կլինի պահպանել:
MCH: - Զարմանալի! Առաջարկում եմ կանգ առնել այստեղ։
Սերվերի կողմի օպտիմալացումից հետո մենք վերջապես կարողացանք նոր կոդը գործարկել արտադրության մեջ: Մենք հրաժարվեցինք որոշ փոփոխություններից՝ հօգուտ արագ միջուկներով մեքենայի անցնելու և կոդերի փոփոխությունների քանակը նվազագույնի հասցնելու: Մենք նաև պարզեցրել ենք կոնֆիգուրացիան և հնարավորության դեպքում վերացրել մակրոները տվյալների տարրերում, քանի որ դրանք լրացուցիչ կողպում են մտցնում:
Օրինակ, snmp-community մակրոյից հրաժարվելը, որը հաճախ հանդիպում է փաստաթղթերում և օրինակներում, մեր դեպքում հնարավոր դարձրեց մոտ 1,5 անգամ ավելի արագացնել NVP-ները:
Երկու օր արտադրությունից հետո
Միջադեպերի պատմության ելնող պատուհանների հեռացում
MCH: – Միշա, մենք երկու օր է օգտվում ենք համակարգից, և ամեն ինչ աշխատում է: Բայց միայն այն ժամանակ, երբ ամեն ինչ աշխատում է: Մենք պլանավորել էինք աշխատանք ցանցի բավականին մեծ հատվածի փոխանցման հետ, և նորից մեր ձեռքերով ստուգեցինք, թե ինչն է բարձրացել, ինչը՝ ոչ։
ՄՄ: - Չի՛ կարելի: Մենք ամեն ինչ ստուգել ենք 10 անգամ։ Սերվերն ակնթարթորեն լուծում է նույնիսկ ցանցի ամբողջական անհասանելիությունը:
MCH: - Այո, ես ամեն ինչ հասկանում եմ՝ սերվեր, տվյալների բազա, վերև, ավստատ, լոգեր - ամեն ինչ արագ է... Բայց մենք նայում ենք վեբ ինտերֆեյսին, և սերվերի վրա կա պրոցեսոր «դարակում» և սա.
ՄՄ: -Պարզ է: Եկեք դիտենք համացանցը: Մենք պարզեցինք, որ մի իրավիճակում, երբ կային մեծ թվով ակտիվ միջադեպեր, կենդանի վիդջեթների մեծ մասը սկսեցին շատ դանդաղ աշխատել.
Սրա պատճառը եղել է միջադեպերի պատմության թռուցիկ պատուհանների ստեղծումը, որոնք ստեղծվում են ցանկի յուրաքանչյուր կետի համար: Հետևաբար, մենք լքեցինք այս պատուհանների սերունդը (կոդում 5 տող մեկնաբանեցինք), և դա լուծեց մեր խնդիրները:
Վիջեթների բեռնման ժամանակը, նույնիսկ երբ ամբողջովին անհասանելի է, մի քանի րոպեից կրճատվել է մեզ համար ընդունելի 10-15 վայրկյանի, և պատմությունը դեռ կարելի է դիտել՝ սեղմելով ժամանակի վրա.
Աշխատանքից հետո. 2 ամիս առաջ
MCH: -Միշա, դու գնում ես? Պետք է խոսենք։
ՄՄ: -Ես մտադրություն չունեի. Նորից ինչ-որ բան կա՞ Զաբբիքսի հետ:
MCH: -Ոչ, հանգստացիր! Ես պարզապես ուզում էի ասել. ամեն ինչ աշխատում է, շնորհակալություն: Ես գարեջուր ունեմ:
Zabbix-ը արդյունավետ է
Zabbix-ը բավականին ունիվերսալ և հարուստ համակարգ և գործառույթ է: Այն կարող է օգտագործվել առանց տուփի փոքր տեղակայման համար, բայց քանի որ կարիքները մեծանում են, այն պետք է օպտիմալացվի: Չափումների մեծ արխիվ պահելու համար օգտագործեք համապատասխան պահեստ.
- դուք կարող եք օգտագործել ներկառուցված գործիքներ Elasticsearch-ի հետ ինտեգրվելու կամ տեքստային ֆայլերի պատմությունը վերբեռնելու տեսքով (հասանելի է XNUMX-րդ տարբերակից);
- Դուք կարող եք օգտվել մեր փորձից և Clickhouse-ի հետ ինտեգրումից:
Չափումների հավաքագրման արագությունը կտրուկ բարձրացնելու համար հավաքեք դրանք ասինխրոն մեթոդներով և փոխանցեք դրանք թակարդի միջերեսի միջոցով Zabbix սերվերին. կամ կարող եք օգտագործել կարկատել՝ Zabbix pollers-ն ասինխրոն դարձնելու համար:
Zabbix-ը գրված է C-ով և բավականին արդյունավետ է: Ճարտարապետական մի քանի խոչընդոտների լուծումը թույլ է տալիս ավելի մեծացնել դրա կատարողականը և, մեր փորձից ելնելով, ստանալ ավելի քան 100 հազար չափումներ մեկ պրոցեսորային մեքենայի վրա:
Նույն Zabbix կարկատանը
ՄՄ: – Ես ուզում եմ մի քանի կետ ավելացնել. Ամբողջ ընթացիկ հաշվետվությունը, բոլոր թեստերը, թվերը տրվում են այն կազմաձևման համար, որը մենք օգտագործում ենք: Այժմ մենք դրանից վերցնում ենք վայրկյանում մոտավորապես 20 հազար չափումներ: Եթե փորձում եք հասկանալ, թե արդյոք սա կաշխատի ձեզ մոտ, կարող եք համեմատել: Այն, ինչ քննարկվել է այսօր, տեղադրված է GitHub-ում կարկատակի տեսքով.
Կարկատելը ներառում է.
- ամբողջական ինտեգրում Clickhouse-ի հետ (և՛ Zabbix սերվեր, և՛ ֆրոնտենդ);
- խնդիրների լուծում նախապրոցեսորի մենեջերի հետ;
- ասինխրոն հարցում.
Patch-ը համատեղելի է բոլոր 4 տարբերակների հետ, ներառյալ lts-ը: Ամենայն հավանականությամբ, նվազագույն փոփոխություններով այն կաշխատի 3.4 տարբերակի վրա։
Շնորհակալություն ուշադրության համար:
Հարցեր
Հարց հանդիսատեսից (այսուհետ՝ Ա). – Բարի օր: Խնդրում եմ, ասեք ինձ, դուք պլաններ ունե՞ք ինտենսիվ շփվելու Zabbix թիմի կամ նրանց հետ ձեզ հետ, որպեսզի սա ոչ թե կարկատան լինի, այլ Zabbix-ի նորմալ վարքագիծը:
ՄՄ: – Այո, մենք անպայման որոշակի փոփոխություններ կանենք։ Ինչ-որ բան կլինի, ինչ-որ բան կմնա կարկատանի մեջ։
A: - Շատ շնորհակալ եմ հիանալի զեկույցի համար: Խնդրում եմ, ասեք ինձ, որ patch-ը կիրառելուց հետո Zabbix-ի աջակցությունը կմնա, և ինչպե՞ս շարունակել թարմացումը ավելի բարձր տարբերակների: Հնարավո՞ր է արդյոք թարմացնել Zabbix-ը ձեր պատչից հետո 4.2, 5.0:
ՄՄ: - Աջակցության մասին ոչինչ ասել չեմ կարող։ Եթե ես լինեի Zabbix-ի տեխնիկական աջակցություն, հավանաբար կասեի ոչ, քանի որ սա ուրիշի ծածկագիրն է: Ինչ վերաբերում է 4.2 կոդերի բազային, ապա մեր դիրքորոշումը հետևյալն է. Հետևաբար, որոշ ժամանակ մենք կտեղադրենք թարմացված տարբերակների համար կարկատան։ Զեկույցում արդեն ասել եմ՝ տարբերակներով փոփոխությունների թիվը դեռ բավականին փոքր է։ Կարծում եմ՝ 3.4-ից 4-ի անցումը մեզ մոտ 15 րոպե խլեց, ինչ-որ բան փոխվեց, բայց ոչ շատ կարևոր:
A: – Այսպիսով, դուք նախատեսում եք աջակցել ձեր կարկատմանը և կարող եք ապահով տեղադրել այն արտադրության մեջ և ապագայում ինչ-որ կերպ թարմացումներ ստանալ:
ՄՄ: - Մենք խստորեն խորհուրդ ենք տալիս: Սա մեզ համար շատ խնդիրներ է լուծում։
MCH: – Եվս մեկ անգամ ուզում եմ ուշադրություն հրավիրել այն փաստի վրա, որ փոփոխությունները, որոնք չեն վերաբերում ճարտարապետությանը և չեն վերաբերում արգելափակմանը կամ հերթերին, մոդուլային են, դրանք առանձին մոդուլների մեջ են։ Նույնիսկ աննշան փոփոխություններով դուք կարող եք դրանք բավականին հեշտությամբ պահպանել:
ՄՄ: – Եթե դուք հետաքրքրված եք մանրամասներով, ապա «Clickhouse»-ն օգտագործում է այսպես կոչված պատմության գրադարանը: Այն արձակված է - դա Elastics աջակցության պատճենն է, այսինքն, այն կարգավորելի է: Հարցումները փոխում են միայն հարցվողներին. Մենք հավատում ենք, որ դա երկար ժամանակ կաշխատի:
A: - Շատ շնորհակալություն. Ասա ինձ, կա՞ արդյոք կատարված փոփոխությունների որևէ փաստաթուղթ:
ՄՄ: – Փաստաթղթերը կարկատել են: Ակնհայտ է, որ Clickhouse-ի ներդրմամբ, նոր տեսակի pollers-ի ներդրմամբ, առաջանում են կոնֆիգուրացիայի նոր տարբերակներ: Վերջին սլայդի հղումը ունի կարճ նկարագրություն, թե ինչպես օգտագործել այն:
Fping-ը nmap-ով փոխարինելու մասին
A: -Ինչպե՞ս վերջապես դա իրականացրեցիք: Կարո՞ղ եք կոնկրետ օրինակներ բերել՝ ունե՞ք strappers և արտաքին սցենար: Ի՞նչն է վերջում այդքան արագ ստուգում հյուրընկալողների նման հսկայական քանակությունը: Ինչպե՞ս եք ականապատում այս տանտերերը: Պե՞տք է նրանց կերակրել, որ ինչ-որ կերպ nmap-ի ենթարկենք, ինչ-որ տեղից վերցնենք, դնենք, գործարկենք:
ՄՄ: -Թույն: Շատ ճիշտ հարց! Բանն այս է. Մենք փոփոխել ենք գրադարանը (ICMP ping, Zabbix-ի մի մասը) ICMP ստուգումների համար, որոնք ցույց են տալիս փաթեթների քանակը՝ մեկ (1), և կոդը փորձում է օգտագործել nmap: Այսինքն՝ սա Զաբբիսի ներքին աշխատանքն է, որը դարձել է պինգերի ներքին գործը։ Համապատասխանաբար, թակարդի համաժամացում կամ օգտագործում չի պահանջվում: Դա արվել է միտումնավոր, որպեսզի համակարգը անձեռնմխելի մնա և ստիպված չլինի համաժամեցնել տվյալների բազայի երկու համակարգեր.
A: - Դա նաև վստահված անձանց համար է աշխատում:
ՄՄ: - Այո, բայց մենք չենք ստուգել: Հարցման կոդը և՛ Zabbix-ում, և՛ սերվերում նույնն է: Պետք է աշխատի: Եվս մեկ անգամ շեշտեմ՝ համակարգի աշխատանքն այնպիսին է, որ վստահված անձի կարիք չունենք։
MCH: - Հարցի ճիշտ պատասխանն է՝ «Ինչի՞ն է պետք նման համակարգով վստահված անձ»: Միայն NAT-ի կամ ինչ-որ դանդաղ ալիքով մոնիտորինգի պատճառով...
A: – Իսկ դուք օգտագործում եք Zabbix-ը որպես ալերտոր, եթե ճիշտ եմ հասկանում: Թե՞ ձեր գրաֆիկան (որտեղ արխիվային շերտն է) տեղափոխվել այլ համակարգ, օրինակ՝ Grafana: Կամ չե՞ք օգտագործում այս գործառույթը:
ՄՄ: – Եվս մեկ անգամ շեշտեմ. մենք հասել ենք ամբողջական ինտեգրման։ Մենք պատմությունը լցնում ենք Clickhouse-ի մեջ, բայց միևնույն ժամանակ մենք փոխել ենք php ճակատը։ Php frontend-ը գնում է Clickhouse և այնտեղից կատարում է բոլոր գրաֆիկները: Միևնույն ժամանակ, եթե անկեղծ լինենք, մենք ունենք մի մաս, որը տվյալների կառուցում է այլ գրաֆիկական ցուցադրման համակարգերում՝ նույն Clickhouse-ից, նույն Zabbix-ի տվյալներից։
MCH: – «Գրաֆանում» էլ.
Ինչպե՞ս են որոշումներ կայացվել ռեսուրսների բաշխման վերաբերյալ։
A: - Մի փոքր կիսվեք ձեր ներքին խոհանոցից: Ինչպե՞ս է որոշում կայացվել, որ ապրանքի լուրջ վերամշակման համար անհրաժեշտ է միջոցներ հատկացնել։ Սրանք, ընդհանուր առմամբ, որոշակի ռիսկեր են։ Եվ խնդրում եմ, ասեք ինձ, այն համատեքստում, որ դուք պատրաստվում եք աջակցել նոր տարբերակներին, ինչպե՞ս է այս որոշումը հիմնավորում կառավարման տեսանկյունից։
ՄՄ: - Ըստ երևույթին, մենք այնքան էլ լավ չենք պատմել պատմության դրաման: Մենք հայտնվեցինք մի իրավիճակում, երբ ինչ-որ բան պետք է արվեր, և մենք, ըստ էության, գնացինք երկու զուգահեռ թիմերով.
- Մեկը մոնիտորինգի համակարգի գործարկումն էր՝ օգտագործելով նոր մեթոդներ. մոնիտորինգը որպես ծառայություն, բաց կոդով լուծումների ստանդարտ փաթեթ, որը մենք համատեղում ենք և այնուհետև փորձում ենք փոխել բիզնես գործընթացը՝ նոր մոնիտորինգի համակարգի հետ աշխատելու համար:
- Միևնույն ժամանակ, մենք ունեինք խանդավառ ծրագրավորող, ով անում էր դա (իր մասին): Այնպես ստացվեց, որ նա հաղթեց։
A: - Իսկ թիմը ո՞րն է:
MCH: -Նա քո առջև է:
A: -Այսինքն, ինչպես միշտ, դուք կրքոտի կարիք ունեք:
ՄՄ: - Ես չգիտեմ, թե ինչ է կրքոտը:
A: -Այս դեպքում, ըստ երեւույթին, դուք։ Շատ շնորհակալ եմ, դուք հիանալի եք:
ՄՄ: - Շնորհակալություն.
Zabbix-ի համար նախատեսված կարկատների մասին
A: – Համակարգի համար, որն օգտագործում է պրոքսիներ (օրինակ՝ որոշ բաշխված համակարգերում), հնարավո՞ր է հարմարեցնել և կարկատել, ասենք, pollers, proxies և մասամբ հենց Zabbix-ի նախապրոցեսորը. և դրանց փոխազդեցությունը. Հնարավո՞ր է օպտիմիզացնել գոյություն ունեցող զարգացումները բազմաթիվ պրոքսի ունեցող համակարգի համար:
ՄՄ: – Ես գիտեմ, որ Zabbix սերվերը հավաքվում է պրոքսիի միջոցով (կոդը կազմվում և ստացվում է): Մենք սա չենք փորձարկել արտադրության մեջ: Ես վստահ չեմ այս հարցում, բայց կարծում եմ, որ preprocessor manager-ը չի օգտագործվում պրոքսիում: Վստահված անձի խնդիրն է Zabbix-ից վերցնել մի շարք չափումներ, միաձուլել դրանք (այն նաև գրանցում է կոնֆիգուրացիան, տեղական տվյալների բազան) և վերադարձնել այն Zabbix սերվերին: Սերվերն ինքը կկատարի նախնական մշակումը, երբ այն ստանա:
Վստահված անձանց նկատմամբ հետաքրքրությունը հասկանալի է. Մենք կստուգենք այն: Սա հետաքրքիր թեմա է։
A: – Գաղափարը հետևյալն էր. եթե դուք կարող եք կարկատել հարցախույզները, կարող եք դրանք կարկատել պրոքսիի վրա և կարկատել սերվերի հետ փոխազդեցությունը, իսկ նախապրոցեսորն այդ նպատակների համար հարմարեցնել միայն սերվերի վրա:
ՄՄ: -Կարծում եմ՝ ավելի պարզ է. Դուք վերցնում եք կոդը, կիրառում եք կարկատել, այնուհետև այն կարգավորում եք այնպես, ինչպես ձեզ անհրաժեշտ է՝ հավաքեք պրոքսի սերվերներ (օրինակ՝ ODBC-ով) և տարածեք կարկատված կոդը համակարգերում: Անհրաժեշտության դեպքում հավաքեք վստահված անձ, անհրաժեշտության դեպքում՝ սերվեր:
A: – Ամենայն հավանականությամբ, դուք ստիպված չեք լինի լրացուցիչ կարկատել պրոքսի փոխանցումը սերվերին:
MCH: -Ոչ, ստանդարտ է:
ՄՄ: – Փաստորեն, մտքերից մեկը չհնչեց։ Մենք միշտ հավասարակշռություն ենք պահպանել գաղափարների պայթյունի և փոփոխությունների քանակի և աջակցության հեշտության միջև:
Մի քանի գովազդ 🙂
Շնորհակալություն մեզ հետ մնալու համար: Ձեզ դուր են գալիս մեր հոդվածները: Ցանկանու՞մ եք տեսնել ավելի հետաքրքիր բովանդակություն: Աջակցեք մեզ՝ պատվիրելով կամ խորհուրդ տալով ընկերներին, , մուտքի մակարդակի սերվերների եզակի անալոգ, որը հորինվել է մեր կողմից ձեզ համար. (հասանելի է RAID1 և RAID10-ով, մինչև 24 միջուկով և մինչև 40 ԳԲ DDR4):
Dell R730xd 2 անգամ ավելի էժան Ամստերդամի Equinix Tier IV տվյալների կենտրոնում: Միայն այստեղ Նիդեռլանդներում! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-ից: Կարդացեք մասին
Source: www.habr.com