«ExtendedPromQL»՝ Ռոման Խավրոնենկոյի զեկույցի սղագրությունը

Առաջարկում եմ կարդալ Ռոման Խավրոնենկոյի «ExtendedPromQL» զեկույցի սղագրությունը

Համառոտ իմ մասին. Իմ անունը Ռոման է։ Ես աշխատում եմ CloudFlare-ում և ապրում եմ Լոնդոնում: Բայց ես նաև VictoriaMetrics-ի սպասարկող եմ:
Իսկ հեղինակը ես եմ ClickHouse plugin Գրաֆանայի համար և ClickHouse- վստահված անձ ClickHouse-ի փոքր վստահված անձ է:

Կսկսենք առաջին մասից, որը կոչվում է «Թարգմանության դժվարություններ» և դրանում կխոսեմ այն ​​մասին, որ ցանկացած լեզու կամ նույնիսկ պարզապես հաղորդակցման լեզու շատ կարևոր է։ Որովհետև այսպես եք ձեր մտքերը փոխանցում մեկ այլ անձի կամ համակարգի, ինչպես եք ձևակերպում խնդրանքը: Ինտերնետում մարդիկ վիճում են, թե որ լեզուն է ավելի լավ՝ java-ն, թե որևէ այլ: Ինձ համար որոշեցի, որ պետք է ընտրեմ ըստ առաջադրանքի, քանի որ այս ամենը կոնկրետ է։

Սկսենք հենց սկզբից։ Ի՞նչ է PromQL-ը: PromQL-ը Պրոմեթևսի հարցման լեզու է: Այսպես մենք հարցումներ ենք կազմում Պրոմեթևսում՝ ժամանակային շարքերի տվյալներ ստանալու համար։

Ի՞նչ է ժամանակային շարքի տվյալները: Բառացիորեն դրանք երեք պարամետր են.

Սա է `

• Ի՞նչ ենք մենք նայում:
• Երբ մենք նայում ենք դրան.
• Իսկ ի՞նչ արժեք է դա ցույց տալիս։

Եթե ​​նայեք այս գծապատկերին (այս աղյուսակը իմ հեռախոսից է, որը ցույց է տալիս իմ քայլերի վիճակագրությունը), այն կարող է արագ պատասխանել այս հարցերին:

Մենք նայում ենք քայլերին. Մենք տեսնում ենք իմաստը և տեսնում ենք ժամանակը, երբ նայում ենք դրան: Այսինքն, նայելով այս գծապատկերին, հեշտությամբ կարող եք ասել, որ կիրակի օրը ես քայլեցի մոտ 15 քայլ։ Սա ժամանակային շարքի տվյալներ է:

Հիմա եկեք դրանք «բաժանենք» (վերափոխենք) տվյալների այլ մոդելի՝ աղյուսակի տեսքով։ Այստեղ մենք նաև ունենք այն, ինչ մենք նայում ենք: Այստեղ ես ավելացրեցի մի փոքր լրացուցիչ տվյալներ, որոնք մենք կանվանենք մետատվյալներ, այսինքն՝ ոչ թե ես եմ անցել, այլ երկու հոգի, օրինակ՝ Ջեյը և Լուռ Բոբը։ Սա այն է, ինչ մենք նայում ենք. ինչ է ցույց տալիս և երբ է ցույց տալիս այդ արժեքը։

Այժմ եկեք փորձենք պահպանել այս բոլոր տվյալները տվյալների բազայում: Օրինակ, ես վերցրեցի ClickHouse շարահյուսությունը: Եվ այստեղ մենք ստեղծում ենք մեկ աղյուսակ, որը կոչվում է «Քայլեր», այսինքն այն, ինչ մենք նայում ենք: Ժամանակ կա, երբ մենք նայում ենք դրան. ինչ է այն ցույց տալիս և որոշ մետա տվյալներ, որտեղ մենք կպահենք, թե ով է դա՝ Ջեյը և Լուռ Բոբը:

Եվ այս ամենը պատկերացնելու համար մենք կօգտագործենք Grafana-ն, քանի որ առաջին հերթին այն գեղեցիկ է:

Մենք կօգտագործենք նաև այս հավելվածը: Դրա համար երկու պատճառ կա. Առաջինն այն է, որ ես գրել եմ այն: Եվ ես հստակ գիտեմ, թե որքան դժվար է ժամանակային սերիաների տվյալները հանել ClickHouse-ից՝ դրանք Grafana-ում ցուցադրելու համար:

Մենք այն կցուցադրենք Graph Panel-ում: Սա Grafana-ի ամենահայտնի վահանակն է, որը ցույց է տալիս արժեքի կախվածությունը ժամանակից, ուստի մեզ անհրաժեշտ է ընդամենը երկու պարամետր:

Եկեք գրենք ամենապարզ հարցումը՝ ինչպես ցույց տալ քայլերի վիճակագրությունը Grafana-ում՝ այս տվյալները պահելով ClickHouse-ում՝ մեր ստեղծած աղյուսակում: Եվ մենք գրում ենք այս պարզ խնդրանքը. Մենք ընտրում ենք քայլերից. Մենք ընտրում ենք արժեք և ընտրում այս արժեքների ժամանակը, այսինքն նույն երեք պարամետրերը, որոնց մասին մենք խոսեցինք:

Եվ արդյունքում մենք կստանանք այսպիսի գրաֆիկ. Ո՞վ գիտի, թե ինչու է նա այդքան տարօրինակ:

Ճիշտ է, մենք պետք է դասավորենք ըստ ժամանակի:

Եվ վերջում մենք ավելի լավ, բայց դեռ տարօրինակ գրաֆիկ ենք ստանալու։ Ո՞վ գիտի, թե ինչու։ Ճիշտ է, երկու մասնակից կա, և մենք Grafana-ում տալիս ենք երկու ժամանակային սերիա, քանի որ եթե նորից նայեք տվյալների մոդելին, ապա յուրաքանչյուր ժամանակային սերիա անվան և բոլոր բանալիների արժեքի պիտակների եզակի համակցություն է:

Հետեւաբար, մենք պետք է ընտրենք կոնկրետ անձի: Մենք ընտրում ենք Ջեյին։

Եվ նորից նկարենք։ Այժմ գրաֆիկը կարծես ճշմարտություն է: Հիմա սա սովորական գրաֆիկ է, և ամեն ինչ լավ է աշխատում։

Եվ դուք հավանաբար գիտեք, թե ինչպես անել մոտավորապես նույն բանը, բայց Prometheus-ում PromQL-ի միջոցով: Այսպիսի մի բան. Մի քիչ ավելի պարզ. Եվ եկեք քանդենք այդ ամենը: Մենք քայլեր արեցինք. Եվ զտել ըստ Ջեյի: Մենք այստեղ չենք նշում, որ մենք պետք է արժեք ստանանք, և մենք ժամանակ չենք ընտրում:

Այժմ փորձենք հաշվարկել Ջեյի կամ Լուռ Բոբի շարժման արագությունը։ ClickHouse-ում մենք պետք է կատարենք runDifference, այսինքն՝ հաշվարկենք զույգ միավորների տարբերությունը և բաժանենք դրանք ժամանակի վրա՝ ճշգրիտ արագությունը ստանալու համար: Հարցումը նման տեսք կունենա.

Եվ դա ցույց կտա մոտավորապես այս արժեքները, այսինքն՝ Լուռ Բոբը կամ Ջեյը կատարում է մոտավորապես 1,8 քայլ վայրկյանում:

Եվ Պրոմեթևսում դուք նույնպես գիտեք, թե ինչպես դա անել: Շատ ավելի հեշտ, քան նախկինում էր:

Եվ Grafana-ում դա անելը նաև հեշտ դարձնելու համար ես ավելացրեցի այս փաթաթան, որը շատ նման է PromQL-ին: Այն կոչվում է Գնահատել մակրոները կամ ինչպես ուզում եք անվանեք: Grafana-ում դուք պարզապես գրում եք «դրույքաչափ», բայց ինչ-որ տեղ խորքում այն ​​վերածվում է այս մեծ խնդրանքի: Եվ դուք նույնիսկ պետք չէ դրան նայել, այն ինչ-որ տեղ կա, բայց դուք շատ ժամանակ եք խնայում, քանի որ նման հսկայական SQL հարցումներ գրելը միշտ թանկ է: Դուք հեշտությամբ կարող եք սխալվել, իսկ հետո երկար ժամանակ չհասկանալ, թե ինչ է կատարվում։

Եվ սա խնդրանք է, որը նույնիսկ մեկ սլայդի մեջ չէր տեղավորվում, և ես նույնիսկ ստիպված էի այն բաժանել երկու սյունակի: Սա նաև խնդրանք է ClickHouse-ում, որը կատարում է նույն տեմպը, բայց երկու ժամանակային սերիաների համար՝ Silent Bob և Jay, այնպես որ մենք ունենանք երկու ժամանակային շարք վահանակի վրա: Իսկ սա արդեն շատ դժվար է, իմ կարծիքով։

Իսկ ըստ Պրոմեթևսի դա կլինի գումար (դրույքաչափ): ClickHouse-ի համար ես պատրաստեցի առանձին մակրո, որը կոչվում է RateColumns, որը նման է հարցման Պրոմեթևսում:

Մենք նայեցինք դրան, և թվում է, թե PromQL-ն այնքան լավն է, բայց այն, իհարկե, սահմանափակումներ ունի:

Սա է `

• Սահմանափակ SELECT.
• Սահմանային միացումներ:
• ՉՈՒՆԵՆԱԼ աջակցություն:

Եվ եթե երկար ժամանակ աշխատել եք դրա հետ, ապա գիտեք, որ երբեմն շատ դժվար է ինչ-որ բան անել PromQL-ում, բայց SQL-ում դուք կարող եք գրեթե ամեն ինչ անել, քանի որ այս բոլոր տարբերակները, որոնց մասին մենք հենց նոր խոսեցինք, կարող էին արվել SQL-ով։ . Բայց արդյո՞ք հարմար կլիներ այն օգտագործել: Եվ դա ինձ ստիպում է մտածել, որ ամենահզոր լեզուն միշտ չէ, որ ամենահարմարն է:

Հետևաբար, երբեմն անհրաժեշտ է լեզու ընտրել առաջադրանքի համար: Դա նման է Բեթմենի դեմ Սուպերմենի հետ: Հասկանալի է, որ Սուպերմենն ավելի ուժեղ է, բայց Բեթմենը կարողացավ հաղթել նրան, քանի որ նա ավելի գործնական է և հստակ գիտեր, թե ինչ է անում։

Իսկ հաջորդ մասը Extending PromQL-ն է:

Եվս մեկ անգամ VictoriaMetrics-ի մասին։ Ինչ է VictoriaMetrics-ը: Սա ժամանակային շարքերի տվյալների բազա է, այն գտնվում է OpenSource-ում, մենք տարածում ենք դրա միայնակ և կլաստերային տարբերակները: Ըստ մեր չափանիշների, այն ավելի արագ է, քան այն, ինչ այժմ շուկայում է, և սեղմումը նման է, այսինքն, իրական մարդիկ նշում են սեղմում մոտ 0,4 բայթ մեկ կետում, մինչդեռ Պրոմեթևսի սեղմումը 1,2-1,4 է:

Մենք աջակցում ենք ոչ միայն Պրոմեթևսին: Մենք աջակցում ենք InfluxDB, Graphite, OpenTSDB:

Դուք կարող եք «գրել» մեզ, այսինքն՝ կարող եք փոխանցել հին տվյալները։

Եվ մենք նաև հիանալի աշխատում ենք Prometheus-ի և Grafana-ի հետ, այսինքն՝ մենք աջակցում ենք PromQL շարժիչին: Իսկ Grafana-ում դուք պարզապես կարող եք Prometheus-ի վերջնակետը փոխել VictoriaMetrics-ի, և ձեր բոլոր վահանակները կաշխատեն այնպես, ինչպես որ արեցին:

Բայց դուք կարող եք նաև օգտագործել լրացուցիչ հնարավորություններ, որոնք ապահովում է VictoriaMetrics-ը:

Մենք արագ կանցնենք մեր ավելացրած գործառույթներին:

Բաց թողնել միջակայքի պարամետրը – կարող եք բաց թողնել ինտերվալային պարամետրերը Grafana-ում: Երբ դուք չեք ցանկանում ստանալ տարօրինակ գծապատկերներ, երբ մեծացնում/փոքրացնում եք վահանակը, խորհուրդ է տրվում օգտագործել փոփոխականը. $__interval. Սա Grafana-ի ներքին փոփոխություն է և ինքն է ընտրում տվյալների տիրույթը: Եվ VictoriaMetrics-ն ինքը կարող է հասկանալ, թե ինչպիսին պետք է լինի այս տիրույթը: Եվ ձեզ հարկավոր չէ թարմացնել ձեր բոլոր հարցումները: Դա շատ ավելի հեշտ կլինի։

Երկրորդ գործառույթը միջակայքի հղումն է: Դուք կարող եք օգտագործել այս միջակայքը ձեր արտահայտություններում: Կարող եք բազմապատկել, բաժանել, փոխանցել, անդրադառնալ դրան։

Հաջորդը համախմբման գործառույթների ընտանիքն է: Համախմբման ֆունկցիան փոխակերպում է ձեր ցանկացած ժամանակային շարք երեք առանձին ժամանակային շարքերի: Սրանք նվազագույն, առավելագույն և միջին են: Ես սա շատ հարմար եմ համարում, քանի որ երբեմն այն կարող է ցույց տալ որոշ արտառոցություններ և անճշտություններ:

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

Հաջորդը լռելյայն փոփոխականն է: Կանխադրված - սա նշանակում է, թե ինչ արժեք պետք է նկարենք Grafana-ում, եթե տվյալ պահին չունենք ժամանակային շարք: Ե՞րբ է դա տեղի ունենում: Ենթադրենք, դուք արտահանում եք սխալի որոշ չափումներ: Եվ դուք ունեք այնպիսի հիանալի հավելված, որ երբ սկսում եք, ոչ մի սխալ և նույնիսկ սխալ չեք ունենա հաջորդ երեք ժամվա կամ նույնիսկ մեկ օրվա ընթացքում: Եվ դուք ունեք վահանակներ, որոնք ցույց են տալիս հարաբերությունները հաջողությունից սխալ: Եվ նրանք ձեզ ոչինչ ցույց չեն տա, քանի որ դուք սխալի չափիչ չունեք: Իսկ լռելյայն կարող եք ցանկացած բան նշել:

Keep_last_Value – պահպանում է չափման վերջին արժեքը, եթե այն բացակայում է: Եթե ​​Պրոմեթևսը չգտնի այն հաջորդ քերծվածքից հետո 5 րոպեի ընթացքում, ապա այստեղ մենք կհիշենք դրա վերջին արժեքը և ձեր գծապատկերներն այլևս չեն կոտրվի:

Scrape_interval – ցույց է տալիս, թե Prometheus-ը որքան հաճախ է հավաքում տվյալներ ձեր չափման վերաբերյալ և ինչ հաճախականությամբ: Այստեղ դուք կարող եք տեսնել, օրինակ, անցագիր:

Պիտակի փոխարինումը հայտնի հատկանիշ է: Բայց մենք կարծում ենք, որ դա մի փոքր բարդ է, քանի որ այն պահանջում է ամբողջական փաստարկներ: Եվ դուք պետք է ոչ միայն հիշեք 5 փաստարկներ, այլեւ հիշեք դրանց հաջորդականությունը:

Հետևաբար, ինչու չդարձնել դրանք ավելի պարզ: Այսինքն՝ բաժանել այն փոքր ֆունկցիաների՝ հասկանալի շարահյուսությամբ։

Իսկ հիմա զվարճալի մասը: Ինչո՞ւ ենք կարծում, որ սա ընդլայնված PromQL է: Քանի որ մենք աջակցում ենք ընդհանուր աղյուսակի արտահայտություններին: Դուք կարող եք հետևել QR կոդը (https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/ExtendedPromQL), տե՛ս խաղահրապարակից օրինակներով հղումները, որտեղ կարող ես հարցումներ կատարել անմիջապես VictoriaMetrics-ում՝ առանց զննարկիչում տեղադրելու:

Իսկ ի՞նչ է սա։ Վերևի այս խնդրանքը բավականին տարածված խնդրանք է: Կարծում եմ, շատ ընկերությունների ցանկացած վահանակում դուք օգտագործում եք նույն ֆիլտրը ամեն ինչի համար: Սովորաբար այդպես է։ Բայց երբ դուք պետք է ավելացնեք ինչ-որ նոր զտիչ, դուք պետք է թարմացնեք յուրաքանչյուր վահանակ կամ ներբեռնեք վահանակը, բացեք այն JSON-ով, գտնեք փոխարինում, ինչը նույնպես ժամանակ է պահանջում: Ինչու՞ չպահել այս արժեքը փոփոխականում և նորից օգտագործել այն: Սա, իմ կարծիքով, շատ ավելի պարզ և պարզ է թվում:

Օրինակ, երբ ես պետք է թարմացնեմ ֆիլտրերը Grafana-ում բոլոր հարցումներում, և վահանակը կարող է հսկայական լինել կամ նույնիսկ դրանցից մի քանիսը լինել: Իսկ ինչպե՞ս կցանկանայի լուծել այս խնդիրը Գրաֆանայում:

Ես այս խնդիրը լուծում եմ այսպես. ես ստեղծում եմ ընդհանուր ֆիլտր և սահմանում այս ֆիլտրը դրա մեջ, այնուհետև այն նորից օգտագործում եմ հարցումներում: Բայց եթե դուք նույնն անեք հիմա, այն չի աշխատի, քանի որ Grafana-ն թույլ չի տալիս Ձեզ օգտագործել փոփոխականներ հարցման փոփոխականների ներսում: Եվ դա մի փոքր տարօրինակ է:

Եվ այսպես, ես ստեղծել եմ մի տարբերակ, որը թույլ է տալիս դա անել: Եվ եթե դուք հետաքրքրված եք կամ ցանկանում եք նման հատկություն, ապա աջակցեք կամ չհավանեք այն, եթե ձեզ դուր չի գալիս այս գաղափարը: https://github.com/grafana/grafana/pull/16694

Ավելին ընդլայնված PromQL-ի մասին: Այստեղ մենք սահմանում ենք ոչ միայն փոփոխական, այլ մի ամբողջ ֆունկցիա։ Եվ մենք այն անվանում ենք ru (ռեսուրսների օգտագործում): Եվ այս ֆունկցիան ընդունում է անվճար ռեսուրսներ, ռեսուրսների սահմանափակում և զտիչ: Շարահյուսությունը կարծես պարզ է. Եվ շատ հեշտ է օգտագործել այս գործառույթը և հաշվարկել մեր ունեցած ազատ հիշողության տոկոսը: Այսինքն՝ որքան հիշողություն ունենք, ինչ սահմանափակում կա և ինչպես զտել։ Շատ ավելի հարմար է թվում, եթե այդ ամենը գրեիք՝ նորից օգտագործելով նույն ֆիլտրերը, քանի որ այն կվերածվեր մեծ, մեծ հարցման։

Եվ ահա այսպիսի մեծ, մեծ խնդրանքի օրինակ. Դա Grafana-ի պաշտոնական NodeExporter վահանակից է: Բայց ես հազիվ եմ հասկանում, թե ինչ է կատարվում այստեղ։ Դա, իհարկե, հասկանում եմ, եթե ուշադիր նայեք, բայց փակագծերի քանակը կարող է անմիջապես նվազեցնել մոտիվացիան՝ հասկանալու, թե ինչ է կատարվում այստեղ։ Իսկ ինչո՞ւ չդարձնել այն ավելի պարզ և պարզ:

Օրինակ՝ այսպես՝ նշանակալից իրերը կամ մասերը փոփոխականների բաժանելը։ Եվ հետո կատարեք ձեր հիմնական մաթեմատիկան: Սա արդեն ավելի շատ ծրագրավորման է նման, սա այն է, ինչ ես կցանկանայի ապագայում տեսնել Grafana-ում:

Ահա երկրորդ օրինակը, թե ինչպես մենք կարող էինք դա ավելի հեշտացնել, եթե մենք արդեն ունենայինք այս ru ֆունկցիան, և այն արդեն գոյություն ունի անմիջապես VictoriaMetrics-ում: Եվ դուք այնուհետև պարզապես փոխանցում եք CTE-ում հայտարարված քեշավորված արժեքը:

Ես արդեն խոսել եմ այն ​​մասին, թե որքան կարևոր է ճիշտ ծրագրավորման լեզու օգտագործելը։ Եվ, հավանաբար, Գրաֆանայի յուրաքանչյուր ընկերությունում ինչ-որ այլ բան է կատարվում: Եվ դուք հավանաբար նաև մուտք եք տալիս Grafana-ին ձեր ծրագրավորողներին, և մշակողները անում են իրենց գործը: Եվ նրանք բոլորն էլ դա անում են ինչ-որ կերպ տարբեր կերպ: Բայց ես ուզում էի, որ ինչ-որ կերպ նույնը լիներ, այսինքն՝ հասցնեի ընդհանուր ստանդարտի։

Ենթադրենք, դուք նույնիսկ չունեք միայն համակարգի ինժեներներ, գուցե դուք նույնիսկ ունեք փորձագետներ, devops կամ SRE: Գուցե դուք ունեք փորձագետներ, ովքեր գիտեն, թե ինչ է մոնիտորինգը, ովքեր գիտեն, թե ինչ է Grafana-ն, այսինքն՝ տարիներ շարունակ աշխատել են դրա հետ և հստակ գիտեն, թե ինչպես դա անել ճիշտ: Ու սա արդեն 100 անգամ գրել են ու բոլորին բացատրել, բայց չգիտես ինչու ոչ ոք չի լսում։

Ի՞նչ կլիներ, եթե նրանք կարողանան այս գիտելիքն ուղղակիորեն տեղադրել Grafana-ի մեջ, որպեսզի մյուս օգտվողները կարողանան նորից օգտագործել այդ հնարավորությունները: Եվ եթե նրանց անհրաժեշտ լիներ հաշվարկել ազատ հիշողության տոկոսը, նրանք պարզապես կկիրառեին ֆունկցիան։ Իսկ եթե արտահանողների ստեղծողները, իրենց արտադրանքի հետ մեկտեղ, տրամադրեին նաև մի շարք գործառույթներ, թե ինչպես աշխատել իրենց ցուցանիշների հետ, քանի որ նրանք հստակ գիտեն, թե որոնք են այդ ցուցանիշները և ինչպես ճիշտ հաշվարկել դրանք:

Սա իրականում գոյություն չունի: Սա այն է, ինչ ես ինքս եմ արել: Սա Գրաֆանայի գրադարանային աջակցությունն է: Ասենք NodeExporter սարքած տղաներն արեցին այն, ինչի մասին խոսեցի։ Եվ նրանք նաև մի շարք գործառույթներ էին ապահովում։

Այսինքն՝ կարծես այսպիսին է. Դուք միացնում եք այս գրադարանը Grafana-ին, անցնում եք խմբագրման և JSON-ով շատ պարզ գրված է, թե ինչպես աշխատել այս չափման հետ: Այսինքն՝ գործառույթների ինչ-որ հավաքածու, դրանց նկարագրությունը և ինչի են դրանք վերածվում։

Կարծում եմ, որ սա կարող է օգտակար լինել, քանի որ այն ժամանակ Գրաֆանայում դուք հենց այդպես կգրեիք։ Եվ Գրաֆանան «ասում է» ձեզ, որ կա այս և այն գործառույթը այսինչ գրադարանից. եկեք օգտագործենք այն: Կարծում եմ, որ դա շատ լավ կլիներ:

Մի փոքր VictoriaMetrics-ի մասին: Մենք շատ հետաքրքիր բաներ ենք անում։ Կարդացեք մեր հոդվածները սեղմման, այլ ժամանակային շարքերի տվյալների հավելվածների հետ մեր մրցույթների մասին, մեր բացատրությունը, թե ինչպես աշխատել PromQL-ի հետ, քանի որ դեռ շատ սկսնակներ կան դրանում, ինչպես նաև ուղղահայաց մասշտաբայնության և Thanos-ի հետ առճակատման մասին:

Հարցեր.

Հարցս կսկսեմ մի պարզ կյանքի պատմությունից. Երբ ես առաջին անգամ սկսեցի օգտագործել Grafana-ն, ես գրեցի շատ ազդեցիկ հարցում, որը 5 տող էր: Վերջնական արդյունքը շատ համոզիչ գրաֆիկ է։ Այս գրաֆիկը գրեթե մտել է արտադրության: Բայց ավելի ուշադիր ուսումնասիրելուց հետո պարզվեց, որ այս գրաֆիկը ցույց է տալիս բացարձակ անհեթեթություն, որը ոչ մի կապ չունի իրականության հետ, թեև թվերը ընկնում են այն տիրույթում, որը մենք ակնկալում էինք տեսնել: Եվ իմ հարցը. Մենք ունենք գրադարաններ, ունենք գործառույթներ, բայց ինչպե՞ս ենք թեստեր գրում Grafana-ի համար: Դուք գրել եք բարդ հարցում, որից կախված է բիզնեսի որոշումը՝ պատվիրե՞լ սերվերների իրական կոնտեյներ, թե՞ չպատվիրել։ Եվ ինչպես գիտենք, այս ֆունկցիան, որը գծում է գրաֆիկը, նման է ճշմարտությանը։ Շնորհակալություն.

Շնորհակալություն հարցի համար: Երկու մաս կա. Նախ, իմ փորձից ելնելով տպավորություն է ստեղծվում, որ օգտատերերի մեծ մասը, երբ նայում է իրենց գծապատկերներին, չի հասկանում, թե ինչ են ցույց տալիս: Չգիտես ինչու, մարդիկ շատ լավ են արդարացումներ գտնելու ցանկացած անոմալիայի համար, որը տեղի է ունենում գրաֆիկներում, նույնիսկ եթե դա ֆունկցիայի սխալ է: Եվ երկրորդ մասը, ինձ թվում է, որ նման գործառույթների օգտագործումը շատ ավելի լավ մոտեցում կլինի ձեր խնդիրը լուծելու համար, ոչ թե ձեր ծրագրավորողներից յուրաքանչյուրն անի իր կարողությունների պլանավորումը և որոշ հավանականությամբ սխալներ թույլ կտա:

Ինչպե՞ս ստուգել:

Ինչպե՞ս ստուգել: Հավանաբար ոչ.

Որպես թեստ Գրաֆանայում:

Ի՞նչ կապ ունի Գրաֆանան դրա հետ։ Grafana-ն այս հարցումն ուղղակիորեն թարգմանում է DataSource-ին:

Պարամետրերին մի փոքր ավելացնելով.

Ոչ, Գրաֆանային ոչինչ չի ավելացվում: Կարող են լինել GET պարամետրեր, ինչպես, ասենք, քայլը: Այն հստակ նշված չէ, բայց դուք կարող եք անտեսել այն, կամ կարող եք չվերացնել, բայց այն ավտոմատ կերպով ավելացվում է: Այստեղ թեստեր չեք գրի։ Չեմ կարծում, որ այստեղ մենք պետք է ապավինենք Գրաֆանային՝ որպես ճշմարտության աղբյուրի:

Շնորհակալություն զեկույցի համար: Շնորհակալություն սեղմման համար: Դուք նշեցիք գրաֆիկում փոփոխականի քարտեզագրումը, որ Grafana-ում չեք կարող փոփոխական օգտագործել փոփոխականի մեջ: Դուք գիտեք, թե ինչ նկատի ունեմ?

Այո:

Սա սկզբում գլխացավանք էր, երբ ես ուզում էի ահազանգ ստեղծել Grafana-ում: Եվ այնտեղ դուք պետք է զգուշացում կատարեք յուրաքանչյուր հաղորդավարի համար առանձին: Ձեր պատրաստած այս բանը, այն աշխատում է Grafana-ում ահազանգերի համար:

Եթե ​​Grafana-ն այլ կերպ չի մուտք գործում փոփոխականներ, ապա այո, այն կաշխատի: Բայց իմ խորհուրդն այն է, որ Grafana-ում ընդհանրապես չօգտագործել alerting, ավելի լավ է օգտագործել alertmanager-ը:

Այո, ես օգտագործում եմ այն, բայց թվում էր, թե ավելի հեշտ է տեղադրել Grafana-ում, բայց շնորհակալություն խորհրդի համար:

Source: www.habr.com