Prometheus 2-ի ժամանակային շարքերի տվյալների բազան (TSDB) ինժեներական լուծման հիանալի օրինակ է, որը Prometheus 2-ի v1 պահեստավորման համեմատ զգալի բարելավումներ է առաջարկում տվյալների կուտակման, հարցումների կատարման արագության և ռեսուրսների արդյունավետության առումով։ Մենք Prometheus 2-ը ներդնում էինք Percona Monitoring and Management (PMM) համակարգում, և ես հնարավորություն ունեցա հասկանալու Prometheus 2 TSDB-ի աշխատանքը։ Այս հոդվածում ես կքննարկեմ այս դիտարկումների արդյունքները։
Պրոմեթևսի միջին աշխատանքային ծանրաբեռնվածությունը
Նրանց համար, ովքեր սովոր են աշխատել հիմնական նպատակի տվյալների բազաների հետ, Prometheus-ի տիպիկ աշխատանքային ծանրաբեռնվածությունը բավականին հետաքրքիր է։ Տվյալների կուտակման տեմպը, որպես կանոն, կայուն է. սովորաբար, ձեր կողմից վերահսկվող ծառայությունները ուղարկում են մոտավորապես նույն քանակությամբ չափանիշներ, և ենթակառուցվածքը փոխվում է համեմատաբար դանդաղ։
Տեղեկատվության հարցումները կարող են գալ տարբեր աղբյուրներից։ Դրանցից մի քանիսը, օրինակ՝ ահազանգերը, նույնպես հակված են լինել կայուն և կանխատեսելի։ Մյուսները, ինչպիսիք են օգտատիրոջ հարցումները, կարող են առաջացնել կտրուկ աճեր, չնայած սա բնորոշ չէ աշխատանքային բեռների մեծ մասի համար։
Բեռնման թեստ
Թեստավորման ընթացքում ես կենտրոնացա տվյալներ կուտակելու ունակության վրա։ Ես տեղակայեցի Prometheus 2.3.2-ը, որը կազմվել էր Go 1.10.1-ի հետ (որպես PMM 1.14-ի մաս), Linode ծառայության մեջ՝ օգտագործելով այս սկրիպտը. . Հնարավորինս իրատեսական բեռներ ստեղծելու համար օգտագործեք սա Ես գործարկեցի մի քանի MySQL հանգույցներ իրական ծանրաբեռնվածությամբ (Sysbench TPC-C Test), որոնցից յուրաքանչյուրը նմանակեց 10 հանգույց։ Linux/MySQL.
Հետևյալ բոլոր թեստերը կատարվել են Linode սերվերի վրա՝ ութ վիրտուալ միջուկով և 32 ԳԲ հիշողությամբ, որի ընթացքում իրականացվել է 20 բեռնման սիմուլյացիա՝ վերահսկելով MySQL-ի երկու հարյուր օրինակ։ Կամ, Պրոմեթևսի տերմիններով ասած՝ 800 թիրախ, վայրկյանում 440 սքրեյփ, վայրկյանում 380 հազար նմուշ և 1,7 միլիոն ակտիվ ժամանակային շարքեր։
Կառուցվածք
Ավանդական տվյալների բազաների, այդ թվում՝ Prometheus 1.x-ի կողմից օգտագործվողի բնորոշ մոտեցումն է . Եթե դա բավարար չէ բեռը կարգավորելու համար, դուք կունենաք բարձր լատենտություն, և որոշ հարցումներ չեն կատարվի։ Prometheus 2-ում հիշողության օգտագործումը կարգավորվում է բանալիի միջոցով storage.tsdb.min-block-duration, որը որոշում է, թե որքան ժամանակ գրառումները կպահվեն հիշողության մեջ՝ սկավառակի վրա մաքրվելուց առաջ (նախնական արժեքը 2 ժամ է): Պահանջվող հիշողության քանակը կախված կլինի ժամանակային շարքերի, պիտակների և սքրեյփերի քանակից՝ բացի մուտքային տվյալների զուտ հոսքից։ Սկավառակի տարածքի առումով, Prometheus-ը նպատակ ունի օգտագործել 3 բայթ յուրաքանչյուր գրառման համար (նմուշ): Մյուս կողմից, հիշողության պահանջները շատ ավելի բարձր են։
Թեև հնարավոր է կարգավորել բլոկի չափը, այն խորհուրդ չի տրվում կարգավորել ձեռքով, ուստի դուք ստիպված եք Prometheus-ին տրամադրել այնքան հիշողություն, որքան այն պահանջում է ձեր աշխատանքային բեռի համար։
Եթե մուտքային չափանիշների հոսքը ապահովելու համար բավարար հիշողություն չկա, Prometheus-ը կփլուզվի հիշողության պակասի պատճառով կամ կբռնվի OOM killer-ի կողմից։
Պրոմեթևսի հիշողության սպառման դեպքում վթարը հետաձգելու համար սվոփ ավելացնելը շատ չի օգնում, քանի որ դրա օգտագործումը հանգեցնում է հիշողության սպառման կտրուկ աճի։ Կարծում եմ՝ սա Go-ն է, դրա աղբահավաքը և այն ձևը, որով այն կարգավորում է սվոփը։
Մեկ այլ հետաքրքիր մոտեցում է գլխային բլոկը սկավառակի վրա մաքրելու համար սահմանել որոշակի ժամանակ, այլ ոչ թե այն հաշվել գործընթացի մեկնարկի պահից։
Ինչպես տեսնում եք գրաֆիկից, սկավառակի լվացումները տեղի են ունենում յուրաքանչյուր երկու ժամը մեկ։ Եթե դուք փոխեք նվազագույն բլոկի տևողության պարամետրը մեկ ժամի, այս վերագործարկումները կկատարվեն յուրաքանչյուր ժամը մեկ՝ սկսած կես ժամից։
Եթե ցանկանում եք օգտագործել սա և այլ գրաֆիկներ ձեր Prometheus տեղադրման մեջ, կարող եք օգտագործել սա . Այն նախագծված էր PMM-ի համար, բայց աննշան փոփոխություններով այն համապատասխանում է Prometheus-ի ցանկացած տեղադրմանը։
Մենք ունենք ակտիվ բլոկ, որը կոչվում է գլխային բլոկ, որը պահվում է հիշողության մեջ։ հին տվյալներով բլոկները հասանելի են mmap(). Սա վերացնում է քեշը առանձին կարգավորելու անհրաժեշտությունը, բայց նաև նշանակում է, որ դուք պետք է բավարար տարածք թողնեք օպերացիոն համակարգի քեշի համար, եթե ցանկանում եք հարցումներ կատարել գլխային բլոկի կարողությունից ավելի հին տվյալների վրա։
Սա նաև նշանակում է, որ Պրոմեթևսի վիրտուալ հիշողության սպառումը բավականին բարձր կլինի, ինչը անհանգստանալու կարիք չկա։
Մեկ այլ հետաքրքիր դիզայնի կետ է WAL-ի (write ahead log) օգտագործումը։ Ինչպես կարող եք տեսնել պահեստավորման փաստաթղթերից, Prometheus-ը օգտագործում է WAL՝ վթարների ժամանակ կորուստներից խուսափելու համար։ Տվյալների կայունությունը երաշխավորող կոնկրետ մեխանիզմները, ցավոք, լավ փաստաթղթավորված չեն։ Prometheus 2.3.2 տարբերակը WAL-ը մաքրում է սկավառակից յուրաքանչյուր 10 վայրկյանը մեկ, և այս պարամետրը օգտատիրոջ կողմից կարգավորելի չէ։
Խտացումներ
Prometheus TSDB-ն նախագծված է Log Structured միաձուլման (LSM) պահոցի նման. գլխավոր բլոկը պարբերաբար թարմացվում է սկավառակի վրա, մինչդեռ սեղմման մեխանիզմը միաձուլում է մի քանի բլոկներ՝ հարցումների ընթացքում չափազանց շատ բլոկներ սկանավորելուց խուսափելու համար։ Այստեղ կարող եք տեսնել բլոկների քանակը, որոնք ես դիտարկել եմ փորձարկման համակարգում 24 ժամ բեռնումից հետո։
Եթե ցանկանում եք ավելին իմանալ պահոցի մասին, կարող եք նայել meta.json ֆայլը, որը պարունակում է տեղեկատվություն առկա բլոկների և դրանց առաջացման մասին։
{
"ulid": "01CPZDPD1D9R019JS87TPV5MPE",
"minTime": 1536472800000,
"maxTime": 1536494400000,
"stats": {
"numSamples": 8292128378,
"numSeries": 1673622,
"numChunks": 69528220
},
"compaction": {
"level": 2,
"sources": [
"01CPYRY9MS465Y5ETM3SXFBV7X",
"01CPYZT0WRJ1JB1P0DP80VY5KJ",
"01CPZ6NR4Q3PDP3E57HEH760XS"
],
"parents": [
{
"ulid": "01CPYRY9MS465Y5ETM3SXFBV7X",
"minTime": 1536472800000,
"maxTime": 1536480000000
},
{
"ulid": "01CPYZT0WRJ1JB1P0DP80VY5KJ",
"minTime": 1536480000000,
"maxTime": 1536487200000
},
{
"ulid": "01CPZ6NR4Q3PDP3E57HEH760XS",
"minTime": 1536487200000,
"maxTime": 1536494400000
}
]
},
"version": 1
}Պրոմեթևսում խտացումները կապված են գլխի բլոկի սկավառակի վրա լվանալու ժամանակի հետ։ Այս պահին կարող են իրականացվել մի քանի նման գործողություններ։
Թվում է, թե խտացումները որևէ կերպ սահմանափակված չեն և կարող են մեծ թռիչքներ առաջացնել սկավառակի մուտք/ելքում կատարման ընթացքում։
CPU-ի ծանրաբեռնվածության կտրուկ աճ
Իհարկե, սա բավականին բացասաբար է անդրադառնում համակարգի աշխատանքի վրա և նաև լուրջ մարտահրավեր է LSM պահեստավորման համար. ինչպե՞ս սեղմել՝ բարձր հարցումների հաճախականությունը ապահովելու համար՝ առանց չափազանց մեծ ծանրաբեռնվածության։
Հիշողության օգտագործումը սեղմման ընթացքում նույնպես բավականին հետաքրքիր է թվում։
Մենք կարող ենք տեսնել, թե ինչպես է սեղմումից հետո հիշողության մեծ մասը փոխում վիճակը՝ քեշից դառնալով ազատ, ինչը նշանակում է, որ այնտեղից հեռացվել է պոտենցիալ արժեքավոր տեղեկատվությունը։ Հետաքրքիր է՝ այստեղ օգտագործվա՞ծ է fadvice() կամ որևէ այլ նվազագույնի հասցնելու տեխնիկա, թե՞ դա պայմանավորված է քեշի ազատմամբ սեղմման ընթացքում ոչնչացված բլոկներից։
Վերականգնում ձախողումից հետո
Անհաջողություններից վերականգնվելը ժամանակ է պահանջում, և դա լավ պատճառներով։ Վայրկյանում մեկ միլիոն գրառումների մուտքային հոսքի դեպքում, հաշվի առնելով SSD սկավառակը, ես ստիպված էի սպասել մոտ 25 րոպե, մինչև վերականգնումը տեղի ունենար։
level=info ts=2018-09-13T13:38:14.09650965Z caller=main.go:222 msg="Starting Prometheus" version="(version=2.3.2, branch=v2.3.2, revision=71af5e29e815795e9dd14742ee7725682fa14b7b)"
level=info ts=2018-09-13T13:38:14.096599879Z caller=main.go:223 build_context="(go=go1.10.1, user=Jenkins, date=20180725-08:58:13OURCE)"
level=info ts=2018-09-13T13:38:14.096624109Z caller=main.go:224 host_details="(Linux 4.15.0-32-generic #35-Ubuntu SMP Fri Aug 10 17:58:07 UTC 2018 x86_64 1bee9e9b78cf (none))"
level=info ts=2018-09-13T13:38:14.096641396Z caller=main.go:225 fd_limits="(soft=1048576, hard=1048576)"
level=info ts=2018-09-13T13:38:14.097715256Z caller=web.go:415 component=web msg="Start listening for connections" address=:9090
level=info ts=2018-09-13T13:38:14.097400393Z caller=main.go:533 msg="Starting TSDB ..."
level=info ts=2018-09-13T13:38:14.098718401Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536530400000 maxt=1536537600000 ulid=01CQ0FW3ME8Q5W2AN5F9CB7R0R
level=info ts=2018-09-13T13:38:14.100315658Z caller=web.go:467 component=web msg="router prefix" prefix=/prometheus
level=info ts=2018-09-13T13:38:14.101793727Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536732000000 maxt=1536753600000 ulid=01CQ78486TNX5QZTBF049PQHSM
level=info ts=2018-09-13T13:38:14.102267346Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536537600000 maxt=1536732000000 ulid=01CQ78DE7HSQK0C0F5AZ46YGF0
level=info ts=2018-09-13T13:38:14.102660295Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536775200000 maxt=1536782400000 ulid=01CQ7SAT4RM21Y0PT5GNSS146Q
level=info ts=2018-09-13T13:38:14.103075885Z caller=repair.go:39 component=tsdb msg="found healthy block" mint=1536753600000 maxt=1536775200000 ulid=01CQ7SV8WJ3C2W5S3RTAHC2GHB
level=error ts=2018-09-13T14:05:18.208469169Z caller=wal.go:275 component=tsdb msg="WAL corruption detected; truncating" err="unexpected CRC32 checksum d0465484, want 0" file=/opt/prometheus/data/.prom2-data/wal/007357 pos=15504363
level=info ts=2018-09-13T14:05:19.471459777Z caller=main.go:543 msg="TSDB started"
level=info ts=2018-09-13T14:05:19.471604598Z caller=main.go:603 msg="Loading configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499156711Z caller=main.go:629 msg="Completed loading of configuration file" filename=/etc/prometheus.yml
level=info ts=2018-09-13T14:05:19.499228186Z caller=main.go:502 msg="Server is ready to receive web requests."Վերականգնման գործընթացի հիմնական խնդիրը դրա հիշողության բարձր սպառումն է։ Չնայած սերվերը սովորաբար կարող է կայուն աշխատել նույն քանակությամբ հիշողությամբ, այն կարող է չվերականգնվել, եթե OOM-ի պատճառով խափանվի։ Միակ լուծումը, որ գտա, տվյալների հավաքագրումն անջատելն էր, սերվերը միացնելը, վերականգնելու թույլտվություն տալը և վերագործարկելը՝ հավաքագրումը միացված վիճակում։
Տաքանալ
Տաքացման ընթացքում հաշվի առնելու մեկ այլ վարքագիծ է ցածր արտադրողականության և բարձր ռեսուրսների սպառման հարաբերակցությունը անմիջապես մեկնարկից հետո։ Որոշ, բայց ոչ բոլոր գործարկումների ժամանակ ես նկատեցի պրոցեսորի և հիշողության զգալի ծանրաբեռնվածություն։
Հիշողության օգտագործման անկումը ցույց է տալիս, որ Prometheus-ը չի կարողանում կարգավորել բոլոր հավաքածուները սկզբից, և որոշ տեղեկություններ կորչում են։
Ես չեմ հասկացել պրոցեսորի և հիշողության բարձր ծանրաբեռնվածության ճշգրիտ պատճառները։ Ես կասկածում եմ, որ սա պայմանավորված է գլխային բլոկում բարձր հաճախականությամբ նոր ժամանակային շարքերի ստեղծմամբ։
CPU-ի ծանրաբեռնվածության կտրուկ աճ
Բացի սեղմումներից, որոնք ստեղծում են բավականին բարձր I/O ծանրաբեռնվածություն, ես նկատեցի CPU-ի ծանրաբեռնվածության զգալի աճ յուրաքանչյուր երկու րոպեն մեկ։ Բարձր մուտքային հոսքի դեպքում ցատկերն ավելի երկար են և, կարծես, պայմանավորված են Go-ի աղբահավաքով, երբ առնվազն որոշ միջուկներ լիովին բեռնված են։
Այս ցատկերը այդքան էլ աննշան չեն։ Պարզվում է, որ երբ դրանք տեղի են ունենում, Prometheus-ի ներքին մուտքի կետը և չափանիշները դառնում են անհասանելի, ինչի հետևանքով նույն ժամանակահատվածներում տվյալների բացեր են առաջանում։
Կարող եք նաև նկատել, որ Prometheus արտահանողը կախվում է մեկ վայրկյան։
Մենք կարող ենք տեսնել համակցություններ աղբահանության (ԱՀ) հետ։
Ամփոփում
Prometheus 2-ի TSDB-ն արագ է, կարող է մշակել միլիոնավոր ժամանակային շարքեր և միևնույն ժամանակ վայրկյանում հազարավոր գրառումներ՝ օգտագործելով բավականին համեստ սարքավորումներ։ CPU-ի և սկավառակի I/O-ի օգտագործումը նույնպես տպավորիչ է։ Իմ օրինակը ցույց տվեց մինչև 200 չափանիշ վայրկյանում յուրաքանչյուր օգտագործված միջուկի համար։
Ընդլայնումը պլանավորելիս պետք է հիշել, որ պետք է ունենալ բավարար հիշողություն, և այն պետք է լինի իրական հիշողություն։ Իմ դիտարկած հիշողության ծավալը մոտ 5 ԳԲ էր մուտքային թրաֆիկի յուրաքանչյուր վայրկյանում 100 գրառման համար, որը, օպերացիոն համակարգի քեշի հետ համատեղ, ընդհանուր առմամբ ապահովում էր մոտ 000 ԳԲ օգտագործված հիշողություն։
Իհարկե, դեռ շատ աշխատանք կա անելու պրոցեսորի և սկավառակի մուտքի/ելքի կտրուկ տատանումները զսպելու համար, և սա զարմանալի չէ՝ հաշվի առնելով, թե որքան երիտասարդ է Prometheus 2 TSDB-ն՝ համեմատած InnoDB-ի, TokuDB-ի, RocksDB-ի, WiredTiger-ի հետ, բայց դրանք բոլորն էլ նմանատիպ խնդիրներ ունեին իրենց կյանքի ցիկլի սկզբում։
Source: www.habr.com
