VictoriaMetrics-ը արագ և մասշտաբային DBMS է տվյալների պահպանման և մշակման համար ժամանակային շարքի տեսքով (գրառումը ձևավորում է ժամանակ և արժեքների մի շարք, որոնք համապատասխանում են այս ժամանակին, օրինակ, ստացված սենսորների կարգավիճակի պարբերական հարցման միջոցով: կամ չափումների հավաքում):
Ես Պավել Կոլոբաևն եմ։ DevOps, SRE, LeroyMerlin, ամեն ինչ նման է կոդի. ամեն ինչ մեր մասին է՝ իմ և LeroyMerlin-ի այլ աշխատակիցների մասին:
Կա ամպ, որը հիմնված է OpenStack-ի վրա: Տեխնիկական ռադարին մի փոքրիկ հղում կա։
Այն կառուցված է Kubernetes երկաթի հիման վրա, ինչպես նաև OpenStack-ի և լոգինգի հետ կապված բոլոր ծառայությունների վրա:
Սա այն սխեման է, որը մենք ունեինք մշակման մեջ։ Երբ մենք մշակում էինք այս ամենը, մենք ունեինք Prometheus օպերատոր, որը տվյալները պահում էր հենց K8s կլաստերի ներսում: Ինքն ինքնաբերաբար գտնում է այն, ինչ պետք է քսել ու կոպիտ ասած դնում է ոտքերի տակ։
Մեզ անհրաժեշտ կլինի տեղափոխել բոլոր տվյալները Kubernetes կլաստերից դուրս, քանի որ եթե ինչ-որ բան պատահի, ապա մենք պետք է հասկանանք, թե ինչ և որտեղ:
Առաջին լուծումն այն է, որ մենք օգտագործում ենք դաշնություն, երբ ունենք երրորդ կողմի Պրոմեթևս, երբ մենք գնում ենք Kubernetes կլաստեր դաշնության մեխանիզմով:
Բայց այստեղ կան փոքր խնդիրներ: Մեր դեպքում խնդիրները սկսվեցին այն ժամանակ, երբ ունեինք 250 չափիչ, իսկ երբ այն դարձավ 000 չափիչ, հասկացանք, որ չենք կարող այդպես աշխատել։ Մենք ավելացրել ենք scrape_timeout-ը մինչև 400 վայրկյան:
Ինչու՞ պետք է դա անեինք: Պրոմեթևսը պարսպի սկզբից սկսում է թայմաութը հաշվել։ Կարևոր չէ, որ տվյալները դեռ հոսում են: Եթե նշված ժամանակահատվածում տվյալները չեն միաձուլվում և նիստը չի փակվում http-ի միջոցով, ապա նիստը համարվում է ձախողված, և տվյալները չեն մտնում հենց Պրոմեթևսի մեջ:
Բոլորը գիտեն գրաֆիկները, որոնք մենք ստանում ենք, երբ տվյալների մի մասը բացակայում է: Գրաֆիկան պատռված է, և մենք դրանից գոհ չենք:
Հաջորդ տարբերակը երկու տարբեր Պրոմեթևսի վրա հիմնված շարադրումն է նույն դաշնային մեխանիզմի միջոցով:
Օրինակ, պարզապես վերցրեք դրանք և բաժանեք դրանք անունով: Սա նույնպես կարելի է օգտագործել, բայց մենք որոշեցինք առաջ գնալ:
Այժմ մենք ստիպված կլինենք ինչ-որ կերպ մշակել այս բեկորները: Դուք կարող եք վերցնել promxy-ն, որն իջնում է բեկորային տարածք և բազմապատկում տվյալները: Այն աշխատում է երկու բեկորներով որպես մեկ մուտքի կետ: Սա կարող է իրականացվել promxy-ի միջոցով, բայց առայժմ չափազանց բարդ է:
Առաջին տարբերակը՝ մենք ուզում ենք հրաժարվել ֆեդերացիայի մեխանիզմից, քանի որ այն շատ դանդաղ է ընթանում։
Prometheus-ի մշակողները հստակ ասում են. «Տղե՛րք, օգտագործե՛ք այլ TimescaleDB, քանի որ մենք չենք աջակցի չափումների երկարաժամկետ պահպանմանը»: Սա նրանց խնդիրը չէ։
Մենք գրում ենք թղթի վրա, որը դեռ պետք է բեռնաթափել դրսում, որպեսզի ամեն ինչ մի տեղում չպահենք։
Երկրորդ թերությունը հիշողության սպառումն է: Այո, ես հասկանում եմ, որ շատերը կասեն, որ 2020 թվականին մի երկու գիգաբայթ հիշողություն արժե մեկ կոպեկ, բայց դեռ։
Այժմ մենք ունենք մշակող և պրոդ միջավայր: Dev-ում սա մոտավորապես 9 գիգաբայթ է 350 մետրի դիմաց: Արտադրանքի մեջ սա 000 գիգաբայթ է՝ փոքր 14 չափորոշիչներով: Միևնույն ժամանակ, մենք ունենք ընդամենը 780 րոպե պահպանման ժամանակ: Սա վատ է: Իսկ հիմա կբացատրեմ, թե ինչու։
Մենք հաշվարկ ենք անում, այսինքն՝ մեկուկես միլիոն մետրիկներով, ու արդեն մոտ ենք դրանց, նախագծման փուլում ստանում ենք 35-37 գիգաբայթ հիշողություն։ Բայց արդեն 4 միլիոն չափիչները պահանջում են մոտ 90 գիգաբայթ հիշողություն: Այսինքն, այն հաշվարկվել է Prometheus-ի մշակողների կողմից տրամադրված բանաձեւով։ Մենք նայեցինք հարաբերակցությանը և հասկացանք, որ չենք ուզում մի քանի միլիոն վճարել սերվերի համար միայն մոնիտորինգի համար:
Մենք ոչ միայն ավելացնելու ենք մեքենաների թիվը, մենք նաև վերահսկում ենք հենց վիրտուալ մեքենաները։ Հետևաբար, որքան շատ վիրտուալ մեքենաներ, այնքան շատ չափումներ տարբեր տեսակների և այլն: Մենք կունենանք մեր կլաստերի հատուկ աճ չափումների առումով:
Սկավառակի տարածության դեպքում այստեղ ամեն ինչ այնքան էլ վատ չէ, բայց ես կցանկանայի բարելավել այն: Մենք 15 օրում ստացել ենք ընդհանուր 120 գիգաբայթ, որից 100-ը սեղմված տվյալներ են, 20-ը՝ չսեղմված, բայց մենք միշտ ավելի քիչ ենք ուզում։
Համապատասխանաբար, մենք գրում ենք ևս մեկ կետ. սա ռեսուրսների մեծ սպառումն է, որը մենք դեռ ցանկանում ենք խնայել, քանի որ մենք չենք ցանկանում, որ մեր մոնիտորինգի կլաստերը ավելի շատ ռեսուրսներ ուտի, քան մեր կլաստերը, որը կառավարում է OpenStack-ը:
Պրոմեթևսի ևս մեկ թերություն կա, որը մենք ինքներս ենք բացահայտել. սա գոնե հիշողության որոշակի սահմանափակում է: Պրոմեթևսի հետ այստեղ ամեն ինչ շատ ավելի վատ է, քանի որ այն ընդհանրապես նման շրջադարձեր չունի։ Docker-ում սահմանափակում օգտագործելը նույնպես տարբերակ չէ: Եթե հանկարծ ձեր RAF-ն ընկավ ու 20-30 գիգաբայթ լինի, ուրեմն շատ երկար ժամանակ կպահանջվի, որ բարձրանա։
Սա ևս մեկ պատճառ է, թե ինչու Պրոմեթևսը մեզ հարմար չէ, այսինքն մենք չենք կարող սահմանափակել հիշողության սպառումը:
Նման սխեմայով հնարավոր կլիներ հանդես գալ։ Այս սխեման մեզ անհրաժեշտ է ՀԱ կլաստեր կազմակերպելու համար: Մենք ցանկանում ենք, որ մեր չափումները հասանելի լինեն միշտ և ամենուր, նույնիսկ եթե այս չափումները պահող սերվերը խափանվի: Եվ այսպես, մենք ստիպված կլինենք կառուցել նման սխեմա։
Այս սխեման ասում է, որ մենք կունենանք բեկորների կրկնօրինակում և, համապատասխանաբար, սպառված ռեսուրսների ծախսերի կրկնօրինակում։ Այն կարող է լինել գրեթե հորիզոնական մասշտաբով, բայց, այնուամենայնիվ, ռեսուրսների սպառումը դժոխային կլինի:
Թերությունները հերթականությամբ, այն ձևով, որով մենք դրանք գրել ենք մեզ համար.
- Պահանջում է արտաքին չափումների վերբեռնում:
- Ռեսուրսների բարձր սպառում:
- Դուք չեք կարող սահմանափակել հիշողության սպառումը:
- ՀԱ-ի համալիր և ռեսուրսային ինտենսիվ իրականացում:
Մենք մեզ համար որոշեցինք, որ հեռանում ենք Պրոմեթևսից՝ որպես պահեստարան։
Մենք ինքներս մեզ համար սահմանել ենք լրացուցիչ պահանջներ, որոնք մեզ անհրաժեշտ են: Սա.
- Սա promql աջակցություն է, քանի որ Պրոմեթևսի համար արդեն շատ բաներ են գրվել՝ հարցումներ, ահազանգեր։
- Եվ հետո մենք ունենք Grafana-ն, որն արդեն իսկ գրված է հենց նույն ձևով Պրոմեթևսի համար որպես հետին պլան։ Ես չեմ ուզում վերաշարադրել վահանակները:
- Մենք ուզում ենք նորմալ ՀԱ ճարտարապետություն կառուցել:
- Մենք ցանկանում ենք նվազեցնել ցանկացած ռեսուրսների սպառումը։
- Կա ևս մեկ փոքրիկ նրբերանգ. Մենք չենք կարող օգտագործել տարբեր տեսակի ամպային համակարգեր՝ չափումներ հավաքելու համար: Մենք չգիտենք, թե ինչն է այս ցուցանիշների մեջ առայժմ վերաբերվում: Եվ քանի որ ամեն ինչ կարող է թռչել այնտեղ, մենք պետք է սահմանափակվենք տեղային տեղաբաշխմամբ:
Քիչ ընտրություն կար: Մենք հավաքեցինք այն ամենը, ինչի փորձ ունեինք։ Մենք նայեցինք Պրոմեթևսի էջը ինտեգրման բաժնում, կարդացինք մի շարք հոդվածներ և տեսանք, թե ինչ կա այնտեղ: Եվ մեզ համար մենք ընտրեցինք VictoriaMetrics-ը որպես Պրոմեթևսի փոխարինող:
Ինչո՞ւ։ Որովհետեւ:
- Գիտի promql.
- Առկա է մոդուլային ճարտարապետություն։
- Grafana-ում փոփոխություններ չեն պահանջում:
- Եվ ամենակարևորը, մենք, հավանաբար, կտրամադրենք չափումների պահեստը մեր ընկերության ներսում որպես ծառայություն, այնպես որ մենք նախօրոք փնտրում ենք տարբեր տեսակի սահմանափակումներ, որպեսզի օգտվողները կարողանան օգտագործել կլաստերի բոլոր ռեսուրսները ինչ-որ սահմանափակ ձևով, քանի որ կա հնարավորություն: որ դա կլինի բազմատենչություն։
Մենք կատարում ենք առաջին համեմատությունը. Մենք վերցնում ենք նույն Պրոմեթևսը կլաստերի ներսում, արտաքին Պրոմեթևսը գնում է դրան: Մենք ավելացնում ենք remoteWrite VictoriaMetrics-ի միջոցով:
Ես անմիջապես վերապահում կանեմ, որ այստեղ մենք տեսանք CPU-ի սպառման մի փոքր աճ VictoriaMetrics-ից: VictoriaMetrics վիքին ասում է, թե որ պարամետրերն են լավագույնը: Մենք ստուգեցինք դրանք։ Նրանք շատ լավ նվազեցրել են պրոցեսորի սպառումը։
Մեր դեպքում Պրոմեթևսի հիշողության սպառումը, որը գտնվում է Կուբերնետեսի կլաստերում, էականորեն չի աճել։
Մենք համեմատում ենք նույն տվյալների երկու տվյալների աղբյուրները: Պրոմեթևսում մենք տեսնում ենք նույն բացակայող տվյալները։ VictoriaMetrics-ում ամեն ինչ կարգին է:
Սկավառակի տարածքով թեստերի արդյունքներ: Մենք Պրոմեթևսում ստացել ենք ընդհանուր առմամբ 120 գիգաբայթ: VictoriaMetrics-ում մենք արդեն ստանում ենք օրական 4 գիգաբայթ: Կա մի փոքր այլ մեխանիզմ, քան այն, ինչ դուք սովոր եք տեսնել Պրոմեթևսում: Այսինքն՝ տվյալներն արդեն բավականին լավ սեղմված են մեկ օրվա համար՝ կես ժամով։ Դրանք արդեն լավ քաղվում են մեկ օրում՝ կես ժամում, չնայած այն բանին, որ հետագայում տվյալները կմիավորվեն։ Արդյունքում մենք խնայեցինք սկավառակի տարածությունը:
Մենք խնայում ենք նաև հիշողության ռեսուրսների սպառման վրա: Փորձարկումների ժամանակ մենք Պրոմեթևսը տեղակայել ենք վիրտուալ մեքենայի վրա՝ 8 միջուկ, 24 գիգաբայթ: Պրոմեթևսն ուտում է գրեթե ամեն ինչ։ Նա ընկել է OOM Killer-ի վրա: Միևնույն ժամանակ, դրա մեջ թափվեց ընդամենը 900 հազար ակտիվ չափիչ: Սա մոտավորապես 000-25 չափումներ է վայրկյանում:
Մենք գործարկեցինք VictoriaMetrics-ը երկմիջուկ վիրտուալ մեքենայի վրա՝ 8 գիգաբայթ օպերատիվ հիշողությամբ: Մեզ հաջողվեց ստիպել VictoriaMetrics-ին լավ աշխատել՝ 8 ԳԲ հզորությամբ սարքի վրա մի քանի բաների հետ շփվելով: Ի վերջո, մենք այն պահեցինք մինչև 7 գիգաբայթ: Միևնույն ժամանակ, բովանդակության, այսինքն՝ չափումների մատուցման արագությունը նույնիսկ ավելի բարձր էր, քան Պրոմեթևսը:
Պրոմեթևսի համեմատ պրոցեսորը շատ ավելի լավն է դարձել։ Այստեղ Պրոմեթևսը սպառում է 2,5 միջուկ, իսկ VictoriaMetrics-ը՝ ընդամենը 0,25 միջուկ: Սկզբում - 0,5 միջուկ: Երբ այն միաձուլվում է, այն հասնում է մեկ միջուկի, բայց դա չափազանց, չափազանց հազվադեպ է:
Մեր դեպքում ընտրությունը ակնհայտ պատճառներով ընկավ VictoriaMetrics-ի վրա, մենք ուզում էինք գումար խնայել և խնայեցինք:
Մենք անմիջապես անցնում ենք երկու կետ. սա չափումների բեռնաթափումն է և ռեսուրսների մեծ սպառումը: Եվ մեզ մնում է որոշել երկու կետ, որոնք դեռ թողել ենք մեզ։
Այստեղ ես անմիջապես վերապահում կանեմ, մենք VictoriaMetrics-ը համարում ենք չափումների շտեմարան։ Բայց քանի որ մենք, ամենայն հավանականությամբ, կտրամադրենք VictoriaMetrics-ը որպես պահեստ ամբողջ Leroy-ի համար, մենք պետք է սահմանափակենք նրանց, ովքեր կօգտագործեն այս կլաստերը, որպեսզի նրանք չդնեն այն մեզ:
Գոյություն ունի հիանալի պարամետր, որը թույլ է տալիս սահմանափակել ըստ ժամանակի, տվյալների քանակի և կատարման ժամանակի։
Գոյություն ունի նաև հիանալի տարբերակ, որը թույլ է տալիս սահմանափակել հիշողության սպառումը, դրանով իսկ մենք կարող ենք գտնել այն հավասարակշռությունը, որը թույլ կտա մեզ ստանալ նորմալ աշխատանքային արագություն և համապատասխան ռեսուրսների սպառում:
Մինուս ևս մեկ կետ, այսինքն, մենք հատում ենք կետը. դուք չեք կարող սահմանափակել հիշողության սպառումը:
Առաջին կրկնություններում մենք փորձարկեցինք VictoriaMetrics Single Node-ը: Հաջորդը մենք անցնում ենք VictoriaMetrics կլաստերի տարբերակին:
Այստեղ մենք ազատ ձեռք ունենք առանձնացնելու տարբեր ծառայություններ VictoriaMetrics-ում՝ կախված նրանից, թե ինչով են դրանք աշխատելու և ինչ ռեսուրսներ են սպառելու: Սա շատ ճկուն և հարմար լուծում է։ Մենք սա օգտագործեցինք մեզ վրա:
VictoriaMetrics Cluster Version-ի հիմնական բաղադրիչներն են vmstsorage: Դրանցից կարող է լինել N թիվը: Մեր դեպքում դրանք առայժմ 2-ն են։
Եվ կա vminsert: Սա պրոքսի սերվեր է, որը թույլ է տալիս մեզ՝ կազմակերպել փոխանակում բոլոր պահեստների միջև, որոնց մասին մենք նրան ասել ենք, և այն թույլ է տալիս մեկ այլ կրկնօրինակ, այսինքն՝ դուք կունենաք և՛ փոխանակում, և՛ կրկնօրինակ:
Vminsert-ն աջակցում է Prometheus-ի OpenTSDB, Graphite, InfluxDB և remoteWrite արձանագրությունները:
Կա նաև vmselect: Նրա հիմնական խնդիրն է գնալ vmstorage, ստանալ տվյալներ նրանցից, հեռացնել այս տվյալները և տալ հաճախորդին:
Vmagent-ի նման հրաշալի բան կա։ Մենք իսկապես սիրում ենք նրան: Այն թույլ է տալիս կարգավորել այնպես, ինչպես Պրոմեթևսը և դեռ ամեն ինչ անել այնպես, ինչպես Պրոմեթևսը: Այսինքն՝ այն հավաքում է չափումներ տարբեր սուբյեկտներից և ծառայություններից և դրանք ուղարկում vminsert։ Հետո ամեն ինչ կախված է քեզնից։
Մեկ այլ հիանալի ծառայություն է vmalert-ը, որը թույլ է տալիս օգտագործել VictoriaMetrics-ը որպես backend, ստանալ մշակված տվյալներ vminsert-ից և ուղարկել մշակված տվյալներ vmselect-ին: Այն մշակում է ինքնին ահազանգերը, ինչպես նաև կանոնները: Ահազանգերի դեպքում մենք ահազանգ ենք ստանում alertmanager-ի միջոցով։
Կա wmauth բաղադրիչ: Մենք, հավանաբար, կօգտագործենք այն, և գուցե ոչ (մենք դեռ չենք որոշել դրա մասին) որպես կլաստերների բազմավարձակալական տարբերակների թույլտվության համակարգ: Այն աջակցում է RemoteWrite for Prometheus-ի համար և կարող է լիազորել url-ի, ավելի ճիշտ՝ դրա երկրորդ մասի հիման վրա, որտեղ դուք կարող եք կամ չեք կարող գրել:
Կա նաև vmbackup, vmrestore: Սա, ըստ էության, բոլոր տվյալների վերականգնումն ու կրկնօրինակումն է: S3, GCS, ֆայլի ընդունակ:
Մեր կլաստերի առաջին կրկնությունը կատարվել է կարանտինի ժամանակ։ Այն ժամանակ կրկնօրինակ չկար, ուստի մեր կրկնությունը բաղկացած էր երկու տարբեր և անկախ կլաստերներից, որոնց մեջ մենք տվյալներ էինք ստանում remoteWrite-ի միջոցով:
Այստեղ ես վերապահում կանեմ, որ երբ մենք VictoriaMetrics Single Node-ից անցանք VictoriaMetrics Cluster տարբերակին, մենք դեռ մնացել ենք նույն սպառված ռեսուրսներով, այսինքն՝ հիմնականը հիշողությունն է։ Մոտավորապես այսպես են բաշխվել մեր տվյալները, այսինքն՝ ռեսուրսների սպառումը:
Այստեղ արդեն ավելացվել է կրկնօրինակ: Մենք այս ամենը միավորեցինք մեկ համեմատաբար մեծ կլաստերի մեջ։ Մեր բոլոր տվյալները և՛ մասնատված են, և՛ կրկնօրինակված:
Ամբողջ կլաստերն ունի N մուտքի կետեր, ինչը նշանակում է, որ Պրոմեթևսը կարող է տվյալներ ավելացնել HAPROXY-ի միջոցով: Այստեղ մենք ունենք այս մուտքի կետը: Եվ այս մուտքի կետի միջոցով կարող եք մուտք գործել Grafana-ից:
Մեր դեպքում, HAPROXY-ը միակ նավահանգիստն է, որը վստահված անձինք ընտրում, տեղադրում և այլ ծառայություններ այս կլաստերի մեջ: Մեր դեպքում անհնար էր մեկ հասցե նշել, մենք պետք է մի քանի մուտքի կետեր դնեինք, քանի որ հենց վիրտուալ մեքենաները, որոնց վրա աշխատում է VictoriaMetrics կլաստերը, գտնվում են նույն ամպային մատակարարի տարբեր գոտիներում, այսինքն՝ ոչ մեր ամպի ներսում։ , բայց դրսում։
Մենք ահազանգ ունենք. Մենք օգտագործում ենք այն: Մենք օգտագործում ենք Prometheus-ի alertmanager-ը: Մենք օգտագործում ենք Opsgenie-ն և Telegram-ը որպես ահազանգերի առաքման ալիք: Telegram-ում դրանք լցվում են dev-ից, միգուցե ինչ-որ բան պրոդից, բայց հիմնականում ինչ-որ բան վիճակագրական, որն անհրաժեշտ է ինժեներներին: Իսկ Օփսգենին քննադատաբար է վերաբերվում: Սրանք զանգեր են, միջադեպերի կառավարում։
Հավերժական հարցը. «Ո՞վ է վերահսկում մոնիտորինգը»: Մեր դեպքում մոնիտորինգը մոնիտորինգ է իրականացնում, քանի որ մենք օգտագործում ենք vmagent յուրաքանչյուր հանգույցի վրա: Եվ քանի որ մեր հանգույցները բաշխված են նույն պրովայդերի տարբեր տվյալների կենտրոններում, յուրաքանչյուր տվյալների կենտրոն ունի իր սեփական ալիքը, դրանք անկախ են, և նույնիսկ եթե ուղեղի պառակտումը գա, մենք դեռ ծանուցումներ կստանանք: Այո, դրանք ավելի շատ կլինեն, բայց ավելի լավ է ավելի շատ ահազանգեր ստանալ, քան ոչ մեկը:
Մեր ցուցակն ավարտում ենք ՀԺ-ի իրականացմամբ։
Եվ հետագայում ես կցանկանայի նշել VictoriaMetrics համայնքի հետ շփվելու փորձը: Շատ դրական ստացվեց։ Տղաները արձագանքում են. Նրանք փորձում են խորանալ յուրաքանչյուր առաջարկվող գործի մեջ։
Ես խնդիրներ ստեղծեցի GitHub-ում: Դրանք շատ արագ լուծվեցին։ Եվս մի երկու հարց կա, որոնք ամբողջությամբ փակված չեն, բայց օրենսգրքով արդեն տեսնում եմ, որ այս ուղղությամբ աշխատանքներ են տարվում։
Ինձ համար կրկնությունների ընթացքում հիմնական ցավն այն էր, որ եթե ես կրճատում էի հանգույցը, ապա առաջին 30 վայրկյանում vminsert-ը չէր կարող հասկանալ, որ backend չկա: Հիմա արդեն որոշված է։ Եվ բառացիորեն մեկ-երկու վայրկյանում տվյալները վերցվում են մնացած բոլոր հանգույցներից, և հարցումը դադարում է սպասել այդ բացակայող հանգույցին։
Մենք ցանկանում էինք, որ ինչ-որ պահի VictoriaMetrics-ից լինի VictoriaMetrics օպերատորը: Մենք սպասում էինք նրան։ Այժմ մենք ակտիվորեն կառուցում ենք VictoriaMetrics օպերատորի հետ կապված բոլոր նախահաշվային կանոնները և այլն: Պրոմեթևս, քանի որ մենք բավականին ակտիվորեն օգտագործում ենք Prometheus օպերատորի հետ կապված կանոնները:
Առաջարկներ կան՝ բարելավելու կլաստերի իրականացումը։ Ես դրանք ուրվագծեցի վերևում:
Եվ ես իսկապես ուզում եմ նվազեցնել նմուշը: Մեր դեպքում կրճատումներն անհրաժեշտ են բացառապես միտումները դիտելու համար: Կոպիտ ասած՝ օրվա ընթացքում մեկ մետրիկ ինձ բավական է։ Այս միտումները պետք են մեկ տարի, երեք, հինգ, տասը տարի: Եվ մեկ մետրային արժեքը բավական է:
- Մենք ցավ ենք ճանաչել, ինչպես և մեր որոշ գործընկերներ Պրոմեթևսից օգտվելիս:
- Մենք մեզ համար ընտրեցինք VictoriaMetrics-ը:
- Այն բավականին լավ է թեքվում ինչպես ուղղահայաց, այնպես էլ հորիզոնական:
- Մենք կարող ենք տարբեր բաղադրիչներ բաշխել կլաստերի տարբեր թվով հանգույցների վրա, սահմանափակել դրանք հիշողությամբ, ավելացնել հիշողություն և այլն։
Տանը մենք կօգտագործենք VictoriaMetrics-ը, քանի որ այն մեզ շատ դուր եկավ։ Ահա թե ինչ եղավ և ինչ եղավ.
Մի քանի qr կոդ VictoriaMetrics զրույցի, իմ կոնտակտների, LeroyMerlin տեխնիկական ռադարի համար:
Source: www.habr.com