Երկու տարի առաջ ես արդեն գրառում էի արել Պարզ ձախողում կայքի համար մոտ օկերր. Հիմա նախագծի որոշակի զարգացում կա, ես էլ հրապարակեցի okerr սերվերի կողմից աղբյուրի կոդը տակ բաց լիցենզիա, այդ իսկ պատճառով ես որոշեցի գրել այս կարճ ակնարկը Habr-ում։

Ում դա կարող է հետաքրքրել

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

Ինչու okerr-ն անսովոր է

Հաջորդիվ ես ցույց կտամ օկերայի հետաքրքիր առանձնահատկությունները, որոնք այն տարբերում են մոնիտորինգի որոշ այլ համակարգերից:

Okerr-ը հիբրիդային մոնիտորինգ է

Ներքին մոնիտորինգի ժամանակ վերահսկվող մեքենաների վրա աշխատում է «գործակալ», որը տվյալները փոխանցում է մոնիտորինգի սերվերին (օրինակ՝ սկավառակի ազատ տարածություն): Երբ արտաքին, սերվերը ստուգումներ է կատարում ցանցի միջոցով (օրինակ՝ ping կամ կայքի հասանելիություն): Յուրաքանչյուր մոտեցում ունի իր սահմանափակումները: Okerr-ն օգտագործում է երկու տարբերակները: Սերվերների ներսում ստուգումները կատարվում են շատ թեթև (30 Կբ) գործակալի կամ ձեր սեփական սկրիպտների և հավելվածների կողմից, իսկ ցանցի ստուգումները կատարվում են տարբեր երկրներում okerr սենսորների միջոցով:

okerr-ը ոչ միայն ծրագրային ապահովում է, այլև ծառայություն

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

Եթե մոնիտորինգը թույլ է տալիս փոխհատուցել և քողարկել սերվերների և հավելվածների հուսալիության պակասը, ապա առաջանում է փիլիսոփայական հարց՝ ո՞վ է պահակը: Ինչպե՞ս կարող է մոնիտորինգը մեզ պատմել խնդրի մասին, եթե այն ինքնին «մահացել է» ինչ-ինչ պատճառներով, առանձին կամ ձեր այլ ռեսուրսների հետ միասին (օրինակ՝ տվյալների կենտրոն տանող ալիքն ընկել է): Արտաքին okerr ծառայությունից օգտվելիս - այս խնդիրը լուծված է - դուք ծանուցում կստանաք, նույնիսկ եթե ձեր սերվերների հետ տվյալների ամբողջ կենտրոնը հոսանքազրկված է կամ ենթարկվում է զոմբիների հարձակմանը:

Իհարկե, վտանգ կա, որ okerr սերվերն ինքնին անհասանելի կլինի, դա ճիշտ է (ինչպես գիտեք, հուսալիության 90% -ը միշտ ձեռք է բերվում պարզ և «անվճար», 99% -ը նվազագույն ջանքերով, և յուրաքանչյուր հաջորդ ինը. էքսպոնենցիալ ավելի դժվար): Բայց, առաջին հերթին, դրա հավանականությունն ավելի քիչ է, և երկրորդը, խնդիրը կարող է աննկատ մնալ միայն այն դեպքում, եթե այն համընկնի մեր սերվերների խնդիրների հետ: Եթե մենք ունենք 99.9% հուսալիություն, իսկ դուք ունեք 99.9% (ոչ շատ բարձր թվեր), ապա չբացահայտված ձախողման հավանականությունը 0.1% է 0.1% = 0.0001%: Ձեր հուսալիությանը երեք ինը ավելացնելը գրեթե առանց ջանքերի և առանց ծախսերի շատ լավ է:

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

Okerr-ը ցուցանիշների մասին է

Ցուցանիշը «լամպ» է: Այն ունի երկու հիմնական վիճակ՝ կանաչ (OK) կամ կարմիր (ERR): Նախագիծը պարունակում է բազմաթիվ խմբավորված (օրինակ՝ ըստ սերվերի) ցուցիչներ։ Նախագծի գլխավոր էջում դուք անմիջապես տեսնում եք, որ կա՛մ ամեն ինչ կանաչ է (և դուք կարող եք այն փակել), կա՛մ ինչ-որ բան կարմիր է վառվել և պետք է ուղղել: Այս վիճակների միջև անցում կատարելիս ահազանգ է ուղարկվում: Օրը մեկ անգամ, երբ դուք այն տեղադրում եք, նախագծի ամփոփագիրն ուղարկվում է:

Յուրաքանչյուր okerr ցուցիչ ունի ներկառուցված պայմաններ, որոնց միջոցով այն փոխում է վիճակը (Zabbix-ում դա կոչվում է ձգան): Օրինակ, բեռի միջինը պետք է լինի ոչ ավելի, քան 2 (իհարկե, սա կարգավորելի է): Եվ յուրաքանչյուր ներքին ստուգման համար (բեռնվածության միջին, սկավառակի ազատ, ...) կա պահակ: Եթե ինչ-ինչ պատճառներով մենք նշանակված ժամին հաջող հաստատում չենք ստանում, սխալ է գրանցվում և ծանուցում է ուղարկվում:

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

Իհարկե, հնարավոր է պարզապես պահպանել «տեղեկատվական» ցուցիչներ (ցանցի պատկերը տեսնել մոնիտորինգից), բայց ամեն ինչ արվում է պարզ, հեշտ և արագ ցուցիչներ ստեղծելու համար, հատուկ ավտոմատ մոնիտորինգի և ազդանշաններ ուղարկելու համար:

Նպատակը, որի համար դուք կարգավորում եք okerr-ը, ազդանշանների մեջ է, որպեսզի կարողանաք մեկ րոպեում ցուցիչ ստեղծել, այն կարող է «քնել» մեկ տարի, պարզապես թարմացումներ ընդունել, իսկ երբ մեկ տարի անց ինչ-որ բան կոտրվում է, այն վառվում է և ուղարկում: ահազանգ. Այն րոպեն, երբ դուք ծախսել եք ցուցիչ ստեղծելու վրա, արդյունք տվեց, դուք անմիջապես իմացաք խնդրի մասին՝ ուրիշներից առաջ: Հնարավոր է, որ նրանք ուղղել են, քանի դեռ որևէ մեկը չի նկատել: Ինչ-որ բան, որը արագ բարձրացվում է, չի համարվում ընկած:

Безопасность

Ամոթ կլինի, եթե դուք մոնիտորինգ ստեղծեք հուսալիության բարձրացման համար, բայց արդյունքում ցանցի միջոցով հարձակվում եք, և մոնիտորինգի տարբեր գործիքներում կան բավականին շատ ցանցային խոցելիություններ (Zabbix- ը, Nagios).

Գործակալ (okerrmod փաթեթից okerrupdate) համակարգում աշխատող ոչ թե ցանցային սերվեր է, այլ հաճախորդ։ Հետևաբար, մոնիտորինգի ենթարկվող սերվերի վրա լրացուցիչ բաց նավահանգիստներ չկան, հաճախորդը հեշտությամբ աշխատում է firewall-ի կամ NAT-ի հետևում և շատ դժվար է (ես կասեի «անհնար») ցանցը կոտրելը, քանի որ սկզբունքորեն այն չի լսում ցանցը: վարդակից.

Մոնիտորինգի ամբողջական ծածկույթ

Այժմ մեր կանոնն այն է, որ մենք տեղեկանում ենք բոլոր տեխնիկական խնդիրների մասին okerr-ից: Եթե հանկարծ կանոնը խախտվի (okerr-ը չի զգուշացրել դրա մոտալուտ առաջացման մասին (եթե դա հնարավոր է) կամ որ այն արդեն տեղի է ունեցել), մենք ստուգումներ ենք ավելացնում okerr-ին:

Արտաքին ստուգումներ

Բավական բնորոշ հավաքածու.

սուլոց
http կարգավիճակը
SSL վկայագրի վավերականության և թարմության ստուգում (կզգուշացնի, եթե դրա ժամկետը լրանա)
բացեք TCP պորտը և դրա վրա դրոշակը
http grep (էջը [չպետք է] պարունակի որոշակի տեքստ)
sha1 հաշ՝ էջի փոփոխությունները որսալու համար:
DNS (DNS գրառումը պետք է ունենա որոշակի արժեք)
WHOIS (կզգուշացնի, եթե տիրույթը պատրաստվում է վատանալ)
Antispam DNSBL (հյուրընկալողի ստուգում միանգամից 50+ հակասպամ սև ցուցակների դեմ)

Ներքին ստուգումներ

Նաև բավականին ստանդարտ հավաքածու (բայց հեշտությամբ ընդարձակվող):

df (ազատ սկավառակի տարածություն)
միջին ծանրաբեռնվածություն
opentcp (բացեք TCP լսողական վարդակները. կտեղեկացնի, եթե ինչ-որ բան սկսվել է կամ խափանվել)
uptime - պարզապես սպասարկիչի վրա աշխատելու ժամանակ: Կտեղեկացնի, եթե այն փոխվել է (այսինքն՝ սերվերը գերբեռնված է)
client_ip
dirsize - մենք օգտագործում ենք այն հետևելու, երբ մեր վիրտուալ մեքենայի rootf-ները գերազանցում են թույլատրելի չափը, առանց խիստ սահմանափակումների ներմուծելու և օգտագործողի տնային գրացուցակների չափը:
դատարկ և ոչ դատարկ - վերահսկել ֆայլերը, որոնք պետք է դատարկ լինեն (կամ դատարկ չլինեն): Օրինակ, բուն okerr սերվերի սխալների գրանցամատյանը պետք է դատարկ լինի, և եթե դրա մեջ նույնիսկ տող լինի, ես ծանուցում կստանամ և կստուգեմ։ Բայց mail.log-ը փոստի սերվերի վրա ՉՊԵՏՔ դատարկ լինի (պտտվելուց հետո N րոպե): Եվ երբեմն այն դատարկ էր մեզ համար համակարգի թարմացումից հետո, երբ logrotate-ը չէր կարող ճիշտ վերագործարկել rsyslog-ը:
linecount - ֆայլի տողերի քանակը (ինչպես wc -l): Մենք այն օգտագործում ենք որպես դատարկի ավելի մեղմ փոխարինում, երբ սխալների գրանցամատյանը դեռ կարող է աճել, բայց միայն դանդաղ (օրինակ, Googlebot-ը հարվածում է որոշ փակ էջերի)։ 2 րոպեում կա 20 տողի սահմանաչափ։ Եթե ավելի բարձր լինի, ահազանգ կլինի

Հետաքրքիր ներքին ստուգումներ

Եթե մինչ այս կարդում էիք «անկյունագծով», ապա այժմ ավելի հետաքրքիր կլինի ավելի ուշադիր կարդալ:

կրկնօրինակումներ

Վերահսկում է պահուստները գրացուցակում: Մեր պահուստային ֆայլերն ունեն այնպիսի անուններ, ինչպիսիք են «ServerName-20200530.tar.gz»: okerr-ի յուրաքանչյուր սերվերի համար ստեղծվում է ServerName-DATE.tar.gz ցուցիչը (փաստացի ամսաթիվը փոխվում է «DATE» տողի): Մշտադիտարկվում է նաև թարմ կրկնօրինակի առկայությունը և դրա չափը (օրինակ, այն չի կարող պակաս լինել նախորդ կրկնօրինակի 90%-ից):

Ի՞նչ պետք է արվի, որպեսզի նոր կրկնօրինակը սկսի հետևել այն բանից հետո, երբ մենք սկսել ենք այն ստեղծել և տեղադրել այն այս գրացուցակում: Ոչինչ! Սա շատ հարմար մոտեցում է, երբ պետք է «ոչինչ» անել, քանի որ.

«Ոչինչ» անելը բավականին արագ է, այն խնայում է ժամանակը
Դժվար է մոռանալ «ոչինչ» անել
Դժվար է սխալ «ոչինչ» անել՝ սխալմամբ։ Ոչինչ ամենահուսալի մեթոդ չէ

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

maxfilesz

Հետևում է ամենամեծ ֆայլերի չափերին (սովորաբար՝ /var/log/*): Սա թույլ է տալիս բռնել անկանխատեսելի խնդիրներ, օրինակ՝ կոպիտ ուժային գաղտնաբառեր կամ սպամ ուղարկել սերվերի միջոցով:

runstatus/runline

Սրանք երկու կարևոր վստահված անձի մոդուլներ են սերվերի վրա այլ ծրագրեր գործարկելու համար: Runstatus-ը հաղորդում է ծրագրի ելքի կոդը ցուցիչին: Օրինակ, okerr-ը չի (պահանջում) մոդուլ՝ ստուգելու, որ systemd ծառայություններն աշխատում են: Դա արվում է runstatus-ի միջոցով (տես ստորև): Runline - հաղորդում է սերվերին այն գիծը, որը արտադրում է ծրագիրը: Օրինակ, temp_RUN="cat /sys/class/thermal/thermal_zone0/temp" Runline կոնֆիգուրայում մեր սերվերի վրա ստեղծում է ցուցիչ սերվերի անունը: temp պրոցեսորի ջերմաստիճանի հետ:

SQL

Կատարում է թվային հարցում MySQL-ում և արդյունքը հաղորդում ցուցիչին: Պարզ դեպքում, դուք կարող եք անել, օրինակ, «SELECT 1» - սա կստուգի, որ DBMS-ն ամբողջությամբ աշխատում է:

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

Նկատի ունեցեք, որ կարևոր չէ, թե ինչ անկանխատեսելի պատճառով է դա տեղի ունեցել.

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

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

Տրամաբանական ցուցանիշներ

Թույլ է տալիս օգտագործել բուլյան արտահայտություններ (Python շարահյուսություն) մոդուլի միջոցով վավերացնել(հոդված Habré-ի մասին) Նախագծի և դրա ցուցանիշների տվյալները հասանելի են արտահայտման համար: Օրինակ, վերևում SQL-ի ստուգման մասին գլխում դուք կարող եք նկատել թույլ կետ. ցերեկը մենք կարող ենք ժամում ունենալ 100 վաճառք, իսկ գիշերը՝ 20, և դա սովորական է, խնդիր չէ: Ինչ պետք է անեմ? Ցուցանիշը գիշերը անընդհատ խուճապի կմատնվի։

Դուք կարող եք ստեղծել երկու ցուցանիշ՝ օր ու գիշեր: Երկուսն էլ դարձրեք «լուռ» (նրանք ահազանգեր չեն ուղարկի): Եվ ստեղծեք տրամաբանական ցուցիչ, որը պահանջում է, որ օրվա ցուցիչը լավ լինի մինչև 20:00-ն, իսկ 20:00-ից հետո բավական է, որ գիշերային ցուցիչը լավ լինի:

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

Նաև հնարավոր է սահմանել աշխատանքի թույլատրելի ժամը, օրինակ՝ առավոտյան ժամը 3-ից մինչև 5-ը։ Մեզ չի հետաքրքրում, թե այս ընթացքում սերվերներն ու կայքերը խափանում են: Բայց ժամը 5:00-ին նրանք պետք է աշխատեն։ Եթե նրանք չեն աշխատում որևէ այլ ժամանակ, զգուշացրեք: Տրամաբանական ցուցիչը նաև թույլ է տալիս հաշվի առնել սերվերի ավելորդությունը։ Եթե ունեք 5 վեբ սերվեր, ապա ադմինները կարող են ցանկացած պահի անջատել 1-2 սերվեր: Բայց եթե մարտում 3 սերվերից 5-ից քիչ լինի, ահազանգ կլինի:

Վերոնշյալ օրինակները oker ֆունկցիաներ չեն, այլ ոչ թե որոշ գործառույթներ, որոնք պետք է ակտիվացվեն և կազմաձևվեն: Okerra-ն չունի այս բոլոր գործառույթները, բայց կա տրամաբանական մոդուլ, որը թույլ է տալիս իրականացնել այս ֆունկցիոնալությունը (մոտավորապես ինչպես ծրագրավորման լեզվում. եթե ունենք թվաբանական օպերատորներ, ապա մեզ հատուկ ֆունկցիա պետք չէ 20% ԱԱՀ-ի հաշվարկման համար: լեզվից, դուք միշտ կարող եք դա անել ինքներդ, որպեսզի այն համապատասխանի ձեր կարիքներին):

Logic Indicator-ը, հավանաբար, okerr-ի համեմատաբար բարդ թեմաներից է, բայց լավ նորությունն այն է, որ դուք ստիպված չեք լինի տիրապետել այն մինչև դրա կարիքը չկա: Բայց միևնույն ժամանակ նրանք մեծապես ընդլայնում են հնարավորությունները՝ միաժամանակ համակարգը ինքնին բավականին պարզ պահելով։

Ձեր սեփական չեկերի ավելացում

Ես իսկապես կցանկանայի փոխանցել այն միտքը, որ okerr-ը բոլոր առիթների համար հազարավոր պատրաստի չեկերի հավաքածու չէ, այլ ընդհակառակը, - առաջին հերթին, պարզ շարժիչ՝ սեփական չեկեր ստեղծելու պարզ ունակությամբ: Okerr-ում ձեր սեփական չեկերի ստեղծումը հաքերների, համակարգի համահեղինակ մշակողների կամ առնվազն առաջադեմ okerr օգտատերերի խնդիր չէ, այլ հնարավոր խնդիր է ցանկացած ադմինիստրատորի համար, ով առաջին անգամ տեղադրել է Linux-ը մեկ ամիս առաջ:

Նվազագույն աշխատավարձի ստուգումները կատարվում են մոդուլի միջոցով գործարկման կարգավիճակը:

Այս տողը կազմաձևում գործարկման կարգավիճակը կտեղեկացնի ձեզ, եթե /bin/true-ը հանկարծ չսկսվի կամ վերադարձնի 0-ից այլ բան:

true_OK=/bin/true

Ընդամենը մեկ տող, և ահա մենք արդեն մի փոքր ենք ընդլայնվել են ֆունկցիոնալությունը okerr.

Նույնիսկ նման ստուգումն արդեն ունի իր արժեքը՝ եթե հանկարծ ձեր սերվերը խափանվի, ապա okerr սերվերի համապատասխան ցուցիչը ժամանակին չի թարմացվի, և ժամանակն անցնելուց հետո կհայտնվի ահազանգ։

Այս ստուգումը կտեղեկացնի, որ apache2 սերվերը խափանվել է (դե, դուք երբեք չգիտեք ...):

apache_OK="systemctl is-active --quiet apache2"

Այսպիսով, եթե դուք խոսում եք ծրագրավորման որևէ լեզվով և գոնե կարող եք գրել shell scripts, ապա արդեն կարող եք ավելացնել ձեր սեփական չեկերը:

Ավելի դժվար - դուք կարող եք գրել (ցանկացած լեզվով) ձեր սեփական մոդուլը okerrmod-ի համար: Ամենապարզ դեպքում այն ունի հետևյալ տեսքը.

#!/usr/bin/python3

print("STATUS: OK")

Շատ դժվար չէ՞։ Մոդուլը պետք է կատարի ստուգումն ինքնին և արդյունքները թողարկի STDOUT: Ավելի բարդ մոդուլը տալիս է, օրինակ, սա.

$ okerrmod --dump df
NAME: pi:df-/
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 49.52%, 13.9G/28.2G used, 13.0G free
STATUS: 49.52

NAME: pi:df-/boot
TAGS: df
METHOD: numerical|maxlim=90
DETAILS: 84.32%, 53.1M/62.9M used, 9.9M free
STATUS: 84.32

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

Կա Telegram բոտ @OkerrBot. Պետք չէ ձեր հեռախոսը խճճել առանձին հավելվածներով (ինձ դուր չի գալիս, որ Պյատերոչկայի համար ձեզ հարկավոր է մի ծրագիր քարտեզով, Lenta-ի համար՝ մեկ այլ, MTS-ի համար՝ երրորդ և այլն բոլորի համար, բոլորի համար, բոլորի համար): Բավական է մեկ հեռագիր։ Telegram-ի միջոցով կարող եք անմիջապես ստանալ ծանուցումներ, ստուգել նախագծի կարգավիճակը և հրաման տալ՝ նորից ստուգել բոլոր խնդրահարույց ցուցանիշները։ Մենք դուրս եկանք թատրոնից/ինքնաթիռից, երկու ժամ մատը զարկերակի վրա չպահեցինք, միացրինք հեռախոսը, սեղմեցինք չաթբոտի մեկ կոճակը և համոզվեցինք, որ ամեն ինչ լավ է։

Կարգավիճակի էջեր

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

Պատկերացրեք մի իրավիճակ. օգտատերը ցանկանում է ինչ-որ բան անել, դիտել տեղեկատվություն կամ պատվիրել, և ինչ-որ բան չի ստացվում: Նա չգիտի, թե ինչ է կատարվում, ում կողմից է խնդիրը և երբ այն կլուծվի։ Միգուցե ձեր ընկերությունն ուղղակի ունի ոչ ֆունկցիոնալ կայք: Թե՞ վեց ամիս առաջ է կոտրվել ու երկու տարի հետո կշտկվի։ Բայց հիմա պետք է սառնարան գնել, այն արդեն սայլի մեջ է... Եվ բոլորովին այլ հարց է, երբ մարդը տեսնում է, որ քեզ հետ ինչ-որ բան այն չէ (համենայն դեպս պարզ է, որ խնդիրն իր կողմը չէ), որ Խնդիրը հայտնաբերվել է, որ դուք արդեն աշխատում եք դրա վրա, և գուցե նույնիսկ գրեք ուղղման մոտավոր ժամանակը: Օգտագործողը կարող է բաժանորդագրվել և ստանալ էլ.

Խնդիրները և պարապուրդը պատահում են բոլորի հետ: Սակայն օգտատերերն ու գործընկերներն ավելի շատ են վստահում նրանց, ովքեր ավելի թափանցիկ և պատասխանատու են այս հարցում իրենց մոտեցումներում:

Այստեղ 10 այլ նախագծերի վերանայում, որոնք թույլ են տալիս ստեղծել կարգավիճակի էջեր. Ահա օրինակներ, թե ինչպիսի տեսք ունեն այս նախագծի էջերը Python и Dropbox. okerr կարգավիճակի էջ.

Failover

Որպեսզի այս հոդվածը չերկարացնեմ, ես ևս մեկ անգամ կանդրադառնամ իմ նախորդ հոդվածին. Պարզ ձախողում կայքի համար . Եթե դուք կարող եք կրկնօրինակ սերվեր ստեղծել, ապա օգտագործելով failover, դուք հիմնականում երկար ժամանակ չեք ունենա. հենց որ խնդիրը հայտնաբերվի, օգտվողներն ավտոմատ կերպով կվերահղվեն աշխատող պահուստային սերվեր: Եվ ինձ թվում է, որ սա շատ հետաքրքիր, վառ հատկանիշ է, որը հազվադեպ է հասանելի որևէ տեղ:

Համակարգի ցածր պահանջներ

Okerr սերվերների համար մենք օգտագործում ենք 2 Գբ օպերատիվ հիշողություն ունեցող մեքենաներ: Ցանցային սենսորների համար նույնիսկ 512 Մբ է բավարար: Հաճախորդի մասը հիմնականում գրեթե զրոյական է: (Պլաստիկ տոպրակ okerrupdate կշռում է 26 Կբ, բայց պահանջում է Python3 և ստանդարտ գրադարաններ): Հաճախորդը աշխատում է cron script-ից, ուստի այն ունի զրոյական մշտական հիշողության սպառում: Մեր կողմից մոնիտորինգի ենթարկված մեքենաների թվում մենք ունենք սենսորներ (գերէժան VPS 512 Մբ օպերատիվ հիշողություն) և Raspberry Pi: Դա հնարավոր է նույնիսկ առանց հաճախորդի մասի ուղարկել թարմացումներ curl-ի միջոցով! (տես ներքեւում)

Սա հաշվի առնելով - okerr, հավանաբար առավել ազատ Մոնիտորինգի համակարգ առկաներից, քանի որ նույնիսկ մեկ այլ անվճար բաց կոդով համակարգ օգտագործելու համար, ինչպիսիք են Zabbix-ը կամ Nagios-ը, պետք է ռեսուրսներ (սերվեր) հատկացնել դրան, և սա արդեն գումար է: Բացի այդ, որոշ սերվերի սպասարկում դեռևս պահանջվում է: okerr-ով այս հատվածը կարելի է հեռացնել: Կամ պետք չէ հեռացնել այն և օգտագործել ձեր սեփական սերվերը՝ կախված նրանից, թե ինչն է ձեզ ամենաշատը դուր գալիս.

API և ինտեգրում սեփական ծրագրային ապահովման մեջ

Պարզ և բաց ճարտարապետություն. okerr-ն ունի բավականին պարզ մեկը API, որի հետ հեշտ է աշխատել։ Պետք է ստեղծել 1000 ցուցանիշ: 3-4 տողից բաղկացած մեկ կեղևի սցենարը դա կանի: Պետք է վերակազմավորե՞լ 1000 ցուցիչ: Դա նույնպես շատ հեշտ է: Օրինակ, մենք ցանկանում ենք կրկնակի ստուգել մեր բոլոր HTTPS վկայագրերը ռուսական սենսորից.

#!/bin/sh

for indicator in `okerrclient --api-filter sslcert`
do
    echo set location for $indicator
    okerrclient --api-set location=ru retest=1 --name $indicator
done

Դուք կարող եք թարմացնել ցուցիչը՝ օգտագործելով մեր հաճախորդի մոդուլը, նույնիսկ առանց դրա, պարզապես curl-ի միջոցով:

# short and nice (using okerrupdate and config file)
$ okerrupdate MyIndicator OK

# only curl is enough!
$ curl -d 'textid=MyProject&name=MyIndicator&secret=MySecret&status=OK' https://bravo.okerr.com/

Դուք կարող եք թարմացնել ցուցիչները անմիջապես ձեր ծրագրից: Օրինակ՝ ուղարկելով սրտի բաբախման ազդանշաններ, որպեսզի okerr-ն իմանա, որ այն աշխատում է և ազդանշան է տալիս, եթե այն խափանվի կամ սառչի: Ի դեպ, okerr-ի բաղադրիչներն անում են հենց դա՝ okerr-ը վերահսկում է ինքն իրեն, և գրեթե ցանկացած մոդուլի խնդիրները կհայտնաբերվեն և կստեղծեն ահազանգ խնդրի մասին: (Իսկ սրա «գրեթե»-ի դեպքում դրանք ստուգվում են մեկ այլ սերվերից)

Ահա կոդը (պարզեցված) մեր հեռագրային բոտում.

from okerrupdate import OkerrProject, OkerrExc

op = OkerrProject()
uptimei = op.indicator("{}:telebot_uptime".format(hostname))
...
uptimei.update('OK', 'pid: {} Uptime: {} cmds: {}'.format(
        os.getpid(), dhms(uptime), commands_cnt))

Կա Python ծրագրերից ցուցիչների թարմացման գրադարան okerrupdate, ցանկացած այլ լեզուների համար գրադարաններ չկան, բայց կարող եք կամ զանգահարել okerrupdate սկրիպտը կամ կատարել HTTP հարցում okerr սերվերին:

Ինչպես է մեզ օգնում okerr-ը

Օկերը փոխեց մեր կյանքը։ Իսկապես. Միգուցե մոնիտորինգի մեկ այլ համակարգ կարող է անել նույնը, բայց okerr-ի հետ աշխատելը մեզ համար հեշտ և պարզ է, և այն ունի բոլոր այն գործառույթները, որոնք մեզ անհրաժեշտ էին (մենք ավելացրեցինք այն, ինչ չուներ): Ի դեպ, եթե որոշ գործառույթներ բացակայում են, հարցրեք և ես կավելացնեմ դրանք (չեմ խոստանում, բայց ուզում եմ, որ okerr-ը լինի փոքր-միջին նախագծերի մոնիտորինգի լավագույն համակարգը): Կամ ավելի լավ է, ինքներդ ավելացրեք այն, դա հեշտ է:

Մեզ հաջողվեց ապրել «սովորել բոլոր խնդիրների մասին կեռայից» սկզբունքով։ Եթե հանկարծ խնդիր առաջանա, որի մասին մենք չենք իմացել okerr-ից, մենք ստուգում ենք ավելացնում okerr-ին: (այս դեպքում «մենք» ասելով նկատի ունեմ մեզ՝ որպես համակարգի օգտագործողներ, այլ ոչ թե համահեղինակ մշակողներ): Սկզբում դա սովորական էր, բայց հիմա շատ հազվադեպ է դարձել։

Մոնիտորինգ

okerr-ի միջոցով մենք վերահսկում ենք գրանցամատյանների չափերը բոլոր սերվերների վրա: Անհնար է, իհարկե, մտածված կերպով կարդալ մատյանից յուրաքանչյուր տողը ձեր աչքերով, բայց պարզապես աճի տեմպերի մոնիտորինգն արդեն շատ բան է տալիս: Սրա միջոցով մենք հայտնաբերեցինք սպամի նամակագրություն և գաղտնաբառերի կոպիտ որոնումներ, և երբ որոշ հավելվածներ «խելագարվում են», նրանց մոտ ինչ-որ բան չի ստացվում և նրանք կրկնում են դա նորից ու նորից (ամեն անգամ մի քանի տող ավելացնելով մատյանում։ )

SSL վկայագրեր. Գործարկումից գրեթե անմիջապես հետո LetsEncrypt- ը մեր հաճախորդը սկսեց անվճար SSL վկայագրեր տրամադրել իր հաճախորդներին (մոտ հազարը): Եվ պարզվեց, որ դա պարզապես դժոխք է վարչարարության համար: Փաստն այն է, որ կայքերը «կենդանի են», հաճախորդները պարբերաբար խնդրում են նրանց ինչ-որ բան անել, ծրագրավորողները դա անում են: Նրանք կարող են ամբողջովին ազատորեն փոխանցել կայքը մեկ այլ DocumentRoot, օրինակ: Կամ ավելացրեք անվերապահ Rewrite-ը virtualhost-ի կազմաձևում: Բնականաբար, սրանից հետո վկայականների ավտոմատ թարմացումը խափանում է։ Այժմ մենք ունենք բոլոր SSL հոսթերն ավտոմատ կերպով ավելացված okerr-ին փաթեթից մեր մեկ այլ օգտակար կոմունալ ծրագրերի միջոցով a2conf. Եկեք ուղղակի գործարկենք a2okerr.py — և եթե սերվերում հայտնվեն մի քանի նոր կայքեր, դրանք ավտոմատ կերպով կհայտնվեն okerr-ում: Եթե հանկարծ ինչ-ինչ պատճառներով վկայականը չերկարացվի, վկայագրի ժամկետի ավարտից երեք շաբաթ առաջ, մենք տեղյակ ենք, և մենք կպարզենք, թե ինչու այն չի թարմացվում, այդպիսի շուն: a2certbot.py նույն փաթեթից - դա շատ է օգնում դրանում (այն անմիջապես ստուգում է ամենահավանական խնդիրները և գրում է այն, ինչ լավ է ստուգվել, և որտեղ, ամենայն հավանականությամբ, խնդիր կա):

Մենք վերահսկում ենք մեր բոլոր տիրույթների գործողության ժամկետը: Եվ մեր բոլոր փոստի սերվերները, որոնք փոստ են ուղարկում, նույնպես ստուգվում են 50+ տարբեր սև ցուցակներում: (Եվ երբեմն նրանք ընկնում են նրանց մեջ): Ի դեպ, դուք գիտեի՞ք, որ Google mail սերվերները նույնպես սև ցուցակում են: Պարզապես ինքնափորձարկման համար մենք ավելացրեցինք mail-wr1-f54.google.com-ը վերահսկվող սերվերներին, և այն դեռ գտնվում է SORBS-ի սև ցուցակում: (Սա «հակասպամերների» արժեքի մասին է)

Կրկնօրինակներ - Ես արդեն գրել եմ վերեւում, թե որքան հեշտ է դրանք վերահսկել okerr-ով: Բայց մենք վերահսկում ենք և՛ վերջին պահուստները մեր սերվերի վրա, և՛ (օգտագործելով առանձին օգտակար ծրագիր, որն օգտագործում է okerr) կրկնօրինակները, որոնք մենք վերբեռնում ենք Amazon Glacier: Եվ, այո, ժամանակ առ ժամանակ խնդիրներ են լինում։ Զարմանալի չէ, որ նրանք դիտում էին:

Մենք օգտագործում ենք էսկալացիայի ցուցանիշը: Այն ցույց է տալիս, եթե որոշ խնդիր երկար ժամանակ չի շտկվել: Իսկ ես ինքս, երբ ինչ-որ խնդիրներ եմ լուծում, երբեմն կարող եմ մոռանալ դրանց մասին։ Էսկալացիան լավ հիշեցում է, նույնիսկ եթե դուք ինքներդ եք վերահսկում:

Ընդհանուր առմամբ, ես կարծում եմ, որ մեր աշխատանքի որակը բարձրացել է մեծության կարգով: Գրեթե չկա պարապուրդ (կամ հաճախորդը ժամանակ չունի դա նկատելու: Ուղղակի շշ!), մինչդեռ աշխատանքի ծավալը փոքրացել է, իսկ աշխատանքային պայմանները՝ ավելի հանգիստ: Վթարային աշխատանքներից՝ ժապավենով անցքեր կարկատելով, անցել ենք հանգիստ և չափված աշխատանքի, երբ շատ խնդիրներ կանխատեսվում են և ժամանակ կա դրանք կանխելու։ Նույնիսկ պատահած խնդիրները նույնպես ավելի հեշտ են շտկվել. նախ՝ մենք դրանց մասին տեղեկանում ենք մինչև հաճախորդների խուճապը, և երկրորդ՝ հաճախ է պատահում, որ խնդիրը կապված է վերջին աշխատանքի հետ (մինչ ես մի բան էի անում, մյուսը կոտրեցի) այնպես որ շոգ է Հետքերի համար ավելի հեշտ է զբաղվել դրա հետ:

Բայց մեկ այլ դեպք էլ կար...

Գիտեի՞ք, որ հանրաճանաչ Debian 9-ում (Stretch) այնպիսի հայտնի փաթեթ, ինչպիսին phpmyadmin-ն է, դեռևս (շատ ամիսներ շարունակ) գտնվում է խոցելի կարգավիճակում: (CVE-2019-6798- ը). Երբ հայտնվեց խոցելիությունը, մենք արագ ծածկեցինք այն տարբեր ձևերով: Բայց ես okerr-ում կարգավորեցի անվտանգության հետագծող էջի մոնիտորինգը, որպեսզի իմանամ, թե երբ դուրս կգա «գեղեցիկ» լուծումը (բովանդակության SHA1 գումարի միջոցով): Ցուցանիշը մի քանի անգամ ցնցեց ինձ, էջը փոխվեց, բայց ինչպես տեսնում եք, այն դեռ (2019 թվականի հունվարից սկսած) չի ցույց տալիս, որ խնդիրը լուծված է: Միգուցե, ի դեպ, ինչ-որ մեկը գիտի, թե որն է խնդիրը, որ նման կարևոր փաթեթը դեռևս մեկ տարուց ավելի խոցելի է։

Մեկ այլ անգամ նմանատիպ իրավիճակում. SSH-ում խոցելիությունից հետո անհրաժեշտ էր թարմացնել բոլոր սերվերները: Եվ երբ դուք խնդիր եք դնում, դուք պետք է վերահսկեք կատարումը: (Ենթակաները հակված են սխալ հասկանալու, մոռանալու, շփոթվելու և սխալվելու): Հետևաբար, նախ մենք ավելացրինք SSH տարբերակի ստուգում okerr-ին բոլոր սերվերների վրա, և okerr-ի միջոցով համոզվեցինք, որ թարմացումները տարածված են բոլոր սերվերների վրա: (Հարմար է. Ես ընտրեցի այս տեսակի ցուցիչ, և դուք անմիջապես կարող եք տեսնել, թե որ սերվերն ինչ տարբերակ ունի): Երբ մենք համոզվեցինք, որ առաջադրանքն ավարտված է բոլոր սերվերների վրա, մենք հեռացրինք ցուցիչները։

Մի երկու անգամ եղել է իրավիճակ, երբ ինչ-որ խնդիր է առաջանում, հետո ինքնըստինքյան անցնում։ (հավանաբար բոլորին ծանոթ): Մինչ դուք նկատում եք, մինչև ստուգեք, և ստուգելու ոչինչ չկա, ամեն ինչ արդեն լավ է աշխատում: Բայց հետո նորից կոտրվում է: Մենք դա պատահեց, օրինակ, ապրանքների հետ, որոնք մենք վերբեռնեցինք Amazon Marketplace (MWS): Ինչ-որ պահի բեռնված գույքագրումը սխալ էր (ապրանքների սխալ քանակություններ և սխալ գներ): Մենք դա պարզեցինք: Բայց դա պարզելու համար կարևոր էր անմիջապես պարզել խնդրի մասին։ Ցավոք, MWS-ը, ինչպես Amazon-ի բոլոր ծառայությունները, մի փոքր դանդաղ է, այնպես որ միշտ ուշացում կար, բայց, այնուամենայնիվ, մենք կարողացանք գոնե մոտավոր կերպով հասկանալ խնդրի և այն առաջացնող սցենարների միջև կապը (մենք ստուգեցինք, խրվեցինք այն okerr-ին և ստուգեց այն՝ ստանալով անմիջապես ահազանգ):

Վերջերս հավաքածուին մի հետաքրքիր դեպք է ավելացրել եվրոպական մեծ և թանկարժեք հոսթերը, որից օգտվում է մեր հաճախորդը։ Հանկարծ մեր ԲՈԼՈՐ սերվերները անհետացան ռադարից: Նախ, հաճախորդն ինքը (ավելի արագ, քան okerra!) նկատեց, որ այն կայքը, որի հետ աշխատում էր, չի բացվում, և դրա մասին տոմս պատրաստեց։ Բայց ոչ միայն մեկ կայք է խափանվել, այլ բոլորը: (Նատաշա, մենք ամեն ինչ գցեցինք): Այստեղ Okerr-ը սկսեց ուղարկել երկար ոտքի փաթաթումներ բոլոր ցուցիչներով, որոնք վառվում էին նրա համար: Խուճապ, խուճապ, մենք վազում ենք շրջանաձև (այլ ի՞նչ կարող ենք անել): Հետո ամեն ինչ բարձրացավ։ Ստացվում է, որ տվյալների կենտրոնում սովորական սպասարկում է եղել (տարիները մեկ անգամ) և, իհարկե, պետք է զգուշացնեինք։ Բայց նրանց հետ ինչ-որ խնդիր է տեղի ունեցել, և նրանք մեզ չեն զգուշացրել։ Դե, ավելի շատ սրտի կաթվածներ, ավելի քիչ ինֆարկտներ: Բայց ամեն ինչ վերականգնվելուց հետո դուք պետք է կրկնակի ստուգեք ամեն ինչ: Չեմ պատկերացնում, թե ինչպես կանեի դա իմ ձեռքերով։ Okerr-ը ամեն ինչ փորձարկեց մի քանի րոպեում: Պարզվեց, որ սերվերների մեծ մասը պարզապես ժամանակավորապես անհասանելի էր, բայց նրանք աշխատում էին: Ոմանք ծանրաբեռնված էին, բայց նաև ոտքի կանգնեցին, ինչպես որ պետք էր։ Բոլոր կորուստներից մենք կորցրինք երկու կրկնօրինակներ, որոնք, ըստ թագի, պետք է ստեղծվեին և բեռնվեին այս լիքը բանանի ընթացքի ժամանակ: Ես նույնիսկ չանհանգստացա ստեղծել դրանք, ընդամենը մեկ օր անց ահազանգեր եկան, որ ամեն ինչ կարգին է, կրկնօրինակներ են հայտնվել: Ինձ շատ է դուր գալիս այս օրինակը, քանի որ okerr-ը շատ օգտակար էր մի իրավիճակում, որի մասին նախապես չէինք էլ մտածել, բայց մոնիտորինգի նպատակը դա է՝ դիմակայել անկանխատեսելիին։

Okerr սենսորների համար մենք օգտագործում ենք հնարավոր ամենաէժան հոսթինգը (որտեղ որակն ու հուսալիությունը կարևոր չեն, դրանք ապահովագրում են միմյանց): Այսպիսով, մենք վերջերս գտանք շատ լավ հոստինգ և սուպեր էժան, հենանիշերը հիանալի են: Բայց... երբեմն պարզվում է, որ վիրտուալ մեքենայից ելքային կապերը կատարվում են մեկ այլ (հարեւան) IP-ից։ Հրաշքներ. Client_ip մոդուլի հետ https://diagnostic.opendns.com/myip սխալ IP է ստանում: Իսկ ցուցիչի սերվերային լոգերից պարզ է դառնում, որ թարմացումը նույնպես եկել է այս հարեւան IP-ից։ Եկեք հիմա զբաղվենք աջակցությամբ: Լավ է, որ մենք սա նկատեցինք խաղաղ ժամանակ։ Բայց, օրինակ, հաճախ է պատահում, որ մուտքը գրանցվում է IP-ի սպիտակ ցուցակի համաձայն, և եթե սերվերը երբեմն թարթում է այսպես կարճ ժամանակով, ապա կարող եք փորձել շատ երկար ժամանակ բռնել այս խնդիրը:

Դե, ևս մեկ բան, քանի որ մենք խոսում ենք VPS հոստինգի մասին, մենք միշտ օգտագործում ենք էժանները (hetzner, ovh, scaleway). Ինձ շատ է դուր գալիս թե՛ հենանիշների, թե՛ կայունության առումով։ Մենք նաև օգտագործում ենք շատ ավելի թանկ Amazon EC2-ը այլ նախագծերի համար: Այսպիսով, okerr-ի շնորհիվ մենք ունենք մեր տեղեկացված կարծիքը։ Երկուսն էլ ընկնում են։ Եվ ես չէի ասի, որ մեր դիտարկումների երկար ժամանակահատվածում hetzner-ի նման էժան հոսթինգները նկատելիորեն ավելի քիչ կայուն էին, քան EC2-ը: Հետևաբար, եթե կապված չեք Amazon-ի այլ հնարավորությունների հետ, ինչո՞ւ ավելի շատ վճարել: 🙂

Ինչ հաջորդ?

Եթե այս փուլում ես դեռ չեմ վախեցրել ձեզ Okerr-ից, ապա փորձեք այն: Դուք կարող եք անմիջապես անցնել այս հղումով okerr դեմո հաշիվ (Սեղմեք հիմա!) Բայց հիշեք, որ բոլորի համար կա միայն մեկ ցուցադրական հաշիվ, այնպես որ, եթե ինչ-որ բան անեք, նույն հաշվում գտնվող մեկ ուրիշը կարող է միաժամանակ խանգարել ձեզ: Կամ (ավելի լավ) գրանցվել հղման միջոցով offsite okerr - ամեն ինչ պարզ է, առանց SMS-ի: Եթե չեք սիրում օգտագործել ձեր իրական էլ. getnada.com). Նման հաշիվները կարող են ժամանակի ընթացքում ջնջվել, բայց դրանք լավ կլինեն թեստավորման համար:

Գրանցվելուց հետո ձեզանից կպահանջվի վերապատրաստում անցնել (կատարել մի քանի ոչ շատ դժվար ուսումնական առաջադրանքներ): Նախնական սահմանները շատ փոքր են, բայց վերապատրաստման կամ մեկ սերվերի համար դրանք բավարար են։ Դասընթացն ավարտելուց հետո սահմանաչափերը (օրինակ՝ ցուցիչների առավելագույն քանակը) կավելացվեն։

Փաստաթղթերից՝ առաջին հերթին ՎԻԿԻ սերվերի և հաճախորդի կողմից (okerrupdate վիքի) Բայց եթե ինչ-որ բան անհասկանալի է, գրեք support (at) okerr.com-ին կամ թողեք տոմս, մենք կփորձենք ամեն ինչ արագ լուծել:

Եթե դուք լրջորեն օգտագործում եք այն, և այս ավելացված սահմանաչափերը բավարար չեն, գրեք աջակցության համար, և մենք այն կավելացնենք (անվճար):

Ցանկանու՞մ եք տեղադրել okerr սերվերը ձեր սերվերի վրա: Այստեղ okerr-dev պահոց. Խորհուրդ ենք տալիս տեղադրել մաքուր վիրտուալ մեքենայի վրա, այնուհետև կարող եք պարզապես դա անել տեղադրման սցենարով: Ձեր վիրտուալ մեքենայի վրա՝ ոչ մի սահմանափակում :-): Դե, էլի, եթե ինչ-որ բան պատահի, մենք միշտ կփորձենք օգնել։

Մենք ցանկանում ենք, որ այս նախագիծը դուրս գա, որպեսզի աշխարհը մեր շնորհիվ ավելի հուսալի դառնա։ Ազատ ծրագրային ապահովման և ծառայությունների շնորհիվ աշխարհը դարձել է ավելի բարեկամական և ավելի դինամիկ զարգանում: Աղբյուրները կարող են պահվել անվճար github-ում, փոստի համար կարող եք օգտագործել անվճար gmail: Մենք օգտագործում ենք անվճար թարմ ցանցեր աջակցության համար։ Դրանցից որևէ մեկի համար ձեզ հարկավոր չէ վճարել սերվերների համար, ձեզ հարկավոր չէ ներբեռնել և կարգավորել, և ձեզ հարկավոր չէ լուծել տարբեր գործառնական խնդիրներ: Յուրաքանչյուր նոր նախագիծ, յուրաքանչյուր թիմ անմիջապես ունի փոստ, պահեստներ և CRM: Եվ այս ամենը շատ որակյալ է և անվճար և անմիջապես։ Մենք ցանկանում ենք, որ նույնը լինի մոնիտորինգի դեպքում. փոքր ընկերությունները և նախագծերը կարող են անվճար օգտագործել okerr-ը և նույնիսկ ծննդյան և աճի փուլում ունենալ մեծահասակների համար լուրջ նախագծերի հուսալիություն:

Source: www.habr.com

Okerr հիբրիդային մոնիտորինգի համակարգի ակնարկ