Պրոմեթևս 2-ի ժամանակային շարքերի տվյալների բազան (TSDB) ինժեներական լուծման հիանալի օրինակ է, որն առաջարկում է մեծ բարելավումներ Պրոմեթևս 2-ի v1 պահեստի համեմատ՝ տվյալների կուտակման արագության, հարցումների կատարման և ռեսուրսների արդյունավետության առումով: Մենք իրականացնում էինք Prometheus 2-ը Percona Monitoring and Management-ում (PMM) և ես հնարավորություն ունեցա հասկանալու Prometheus 2 TSDB-ի կատարումը: Այս հոդվածում ես կխոսեմ այս դիտարկումների արդյունքների մասին:
Պրոմեթևսի միջին ծանրաբեռնվածությունը
Նրանց համար, ովքեր սովոր են գործ ունենալ ընդհանուր նշանակության տվյալների բազաների հետ, Պրոմեթևսի տիպիկ ծանրաբեռնվածությունը բավականին հետաքրքիր է: Տվյալների կուտակման արագությունը հակված է կայուն լինելու. սովորաբար ծառայությունները, որոնք դուք վերահսկում եք, ուղարկում են մոտավորապես նույն թվով չափումներ, և ենթակառուցվածքը փոխվում է համեմատաբար դանդաղ:
Տեղեկատվության հարցումները կարող են լինել տարբեր աղբյուրներից: Դրանցից մի քանիսը, ինչպիսիք են ահազանգերը, նույնպես ձգտում են կայուն և կանխատեսելի արժեքի: Մյուսները, օրինակ՝ օգտատերերի հարցումները, կարող են պոռթկումներ առաջացնել, թեև դա այդպես չէ ծանրաբեռնվածության մեծ մասի դեպքում:
Բեռնման փորձարկում
Թեստավորման ընթացքում ես կենտրոնացել եմ տվյալներ կուտակելու ունակության վրա: Ես տեղադրեցի 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-ի կողմից օգտագործվածը, հետևյալն է . Եթե դա բավարար չէ բեռը կարգավորելու համար, դուք կզգաք բարձր ուշացումներ, և որոշ հարցումներ կձախողվեն: Պրոմեթևս 2-ում հիշողության օգտագործումը կարգավորելի է բանալիով storage.tsdb.min-block-duration, որը որոշում է, թե որքան ժամանակ կպահվեն ձայնագրությունները հիշողության մեջ՝ նախքան սկավառակի վրա լցվելը (կանխադրվածը 2 ժամ է): Պահանջվող հիշողության քանակը կախված կլինի զուտ մուտքային հոսքին ավելացված ժամանակային շարքերի, պիտակների և քերծվածքների քանակից: Սկավառակի տարածության առումով Պրոմեթևսը նպատակ ունի օգտագործել 3 բայթ մեկ ձայնագրության համար (նմուշ): Մյուս կողմից, հիշողության պահանջները շատ ավելի բարձր են:
Թեև հնարավոր է կարգավորել բլոկի չափը, խորհուրդ չի տրվում այն կարգավորել ձեռքով, այնպես որ դուք ստիպված եք Պրոմեթևսին տալ այնքան հիշողություն, որքան այն պահանջում է ձեր ծանրաբեռնվածության համար:
Եթե բավարար հիշողություն չլինի չափումների մուտքային հոսքին աջակցելու համար, Պրոմեթևսը կկորցնի հիշողությունը կամ OOM մարդասպանը կհասնի դրան:
Փոխանակման ավելացումը՝ խափանումը հետաձգելու համար, երբ Պրոմեթևսի հիշողությունը սպառվում է, իրականում չի օգնում, քանի որ այս ֆունկցիայի օգտագործումը հանգեցնում է հիշողության պայթյունավտանգ սպառման: Կարծում եմ, որ դա կապված է Go-ի, նրա աղբահանի և փոխանակման հետ գործ ունենալու հետ:
Մեկ այլ հետաքրքիր մոտեցում է կարգավորել գլխի բլոկը, որպեսզի այն որոշակի ժամանակ լցվի սկավառակի վրա, այն գործընթացի սկզբից հաշվելու փոխարեն:
Ինչպես երևում է գրաֆիկից, սկավառակի վրա ողողումներ տեղի են ունենում յուրաքանչյուր երկու ժամը մեկ: Եթե փոխեք min-block-duration պարամետրը մեկ ժամ, ապա այդ զրոյացումները տեղի կունենան ամեն ժամը մեկ՝ կես ժամից հետո:
Եթե ցանկանում եք օգտագործել այս և այլ գրաֆիկները ձեր Պրոմեթևսի տեղադրման մեջ, կարող եք օգտագործել սա . Այն նախատեսված էր PMM-ի համար, բայց փոքր փոփոխություններով տեղավորվում է Պրոմեթևսի ցանկացած տեղադրման մեջ:
Մենք ունենք ակտիվ բլոկ, որը կոչվում է head block, որը պահվում է հիշողության մեջ; Ավելի հին տվյալներով բլոկները հասանելի են միջոցով mmap(). Սա վերացնում է քեշը առանձին կարգավորելու անհրաժեշտությունը, բայց նաև նշանակում է, որ դուք պետք է բավականաչափ տարածք թողնեք օպերացիոն համակարգի քեշի համար, եթե ցանկանում եք հարցումներ կատարել ավելի հին տվյալներ, քան այն, ինչ կարող է տեղավորել գլխի բլոկը:
Սա նաև նշանակում է, որ Պրոմեթևսի վիրտուալ հիշողության սպառումը բավականին բարձր տեսք կունենա, ինչը անհանգստանալու պատճառ չէ:
Դիզայնի մեկ այլ հետաքրքիր կետ WAL-ի օգտագործումն է (գրել առաջ գրանցամատյան): Ինչպես երևում է պահեստավորման փաստաթղթերից, Պրոմեթևսն օգտագործում է WAL-ը՝ վթարներից խուսափելու համար: Տվյալների գոյատևման երաշխավորման հատուկ մեխանիզմները, ցավոք, լավ փաստաթղթավորված չեն: Պրոմեթևսի 2.3.2 տարբերակը յուրաքանչյուր 10 վայրկյանը մեկ միացնում է WAL-ը սկավառակի վրա, և այս տարբերակը կարգավորելի չէ օգտվողի կողմից:
Կոմպակտներ
Prometheus TSDB-ն նախագծված է LSM-ի (Log Structured Merge) խանութի նման. գլխի բլոկը պարբերաբար լցվում է սկավառակի վրա, մինչդեռ խտացման մեխանիզմը միավորում է բազմաթիվ բլոկներ՝ խուսափելու համար հարցումների ժամանակ շատ բլոկների սկանավորումից: Այստեղ դուք կարող եք տեսնել բլոկների քանակը, որոնք ես նկատեցի թեստային համակարգում մեկ օր բեռնվածությունից հետո:
Եթե ցանկանում եք ավելին իմանալ խանութի մասին, կարող եք ուսումնասիրել 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
}Պրոմեթևսի խտացումները կապված են այն ժամանակի հետ, երբ գլխի բլոկը լցվում է սկավառակի վրա: Այս պահին կարող են իրականացվել մի քանի նման գործողություններ։
Ըստ երևույթին, սեղմումները որևէ կերպ սահմանափակված չեն և կարող են առաջացնել սկավառակի I/O մեծ աճեր կատարման ընթացքում:
CPU-ի բեռնվածության աճեր
Իհարկե, սա բավականին բացասաբար է ազդում համակարգի արագության վրա, ինչպես նաև լուրջ մարտահրավեր է ներկայացնում LSM պահեստավորման համար. ինչպե՞ս անել խտացում՝ մեծ պահանջների տեմպերն ապահովելու համար՝ առանց ավելորդ ծախսեր առաջացնելու:
Հիշողության օգտագործումը խտացման գործընթացում նույնպես բավականին հետաքրքիր է թվում:
Մենք կարող ենք տեսնել, թե ինչպես է խտացումից հետո հիշողության մեծ մասը փոխում է վիճակը «Cached»-ից «Free»-ի. սա նշանակում է, որ պոտենցիալ արժեքավոր տեղեկատվությունը հեռացվել է այնտեղից: Հետաքրքիր է, արդյոք այն օգտագործվում է այստեղ fadvice() կամ մինիմալացման այլ տեխնիկա, թե՞ այն պատճառով, որ քեշը ազատվել է խտացման ժամանակ ոչնչացված բլոկներից:
Վերականգնում ձախողումից հետո
Անհաջողություններից վերականգնումը ժամանակ է պահանջում և լավ պատճառներով: Մեկ վայրկյանում միլիոն ձայնագրությունների մուտքային հոսքի համար ես ստիպված էի սպասել մոտ 25 րոպե, մինչ վերականգնումը կատարվեր՝ հաշվի առնելով SSD սկավառակը:
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-ի պատճառով: Միակ լուծումը, որը ես գտա, անջատելն էր տվյալների հավաքագրումը, սերվերը բարձրացնելը, թույլ տալ, որ այն վերականգնվի և վերագործարկվի հավաքածուն միացված վիճակում:
Տաքանալ
Մեկ այլ վարքագիծ, որը պետք է հիշել տաքացման ժամանակ, ցածր կատարողականության և ռեսուրսների բարձր սպառման միջև կապն է հենց սկզբից անմիջապես հետո: Որոշ, բայց ոչ բոլոր մեկնարկների ժամանակ ես նկատեցի լուրջ ծանրաբեռնվածություն պրոցեսորի և հիշողության վրա:
Հիշողության օգտագործման բացերը ցույց են տալիս, որ Պրոմեթևսը չի կարող սկզբից կարգավորել բոլոր հավաքածուները, և որոշ տեղեկություններ կորչում են:
Ես չեմ պարզել բարձր պրոցեսորի և հիշողության ծանրաբեռնվածության ճշգրիտ պատճառները: Ես կասկածում եմ, որ դա պայմանավորված է գլխային բլոկում բարձր հաճախականությամբ նոր ժամանակային շարքերի ստեղծմամբ։
CPU-ի բեռնվածության բարձրացում
Ի հավելումն խտացումների, որոնք ստեղծում են բավականին բարձր I/O բեռ, ես նկատեցի CPU-ի ծանրաբեռնվածության լուրջ աճեր յուրաքանչյուր երկու րոպեն մեկ: Պոռթկումներն ավելի երկար են, երբ մուտքային հոսքը մեծ է, և, ըստ երևույթին, առաջանում է Go-ի աղբահանի պատճառով, երբ առնվազն որոշ միջուկներ ամբողջությամբ բեռնված են:
Այս թռիչքներն այնքան էլ աննշան չեն։ Թվում է, որ երբ դրանք տեղի են ունենում, Պրոմեթևսի ներքին մուտքի կետը և չափումները անհասանելի են դառնում՝ պատճառելով տվյալների բացեր նույն ժամանակահատվածներում:
Կարելի է նկատել նաև, որ Պրոմեթևս արտահանողն անջատվում է մեկ վայրկյանով։
Կարելի է նկատել հարաբերակցություններ աղբահանության (GC) հետ։
Ամփոփում
Պրոմեթևս 2-ի TSDB-ն արագ է, ունակ է մշակել միլիոնավոր ժամանակային շարքեր և միևնույն ժամանակ վայրկյանում հազարավոր գրառումներ՝ օգտագործելով բավականին համեստ սարքավորում: Տպավորիչ է նաև պրոցեսորի և սկավառակի I/O օգտագործումը: Իմ օրինակը ցույց տվեց մինչև 200 չափումներ վայրկյանում մեկ օգտագործվող միջուկի համար:
Ընդլայնումը պլանավորելու համար հարկավոր է հիշել բավարար քանակությամբ հիշողություն, և դա պետք է լինի իրական հիշողություն: Օգտագործված հիշողության ծավալը, որը ես նկատեցի, կազմում էր մոտ 5 ԳԲ մուտքային հոսքի 100 գրառումների վայրկյանում, որը օպերացիոն համակարգի քեշի հետ միասին տալիս էր մոտ 000 ԳԲ զբաղված հիշողություն:
Իհարկե, դեռ շատ աշխատանք կա անելու պրոցեսորի և սկավառակի I/O ցատկերը ընտելացնելու համար, և դա զարմանալի չէ, եթե հաշվի առնենք, թե որքան երիտասարդ TSDB Prometheus 2-ը համեմատվում է InnoDB-ի, TokuDB-ի, RocksDB-ի, WiredTiger-ի հետ, բայց դրանք բոլորն էլ նման էին: խնդիրներ իրենց կյանքի ցիկլի սկզբում:
Source: www.habr.com