Վերադարձեք անհետացած սկուտերը կամ մեկ IoT մոնիտորինգի պատմությունը

Մեկ տարի առաջ մենք գործարկեցինք գովազդային նախագծի փորձնական տարբերակը Էլեկտրական սկուտերների ապակենտրոնացված վարձույթ.

Սկզբում նախագիծը կոչվում էր Road-To-Barcelona, ​​ավելի ուշ այն դարձավ Road-To-Berlin (հետևաբար R2B սքրինշոթերում), իսկ վերջում այն ​​կոչվեց xRide:

Նախագծի հիմնական գաղափարը հետևյալն էր. մեքենաների կամ սկուտերների վարձույթի կենտրոնացված ծառայություն ունենալու փոխարեն (խոսքը վերաբերում է սկուտերներին՝ էլեկտրական մոտոցիկլետներին, ոչ թե kickscooter/scooters-ին), մենք ցանկանում էինք ապակենտրոնացված վարձույթի հարթակ ստեղծել: Մեր հանդիպած դժվարությունների մասին արդեն գրել է ավելի վաղ.

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

Օգտատերը հեռախոսի վրա տեղադրեց iOS կամ Android հավելված, մոտեցավ իրեն դուր եկած սկուտերին, որից հետո հեռախոսը և սկուտերը հասակին կապ հաստատեցին, ETH փոխանակվեց, և օգտատերը կարող էր սկսել երթևեկությունը՝ միացնելով սկուտերը։ հեռախոս. Ուղևորության ավարտին հնարավոր եղավ նաև վճարել ուղևորության համար Ethereum-ի միջոցով օգտատիրոջ հեռախոսի դրամապանակից:

Բացի սկուտերներից, օգտատերը հավելվածում տեսել է «խելացի լիցքավորիչներ», որոնց այցելելով օգտատերը կարող էր ինքը փոխել ընթացիկ մարտկոցը, եթե այն ցածր լիներ։

Այսպիսի տեսք ուներ ընդհանուր առմամբ մեր օդաչուն, որը մեկնարկել էր անցյալ տարվա սեպտեմբերին Գերմանիայի երկու քաղաքներում՝ Բոննում և Բեռլինում:

Եվ հետո, մի օր, Բոննում, վաղ առավոտյան, մեր աջակցության թիմը (տեղակայված էր տեղում՝ սկուտերները աշխատունակ վիճակում պահելու համար) ահազանգեցին. սկուտերներից մեկն անհետացել էր առանց հետքի:

Ինչպե՞ս գտնել այն և վերադարձնել այն:

Այս հոդվածում ես կխոսեմ այս մասին, բայց նախ՝ այն մասին, թե ինչպես ենք մենք կառուցել մեր սեփական IoT հարթակը և ինչպես ենք վերահսկել այն:

Ի՞նչ և ինչու՞ մոնիտորինգ անել՝ սկուտերներ, ենթակառուցվածքներ, լիցքավորման կայաններ:

Այսպիսով, ի՞նչն էինք ուզում վերահսկել մեր նախագծում:

Նախ, սրանք հենց սկուտերներն են. էլեկտրական սկուտերներն իրենք բավականին թանկ են, դուք չեք կարող նման նախագիծ սկսել առանց բավականաչափ պատրաստված լինելու, հնարավորության դեպքում ցանկանում եք հնարավորինս շատ տեղեկատվություն հավաքել սկուտերների մասին՝ դրանց գտնվելու վայրի, լիցքավորման մակարդակի մասին: և այլն։

Բացի այդ, ես կցանկանայի վերահսկել մեր սեփական ՏՏ ենթակառուցվածքի վիճակը՝ տվյալների բազաները, ծառայությունները և այն ամենը, ինչ անհրաժեշտ է աշխատելու համար: Անհրաժեշտ էր նաև հետևել «խելացի լիցքավորիչների» կարգավիճակին, եթե դրանք փչանան կամ մարտկոցները սպառվեն։

Սկուտերներ

Որո՞նք էին մեր սկուտերները և ի՞նչ էինք ուզում իմանալ դրանց մասին:

Առաջին և ամենակարևորը GPS կոորդինատներն են, քանի որ դրանց շնորհիվ մենք կարող ենք հասկանալ, թե որտեղ են դրանք և ուր են շարժվում։

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

Իհարկե, անհրաժեշտ է նաև ստուգել, ​​թե ինչ է կատարվում մեր Hardware բաղադրիչների հետ.

• Bluetooth-ն աշխատում է?
• GPS մոդուլն ինքնին աշխատում է?
  • Մենք նաև խնդիր ունեինք այն բանի հետ, որ GPS-ը կարող էր սխալ կոորդինատներ ուղարկել և խրվել, և դա կարող էր որոշվել միայն սկուտերի վրա լրացուցիչ ստուգումներով,
    և որքան հնարավոր է շուտ տեղեկացրեք աջակցությանը՝ խնդիրը լուծելու համար

Եվ վերջապես. ծրագրային ապահովման ստուգումներ՝ սկսած ՕՀ-ից և պրոցեսորից, ցանցի և սկավառակի բեռնվածությունից, վերջացրած մեր սեփական մոդուլների ստուգումներով, որոնք ավելի հատուկ են մեզ (Jolocom, ստեղնաշար).

Hardware

Ո՞րն էր մեր «երկաթե» մասը:

Հաշվի առնելով հնարավոր ամենակարճ ժամկետը և արագ նախատիպավորման անհրաժեշտությունը՝ մենք ընտրեցինք բաղադրիչների ներդրման և ընտրության ամենահեշտ տարբերակը՝ Raspberry Pi-ն:
Բացի հենց Rpi-ից, մենք ունեինք մաքսային տախտակ (որը մենք ինքներս մշակեցինք և պատվիրեցինք Չինաստանից վերջնական լուծման հավաքման գործընթացը արագացնելու համար) և մի շարք բաղադրիչներ՝ ռելե (սկուտերը միացնելու/անջատելու համար), մարտկոցի լիցքավորման սարք, մոդեմ, ալեհավաքներ։ Այս ամենը կոմպակտ փաթեթավորված էր հատուկ «xRide տուփի» մեջ:

Նշենք նաեւ, որ ամբողջ տուփը սնուցվում էր լրացուցիչ էներգաբանկով, որն իր հերթին սնվում էր սկուտերի հիմնական մարտկոցից։

Սա հնարավորություն տվեց օգտագործել մոնիտորինգը և միացնել սկուտերը նույնիսկ ուղևորության ավարտից հետո, քանի որ հիմնական մարտկոցն անջատվել է բոցավառման բանալին «անջատված» դիրքին միացնելուց անմիջապես հետո:

Docker? Պարզ Linux? և տեղակայում

Եկեք վերադառնանք մոնիտորինգին, ուստի Raspberry - ինչ ունենք:

Առաջին բաներից մեկը, որ ցանկանում էինք օգտագործել՝ արագացնելու համար բաղադրիչների տեղակայումը, թարմացումը և ֆիզիկական սարքերին հասցնելը, Docker-ն էր:

Ցավոք սրտի, արագ պարզ դարձավ, որ Docker-ը RPi-ում, թեև այն աշխատում է, ունի մեծ ծախսեր, հատկապես էներգիայի սպառման առումով:

«Մայրենի» ՕՀ-ի օգտագործման տարբերությունը, թեև ոչ այնքան ուժեղ, այնուամենայնիվ բավարար էր, որպեսզի զգուշանանք լիցքավորումը շատ արագ կորցնելու հավանականությունից:

Երկրորդ պատճառը մեր գործընկեր գրադարաններից մեկն էր Node.js-ում (sic!)՝ համակարգի միակ բաղադրիչը, որը գրված չէր Go/C/C++-ով:

Գրադարանի հեղինակները ժամանակ չեն ունեցել «մայրենի» լեզուներից որևէ մեկով աշխատանքային տարբերակ տրամադրելու։

Ոչ միայն հանգույցն ինքնին ամենաէլեգանտ լուծումը չէ ցածր արդյունավետությամբ սարքերի համար, այլև գրադարանն ինքնին շատ ռեսուրսների կարիք ուներ:

Մենք հասկացանք, որ նույնիսկ եթե ցանկանայինք, Docker-ի օգտագործումը չափազանց մեծ ծախս կլիներ մեզ համար: Ընտրությունը կատարվել է հօգուտ հայրենի ՕՀ-ի և անմիջապես դրա տակ աշխատելու։

OS

Արդյունքում, մենք, կրկին, ընտրեցինք ամենապարզ տարբերակը որպես ՕՀ և օգտագործեցինք Raspbian (Debian build Pi-ի համար):

Մենք գրում ենք մեր ամբողջ ծրագրաշարը Go-ում, այնպես որ մենք գրել ենք նաև հիմնական ապարատային գործակալի մոդուլը մեր համակարգում Go-ում:

Հենց նա է պատասխանատու GPS-ով, Bluetooth-ով աշխատելու, լիցքը կարդալու, սկուտերը միացնելու և այլն։

Տեղակայել

Անմիջապես հարց ծագեց սարքերին թարմացումներ մատակարարելու մեխանիզմի ներդրման անհրաժեշտության մասին (OTA)՝ և՛ մեր գործակալի/հավելվածի թարմացումները, և՛ հենց ՕՀ/որոնվածի թարմացումները (քանի որ գործակալի նոր տարբերակները կարող են պահանջել թարմացումներ միջուկում: կամ համակարգի բաղադրիչներ, գրադարաններ և այլն):

Շուկայի բավականին երկար վերլուծությունից հետո պարզվեց, որ սարքի թարմացումները հասցնելու համար բավականին շատ լուծումներ կան։

Համեմատաբար պարզ, հիմնականում թարմացման/երկակի բեռնման վրա հիմնված կոմունալ ծառայություններից, ինչպիսիք են swupd/SWUpdate/OSTree-ն մինչև լիարժեք հարթակներ, ինչպիսիք են Mender-ը և Balena-ն:

Առաջին հերթին մենք որոշեցինք, որ մեզ հետաքրքրում են վերջնական լուծումները, ուստի ընտրությունն անմիջապես ընկավ հարթակների վրա:

Հենց դա է Բալենա բացառվել է այն պատճառով, որ այն իրականում օգտագործում է նույն Docker-ը իր balenaEngine-ի ներսում:

Բայց ես նշում եմ, որ չնայած դրան, մենք ի վերջո անընդհատ օգտագործում էինք նրանց արտադրանքը Բալեա Էթչեր SD քարտերի վրա ֆլեշ որոնվածի համար - դրա համար պարզ և չափազանց հարմար գործիք:

Հետևաբար, ի վերջո ընտրությունն ընկավ Մենդերը. Mender-ը ամբողջական հարթակ է որոնվածը հավաքելու, առաքելու և տեղադրելու համար:

Ընդհանուր առմամբ, հարթակը հիանալի տեսք ունի, բայց մեզ մոտ մեկուկես շաբաթ պահանջվեց, որպեսզի ստեղծենք մեր որոնվածի ճիշտ տարբերակը՝ օգտագործելով mender Builder:
Եվ որքան շատ էինք խորանում դրա օգտագործման բարդությունների մեջ, այնքան ավելի պարզ էր դառնում, որ այն ամբողջությամբ տեղակայելու համար մեզ շատ ավելի շատ ժամանակ կպահանջվի, քան ունեինք:

Ավաղ, մեր սեղմ ժամկետները նշանակում էին, որ մենք ստիպված եղանք հրաժարվել Մենդերի օգտագործումից և ընտրել ավելի պարզը:

Հղիություն

Մեր իրավիճակում ամենապարզ լուծումը Ansible-ի օգտագործումն էր: Սկսելու համար բավական էր մի քանի գրքույկ:

Դրանց էությունն այն էր, որ մենք պարզապես ssh-ի միջոցով միացանք հոսթից (CI սերվեր) մեր rasberries-ին և թարմացումներ բաժանեցինք նրանց։

Հենց սկզբում ամեն ինչ պարզ էր՝ սարքերի հետ պետք է լինեիր նույն ցանցում, լցնումն արվում էր Wi-Fi-ի միջոցով։

Գրասենյակում պարզապես մի տասնյակ փորձնական ազնվամորու միացված էր նույն ցանցին, յուրաքանչյուր սարք ուներ ստատիկ IP հասցե, որը նույնպես նշված էր Ansible Inventory-ում:

Դա Ansible-ն էր, որը մեր մոնիտորինգի գործակալին հասցրեց վերջնական սարքերին

3G / LTE

Ցավոք, Ansible-ի այս օգտագործման դեպքը կարող էր աշխատել միայն զարգացման ռեժիմում, նախքան մենք կունենայինք իրական սկուտերներ:

Քանի որ սկուտերները, ինչպես հասկանում եք, միացված չեն մեկ Wi-Fi երթուղիչին՝ անընդհատ սպասելով ցանցի միջոցով թարմացումների:

Իրականում, սկուտերները չեն կարող որևէ այլ կապ ունենալ, բացի շարժական 3G/LTE-ից (և նույնիսկ այդ դեպքում ոչ միշտ):

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

Բայց ամենակարևորն այն է, որ 3G/LTE ցանցում մենք չենք կարող պարզապես ապավինել ցանցին հատկացված ստատիկ IP-ին:

Սա մասամբ լուծվում է SIM քարտերի որոշ մատակարարների կողմից, կան նույնիսկ հատուկ SIM քարտեր, որոնք նախատեսված են ստատիկ IP հասցեներով IoT սարքերի համար: Բայց մենք մուտք չունեինք նման SIM քարտեր և չէինք կարող օգտագործել IP հասցեներ:

Իհարկե, գաղափարներ կային ինչ-որ տեղ IP-հասցեների գրանցում, այսինքն՝ ծառայության հայտնաբերում, ինչ-որ տեղ Consul-ի նման, բայց մենք ստիպված էինք հրաժարվել նման գաղափարներից, քանի որ մեր թեստերում IP հասցեն կարող էր շատ հաճախ փոխվել, ինչը հանգեցրեց մեծ անկայունության:

Այդ իսկ պատճառով, չափիչները մատուցելու համար ամենահարմար օգտագործումը կլինի ոչ թե քաշման մոդելի օգտագործումը, որտեղ մենք պետք է գնայինք դեպի սարքեր՝ անհրաժեշտ չափումների համար, այլ մղենք՝ չափումները սարքից անմիջապես սերվեր հասցնելով:

VPN

Որպես այս խնդրի լուծում՝ մենք հատուկ ընտրեցինք VPN-ը Մետաղալար.

Հաճախորդները (սկուտերները) համակարգի սկզբում միացել են VPN սերվերին և կարողացել են միանալ նրանց: Այս թունելն օգտագործվել է թարմացումներ մատակարարելու համար:

Տեսականորեն նույն թունելը կարող էր օգտագործվել մոնիտորինգի համար, սակայն նման միացումն ավելի բարդ և պակաս հուսալի էր, քան պարզ հրում:

Ամպային ռեսուրսներ

Վերջապես, անհրաժեշտ է վերահսկել մեր ամպային ծառայությունները և տվյալների բազաները, քանի որ մենք օգտագործում ենք Kubernetes-ը նրանց համար, իդեալականորեն, որպեսզի մոնիտորինգի տեղակայումը կլաստերում հնարավորինս պարզ լինի: Իդեալում, օգտագործելով սաղավարտ, քանի որ տեղակայման համար մենք այն օգտագործում ենք շատ դեպքերում։ Եվ, իհարկե, ամպին վերահսկելու համար հարկավոր է օգտագործել նույն լուծումները, ինչ որ սկուտերների համար:

Տրված է

Ֆու, մենք կարծես թե դասավորել ենք նկարագրությունը, եկեք վերջում կազմենք այն, ինչ մեզ անհրաժեշտ էր.

• Արագ լուծում, քանի որ մոնիտորինգն անհրաժեշտ է արդեն մշակման գործընթացում
• Ծավալ/քանակ – անհրաժեշտ են բազմաթիվ չափումներ
• Պահանջվում է գրանցամատյանների հավաքագրում
• Հուսալիություն. տվյալները շատ կարևոր են հաջող գործարկման համար
• Դուք չեք կարող օգտագործել քաշման մոդելը, ձեզ հարկավոր է մղել
• Մեզ անհրաժեշտ է ոչ միայն ապարատային, այլ նաև ամպի միասնական մոնիտորինգ

Վերջնական պատկերն այսպիսի տեսք ուներ

Դույների ընտրություն

Այսպիսով, մենք կանգնած էինք մոնիտորինգի կույտ ընտրելու հարցի առաջ:

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

Գոյություն ունեն մոնիտորինգի լուծումների հսկայական բազմազանություն՝ սկսած նման լիարժեք համակարգերից Nagios, icinga կամ zabbix- ը և ավարտվում է Fleet կառավարման պատրաստի լուծումներով:

Ի սկզբանե, վերջինս մեզ համար իդեալական լուծում էր թվում, բայց ոմանք չունեին ամբողջական մոնիտորինգ, մյուսներն ունեին անվճար տարբերակների խիստ սահմանափակ հնարավորություններ, իսկ մյուսները պարզապես չէին ծածկում մեր «ցանկությունները» կամ բավական ճկուն չէին մեր սցենարներին համապատասխանելու համար: Ոմանք պարզապես հնացած են:

Մի շարք նմանատիպ լուծումներ վերլուծելուց հետո մենք արագ եկանք այն եզրակացության, որ ավելի հեշտ և արագ կլինի ինքներս հավաքել նմանատիպ կույտ: Այո, դա մի փոքր ավելի բարդ կլինի, քան լիովին պատրաստ Fleet կառավարման հարթակի տեղակայումը, բայց մենք ստիպված չենք լինի գնալ փոխզիջումների:

Գրեթե անկասկած, լուծումների ողջ հսկայական առատության մեջ արդեն կա պատրաստի լուծում, որը լիովին կհամապատասխանի մեզ, բայց մեր դեպքում շատ ավելի արագ էր ինքնուրույն հավաքել որոշակի կույտ և այն հարմարեցնել «մեզ համար», քան պատրաստի արտադրանքի փորձարկում.

Այս ամենի հետ մեկտեղ մենք ինքներս չէինք ձգտում հավաքել մոնիտորինգի մի ամբողջ հարթակ, այլ փնտրում էինք ամենաֆունկցիոնալ «պատրաստի» կույտերը՝ միայն դրանք ճկուն կարգավորելու ունակությամբ:

(B)ELK?

Առաջին լուծումը, որն իրականում դիտարկվեց, հայտնի ELK stack-ն էր:
Իրականում այն ​​պետք է անվանել BELK, քանի որ ամեն ինչ սկսվում է Beats-ից - https://www.elastic.co/what-is/elk-stack

Իհարկե, ELK-ն ամենահայտնի և հզոր լուծումներից է մոնիտորինգի ոլորտում, և առավել ևս՝ տեղեկամատյանների հավաքագրման և մշակման ոլորտում:

Մենք նախատեսում էինք, որ ELK-ը կօգտագործվի տեղեկամատյանները հավաքելու և ինչպես նաև Պրոմեթևսից ստացված ցուցանիշների երկարաժամկետ պահպանման համար:

Վիզուալիզացիայի համար կարող եք օգտագործել Grafan-ը:

Իրականում, նոր ELK stack-ը կարող է ինքնուրույն հավաքել չափումներ (metricbeat), իսկ Kibana-ն կարող է նաև ցուցադրել դրանք։

Այնուամենայնիվ, ELK-ն ի սկզբանե աճել է տեղեկամատյաններից և մինչ այժմ չափումների ֆունկցիոնալությունն ունի մի շարք լուրջ թերություններ.

• Զգալիորեն դանդաղ, քան Պրոմեթևսը
• Ինտեգրվում է շատ ավելի քիչ վայրերում, քան Պրոմեթևսը
• Դժվար է նրանց համար նախազգուշացումներ ստեղծել
• Չափիչները շատ տեղ են զբաղեցնում
• Kiban-ում չափիչներով վահանակների տեղադրումը շատ ավելի բարդ է, քան Grafan-ում

Ընդհանուր առմամբ, ELK-ի չափումները ծանր են և դեռ ոչ այնքան հարմար, որքան մյուս լուծումներում, որոնցից այժմ կան շատ ավելին, քան պարզապես Պրոմեթևսը՝ TSDB, Victoria Metrics, Cortex և այլն, և այլն: Իհարկե, ես շատ կուզենայի, որ միանգամից լիարժէք լուծում ունենայինք, բայց մետրիկբիթի պարագայում փոխզիջումները չափազանց շատ էին։

Եվ ELK stack-ն ինքնին ունի մի շարք դժվար պահեր.

• Այն ծանր է, երբեմն նույնիսկ շատ ծանր, եթե բավականին մեծ քանակությամբ տվյալներ եք հավաքում
• Դուք պետք է «իմանաք, թե ինչպես պատրաստել» այն, դուք պետք է չափեք այն, բայց դա աննշան չէ:
• Անվճար տարբերակ - անվճար տարբերակը չունի նորմալ ահազանգ, և ընտրության պահին նույնականացում չի եղել

Պետք է ասեմ, որ վերջերս վերջին կետն ավելի լավն է դարձել և հավելյալ ելք բաց կոդով X-pack-ում (ներառյալ իսկությունը) գնագոյացման մոդելն ինքնին սկսեց փոխվել:

Բայց այն ժամանակ, երբ մենք պատրաստվում էինք կիրառել այս լուծումը, ընդհանրապես ահազանգ չկար:
Միգուցե մենք կարող էինք փորձել ինչ-որ բան կառուցել՝ օգտագործելով ElastAlert-ը կամ համայնքային այլ լուծումներ, բայց մենք դեռ որոշեցինք դիտարկել այլ այլընտրանքներ:

Լոկի - Գրաֆանա - Պրոմեթևս

Այս պահին լավ լուծում կարող է լինել միայն Պրոմեթևսի վրա հիմնված մոնիտորինգի կույտ ստեղծելը՝ որպես չափումների մատակարար, Loki՝ տեղեկամատյանների համար, իսկ վիզուալիզացիայի համար կարող եք օգտագործել նույն Grafana-ն:

Ցավոք, նախագծի վաճառքի փորձնական մեկնարկի պահին (19թ. սեպտեմբեր-հոկտեմբեր) Loki-ն դեռ գտնվում էր 0.3-0.4 բետա տարբերակում, և մշակման մեկնարկի պահին այն չէր կարող դիտարկվել որպես արտադրական լուծում: ընդհանրապես.

Ես դեռ լուրջ նախագծերում Loki-ին իրականում օգտագործելու փորձ չունեմ, բայց կարող եմ ասել, որ Promtail-ը (գերանների հավաքման գործակալ) հիանալի է աշխատում ինչպես մերկ մետաղի, այնպես էլ կուբերնետներում պատիճների համար։

ՏԻԿԵԼ

Թերևս ամենաարժանավոր (միակ?) լիարժեք այլընտրանքը ELK stack-ին այժմ կարելի է անվանել միայն TICK stack - Telegraf, InfluxDB, Chronograf, Kapacitor:

Ես ստորև նկարագրելու եմ բոլոր բաղադրիչները ավելի մանրամասն, բայց ընդհանուր գաղափարը հետևյալն է.

• Telegraf - չափումների հավաքման գործակալ
• InfluxDB - չափումների տվյալների բազա
• Kapacitor - իրական ժամանակի չափման պրոցեսոր ահազանգման համար
• Chronograf - վեբ վահանակ վիզուալիզացիայի համար

InfluxDB-ի, Kapacitor-ի և Chronograf-ի համար կան պաշտոնական ղեկային գծապատկերներ, որոնք մենք օգտագործել ենք դրանք տեղադրելու համար:

Հարկ է նշել, որ Influx 2.0-ի վերջին տարբերակում (բետա) Kapacitor-ը և Chronograf-ը դարձել են InfluxDB-ի մաս և այլևս գոյություն չունեն առանձին:

Telegraph

Telegraph շատ թեթև գործակալ է պետական ​​մեքենայի վրա չափումներ հավաքելու համար:

Նա կարող է վերահսկել հսկայական քանակությամբ ամեն ինչ, սկսած nginx դեպի
սերվեր minecraft.

Այն ունի մի շարք հիանալի առավելություններ.

• Արագ և թեթև (գրված է Go-ում)
  • Ուտում է նվազագույն քանակությամբ ռեսուրսներ
• Հրում չափիչները լռելյայնորեն
• Հավաքում է բոլոր անհրաժեշտ չափումները
  • Համակարգի չափումներ՝ առանց որևէ կարգավորումների
  • Սարքավորումների չափումներ, ինչպիսիք են սենսորներից ստացված տեղեկատվությունը
  • Շատ հեշտ է ավելացնել ձեր սեփական չափումները
• Բազմաթիվ պլագիններ տուփից դուրս
• Հավաքում է տեղեկամատյանները

Քանի որ մղման չափումները մեզ համար անհրաժեշտ էին, մնացած բոլոր առավելություններն ավելին էին, քան հաճելի լրացումները:

Գործակալի կողմից տեղեկամատյանների հավաքումը նույնպես շատ հարմար է, քանի որ տեղեկամատյանների համար լրացուցիչ կոմունալ ծառայություններ միացնելու կարիք չկա:

Influx-ն առաջարկում է տեղեկամատյանների հետ աշխատելու ամենահարմար փորձը, եթե դուք օգտագործում եք syslog.

Telegraf-ը, ընդհանուր առմամբ, հիանալի գործակալ է չափումների հավաքագրման համար, նույնիսկ եթե դուք չեք օգտագործում ICK փաթեթի մնացած մասը:

Շատերը հարմարության համար հատում են այն ELK-ի և ժամանակային շարքերի այլ տվյալների բազաների հետ, քանի որ այն կարող է չափումներ գրել գրեթե ամենուր:

Ներխուժում

InfluxDB-ն TICK բուրգի հիմնական միջուկն է, մասնավորապես՝ չափումների ժամանակային շարքի տվյալների բազան:
Ի լրումն չափումների, Influx-ը կարող է նաև պահել տեղեկամատյանները, չնայած, ըստ էության, դրա համար տեղեկամատյանները նույն չափիչն են, միայն սովորական թվային ցուցանիշների փոխարեն հիմնական գործառույթն իրականացվում է մատյան տեքստի տողով:

InfluxDB-ը նույնպես գրված է Go-ում և կարծես թե շատ ավելի արագ է աշխատում՝ համեմատած ELK-ի հետ մեր (ոչ ամենահզոր) կլաստերի վրա:

Influx-ի հիանալի առավելություններից մեկը ներառում է նաև տվյալների հարցումների համար շատ հարմար և հարուստ API, որը մենք շատ ակտիվորեն օգտագործում էինք:

Թերություններ - $$$, թե scaling.

TICK դարակը ունի միայն մեկ թերություն, որը մենք հայտնաբերեցինք՝ այն սիրելի. Նույնիսկ ավելի շատ.

Ի՞նչ ունի վճարովի տարբերակը, որը չունի անվճար տարբերակը:

Որքանով կարողացանք հասկանալ, TICK stack-ի վճարովի տարբերակի և անվճար տարբերակի միակ տարբերությունը մասշտաբավորման հնարավորություններն են:

Մասնավորապես, դուք կարող եք բարձրացնել կլաստերը բարձր հասանելիությամբ միայն ներսում Ձեռնարկությունների տարբերակները.

Եթե ​​ցանկանում եք լիարժեք HA, դուք կամ պետք է վճարեք, կամ օգտագործեք որոշ հենակներ: Կան մի քանի համայնքային լուծումներ, օրինակ ներհոսքդբ-հա կարծես գրագետ լուծում է, բայց գրված է, որ արտադրության համար պիտանի չէ, ինչպես նաև
ներհոսք-հեղեղ - պարզ լուծում NATS-ի միջոցով տվյալների պոմպով (այն նաև պետք է մասշտաբավորվի, բայց դա հնարավոր է լուծել):

Ցավալի է, բայց երկուսն էլ կարծես թե լքված են. թարմ պարտավորություններ չկան, ենթադրում եմ, որ խնդիրը Influx 2.0-ի նոր տարբերակի շուտով սպասվող թողարկումն է, որում շատ բան տարբեր կլինի (տեղեկություններ չկան դրա մասին։ դեռևս մասշտաբում է դրա մեջ):

Պաշտոնապես կա անվճար տարբերակ Ռելե - իրականում սա պարզունակ ՀԱ է, բայց միայն հավասարակշռման միջոցով,
քանի որ բոլոր տվյալները կգրվեն բոլոր InfluxDB օրինակների վրա, որոնք գտնվում են բեռի հավասարակշռիչի հետևում:
Նա ունի մի քանիսը թերությունները ինչպես վերագրման կետերի հետ կապված հնարավոր խնդիրներն ու չափումների համար նախապես հիմքեր ստեղծելու անհրաժեշտությունը
(ինչը տեղի է ունենում ավտոմատ կերպով InfluxDB-ի հետ նորմալ աշխատանքի ժամանակ):

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

Վիկտորյա մետրիկս?

Արդյունքում, չնայած այն հանգամանքին, որ մենք լիովին գոհ էինք TICK փաթեթից, բացի վճարովի մասշտաբից, մենք որոշեցինք տեսնել, թե արդյոք կան անվճար լուծումներ, որոնք կարող են փոխարինել InfluxDB տվյալների բազան՝ թողնելով մնացած T_CK բաղադրիչները:

Կան բազմաթիվ ժամանակային շարքերի տվյալների բազաներ, բայց ամենահեռանկարայինը Victoria Metrics-ն է, այն ունի մի շարք առավելություններ.

• Արագ և հեշտ, գոնե արդյունքների համաձայն հենանիշներ
• Կա կլաստերային տարբերակ, որի մասին հիմա նույնիսկ լավ ակնարկներ կան
  • Նա կարող է կոտրել
• Աջակցում է InfluxDB արձանագրությանը

Մենք մտադիր չէինք ստեղծել ամբողջովին մաքսային փաթեթ՝ հիմնված Վիկտորիայի վրա, և հիմնական հույսն այն էր, որ մենք կարող ենք օգտագործել այն որպես InfluxDB-ի անկումային փոխարինում:

Ցավոք, դա հնարավոր չէ, չնայած այն հանգամանքին, որ InfluxDB արձանագրությունն ապահովված է, այն աշխատում է միայն չափումների գրանցման համար. միայն Prometheus API-ն է հասանելի «դրսում», ինչը նշանակում է, որ հնարավոր չի լինի դրա վրա տեղադրել Chronograf:

Ավելին, չափումների համար աջակցվում են միայն թվային արժեքները (մենք օգտագործեցինք լարային արժեքներ մաքսային չափումների համար. ավելին դրա մասին բաժնում ադմինիստրատորի վահանակ).

Ակնհայտ է, որ նույն պատճառով, VM-ը չի կարող պահել տեղեկամատյանները, ինչպես դա անում է Influx-ը:

Նաև հարկ է նշել, որ օպտիմալ լուծում փնտրելու պահին Victoria Metrics-ը դեռ այնքան էլ հայտնի չէր, փաստաթղթերը շատ ավելի փոքր էին, իսկ ֆունկցիոնալությունը՝ ավելի թույլ։
(Ես չեմ հիշում կլաստերի տարբերակի և շարադրման մանրամասն նկարագրությունը):

Հիմքի ընտրություն

Արդյունքում որոշվեց, որ օդաչուի համար մենք դեռ կսահմանափակվենք մեկ InfluxDB հանգույցով:

Այս ընտրության մի քանի հիմնական պատճառ կար.

• Մեզ շատ դուր եկավ TICK stack-ի ամբողջ ֆունկցիոնալությունը
• Մեզ արդեն հաջողվել է տեղակայել այն, և այն հիանալի աշխատեց
• Ժամկետները սպառվում էին, և շատ ժամանակ չէր մնացել այլ տարբերակներ փորձարկելու համար:
• Այսքան ծանր բեռ չէինք սպասում

Փորձնական առաջին փուլի համար մենք շատ սկուտերներ չունեինք, և մշակման ընթացքում փորձարկումները չբացահայտեցին աշխատանքի որևէ խնդիր:

Հետևաբար, մենք որոշեցինք, որ այս նախագծի համար մեզ բավարար կլինի մեկ Influx հանգույց՝ առանց մասշտաբավորման անհրաժեշտության (տես եզրակացությունները վերջում):

Մենք որոշել ենք կույտի և բազայի մասին՝ այժմ TICK stack-ի մնացած բաղադրիչների մասին:

Կապիչատոր

Kapacitor-ը TICK stack-ի մի մասն է, ծառայություն, որը կարող է իրական ժամանակում վերահսկել տվյալների բազա մուտք գործող չափումները և կանոնների հիման վրա կատարել տարբեր գործողություններ:

Ընդհանուր առմամբ, այն դիրքավորվում է որպես պոտենցիալ անոմալիաների հետևման և մեքենայական ուսուցման գործիք (վստահ չեմ, որ այս գործառույթները պահանջարկ ունեն), բայց դրա օգտագործման ամենատարածված դեպքն ավելի տարածված է՝ ահազանգելը:

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

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

Պարզ օրինակ․ մեր «տուփը» սնուցելու լրացուցիչ մարտկոցը խափանվել է կամ ինչ-ինչ պատճառներով սպառվել է, պարզապես նորը տեղադրելով, որոշ ժամանակ անց մենք պետք է ծանուցում ստանանք, որ սկուտերի ֆունկցիոնալությունը վերականգնվել է։

Influx 2.0-ում Kapacitor-ը դարձավ DB-ի մի մասը

Քրոնոգրաֆ

Ես տեսել եմ բազմաթիվ տարբեր UI լուծումներ մոնիտորինգի համար, բայց կարող եմ ասել, որ ֆունկցիոնալության և UX-ի առումով ոչինչ չի համեմատվում Chronograf-ի հետ։

Մենք սկսեցինք օգտագործել TICK stack-ը, տարօրինակ կերպով, Grafan-ի հետ որպես վեբ ինտերֆեյս:
Ես չեմ նկարագրի դրա ֆունկցիոնալությունը, բոլորը գիտեն դրա լայն հնարավորությունները որևէ բան կարգավորելու համար:

Այնուամենայնիվ, Grafana-ն դեռևս լիովին ունիվերսալ գործիք է, մինչդեռ Chronograf-ը հիմնականում նախատեսված է Influx-ի հետ օգտագործելու համար:

Եվ, իհարկե, դրա շնորհիվ Chronograf-ը կարող է իրեն թույլ տալ շատ ավելի խելացի կամ հարմար ֆունկցիոնալություն:

Թերևս Chronograf-ի հետ աշխատելու հիմնական հարմարությունն այն է, որ դուք կարող եք դիտել ձեր InfluxDB-ի ներսը Explore-ի միջոցով:

Թվում է, թե Grafana-ն գրեթե նույնական ֆունկցիոնալությունն ունի, բայց իրականում Chronograf-ում վահանակի տեղադրումը կարելի է անել մկնիկի մի քանի կտտոցով (միևնույն ժամանակ նայելով այնտեղի վիզուալիզացիան), մինչդեռ Grafana-ում դուք դեռ վաղ թե ուշ կունենաք: JSON կոնֆիգուրացիան խմբագրելու համար (իհարկե Chronograf-ը թույլ է տալիս վերբեռնել ձեր ձեռքով կազմաձևված dasha-ները և անհրաժեշտության դեպքում խմբագրել դրանք որպես JSON, բայց ես երբեք ստիպված չեմ եղել դիպչել դրանց UI-ում ստեղծելուց հետո):

Kibana-ն շատ ավելի հարուստ հնարավորություններ ունի դրանց համար վահանակներ և կառավարումներ ստեղծելու համար, սակայն նման գործողությունների UX-ը շատ բարդ է:

Հարմար ցուցատախտակ ստեղծելու համար որոշակի լավ հասկացողություն կպահանջվի: Եվ չնայած Chronograf-ի վահանակների ֆունկցիոնալությունն ավելի քիչ է, դրանց պատրաստումն ու հարմարեցումը շատ ավելի պարզ է:

Ինքնին վահանակները, բացի հաճելի տեսողական ոճից, իրականում ոչնչով չեն տարբերվում Grafana-ի կամ Kibana-ի վահանակներից.

Հարցման պատուհանի տեսքը հետևյալն է.

Կարևոր է նշել, ի թիվս այլ բաների, որ իմանալով InfluxDB տվյալների բազայի դաշտերի տեսակները, ժամանակագրողն ինքնին երբեմն կարող է ավտոմատ կերպով օգնել ձեզ հարցում գրելիս կամ ընտրել ճիշտ ագրեգացիոն ֆունկցիան, ինչպիսին միջինն է:

Եվ, իհարկե, Chronograf-ը հնարավորինս հարմար է տեղեկամատյանները դիտելու համար: Այն կարծես այսպիսին է.

Լռելյայնորեն, Influx տեղեկամատյանները հարմարեցված են syslog-ն օգտագործելու համար և, հետևաբար, դրանք ունեն կարևոր պարամետր՝ խստություն:

Հատկապես օգտակար է վերևի գրաֆիկը, որի վրա դուք կարող եք տեսնել տեղի ունեցող սխալները, և գույնը անմիջապես պարզորոշ ցույց է տալիս, թե արդյոք խստությունը ավելի բարձր է:

Մի քանի անգամ մենք այս կերպ որսացանք կարևոր վրիպակներ՝ դիտելով վերջին շաբաթվա տեղեկամատյանները և տեսնելով կարմիր հասկ:

Իհարկե, իդեալական տարբերակ կլիներ նման սխալների համար ահազանգեր տեղադրելը, քանի որ մենք արդեն ամեն ինչ ունեինք դրա համար:

Մենք նույնիսկ որոշ ժամանակ միացրեցինք սա, բայց փորձնական պատրաստման գործընթացում պարզվեց, որ բավականին շատ սխալներ էինք ստանում (ներառյալ համակարգային, ինչպիսիք են LTE ցանցի անհասանելիությունը), որոնք «սպամում» էին Slack ալիքը: չափազանց շատ, առանց որևէ խնդիր առաջացնելու, մեծ օգուտ.

Ճիշտ լուծումը կլինի այս տեսակի սխալների մեծամասնությունը կարգավորելը, դրանց խստությունը կարգավորելը և միայն դրանից հետո ահազանգելը միացնելը:

Այս կերպ միայն նոր կամ կարևոր սխալները կտեղադրվեն Slack-ում: Պարզապես բավական ժամանակ չկար նման կարգաբերման համար՝ հաշվի առնելով սեղմ ժամկետները:

Նույնականացմանը

Հարկ է նաև նշել, որ Chronograf-ն աջակցում է OAuth-ին և OIDC-ին որպես նույնականացում:

Սա շատ հարմար է, քանի որ թույլ է տալիս հեշտությամբ կցել այն ձեր սերվերին և ստեղծել լիարժեք SSO:

Մեր դեպքում սերվերն էր ստեղնաշար — այն օգտագործվել է մոնիտորինգին միանալու համար, բայց նույն սերվերն օգտագործվել է նաև սկուտերների իսկությունը հաստատելու և հետին մասի հարցումները:

«Ադմին»

Վերջին բաղադրիչը, որը ես նկարագրելու եմ, մեր ինքնագրված «ադմինիստրատորի վահանակն» է Vue-ում:
Հիմնականում դա պարզապես ինքնուրույն ծառայություն է, որը միաժամանակ ցուցադրում է սկուտերային տեղեկատվությունը մեր սեփական տվյալների բազաներից, միկրոծառայությունների և InfluxDB-ի չափման տվյալներից:

Բացի այդ, այնտեղ տեղափոխվեցին բազմաթիվ վարչական գործառույթներ, ինչպիսիք են արտակարգ իրավիճակների վերագործարկումը կամ աջակցության թիմի համար կողպեքի հեռակա բացումը:

Կային նաև քարտեզներ։ Ես արդեն նշեցի, որ Chronograf-ի փոխարեն մենք սկսել ենք Grafana-ով, քանի որ Grafana-ի համար քարտեզները հասանելի են պլագինների տեսքով, որոնց վրա մենք կարող ենք դիտել սկուտերների կոորդինատները: Ցավոք, Grafana-ի համար քարտեզի վիդջեթների հնարավորությունները շատ սահմանափակ են, և արդյունքում շատ ավելի հեշտ էր մի քանի օրում քարտեզներով գրել ձեր սեփական վեբ հավելվածը, որպեսզի ոչ միայն տեսնեք տվյալ պահին կոորդինատները, այլև ցուցադրեք: երթուղին, որով անցնում է սկուտերը, կարողանալ զտել տվյալները քարտեզի վրա և այլն (այն ամբողջ գործառույթը, որը մենք չկարողացանք կարգավորել պարզ վահանակում):

Influx-ի արդեն նշված առավելություններից է սեփական չափորոշիչները հեշտությամբ ստեղծելու հնարավորությունը։
Սա թույլ է տալիս այն օգտագործել հսկայական տարբեր սցենարների համար:

Մենք փորձեցինք այնտեղ գրանցել բոլոր օգտակար տեղեկությունները` մարտկոցի լիցքավորումը, կողպեքի կարգավիճակը, սենսորի աշխատանքը, Bluetooth-ը, GPS-ը և բազմաթիվ այլ առողջական ստուգումներ:
Այս ամենը մենք ցուցադրեցինք ադմինիստրատորի վահանակում:

Իհարկե, մեզ համար ամենակարևոր չափանիշը սկուտերի գործառնական վիճակն էր. իրականում Influx-ը դա ինքն է ստուգում և «կանաչ լույսերով» ցույց տալիս հանգույցների բաժնում:

Սա կատարվում է ֆունկցիայի միջոցով մոլեռանդ — մենք այն օգտագործել ենք՝ հասկանալու մեր տուփի աշխատանքը և նույն ահազանգերն ուղարկել Slack-ին:

Ի դեպ, մենք սկուտերներին անվանակոչել ենք «Սիմփսոնների» հերոսների անուններով. այնքան հարմար էր դրանք տարբերել միմյանցից:

Իսկ ընդհանրապես այսպես ավելի զվարճալի էր։ Անընդհատ հնչում էին «Տղաներ, Սմիթերսը մեռած է» արտահայտությունները։

Լարային չափումներ

Կարևոր է, որ InfluxDB-ն թույլ է տալիս պահպանել ոչ միայն թվային արժեքները, ինչպես դա տեղի է ունենում Victoria Metrics-ի դեպքում:

Թվում է, թե դա այնքան էլ կարևոր չէ. ի վերջո, տեղեկամատյաններից բացի, ցանկացած չափիչ կարող է պահպանվել թվերի տեսքով (պարզապես ավելացրե՛ք քարտեզագրումը հայտնի վիճակների համար. մի տեսակ թվո՞ւմ):

Մեր դեպքում կար առնվազն մեկ սցենար, որտեղ լարային չափումները շատ օգտակար էին:
Պարզապես պատահեց, որ մեր «խելացի լիցքավորիչների» մատակարարը երրորդ կողմ էր, մենք վերահսկողություն չունեինք մշակման գործընթացի և այն տեղեկատվության վրա, որը կարող էին մատակարարել այս լիցքավորիչները:

Արդյունքում, լիցքավորման API-ն հեռու էր իդեալական լինելուց, բայց հիմնական խնդիրն այն էր, որ մենք միշտ չէինք կարողանում հասկանալ դրանց վիճակը:

Ահա, որտեղ Influx-ը օգնության հասավ: Մենք պարզապես գրել ենք տողի կարգավիճակը, որը եկել է մեզ InfluxDB տվյալների բազայի դաշտում՝ առանց փոփոխությունների:

Որոշ ժամանակ այնտեղ հասնում էին միայն «առցանց» և «օֆլայն» արժեքները, որոնց հիման վրա տեղեկատվությունը ցուցադրվում էր մեր ադմինիստրատորի վահանակում, և ծանուցումները ուղարկվում էին Slack-ին: Այնուամենայնիվ, ինչ-որ պահի այնտեղ սկսեցին հայտնվել նաև այնպիսի արժեքներ, ինչպիսիք են «անջատված»:

Ինչպես պարզվեց ավելի ուշ, կապը կորցնելուց հետո այս կարգավիճակն ուղարկվել է մեկ անգամ, եթե որոշակի քանակությամբ փորձերից հետո լիցքավորիչը չի կարողացել կապ հաստատել սերվերի հետ։

Այսպիսով, եթե մենք օգտագործեինք միայն ֆիքսված արժեքների հավաքածու, մենք կարող ենք չտեսնել այս փոփոխությունները որոնվածում ճիշտ ժամանակին:

Իսկ ընդհանուր առմամբ, լարային չափորոշիչները օգտագործման շատ ավելի շատ հնարավորություններ են տալիս, դուք կարող եք գրեթե ցանկացած տեղեկատվություն գրանցել դրանցում: Չնայած, իհարկե, դուք նույնպես պետք է ուշադիր օգտագործեք այս գործիքը:

Ի հավելումն սովորական չափումների, մենք նաև գրանցել ենք GPS-ի տեղադրության մասին տեղեկությունները InfluxDB-ում: Սա աներևակայելի օգտակար էր մեր ադմինիստրատորի վահանակում սկուտերների գտնվելու վայրը վերահսկելու համար:
Իրականում մենք միշտ գիտեինք, թե որտեղ և որ սկուտերն է մեզ անհրաժեշտ պահին:

Սա շատ օգտակար էր մեզ համար, երբ մենք փնտրում էինք սկուտեր (տես եզրակացությունները վերջում):

Ենթակառուցվածքի մոնիտորինգ

Բացի բուն սկուտերներից, մեզ անհրաժեշտ էր նաև վերահսկել մեր ամբողջ (բավականին ընդարձակ) ենթակառուցվածքը:

Շատ ընդհանուր ճարտարապետությունն այսպիսի տեսք ուներ.

Եթե ​​մենք ընդգծենք մաքուր մոնիտորինգի կույտը, ապա դա հետևյալն է.

Այն, ինչ մենք կցանկանայինք ստուգել ամպի մեջ, հետևյալն է.

• Տվյալների բազա
• ստեղնաշար
• Միկրոծառայություններ

Քանի որ մեր բոլոր ամպային ծառայությունները տեղակայված են Kubernetes-ում, լավ կլիներ տեղեկություններ հավաքել դրա վիճակի մասին:

Բարեբախտաբար, Telegraf-ը կարող է հավաքել մեծ թվով չափումներ Kubernetes կլաստերի վիճակի վերաբերյալ, և Chronograf-ն անմիջապես առաջարկում է դրա համար գեղեցիկ վահանակներ:

Մենք հիմնականում վերահսկում էինք պատիճների աշխատանքը և հիշողության սպառումը: Անկման դեպքում ահազանգեր Slack-ում։

Kubernetes-ում pods-ներին հետևելու երկու եղանակ կա՝ DaemonSet և Sidecar:
Երկու մեթոդներն էլ մանրամասն նկարագրված են այս բլոգի գրառման մեջ.

Մենք օգտագործեցինք Telegraf Sidecar-ը և, ի լրումն չափումների, հավաքեցինք պատիճների տեղեկամատյանները:

Մեր դեպքում մենք ստիպված եղանք կոճղացնել գերանները: Չնայած այն հանգամանքին, որ Telegraf-ը կարող է տեղեկամատյաններ քաշել Docker API-ից, մենք ցանկանում էինք ունենալ տեղեկամատյանների միասնական հավաքածու մեր վերջնական սարքերի հետ և դրա համար կոնֆիգուրացված տեղեկամատյաններ բեռնարկղերի համար: Թերևս այս լուծումը գեղեցիկ չէր, բայց դրա աշխատանքի վերաբերյալ բողոքներ չկային, և տեղեկամատյանները լավ էին ցուցադրվում Chronograf-ում։

Մոնիտորինգի մոնիտորինգ???

Ի վերջո, առաջացավ մոնիտորինգի համակարգերի դարավոր հարցը, բայց, բարեբախտաբար, կամ ցավոք սրտի, մենք պարզապես ժամանակ չունեինք դրա համար։

Թեև Telegraf-ը կարող է հեշտությամբ ուղարկել իր չափումները կամ հավաքել չափումներ InfluxDB տվյալների բազայից՝ ուղարկելու համար կամ նույն Influx-ին կամ որևէ այլ տեղ:

Արդյունքները

Ի՞նչ եզրակացություններ արեցինք օդաչուի արդյունքներից։

Ինչպե՞ս կարող եք մոնիտորինգ անել:

Նախ և առաջ, TICK-ը լիովին արդարացրեց մեր ակնկալիքները և նույնիսկ ավելի շատ հնարավորություններ տվեց, քան մենք ի սկզբանե ակնկալում էինք:

Մեզ անհրաժեշտ ամբողջ ֆունկցիոնալությունը ներկա էր: Այն ամենը, ինչ մենք արեցինք դրա հետ, աշխատեց առանց խնդիրների:

Արտադրողականություն

Անվճար տարբերակում TICK stack-ի հիմնական խնդիրը մասշտաբային հնարավորությունների բացակայությունն է: Սա մեզ համար խնդիր չէր։

Մենք չենք հավաքել ճշգրիտ բեռնվածության տվյալներ/թվեր, բայց մենք հավաքել ենք տվյալներ միանգամից մոտ 30 սկուտերներից:

Նրանցից յուրաքանչյուրը հավաքել է ավելի քան երեք տասնյակ չափումներ: Միաժամանակ սարքերից տեղեկամատյաններ են հավաքվել։ Տվյալների հավաքագրումն ու ուղարկումը տեղի է ունեցել 10 վայրկյանը մեկ:

Կարևոր է նշել, որ փորձնական մեկուկես շաբաթ անց, երբ շտկվեցին «մանկության խնդիրների» հիմնական մասը, և ամենակարևոր խնդիրները արդեն լուծված էին, մենք ստիպված էինք կրճատել տվյալների սերվեր ուղարկելու հաճախականությունը. 30 վայրկյան. Դա անհրաժեշտ դարձավ, քանի որ մեր LTE SIM քարտերի տրաֆիկը սկսեց արագ անհետանալ:

Երթևեկության հիմնական մասը սպառվում էր գերաններով, իսկ չափիչները, նույնիսկ 10 վայրկյան ընդմիջումով, գործնականում չեն վատնում այն:

Արդյունքում որոշ ժամանակ անց մենք ամբողջությամբ անջատեցինք տեղեկամատյանների հավաքումը սարքերում, քանի որ կոնկրետ խնդիրներն արդեն ակնհայտ էին նույնիսկ առանց մշտական ​​հավաքագրման։

Որոշ դեպքերում, եթե տեղեկամատյանները դիտելը դեռևս անհրաժեշտ էր, մենք պարզապես միացանք WireGuard-ի միջոցով VPN-ի միջոցով:

Ավելացնեմ նաև, որ յուրաքանչյուր առանձին միջավայր առանձնացված էր միմյանցից, և վերը նկարագրված բեռը տեղին էր միայն արտադրական միջավայրի համար:

Զարգացման միջավայրում մենք բարձրացրեցինք առանձին InfluxDB օրինակ, որը շարունակեց տվյալների հավաքագրումը յուրաքանչյուր 10 վայրկյանը մեկ, և մենք կատարողականի որևէ խնդրի չենք հանդիպել:

TICK - իդեալական փոքր և միջին նախագծերի համար

Հիմնվելով այս տեղեկատվության վրա՝ ես կեզրակացնեի, որ TICK ստեկը իդեալական է համեմատաբար փոքր նախագծերի կամ նախագծերի համար, որոնք հաստատ չեն ակնկալում որևէ HighLoad:

Եթե ​​դուք չունեք հազարավոր պատյաններ կամ հարյուրավոր մեքենաներ, նույնիսկ մեկ InfluxDB օրինակը լավ կզբաղվի բեռով:

Որոշ դեպքերում դուք կարող եք գոհ լինել Influx Relay-ից՝ որպես բարձր հասանելիության պարզունակ լուծում:

Եվ, իհարկե, ոչ ոք ձեզ չի խանգարում կարգավորել «ուղղահայաց» մասշտաբը և պարզապես տարբեր սերվերներ հատկացնել տարբեր տեսակի չափումների համար:

Եթե ​​վստահ չեք մոնիտորինգի ծառայությունների սպասվող ծանրաբեռնվածության մասին, կամ երաշխավորված է, որ կունենաք/ կունենաք շատ «ծանր» ճարտարապետություն, ես խորհուրդ չեմ տա օգտագործել TICK stack-ի անվճար տարբերակը:

Իհարկե, պարզ լուծում կլինի գնելը InfluxDB Enterprise - Բայց այստեղ ես չեմ կարող ինչ-որ կերպ մեկնաբանել, քանի որ ես ինքս ծանոթ չեմ նրբություններին: Բացի այն, որ այն շատ թանկ է և միանշանակ հարմար չէ փոքր ընկերությունների համար։

Այս դեպքում, այսօր ես խորհուրդ կտայի նայել դեպի Victoria Metrics-ի և Loki-ի օգտագործմամբ տեղեկամատյանների չափումներ հավաքելը:

Ճիշտ է, նորից վերապահում կանեմ, որ Loki/Grafana-ն շատ ավելի քիչ հարմար է (դրանց ավելի մեծ բազմակողմանիության պատճառով), քան պատրաստի TICK-ը, բայց դրանք անվճար են։

Կարեւոր է,Այստեղ նկարագրված ամբողջ տեղեկատվությունը վերաբերում է Influx 1.8 տարբերակին, այս պահին Influx 2.0-ը պատրաստվում է թողարկվել:

Թեև ես հնարավորություն չեմ ունեցել այն փորձել մարտական ​​պայմաններում, և դժվար է եզրակացություններ անել բարելավումների մասին, ինտերֆեյսը, անկասկած, դարձել է ավելի լավը, ճարտարապետությունը պարզեցվել է (առանց capacitor-ի և chronograf-ի),
հայտնվեցին կաղապարներ («մարդասպանի հատկանիշ» - Դուք կարող եք հետևել խաղացողներին Fortnite-ում և ստանալ ծանուցումներ, երբ ձեր սիրելի խաղացողը հաղթում է խաղը) Բայց, ցավոք սրտի, այս պահին 2-րդ տարբերակում չկա այն առանցքային բանը, որի համար մենք ընտրել ենք առաջին տարբերակը՝ տեղեկամատյանների հավաքածու չկա:

Այս ֆունկցիոնալությունը կհայտնվի նաև Influx 2.0-ում, բայց մենք չկարողացանք որևէ վերջնաժամկետ գտնել, նույնիսկ մոտավոր:

Ինչպես չստեղծել IoT հարթակներ (այժմ)

Ի վերջո, գործարկելով փորձնական տարբերակը, մենք ինքներս հավաքեցինք մեր սեփական լիարժեք IoT փաթեթը՝ մեր չափանիշներին համապատասխան այլընտրանքի բացակայության դեպքում:

Այնուամենայնիվ, վերջերս այն հասանելի է բետա տարբերակով OpenBalena — Ափսոս, որ նա այնտեղ չէր, երբ մենք սկսեցինք նախագիծը պատրաստել:

Մենք լիովին գոհ ենք վերջնական արդյունքից և Ansible + TICK + WireGuard-ի վրա հիմնված հարթակից, որը մենք ինքներս ենք հավաքել: Բայց այսօր ես խորհուրդ կտայի ավելի մոտիկից նայել Balena-ին, նախքան ինքներդ փորձեք կառուցել ձեր սեփական IoT հարթակը:

Քանի որ, ի վերջո, այն կարող է անել մեր արածի մեծ մասը, և OpenBalena-ն անվճար է և բաց կոդով:

Այն արդեն գիտի, թե ինչպես պետք է ոչ միայն թարմացումներ ուղարկել, այլև VPN-ն արդեն ներկառուցված և հարմարեցված է IoT միջավայրում օգտագործելու համար:

Եվ հենց վերջերս նրանք նույնիսկ թողարկեցին իրենց Hardware, որը հեշտությամբ միանում է նրանց էկոհամակարգին։

Հեյ, ինչ վերաբերում է անհետացած սկուտերին:

Այսպիսով, սկուտերը՝ «Ռալֆը», անհետացել է առանց հետքի։

Մենք անմիջապես վազեցինք քարտեզը նայելու մեր «ադմինիստրատորի վահանակում»՝ InfluxDB-ից GPS չափման տվյալների հետ:

Մոնիտորինգի տվյալների շնորհիվ մենք հեշտությամբ պարզեցինք, որ սկուտերը լքել է ավտոկայանատեղը անցյալ օրը ժամը 21:00-ի սահմաններում, մոտ կես ժամ քշել է ինչ-որ տարածք և մինչև առավոտյան ժամը 5-ը կայանվել է ինչ-որ գերմանական տան մոտ:

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

Սակայն տան տիրոջը դա նույնպես զարմացրել է, քանի որ երեկ երեկոյան նա իրականում այս սկուտերով տուն է գնացել գրասենյակից։

Ինչպես պարզվել է, աջակցության աշխատակիցներից մեկը վաղ առավոտյան ժամանել է և վերցրել սկուտերը՝ տեսնելով, որ դրա լրացուցիչ մարտկոցն ամբողջությամբ լիցքաթափվել է և այն (ոտքով) տարել ավտոկայանատեղի։ Իսկ լրացուցիչ մարտկոցը խափանվել է խոնավության պատճառով։

Մենք մեզանից գողացել ենք սկուտերը. Ի դեպ, ես չգիտեմ, թե ինչպես և ով է այնուհետև լուծել ոստիկանության գործի հետ կապված խնդիրը, բայց մոնիտորինգը հիանալի աշխատեց...

Source: www.habr.com