Մեկ այլ մոնիտորինգի համակարգ

16 մոդեմ, 4 բջջային օպերատոր = Ելքային արագություն 933.45 Մբիթ/վ

Ներածություն

Բարեւ Ձեզ! Այս հոդվածն այն մասին է, թե ինչպես ենք մենք մեզ համար գրել մոնիտորինգի նոր համակարգ: Այն գոյություն ունեցողներից տարբերվում է բարձր հաճախականությամբ համաժամանակյա չափումներ ստանալու ունակությամբ և ռեսուրսների շատ ցածր սպառմամբ: Հարցման արագությունը կարող է հասնել 0.1 միլիվայրկյան՝ 10 նանվայրկյան չափումների միջև համաժամացման ճշգրտությամբ: Բոլոր երկուական ֆայլերը զբաղեցնում են 6 մեգաբայթ:

Ծրագրի մասին

Մենք ունենք բավականին կոնկրետ ապրանք։ Մենք արտադրում ենք համապարփակ լուծում տվյալների փոխանցման ալիքների թողունակության և սխալների հանդուրժողականության ամփոփման համար: Սա այն դեպքում, երբ կան մի քանի ալիքներ, ասենք Operator1 (40Mbit/s) + Operator2 (30Mbit/s)+ այլ բան (5 Mbit/s), արդյունքը մեկ կայուն և արագ ալիք է, որի արագությունը կլինի մոտավորապես նման. սա՝ (40+ 30+5)x0.92=75×0.92=69 Մբիթ/վ:

Նման լուծումները պահանջարկ ունեն, երբ որևէ մեկ ալիքի հզորությունը բավարար չէ: Օրինակ՝ տրանսպորտ, տեսահսկման համակարգեր և իրական ժամանակի վիդեո հոսք, ուղիղ հեռուստատեսային և ռադիոհաղորդումների հեռարձակում, ցանկացած արվարձանային օբյեկտ, որտեղ հեռահաղորդակցության օպերատորների թվում կան միայն Մեծ քառյակի ներկայացուցիչներ, և մեկ մոդեմի/ալիքի արագությունը բավարար չէ։ .
Այս ոլորտներից յուրաքանչյուրի համար մենք արտադրում ենք սարքերի առանձին գիծ, ​​սակայն դրանց ծրագրային մասը գրեթե նույնն է, և բարձրորակ մոնիտորինգի համակարգը դրա հիմնական մոդուլներից մեկն է, առանց որի ճիշտ ներդրման արտադրանքը հնարավոր չէր լինի:

Մի քանի տարիների ընթացքում մեզ հաջողվեց ստեղծել բազմաստիճան, արագ, խաչմերուկային և թեթև մոնիտորինգի համակարգ: Սա այն է, ինչ մենք ուզում ենք կիսվել մեր հարգված համայնքի հետ:

Խնդրի ձևակերպում

Մոնիտորինգի համակարգը տրամադրում է երկու սկզբունքորեն տարբեր դասերի չափումներ՝ իրական ժամանակի չափումներ և բոլոր մյուսները: Մոնիտորինգի համակարգն ուներ միայն հետևյալ պահանջները.

1. Բարձր հաճախականության սինխրոն ձեռքբերում իրական ժամանակի չափումների և դրանց փոխանցում կապի կառավարման համակարգ առանց ուշացման:
   Բարձր հաճախականությունը և տարբեր չափումների համաժամացումը ոչ միայն կարևոր է, այլ կենսական նշանակություն ունի տվյալների փոխանցման ալիքների էնտրոպիան վերլուծելու համար: Եթե ​​տվյալների փոխանցման մեկ ալիքում միջին ուշացումը 30 միլիվայրկյան է, ապա միայն մեկ միլիվայրկյան մնացած ցուցանիշների միջև համաժամացման սխալը կհանգեցնի ստացված ալիքի արագության նվազմանը մոտավորապես 5%-ով: Եթե ​​մենք 1 ալիքների վրա ժամանակավորումը 4 միլիվայրկյանով ժամանակավորենք, արագության անկումը հեշտությամբ կարող է իջնել մինչև 30%: Բացի այդ, ալիքներում էնտրոպիան շատ արագ փոխվում է, ուստի, եթե այն չափենք 0.5 միլիվայրկյան մեկ անգամից պակաս, արագ ալիքների վրա փոքր ուշացումով մենք կստանանք բարձր արագության դեգրադացիա։ Իհարկե, նման ճշգրտություն անհրաժեշտ չէ բոլոր չափումների համար և ոչ բոլոր պայմաններում: Երբ ալիքի ուշացումը 500 միլիվայրկյան է, և մենք աշխատում ենք այդպիսիների հետ, ապա 1 միլիվայրկյան սխալը գրեթե նկատելի չի լինի։ Բացի այդ, կյանքի աջակցության համակարգի չափման համար մենք ունենք բավարար հարցումների և համաժամացման տեմպեր՝ 2 վայրկյան, բայց մոնիտորինգի համակարգն ինքնին պետք է կարողանա աշխատել գերբարձր հարցումների և չափումների գերճշգրիտ համաժամացման հետ:
2. Ռեսուրսների նվազագույն սպառում և մեկ կույտ:
   Վերջնական սարքը կարող է լինել կա՛մ հզոր ինտերիերային համալիր, որը կարող է վերլուծել իրավիճակը ճանապարհին կամ իրականացնել մարդկանց կենսաչափական ձայնագրում, կա՛մ ափի չափի մեկ տախտակային համակարգիչ, որը հատուկ նշանակության ջոկատի զինվորը կրում է իր զրահի տակ՝ տեսանյութը փոխանցելու համար։ իրական ժամանակում վատ հաղորդակցության պայմաններում: Չնայած ճարտարապետության և հաշվողական հզորության նման բազմազանությանը, մենք կցանկանայինք ունենալ նույն ծրագրային փաթեթը:
3. Հովանոցային ճարտարապետություն
   Չափիչները պետք է հավաքվեն և հավաքվեն վերջնական սարքի վրա, պահվեն տեղում և տեսանելի լինեն իրական ժամանակում և հետընթաց: Եթե ​​կապ կա, տվյալները փոխանցեք կենտրոնական մոնիտորինգի համակարգին: Երբ կապ չկա, ուղարկող հերթը պետք է կուտակվի և չսպառի RAM-ը:
4. API՝ հաճախորդի մոնիտորինգի համակարգում ինտեգրվելու համար, քանի որ ոչ ոքի շատ մոնիտորինգի համակարգեր պետք չեն: Հաճախորդը պետք է հավաքի տվյալներ ցանկացած սարքերից և ցանցերից մեկ մոնիտորինգի մեջ:

Ինչ է պատահել

Որպեսզի չծանրաբեռնեմ առանց այն էլ տպավորիչ երկարաշունչը, ես չեմ բերի մոնիտորինգի բոլոր համակարգերի օրինակներ և չափումներ։ Սա կհանգեցնի մեկ այլ հոդվածի: Ես պարզապես կասեմ, որ մենք չկարողացանք գտնել մոնիտորինգի համակարգ, որն ի վիճակի է միաժամանակ ընդունել երկու չափումներ՝ 1 միլիվայրկյանից պակաս սխալով, և որը հավասարապես արդյունավետ է աշխատում ինչպես ARM ճարտարապետության վրա՝ 64 ՄԲ օպերատիվ հիշողությամբ, այնպես էլ x86_64 ճարտարապետության վրա՝ 32: ԳԲ RAM: Ուստի մենք որոշեցինք գրել մերը, որը կարող է անել այս ամենը։ Ահա թե ինչ ենք ստացել.

Ցանցի տարբեր տոպոլոգիաների համար երեք ալիքների թողունակության ամփոփում

Որոշ հիմնական ցուցանիշների պատկերացում

ճարտարապետություն

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

Համակարգն իրականացվում է դասական մոդուլային սկզբունքով և պարունակում է մի քանի ենթահամակարգեր.

1. Չափումների գրանցում.
   Յուրաքանչյուր չափիչ սպասարկվում է իր սեփական շղթայով և համաժամացվում է ալիքների միջև: Մենք կարողացանք հասնել մինչև 10 նանվայրկյան համաժամացման ճշգրտության:
2. Չափումների պահեստավորում
   Մենք ընտրում էինք ժամանակային շարքերի համար մեր սեփական պահեստը գրելու կամ արդեն հասանելի որևէ բան օգտագործելու միջև: Տվյալների բազան անհրաժեշտ է հետահայաց տվյալների համար, որոնք ենթակա են հետագա վիզուալացման: Այսինքն, այն չի պարունակում տվյալներ ալիքում ուշացումների կամ տրանսպորտային ցանցում սխալների ընթերցումների վերաբերյալ, բայց յուրաքանչյուր ինտերֆեյսի վրա կա արագություն յուրաքանչյուր 0.5 միլիվայրկյանում: Ի հավելումն միջպլատֆորմի բարձր պահանջների և ռեսուրսների ցածր սպառման, մեզ համար չափազանց կարևոր է, որ կարողանանք մշակել: տվյալներն այնտեղ են, որտեղ դրանք պահվում են: Սա խնայում է հսկայական հաշվողական ռեսուրսներ: Մենք այս նախագծում օգտագործում ենք Tarantool DBMS-ը 500 թվականից ի վեր և մինչ այժմ հորիզոնում չենք տեսնում դրա փոխարինումը: Ճկուն, ռեսուրսների օպտիմալ սպառմամբ, ավելի քան բավարար տեխնիկական աջակցություն: Tarantool-ը նաև իրականացնում է GIS մոդուլ: Իհարկե, այն այնքան հզոր չէ, որքան PostGIS-ը, բայց դա բավարար է տեղանքի հետ կապված որոշ չափումներ (փոխադրման համար համապատասխան) ​​պահելու մեր առաջադրանքների համար:
3. Չափումների պատկերացում
   Այստեղ ամեն ինչ համեմատաբար պարզ է. Մենք վերցնում ենք տվյալներ պահեստից և ցուցադրում դրանք կամ իրական ժամանակում կամ հետընթաց:
4. Տվյալների համաժամացում կենտրոնական մոնիտորինգի համակարգի հետ:
   Կենտրոնական մոնիտորինգի համակարգը ստանում է տվյալներ բոլոր սարքերից, պահպանում է դրանք նշված պատմությամբ և API-ի միջոցով ուղարկում Հաճախորդի մոնիտորինգի համակարգ: Ի տարբերություն դասական մոնիտորինգի համակարգերի, որոնցում «գլուխը» շրջում և տվյալներ է հավաքում, մենք ունենք հակառակ սխեմա։ Սարքերն իրենք են տվյալներ ուղարկում, երբ կապ կա: Սա շատ կարևոր կետ է, քանի որ այն թույլ է տալիս սարքից տվյալներ ստանալ այն ժամանակահատվածների համար, որոնց ընթացքում դրանք հասանելի չեն եղել և չբեռնել ալիքներն ու ռեսուրսները, երբ սարքն անհասանելի է: Մենք օգտագործում ենք Influx մոնիտորինգի սերվերը որպես կենտրոնական մոնիտորինգի համակարգ: Ի տարբերություն իր անալոգների, այն կարող է ներմուծել հետահայաց տվյալներ (այսինքն՝ ժամանակային դրոշմով, որը տարբերվում է չափումների ստացման պահից): Այս ստանդարտ փաթեթը նույնպես ընտրվել է, քանի որ այն ունի պատրաստի API ինտեգրումներ գրեթե ցանկացած հաճախորդների մոնիտորինգի համակարգի հետ:
5. Տվյալների համաժամացում կենտրոնական սարքի կառավարման համակարգի հետ:
   Սարքի կառավարման համակարգն իրականացնում է Zero Touch Provisioning (որոնվածի թարմացում, կոնֆիգուրացիա և այլն) և, ի տարբերություն մոնիտորինգի համակարգի, ստանում է միայն խնդիրներ յուրաքանչյուր սարքի համար: Սրանք գործարկիչներ են ապարատային հսկողության ծառայությունների և կյանքի աջակցության համակարգերի բոլոր չափանիշների համար՝ CPU և SSD ջերմաստիճան, պրոցեսորի բեռնվածություն, ազատ տարածություն և SMART առողջություն սկավառակների վրա: Ենթահամակարգի պահեստը նույնպես կառուցված է Tarantool-ի վրա: Սա մեզ զգալի արագություն է տալիս հազարավոր սարքերում ժամանակային շարքերի համախմբման գործում, ինչպես նաև ամբողջությամբ լուծում է տվյալ սարքերի հետ տվյալների համաժամացման խնդիրը: Tarantool-ն ունի գերազանց հերթերի և երաշխավորված առաքման համակարգ։ Մենք ստացանք այս կարևոր հատկությունը տուփից, հիանալի:

Ցանցի կառավարման համակարգ

Ինչ է հաջորդը

Առայժմ մեր ամենաթույլ օղակը կենտրոնական մոնիտորինգի համակարգն է։ Այն իրականացվում է 99.9% ստանդարտ փաթեթի վրա և ունի մի շարք թերություններ.

1. InfluxDB-ն կորցնում է տվյալները, երբ հոսանքազրկվում է: Որպես կանոն, Հաճախորդը անհապաղ հավաքում է այն ամենը, ինչ գալիս է սարքերից, և տվյալների բազան ինքնին չի պարունակում 5 րոպեից ավելի հին տվյալներ, սակայն ապագայում դա կարող է ցավ դառնալ։
2. Grafana-ն մի շարք խնդիրներ ունի տվյալների համախմբման և ցուցադրման համաժամացման հետ կապված: Ամենատարածված խնդիրն այն է, երբ տվյալների բազան պարունակում է ժամանակային շարք 2 վայրկյան ընդմիջումով, սկսած, ասենք, 00:00:00-ից, իսկ Grafana-ն սկսում է ցույց տալ տվյալները ագրեգացված +1 վայրկյանից: Արդյունքում օգտատերը տեսնում է պարող գրաֆիկ։
3. Չափազանց մեծ քանակությամբ կոդ API-ի ինտեգրման համար երրորդ կողմի մոնիտորինգի համակարգերին: Այն կարելի է շատ ավելի կոմպակտ դարձնել և, իհարկե, վերաշարադրել Go-ում)

Կարծում եմ, դուք բոլորդ հիանալի տեսել եք, թե ինչպիսի տեսք ունի Grafana-ն և գիտեք դրա խնդիրները առանց ինձ, այնպես որ ես չեմ ծանրաբեռնի գրառումը նկարներով:

Ամփոփում

Ես միտումնավոր չեմ նկարագրել տեխնիկական մանրամասները, այլ նկարագրել եմ միայն այս համակարգի հիմնական դիզայնը: Նախ, համակարգը տեխնիկապես ամբողջությամբ նկարագրելու համար կպահանջվի ևս մեկ հոդված: Երկրորդ՝ սա ոչ բոլորին կհետաքրքրի։ Մեկնաբանություններում գրեք, թե ինչ տեխնիկական մանրամասներ կուզենայիք իմանալ։

Եթե ​​որևէ մեկն այս հոդվածի շրջանակներից դուրս հարցեր ունի, կարող եք գրել ինձ a.rodin @ qedr.com հասցեով:

Source: www.habr.com