SNMP մոնիտորինգ Odoo 19-ում. շեմը գերազանցվեց, տիկետը բացվեց
Սերվերներ, switch-եր, UPS համակարգեր, ջերմաստիճանի սենսորներ սերվերային սենյակում. ցանցում կախված գրեթե ամեն ինչ խոսում է SNMP-ով և կարող է տեղեկություն տալ իր վիճակի մասին։ Հարցը միայն այն է, թե ով է լսում, և ինչ է լինում, երբ որևէ արժեք դուրս է գալիս նորմայից։
Այն ենթակառուցվածքի համար, որը մենք սպասարկում ենք մեր հաճախորդների համար, այս շղթան այժմ հավաքել ենք մեկ տեղում. մեր Odoo 19-ը հարցում է կատարում սարքերին, համեմատում է արժեքները շեմերի հետ, և երբ սահմանին հասնում է, Helpdesk-ում տիկետ է բացում՝ այն հաճախորդի մոտ, ում պատկանում է սարքը։ Ոչ թե առանձին մոնիտորինգ համակարգ, որը էլ. փոստով գրում է Helpdesk-ին, այլ նույն համակարգը, որտեղ հաճախորդը, սարքը և տիկետը այնպես էլ կապված են։
Մոդուլը մենք մշակել ենք սեփական գործունեության համար։ Այն համայնքային հրապարակում չէ, ինչպես մեր բանկային քաղվածքների կամ e-հաշիվների մոդուլները, այլ մեր ներքին սպասարկման հարթակի մաս է՝ ինչպես հետևումը, որի մասին վերջերս հաղորդել ենք։
Չափված արժեքից մինչև տիկետ
Ընթացքը միտումնավոր պարզ է պահվել՝
- Սարքը ստեղծվում է հասցեով և մուտքի տվյալներով (SNMP v1, v2c կամ v3՝ նույնականացմամբ և գաղտնագրմամբ)։ Պահպանելիս Odoo-ն ստանում է համակարգի նկարագրությունը, համակարգի անունը և uptime-ը՝ ամենանրբահույզ հաստատումը, որ հասցեն և մուտքի տվյալները ճիշտ են։
- Սարքի վրա սահմանվում են տվյալների կետեր՝ OID, չափման միավոր, հաճախորդին վերագրում։
- Ժամանակացույցը հարցում է կատարում բոլոր ակտիվ տվյալների կետերին։ Յուրաքանչյուր սարքի համար միանում է մեկ անգամ, ոչ թե յուրաքանչյուր տվյալների կետի համար. switch-ի վրա քսան OID-ի դեպքում դա տարբերությունն է մեկ և քսան սեսիայի միջև։
- Յուրաքանչյուր տվյալների կետ կարող է վերահսկել շեմեր՝ վերին սահման, ստորին սահման կամ երկուսը։
- Եթե սահմանը գերազանցվում է, ստեղծվում է Helpdesk տիկետ։
Մեկ տիկետ յուրաքանչյուր միջադեպի համար, ոչ թե յուրաքանչյուր չափման
Ահազանգի տրամաբանության ամենակարևոր կետը՝ միայն վիճակի փոփոխությունն է հաշվվում։ Ով յուրաքանչյուր չափման դեպքում տիկետ է ստեղծում, մի գիշերվա ընթացքում խրված կամ թրթռացող սենսորի դեպքում ունենում է երեք հարյուր տիկետ. դա ահազանգում չէ, դա մառախուղ է։
Ուստի մոդուլը յուրաքանչյուր տվյալների կետի համար հիշում է, թե արդյոք այն գտնվում է «Նորմալ» թե «Ահազանգ» վիճակում։ Սահմանը առաջին անգամ գերազանցելիս վիճակը փոխվում է, հաղորդագրությունը հայտնվում է սարքի Chatter-ում, և տիկետ է բացվում՝ տուժած հաճախորդով որպես գործընկեր, տեքստում՝ տվյալների կետով, սարքով, չափված արժեքով և խախտված սահմանով։ Քանի դեռ արժեքը մնում է սահմանից դուրս, այլ ոչինչ չի լինում. տիկետը բաց է, մեր տեխնիկները տեղյակ են։
Երբ արժեքը վերադառնում է նորմալ տիրույթ, մոդուլը նույն տիկետում գրում է հանգստացման ազդանշան և լուծում է կապը։ Արդյոք տիկետը կփակվի, դեռևս որոշում է մարդը. արժեքը, որը կարճ ժամանակով ընկնում է սահմանից ցածր, դեռ չի նշանակում, որ պատճառը վերացել է։
Շեմերը ստուգվում են յուրաքանչյուր չափման դեպքում՝ անկախ այն բանից, արդյոք արժեքը պահպանվում է։ Մշտապես չափազանց բարձր արժեքը մնում է ահազանգ։ Եվ ահազանգը երբեք չպետք է խափանվի այն պատճառով, որ տիկետը հնարավոր չէ ստեղծել. եթե ստեղծումը ձախողվի, արձանագրությունը և հաղորդագրությունը սարքի մոտ այնուամենայնիվ մնում են։
Պահպանել միայն այն, ինչ փոխվում է
Տվյալների կետը, որին հարցում է կատարվում յուրաքանչյուր հինգ րոպեն մեկ, տարեկան տալիս է 105 000 արժեք։ Հարյուր տվյալների կետի դեպքում դա տասը միլիոնից ավելի տող է՝ արժեքների համար, որոնք հիմնականում ընդհանրապես չեն փոխվել։
Ուստի պահպանվում է միայն այն, ինչ վերջին պահպանված արժեքից տարբերվում է ավելի, քան սահմանված շեմը՝ յուրաքանչյուր տվյալների կետի համար որպես բացարձակ տարբերություն (օրինակ՝ 0,5 °C), որպես տոկոսային շեղում կամ յուրաքանչյուր փոփոխության դեպքում։ Ընթացիկ արժեքը և վերջին հարցման ժամանակը այնուամենայնիվ միշտ գտնվում են տվյալների կետի մոտ. նոսրացվում է միայն պատմությունը։
Թե ուր են գրվում արժեքները, նույնպես կարգավորվում է՝ Odoo տվյալների բազայում, MongoDB-ում կամ որպես CSV ֆայլեր Odoo-ի filestore-ում։ Այդպիսով չափված արժեքները մենք պահում ենք ERP տվյալների բազայից դուրս՝ նույն սկզբունքով, ինչ հետևման դիրքի տվյալների դեպքում։ Պատմությունը ցանկացած դեպքում կարելի է ցուցադրել դիագրամի տեսքով, ժամային խտացման դեպքում՝ որպես միջին, ոչ թե որպես գումար։
Լցվածության մակարդակը տոկոսով՝ բայթերի փոխարեն
Որոշ մեծություններ որպես այդպիսին սարքում չկան։ Բաժանման լցվածության մակարդակը պետք է հաշվարկվի զբաղված հիշողությունից և ընդհանուր չափից. ջերմաստիճանի սենսորները հաճախ տալիս են մասշտաբավորված ամբողջ թվեր՝ 235՝ 23,5 աստիճանի համար։
Ուստի տվյալների կետը կարող է արժեքը վերցնել այնպես, ինչպես հաղորդվել է, բազմապատկել գործակցով կամ հաշվարկել որպես երկրորդ OID-ի տոկոս։ Շեմերի համար սա վճռական է. 90 % սահմանը գործում է սկավառակի ցանկացած չափի համար։ Գիգաբայթերով սահմանը պետք է յուրաքանչյուր սկավառակի համար առանձին թարմացվեր։
Ոչ ոք պարտավոր չէ անգիր իմանալ OID-ները
Windows և Linux սերվերների դեպքում HOST-RESOURCES-MIB-ը ստանդարտացված է. սկավառակները և օպերատիվ հիշողությունը գտնվում են հայտնի տեղում։ Սարքի հայտնաբերումը կարդում է աղյուսակը, լցվածության մակարդակները փոխարկում է տոկոսի և տվյալների կետերը՝ ահազանգի սահմանով հանդերձ, ստեղծում է մեկ սեղմումով։
Մնացած ամեն ինչի համար կա SNMP բրաուզեր, որը անցնում է OID ծառով և ցույց է տալիս յուրաքանչյուր գտնված OID՝ իր ընթացիկ արժեքով, և եթե կատալոգում հայտնի է՝ անունով, նկարագրությամբ և չափման միավորով ներմուծված արտադրողի MIB-ից։ Բավական է նշել։
Ինչ են ստանում մեր հաճախորդները դրանից
Սարքերը և տվյալների կետերը վերագրված են հաճախորդներին։ Հաճախորդների պորտալում Իմ SNMP արժեքները բաժնում Դուք կգտնեք Ձեր սարքերի ընթացիկ չափված արժեքները և վերջին 24 ժամվա, 7 օրվա, 30 օրվա կամ 12 ամսվա պատմությունը դիագրամի տեսքով՝ նույն արժեքները, որոնք տեսնում ենք նաև մենք։ Տեսանելի է բացառապես այն, ինչ վերագրված է Ձեր ընկերությանը։
Եվ եթե շեմը գերազանցվի, Դուք ոչինչ անելու կարիք չունեք. տիկետն արդեն մեզ մոտ է՝ սարքով, արժեքով և ժամով, նախքան Դուք դա կնկատեք։
Ինչ չէ մոդուլը միտումնավոր
Այն լիարժեք մոնիտորինգի փոխարինող չէ՝ հասանելիության ստուգումներով, էսկալացիայի շղթաներով և կախվածության ծառերով։ Այն SNMP trap-եր չի ընդունում, այլ ակտիվորեն հարցում է կատարում։ Եվ այն ոչ մի տիկետ ավտոմատ չի փակում. հանգստացման ազդանշանը հաղորդագրություն է, ոչ թե կարգավիճակի փոփոխություն։
Խոսքը հենց մեկ հատվածի մասին է՝ չափված արժեքից՝ սահմանի միջով, մինչև տեխնիկը, որը զբաղվում է դրանով։ Այս հատվածն այժմ այնքան կարճ է, որքան կարող է լինել։
Եթե ցանկանում եք Ձեր սերվերները, ցանցային սարքերը կամ սենսորները ընդգրկել այս վերահսկողության մեջ, դիմեք մեզ։