VictoriaMetrics နှင့် သီးသန့် cloud စောင့်ကြည့်ခြင်း။ Pavel Kolobaev

VictoriaMetrics သည် အချိန်စီးရီးပုံစံဖြင့် ဒေတာကို သိမ်းဆည်းခြင်းနှင့် စီမံဆောင်ရွက်ရန်အတွက် လျင်မြန်ပြီး အတိုင်းအတာ DBMS တစ်ခုဖြစ်သည် (မှတ်တမ်းတစ်ခုတွင် အချိန်နှင့် သက်ဆိုင်သည့် တန်ဖိုးများအစုတစ်ခုပါရှိသည်၊ ဥပမာ၊ အာရုံခံကိရိယာများ၏ အခြေအနေကို အချိန်အပိုင်းအခြားအလိုက် ကောက်ယူခြင်း သို့မဟုတ်၊ တိုင်းတာမှုများ စုစည်းမှု)။

ကျွန်တော့်နာမည် Kolobaev Pavel ပါ။ DevOps၊ SRE၊ LeroyMerlin၊ အရာအားလုံးသည် ကုဒ်နှင့်တူသည် - ကျွန်ုပ်အကြောင်းနှင့် အခြား LeroyMerlin ဝန်ထမ်းများအကြောင်း။

https://bit.ly/3jf1fIK

OpenStack ကိုအခြေခံ၍ cloud တစ်ခုရှိသည်။ နည်းပညာရေဒါ လင့်ခ်လေးတစ်ခုရှိပါတယ်။

၎င်းကို Kubernetes ဟာ့ဒ်ဝဲအပြင် OpenStack နှင့် မှတ်တမ်းအတွက် ဆက်စပ်ဝန်ဆောင်မှုအားလုံးတွင် တည်ဆောက်ထားသည်။

ဒါက ကျွန်တော်တို့ ဖွံ့ဖြိုးတိုးတက်ရေး အစီအစဉ်ပါ။ ကျွန်ုပ်တို့ ဤအရာအားလုံးကို တီထွင်နေစဉ်တွင်၊ ကျွန်ုပ်တို့တွင် K8s အစုအဝေးအတွင်း ဒေတာများကို သိမ်းဆည်းသည့် Prometheus အော်ပရေတာတစ်ခုရှိသည်။ အကြမ်းဖျင်းအားဖြင့် သူသည် ပွတ်တိုက်ရန် လိုအပ်သောအရာကို အလိုအလျောက် ရှာတွေ့ပြီး သူ့ခြေဖဝါးအောက်တွင် ထားလိုက်သည်။

ကျွန်ုပ်တို့သည် Kubernetes အစုအဝေးပြင်ပတွင် ဒေတာအားလုံးကို ရွှေ့ရန် လိုအပ်မည်ဖြစ်သည်၊ အကြောင်းမှာ တစ်စုံတစ်ခုဖြစ်လာပါက၊ ကျွန်ုပ်တို့သည် အဘယ်အရာနှင့် မည်သည့်နေရာတွင်ရှိသည်ကို နားလည်ရန်လိုအပ်သောကြောင့် ဖြစ်သည်။

ပထမဖြေရှင်းချက်မှာ ဖယ်ဒရေးရှင်းယန္တရားမှတဆင့် Kubernetes အစုအဝေးသို့သွားသည့်အခါ ကျွန်ုပ်တို့တွင် ပြင်ပအဖွဲ့အစည်း Prometheus ရှိသည့်အခါ ဖက်ဒရယ်ကိုအသုံးပြုခြင်းဖြစ်သည်။

ဒါပေမယ့် ဒီမှာ ပြဿနာလေးတွေရှိတယ်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ကျွန်ုပ်တို့တွင် မက်ထရစ်ပေါင်း 250 ရှိ၍ မက်ထရစ် 000 ရှိသောအခါတွင် ပြဿနာများစတင်ခဲ့ပြီး ထိုကဲ့သို့ လုပ်ဆောင်နိုင်မည်မဟုတ်ကြောင်း ကျွန်ုပ်တို့သဘောပေါက်ပါသည်။ ကျွန်ုပ်တို့သည် scrape_timeout ကို 400 စက္ကန့်အထိ တိုးမြှင့်ထားသည်။

ငါတို့ဘာကြောင့် ဒီလိုလုပ်ရမှာလဲ။ Prometheus သည် ခြံစည်းရိုးအစမှ ကုန်ဆုံးချိန်ကို စတင်ရေတွက်သည်။ ဒေတာစီးဆင်းနေသေးတာ အရေးမကြီးပါဘူး။ အကယ်၍ ဤသတ်မှတ်ထားသောအချိန်ကာလအတွင်း ဒေတာကို ပေါင်းစည်းခြင်းမပြုဘဲ http မှတစ်ဆင့် session ကို မပိတ်ပါက၊ session သည် ကျရှုံးသွားသည်ဟု ယူဆရပြီး ဒေတာသည် Prometheus ကိုယ်တိုင်သို့ မရောက်ပါ။

ဒေတာအချို့ ပျောက်ဆုံးနေချိန်တွင် ကျွန်ုပ်တို့ရရှိသည့် ဂရပ်များနှင့် လူတိုင်း ရင်းနှီးကြသည်။ အချိန်ဇယားတွေ ပျက်နေပြီး ဒါကို ကျွန်တော်တို့ မကျေနပ်ဘူး။

နောက်ရွေးချယ်မှုမှာ တူညီသောဖက်ဒရယ်ယန္တရားမှတဆင့် မတူညီသော Prometheus နှစ်ခုကို အခြေခံ၍ ခွဲထုတ်ခြင်းဖြစ်သည်။

ဥပမာအားဖြင့်၊ ၎င်းတို့ကိုယူ၍ နာမည်ဖြင့် ခွဲရုံသာဖြစ်သည်။ ဒါကိုလည်း သုံးနိုင်ပေမယ့် ဆက်လုပ်ဖို့ ဆုံးဖြတ်ခဲ့ပါတယ်။

ယခု ကျွန်ုပ်တို့သည် ဤအပိုင်းများကို တစ်နည်းနည်းဖြင့် စီမံဆောင်ရွက်ရမည်ဖြစ်ပါသည်။ shard ဧရိယာသို့သွားကာ ဒေတာကို မြှောက်ပေးသည့် promxy ကို သင်ယူနိုင်သည်။ ၎င်းသည် ဝင်ပေါက်အမှတ်တစ်ခုအဖြစ် shard နှစ်ခုဖြင့် အလုပ်လုပ်သည်။ ၎င်းကို promxy ဖြင့် အကောင်အထည်ဖော်နိုင်သော်လည်း ၎င်းသည် ခက်ခဲလွန်းနေသေးသည်။

ပထမရွေးချယ်မှုမှာ အဖွဲ့ချုပ်ယန္တရားသည် အလွန်နှေးကွေးသောကြောင့် ကျွန်ုပ်တို့ စွန့်လွှတ်လိုခြင်းဖြစ်သည်။

Prometheus developer များသည် "ယောက်ျားများ၊ ကျွန်ုပ်တို့သည် မက်ထရစ်များ ရေရှည်သိုလှောင်မှုကို မပံ့ပိုးနိုင်သောကြောင့် မတူညီသော TimescaleDB ကိုသုံးပါ" ဟု ရှင်းလင်းစွာပြောနေကြသည်။ ဒါက သူတို့တာဝန်မဟုတ်ဘူး။

အားလုံးကို တစ်နေရာတည်းမှာ သိမ်းမထားဖို့ အပြင်မှာ လွှင့်ပစ်ဖို့ လိုသေးကြောင်း စာရွက်တစ်ရွက်ပေါ်မှာ ချရေးပါ။

ဒုတိယအားနည်းချက်မှာ memory သုံးစွဲမှုဖြစ်သည်။ ဟုတ်ကဲ့၊ တော်တော်များများက 2020 မှာ မမ်မိုရီဂစ်ဂါဘိုက်နှစ်ကောင်ကို တစ်ပြားတစ်ချပ်မှ ကုန်ကျတယ်လို့ ပြောကြလိမ့်မယ်၊ ဒါပေမယ့်လည်း နားလည်ပါတယ်။

ယခု ကျွန်ုပ်တို့တွင် dev နှင့် ထုတ်ကုန်ပတ်ဝန်းကျင်တစ်ခုရှိသည်။ dev တွင် မက်ထရစ် 9 အတွက် 350 ဂစ်ဂါဘိုက်ခန့် ရှိသည်။ ထုတ်ကုန်တွင် ၁၄ ဂစ်ဂါဘိုက်ရှိပြီး မက်ထရစ် ၇၈၀,၀၀၀ ကျော်ရှိသည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့၏ထိန်းသိမ်းချိန်သည် မိနစ် 000 သာဖြစ်သည်။ ဒါက မကောင်းဘူး။ ယခုမူ ကျွန်ုပ်သည် အဘယ်ကြောင့်နည်း။

ကျွန်ုပ်တို့သည် မက်ထရစ်ပေါင်း တစ်သန်းခွဲခန့်ဖြင့် တွက်ချက်မှုတစ်ခုပြုလုပ်ပြီး ၎င်းတို့နှင့် နီးစပ်နေပြီဖြစ်ပြီး ဒီဇိုင်းအဆင့်တွင် ကျွန်ုပ်တို့သည် မှတ်ဉာဏ် 35-37 ဂစ်ဂါဗိုက်ကို ရရှိမည်ဖြစ်သည်။ သို့သော် မက်ထရစ်ပေါင်း ၄ သန်းသည် မှတ်ဉာဏ် ၉၀ ဂစ်ဂါဘိုက်ခန့် လိုအပ်သည်။ ဆိုလိုသည်မှာ၊ ၎င်းကို Prometheus developer များမှပေးသောဖော်မြူလာကို အသုံးပြု၍ တွက်ချက်ခဲ့ခြင်းဖြစ်သည်။ ဆက်စပ်မှုကို ကြည့်ရှုပြီး ဆာဗာတစ်လုံးအတွက် သန်းနှစ်ဆယ်လောက် ပေးချေလိုခြင်းမရှိကြောင်း ကျွန်ုပ်တို့ သဘောပေါက်ပါသည်။

ကျွန်ုပ်တို့သည် စက်အရေအတွက်ကို တိုးမြှင့်ရုံသာမက virtual machines များကိုလည်း ၎င်းတို့ကိုယ်တိုင် စောင့်ကြည့်နေပါသည်။ ထို့ကြောင့်၊ virtual machines များလေ၊ အမျိုးမျိုးသော မက်ထရစ်များ များပြားလေ၊ စသည်ဖြင့်၊ မက်ထရစ်များ၏ သတ်မှတ်ချက်များတွင် ကျွန်ုပ်တို့၏ အစုအဝေး၏ အထူးတိုးတက်မှုကို ရရှိမည်ဖြစ်ပါသည်။

ဒစ်ခ်နေရာလွတ်ဖြင့် ဤနေရာ၌ အရာအားလုံးသည် ဤမျှဆိုးရွားသည်မဟုတ်သော်လည်း ၎င်းကို မြှင့်တင်လိုပါသည်။ ကျွန်ုပ်တို့သည် 15 ရက်အတွင်း စုစုပေါင်း 120 ဂစ်ဂါဘိုက်ကို လက်ခံရရှိပြီး ၎င်းတို့အနက် 100 သည် ချုံ့ထားသောဒေတာဖြစ်ပြီး 20 သည် ချုံ့မထားသောဒေတာဖြစ်သည်၊ သို့သော် ကျွန်ုပ်တို့အမြဲတမ်းလျော့နည်းလိုပါသည်။

ထို့ကြောင့်၊ ကျွန်ုပ်တို့သည် နောက်ထပ်အချက်တစ်ချက်ကို ချရေးလိုက်ပါသည် - ဤသည်မှာ ကျွန်ုပ်တို့ သိမ်းဆည်းလိုသော အရင်းအမြစ်များ သုံးစွဲမှု များပြားနေသည်၊ အကြောင်းမှာ ကျွန်ုပ်တို့၏ စောင့်ကြည့်ရေးအစုအဖွဲ့သည် OpenStack ကို စီမံခန့်ခွဲသည့် ကျွန်ုပ်တို့၏ အစုအဖွဲ့ထက် အရင်းအမြစ်များကို ပိုမိုစားသုံးရန် မလိုလားသောကြောင့် ဖြစ်သည်။

Prometheus ၏နောက်ထပ်အားနည်းချက်တစ်ခုရှိပါသည်၊ ၎င်းသည်အနည်းဆုံးမှတ်ဉာဏ်ကန့်သတ်ချက်အချို့ဖြစ်သည်။ Prometheus နှင့်အတူ၊ ဤနေရာတွင် ဤကဲ့သို့ လှည့်ကွက်များ လုံးဝမရှိသောကြောင့် အရာအားလုံးက ပိုဆိုးသည်။ docker တွင် ကန့်သတ်ချက်ကို အသုံးပြုခြင်းသည်လည်း ရွေးချယ်စရာတစ်ခုမဟုတ်ပါ။ အကယ်၍ သင်၏ RAF သည် ရုတ်တရက် ပြုတ်ကျပြီး 20-30 ဂစ်ဂါဘိုက် ရှိနေပါက တက်လာရန် အချိန်အတော်ကြာမည်ဖြစ်သည်။

ဤသည်မှာ Prometheus သည် ကျွန်ုပ်တို့အတွက် မသင့်လျော်သည့် အကြောင်းရင်းဖြစ်သည်၊ ဆိုလိုသည်မှာ ကျွန်ုပ်တို့သည် မှတ်ဉာဏ်သုံးစွဲမှုကို ကန့်သတ်၍မရပါ။

ထိုသို့သော အစီအစဥ်မျိုး ဖြစ်ပေါ်လာနိုင်ပေသည်။ HA အစုအဝေးကို စုစည်းရန်အတွက် ဤအစီအစဉ်ကို ကျွန်ုပ်တို့ လိုအပ်ပါသည်။ ဤမက်ထရစ်များကို သိမ်းဆည်းသည့်ဆာဗာ ပျက်သွားလျှင်ပင် ကျွန်ုပ်တို့၏ မက်ထရစ်များကို နေရာတိုင်းနှင့် အမြဲရရှိနိုင်စေလိုပါသည်။ ဒါကြောင့်လည်း ဒီလိုမျိုး အစီအစဥ်ကို တည်ဆောက်ရပါလိမ့်မယ်။

ဤအစီအစဥ်သည် ကျွန်ုပ်တို့တွင် shards များထပ်ပွားရမည်ဖြစ်ပြီး၊ ထို့ကြောင့်၊ စားသုံးထားသောအရင်းအမြစ်များ၏ကုန်ကျစရိတ်များ ထပ်ပွားမည်ဟုဆိုသည်။ ၎င်းကို အလျားလိုက်နီးပါး အတိုင်းအတာဖြင့် တိုင်းတာနိုင်သော်လည်း သယံဇာတ သုံးစွဲမှုမှာ ငရဲကျမည်ဖြစ်သည်။

အားနည်းချက်များကို ကျွန်ုပ်တို့ကိုယ်တိုင် ရေးမှတ်ထားသော ပုံစံဖြင့် အစီအစဥ်အတိုင်း၊

• မက်ထရစ်များကို ပြင်ပတွင် အပ်လုဒ်တင်ရန် လိုအပ်သည်။
• သယံဇာတ သုံးစွဲမှု မြင့်မားခြင်း။
• မှတ်ဉာဏ်သုံးစွဲမှုကို ကန့်သတ်ရန် နည်းလမ်းမရှိပါ။
• HA ၏ ရှုပ်ထွေးပြီး အရင်းအမြစ်များ အထူးပြု အကောင်အထည်ဖော်ခြင်း။

ကျွန်ုပ်တို့ကိုယ်တိုင်အတွက်၊ ကျွန်ုပ်တို့သည် သိုလှောင်ရုံတစ်ခုအဖြစ် Prometheus မှ ထွက်ခွာရန် ဆုံးဖြတ်ခဲ့သည်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့လိုအပ်သော ကျွန်ုပ်တို့ကိုယ်တိုင်အတွက် နောက်ထပ်လိုအပ်ချက်များကို ရှာဖွေဖော်ထုတ်ထားပါသည်။ ဤ-

• Prometheus အတွက် အကြောင်းအရာများစွာကို ရေးသားထားပြီးဖြစ်သောကြောင့် promql ပံ့ပိုးမှုဖြစ်ပါသည်- မေးမြန်းချက်များ၊ သတိပေးချက်များ။
• ထို့နောက် ကျွန်ုပ်တို့တွင် Prometheus အတွက် ကျောထောက်နောက်ခံအဖြစ် အတိအကျရေးထားပြီးဖြစ်သည့် Grafana ရှိသည်။ ဒက်ရှ်ဘုတ်များကို ပြန်မရေးချင်ပါ။
• ကျွန်ုပ်တို့သည် သာမန် HA ဗိသုကာကို တည်ဆောက်လိုပါသည်။
• ကျွန်ုပ်တို့သည် မည်သည့်အရင်းအမြစ်များကိုမဆို သုံးစွဲမှုကို လျှော့ချလိုပါသည်။
• နောက်ထပ်ထူးခြားချက်လေးတစ်ခုရှိပါသေးတယ်။ cloud တိုင်းထွာစုဆောင်းမှုစနစ် အမျိုးအစားအမျိုးမျိုးကို ကျွန်ုပ်တို့ အသုံးမပြုနိုင်ပါ။ ဤမက်ထရစ်များတွင် မည်သည့်အရာများ ကျရောက်လာမည်ကို ကျွန်ုပ်တို့ မသိရသေးပါ။ ပြီးတော့ အဲဒီမှာ ဘာမဆို ပျံသန်းနိုင်တဲ့အတွက်ကြောင့် ကျွန်တော်တို့ဟာ ကိုယ့်ကိုကိုယ် ကန့်သတ်ထားရမယ်။

ရွေးချယ်မှုအနည်းငယ်ရှိခဲ့သည်။ အတွေ့အကြုံတွေ အားလုံးကို စုဆောင်းတယ်။ ပေါင်းစည်းမှုအပိုင်းရှိ Prometheus စာမျက်နှာကို ကြည့်ရှုခဲ့ပြီး ဆောင်းပါးများစွာကို ဖတ်ရှုကာ အပြင်တွင် ရှိနေသည်ကို တွေ့ခဲ့ရသည်။ ကျွန်ုပ်တို့ကိုယ်တိုင်အတွက်၊ ကျွန်ုပ်တို့သည် Prometheus အတွက် အစားထိုးအဖြစ် VictoriaMetrics ကို ရွေးချယ်ခဲ့သည်။

အဘယ်ကြောင့်? ဘာဖြစ်လို့လဲဆိုတော့:

• promql ကို သိတယ်။
• Modular ဗိသုကာတစ်ခုရှိပါတယ်။
• Grafana တွင် ပြောင်းလဲမှုများ မလိုအပ်ပါ။
• အရေးအကြီးဆုံးမှာ၊ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏ကုမ္ပဏီအတွင်း မက်ထရစ်သိုလှောင်မှုကို ဝန်ဆောင်မှုတစ်ခုအဖြစ် ပံ့ပိုးပေးလိမ့်မည်ဖြစ်သောကြောင့်၊ သုံးစွဲသူများသည် အစုအဖွဲ့၏အရင်းအမြစ်အားလုံးကို အကန့်အသတ်အချို့ဖြင့် အသုံးပြုနိုင်ရန် အမျိုးမျိုးသောကန့်သတ်ချက်များဆီသို့ ကြိုတင်ရှာဖွေနေပါသည်။ multitenancy ရှိမည်၊

ပထမဆုံး နှိုင်းယှဉ်ကြည့်ရအောင်။ ကျွန်ုပ်တို့သည် အစုအဝေးအတွင်း၌ တူညီသော Prometheus ကိုယူ၍ ပြင်ပ Prometheus သည် ၎င်းဆီသို့သွားပါသည်။ remoteWrite VictoriaMetrics မှတဆင့်ထည့်ပါ။

VictoriaMetrics မှ CPU သုံးစွဲမှု အနည်းငယ် တိုးလာသည်ကို ဤနေရာတွင် ကျွန်ုပ်ချက်ချင်း ကြိုတင်မှာထားပါမည်။ VictoriaMetrics wiki သည် သင့်အား မည်သည့် parameters များကို အကောင်းဆုံးဖြစ်ကြောင်း ပြောပြသည်။ သူတို့ကို စစ်ဆေးတယ်။ ၎င်းတို့သည် CPU သုံးစွဲမှုကို အလွန်ကောင်းမွန်စွာ လျှော့ချထားသည်။

ကျွန်ုပ်တို့၏အခြေအနေတွင် Kubernetes အစုအဝေးတွင်ရှိသော Prometheus ၏မှတ်ဉာဏ်သုံးစွဲမှုသည် သိသိသာသာတိုးမလာပါ။

ကျွန်ုပ်တို့သည် တူညီသောဒေတာ၏ ဒေတာအရင်းအမြစ်နှစ်ခုကို နှိုင်းယှဉ်ပါသည်။ Prometheus တွင် အလားတူ ပျောက်ဆုံးနေသော ဒေတာကို ကျွန်ုပ်တို့တွေ့မြင်ရသည်။ VictoriaMetrics တွင် အရာအားလုံး အဆင်ပြေပါသည်။

Disk space စမ်းသပ်မှုရလဒ်များ။ Prometheus တွင်ကျွန်ုပ်တို့သည်စုစုပေါင်း 120 gigabyte ကိုလက်ခံရရှိခဲ့သည်။ VictoriaMetrics တွင် ကျွန်ုပ်တို့သည် တစ်နေ့လျှင် 4 ဂစ်ဂါဘိုက် ရရှိပြီးဖြစ်သည်။ Prometheus တွင်ကျွန်ုပ်တို့မြင်တွေ့နေကျအရာထက်အနည်းငယ်ကွဲပြားသောယန္တရားတစ်ခုရှိသည်။ ဆိုလိုသည်မှာ ဒေတာကို နာရီဝက်အတွင်း တစ်ရက်အတွင်း ကောင်းစွာ ဖိသိပ်ထားပြီးဖြစ်သည်။ ဒေတာများ ပျောက်ဆုံးနေသေးသော်လည်း၊ ၎င်းတို့သည် တစ်နေ့လျှင် နာရီဝက်အတွင်း ကောင်းမွန်စွာ ရိတ်သိမ်းပြီးဖြစ်သည်။ ရလဒ်အနေဖြင့်၊ ကျွန်ုပ်တို့သည် disk space တွင်သိမ်းဆည်းထားသည်။

ကျွန်ုပ်တို့သည် မှတ်ဉာဏ်အရင်းအမြစ်သုံးစွဲမှုကိုလည်း သက်သာစေပါသည်။ စမ်းသပ်ချိန်တွင်၊ ကျွန်ုပ်တို့သည် Prometheus ကို virtual machine - 8 cores၊ 24 gigabytes တွင်အသုံးပြုထားသည်။ Prometheus သည် အရာအားလုံးနီးပါး စားသည်။ သူက OOM Killer ပေါ်လဲကျသွားတယ်။ တစ်ချိန်တည်းမှာပင်၊ 900 သာတက်ကြွသောမက်ထရစ်များကို၎င်းထဲသို့သွန်းလောင်းခဲ့သည်။ ၎င်းသည် တစ်စက္ကန့်လျှင် 000-25 မက်ထရစ်များဖြစ်သည်။

ကျွန်ုပ်တို့သည် RAM 8 ဂစ်ဂါဗိုက်ပါရှိသော dual-core virtual machine တစ်ခုတွင် VictoriaMetrics ကို လုပ်ဆောင်ခဲ့သည်။ ကျွန်ုပ်တို့သည် 8GB စက်တွင် အရာအနည်းငယ်ဖြင့် ကောင်းစွာအလုပ်လုပ်ရန် VictoriaMetrics ကို ရယူနိုင်ခဲ့သည်။ အဆုံးတွင်၊ ကျွန်ုပ်တို့ ၎င်းကို 7 ဂစ်ဂါဘိုက်အထိ ထားရှိခဲ့သည်။ တစ်ချိန်တည်းမှာပင်၊ ဆိုလိုသည်မှာ မက်ထရစ်များ ပေးပို့ခြင်း၏ အမြန်နှုန်းသည် Prometheus ၏ထက်ပင် မြင့်မားခဲ့သည်။

CPU သည် Prometheus နှင့် ယှဉ်လျှင် များစွာ ပိုကောင်းလာသည်။ ဤတွင် Prometheus သည် 2,5 cores ကိုစားသုံးပြီး VictoriaMetrics သည် 0,25 cores သာစားသုံးသည်။ အစတွင် - 0,5 cores ။ ပေါင်းစည်းလိုက်သည်နှင့်အမျှ ၎င်းသည် အူတိုင်တစ်ခုသို့ရောက်ရှိသွားသော်လည်း ၎င်းသည် အလွန်ရှားပါးသည်၊ အလွန်ရှားပါးသည်။

ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ရွေးချယ်မှုသည် ထင်ရှားသောအကြောင်းပြချက်များကြောင့် VictoriaMetrics တွင် ကျဆင်းသွားသည်၊ ကျွန်ုပ်တို့သည် ငွေကိုချွေတာလိုပြီး ကျွန်ုပ်တို့လုပ်ဆောင်ခဲ့သည်။

အချက်နှစ်ချက်ကို ချက်ခြင်းဖြတ်ကြပါစို့ - မက်ထရစ်များကို အပ်လုဒ်တင်ခြင်းနှင့် အရင်းအမြစ်များ သုံးစွဲမှုမြင့်မားခြင်း။ ကိုယ့်အတွက် ကျန်နေသေးတဲ့ အချက်နှစ်ချက်ကိုပဲ ဆုံးဖြတ်ရမယ်။

ဤတွင် ကျွန်ုပ်သည် ချက်ချင်း ကြိုတင်စာရင်းသွင်းလိုက်မည်၊ ကျွန်ုပ်တို့သည် VictoriaMetrics ကို မက်ထရစ်များ သိုလှောင်မှုအဖြစ် သတ်မှတ်သည်။ သို့သော် ကျွန်ုပ်တို့သည် Leroy အားလုံးအတွက် သိုလှောင်မှုအဖြစ် VictoriaMetrics ကို ပေးစွမ်းနိုင်သောကြောင့် ဤအစုအဝေးကို အသုံးပြုမည့်သူများကို ကန့်သတ်ရန် လိုအပ်ပါသည်။

အချိန်အားဖြင့်၊ ဒေတာပမာဏအားဖြင့်နှင့် လုပ်ဆောင်ချိန်အားဖြင့် ကန့်သတ်ရန်ခွင့်ပြုသည့် အံ့သြဖွယ် parameter တစ်ခုရှိသည်။

Memory သုံးစွဲမှုကို ကန့်သတ်ရန် အကောင်းဆုံး ရွေးချယ်ခွင့်လည်း ရှိပြီး၊ ထို့ကြောင့် ပုံမှန်လည်ပတ်မှု အမြန်နှုန်းနှင့် လုံလောက်သော အရင်းအမြစ် သုံးစွဲမှုတို့ကို ရရှိစေမည့် ချိန်ခွင်လျှာကို ရှာဖွေနိုင်သည်။

အနှုတ်နောက်တစ်ခု၊ ဆိုလိုသည်မှာ အမှတ်ကိုဖြတ်လိုက်သည် - မှတ်ဉာဏ်သုံးစွဲမှုကို သင်ကန့်သတ်၍မရပါ။

ပထမအကြိမ်တွင်၊ ကျွန်ုပ်တို့သည် VictoriaMetrics Single Node ကို စမ်းသပ်ခဲ့သည်။ ထို့နောက် VictoriaMetrics Cluster Version သို့ ဆက်သွားပါမည်။

ဤနေရာတွင် VictoriaMetrics ရှိ မတူညီသောဝန်ဆောင်မှုများကို ၎င်းတို့လုပ်ဆောင်မည့်အရာနှင့် ၎င်းတို့သုံးစွဲမည့်အရင်းအမြစ်များပေါ်မူတည်၍ ကွဲပြားသောဝန်ဆောင်မှုများကို ဤနေရာတွင် ကျွန်ုပ်တို့တွင် အခမဲ့ခွဲထုတ်ရန် လက်ရှိသည်။ ဤသည်မှာ အလွန်ပြောင်းလွယ်ပြင်လွယ်နှင့် အဆင်ပြေသောဖြေရှင်းချက်ဖြစ်သည်။ ဒါကို ကျွန်တော်တို့ ကိုယ်တိုင်သုံးတယ်။

VictoriaMetrics Cluster Version ၏ အဓိက အစိတ်အပိုင်းများမှာ vmstsorage ဖြစ်သည်။ ၎င်းတို့တွင် N နံပါတ်ရှိနိုင်သည်။ ကျွန်တော်တို့ ကိစ္စမှာ အခုထိ ၂ ယောက်ရှိတယ်။

ပြီးတော့ vminsert ရှိတယ်။ ၎င်းသည် ကျွန်ုပ်တို့အား ခွင့်ပြုပေးသော ပရောက်စီဆာဗာတစ်ခုဖြစ်သည်- ကျွန်ုပ်တို့ပြောပြခဲ့သည့် သိုလှောင်မှုအားလုံးကြားတွင် ခွဲခြမ်းစိပ်ဖြာမှုကို စီစဉ်ပေးပြီး၊ ၎င်းသည် ပုံတူတစ်ခုကိုလည်း ခွင့်ပြုပေးသည်၊ ဆိုလိုသည်မှာ သင့်တွင် sharding နှင့် ပုံစံတူ နှစ်မျိုးလုံးရှိမည်ဖြစ်သည်။

Vminsert သည် Prometheus မှ OpenTSDB၊ Graphite၊ InfluxDB နှင့် remoteWrite ပရိုတိုကောများကို ပံ့ပိုးပေးသည်။

vmselect လည်းရှိပါတယ်။ ၎င်း၏အဓိကတာဝန်မှာ vmstorage သို့သွားရန်၊ ၎င်းတို့ထံမှဒေတာကိုရယူရန်၊ ဤဒေတာကိုပွားပြီး client ကိုပေးခြင်းဖြစ်သည်။

vmagent လို့ ခေါ်တဲ့ အံ့သြစရာကောင်းတဲ့ အရာတစ်ခုရှိပါတယ်။ ငါတို့သူမကိုတကယ်ကြိုက်တယ်။ ၎င်းသည် သင့်အား Prometheus ကဲ့သို့ အတိအကျ configure လုပ်နိုင်ပြီး Prometheus ကဲ့သို့ အတိအကျ လုပ်ဆောင်နိုင်သေးသည်။ ဆိုလိုသည်မှာ၊ ၎င်းသည် မတူညီသော အဖွဲ့အစည်းများနှင့် ဝန်ဆောင်မှုများမှ မက်ထရစ်များကို စုဆောင်းပြီး vminsert သို့ ပေးပို့သည်။ ဒါဆိုရင် အရာအားလုံးက မင်းအပေါ်မှာပဲ မူတည်တယ်။

အခြားကောင်းမွန်သောဝန်ဆောင်မှုမှာ vmalert ဖြစ်ပြီး၊ သင်သည် VictoriaMetrics ကို နောက်ခံအဖြစ်အသုံးပြုရန်၊ vminsert မှ စီမံဆောင်ရွက်ထားသော ဒေတာကို လက်ခံပြီး vmselect သို့ ပေးပို့နိုင်စေပါသည်။ ၎င်းသည် သတိပေးချက်များကို ၎င်းတို့ကိုယ်တိုင် လုပ်ဆောင်သည့်အပြင် စည်းမျဉ်းများဖြစ်သည်။ သတိပေးချက်များ၌ ကျွန်ုပ်တို့သည် သတိပေးချက်မန်နေဂျာမှတစ်ဆင့် သတိပေးချက်ကို လက်ခံရရှိပါသည်။

wmauth အစိတ်အပိုင်းတစ်ခုရှိသည်။ ကျွန်ုပ်တို့သည် ၎င်းကို အစုအဝေး၏ များပြားသော ဗားရှင်းအတွက် ခွင့်ပြုချက်စနစ်အဖြစ် အသုံးပြုနိုင်သည် သို့မဟုတ် မလုပ်ဆောင်နိုင်ပါ။ ၎င်းသည် Prometheus အတွက် remoteWrite ကိုပံ့ပိုးပေးပြီး သင်ရေးသားနိုင်သည် သို့မဟုတ် မရေးနိုင်သော url ကိုအခြေခံ၍ သို့မဟုတ် ၎င်း၏ဒုတိယအပိုင်းကိုအခြေခံ၍ ခွင့်ပြုနိုင်သည်။

vmbackup၊ vmrestore လည်းရှိပါတယ်။ ဤသည်မှာ အနှစ်သာရအားဖြင့် ဒေတာအားလုံး၏ ပြန်လည်ထူထောင်ခြင်းနှင့် အရန်ကူးခြင်း ဖြစ်သည်။ S3, GCS, file တွေလုပ်လို့ရတယ်။

ကျွန်ုပ်တို့၏အစုအဝေး၏ပထမဆုံးအကြိမ်ကို သီးသန့်ခွဲထားစဉ်အတွင်း ပြုလုပ်ခဲ့သည်။ ထိုအချိန်တွင်၊ ပုံစံတူမရှိသောကြောင့် ကျွန်ုပ်တို့၏ ထပ်တူပြုခြင်းတွင် remoteWrite မှတစ်ဆင့် ဒေတာလက်ခံရရှိသည့် မတူညီသော သီးခြားအစုအဝေးနှစ်ခု ပါဝင်ပါသည်။

ဤနေရာတွင် ကျွန်ုပ်တို့ VictoriaMetrics Single Node မှ VictoriaMetrics Cluster ဗားရှင်းသို့ ပြောင်းသောအခါ၊ ကျွန်ုပ်တို့သည် တူညီသော သုံးစွဲထားသော အရင်းအမြစ်များဖြစ်သည့် အဓိကအရာမှာ မမ်မိုရီဖြင့် ကျန်နေသေးကြောင်း ဤနေရာတွင် ကြိုတင်မှာကြားထားပါမည်။ ဤသည်မှာ ကျွန်ုပ်တို့၏ဒေတာ၊ ဆိုလိုသည်မှာ အရင်းအမြစ်သုံးစွဲမှုအား ဖြန့်ဝေပုံကို ခန့်မှန်းခြေအားဖြင့် ဖြစ်ပါသည်။

ပုံတူတစ်ခုကို ဤနေရာတွင် ထည့်သွင်းပြီးဖြစ်သည်။ ဤအရာအားလုံးကို ကျွန်ုပ်တို့သည် အတော်လေးကြီးမားသော အစုအဝေးတစ်ခုအဖြစ် ပေါင်းစပ်ထားသည်။ ကျွန်ုပ်တို့၏ဒေတာအားလုံးကို ခွဲခြမ်းစိပ်ဖြာပြီး ပုံတူကူးထားသည်။

အစုအဝေးတစ်ခုလုံးတွင် N entry point များပါရှိသည်၊ ဆိုလိုသည်မှာ Prometheus သည် HAPROXY မှတစ်ဆင့် ဒေတာကို ထည့်နိုင်သည်။ ဤတွင် ကျွန်ုပ်တို့တွင် ဤဝင်ခွင့်အမှတ်ရှိသည်။ ဤဝင်ပေါက်အမှတ်မှတဆင့်သင် Grafana မှဝင်ရောက်နိုင်သည်။

ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ HAPROXY သည် ဤအစုအဝေးအတွင်းတွင် ပရောက်စီများကို ရွေးချယ်၊ ထည့်သွင်းရန်နှင့် အခြားဝန်ဆောင်မှုများကိုပေးသည့် တစ်ခုတည်းသောဆိပ်ကမ်းဖြစ်သည်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ လိပ်စာတစ်ခုတည်းကို ပြုလုပ်ရန်မဖြစ်နိုင်ပါ၊ အဘယ်ကြောင့်ဆိုသော် ကျွန်ုပ်တို့သည် VictoriaMetrics အစုအဝေးလည်ပတ်သည့် virtual machines များသည် တူညီသော cloud ပံ့ပိုးပေးသူ၏ မတူညီသောဇုန်များတွင် တည်ရှိသောကြောင့်၊ ဥပမာ၊ ကျွန်ုပ်တို့၏ cloud အတွင်းမဟုတ်ဘဲ အပြင်ဘက်တွင်ရှိသော virtual machines များဖြစ်သောကြောင့်၊ .

ကျွန်ုပ်တို့တွင် သတိပေးချက်ရှိသည်။ အဲဒါကို သုံးပါတယ်။ ကျွန်ုပ်တို့သည် Prometheus မှ သတိပေးချက်မန်နေဂျာကို အသုံးပြုသည်။ ကျွန်ုပ်တို့သည် Opsgenie နှင့် Telegram အား သတိပေးချက်ပေးပို့ခြင်းချန်နယ်တစ်ခုအဖြစ် အသုံးပြုပါသည်။ Telegram တွင် ၎င်းတို့သည် ထုတ်ကုန်မှ တစ်ခုခုဖြစ်နိုင်သော်လည်း အင်ဂျင်နီယာများ လိုအပ်သော ကိန်းဂဏန်းအချက်အလတ်တစ်ခုဖြစ်သည်။ Opsgenie သည် အရေးကြီးသည်။ ဒါတွေဟာ ခေါ်ဆိုမှုတွေ၊ အဖြစ်အပျက်တွေကို စီမံခန့်ခွဲခြင်းတွေပါ။

ထာဝရမေးခွန်း- "စောင့်ကြည့်မှုကို ဘယ်သူက စောင့်ကြည့်တာလဲ။" ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ကျွန်ုပ်တို့သည် node တစ်ခုစီတွင် vmagent ကိုအသုံးပြုသောကြောင့် စောင့်ကြည့်စစ်ဆေးသည့်မော်နီတာများသည် သူ့အလိုလိုစောင့်ကြည့်နေသည်။ ကျွန်ုပ်တို့၏ node များကို တူညီသောဝန်ဆောင်မှုပေးသူ၏ မတူညီသောဒေတာစင်တာများတွင် ဖြန့်ဝေထားသောကြောင့်၊ ဒေတာစင်တာတစ်ခုစီတွင် ၎င်း၏ကိုယ်ပိုင်ချန်နယ်ရှိပြီး ၎င်းတို့သည် သီးခြားဖြစ်ပြီး သီးခြားဦးနှောက်တစ်ခုရောက်ရှိလာပါကပင် ကျွန်ုပ်တို့သည် သတိပေးချက်များကို လက်ခံရရှိဆဲဖြစ်သည်။ ဟုတ်တယ်၊ သူတို့ထဲက ပိုများလိမ့်မယ်၊ ဒါပေမယ့် ဘယ်အရာမှထက် သတိပေးချက်တွေ ပိုလက်ခံတာက ပိုကောင်းပါတယ်။

ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏စာရင်းကို HA အကောင်အထည်ဖော်မှုဖြင့် အဆုံးသတ်ပါသည်။

ထို့အပြင် VictoriaMetrics အသိုင်းအဝိုင်းနှင့် ဆက်သွယ်ခြင်း၏ အတွေ့အကြုံကို မှတ်သားလိုပါသည်။ ဒါဟာအလွန်အပြုသဘောထွက်လှည့်။ ယောက်ျားလေးတွေက တုံ့ပြန်တယ်။ ကမ်းလှမ်းတဲ့ ကိစ္စတိုင်းကို စေ့စေ့စပ်စပ် ကြိုးစားကြတယ်။

GitHub တွင် ပြဿနာများ စတင်ခဲ့သည်။ သူတို့သည် အလွန်လျင်မြန်စွာ ဖြေရှင်းခဲ့ကြသည်။ လုံးလုံးမပိတ်နိုင်သော နောက်ထပ်ပြဿနာအချို့ရှိပါသည်၊ သို့သော် ဤလမ်းညွှန်ချက်တွင် လုပ်ဆောင်နေဆဲဖြစ်သော ကုဒ်မှ ကျွန်ုပ်မြင်နိုင်နေပြီဖြစ်သည်။

ထပ်ခါထပ်ခါလုပ်နေချိန်မှာ ကျွန်တော့်အတွက် အဓိက နာကျင်မှုက node တစ်ခုကို ပိတ်လိုက်ရင် ပထမ စက္ကန့် 30 မှာ vminsert က backend မရှိဘူးဆိုတာကို နားမလည်နိုင်ပါဘူး။ ဒါကို အခု ဆုံးဖြတ်ပြီးပြီ။ တစ်စက္ကန့် သို့မဟုတ် နှစ်စက္ကန့်အတွင်း ဒေတာကို ကျန်ရှိသော node များအားလုံးမှ ထုတ်ယူပြီး တောင်းဆိုချက်သည် ပျောက်ဆုံးနေသော ကုဒ်ကို စောင့်ဆိုင်းနေခြင်းကို ရပ်သွားစေသည်။

တစ်ချိန်ချိန်တွင် ကျွန်ုပ်တို့သည် VictoriaMetrics ကို VictoriaMetrics အော်ပရေတာအဖြစ် လိုလားခဲ့ကြသည်။ ငါတို့က သူ့ကိုစောင့်နေတယ်။ ကျွန်ုပ်တို့သည် Prometheus အော်ပရေတာနှင့်အတူ ပါလာသော စည်းမျဉ်းများကို အလွန်တက်ကြွစွာ အသုံးပြုနေသောကြောင့် ကျွန်ုပ်တို့သည် ကြိုတင်တွက်ချက်ခြင်းဆိုင်ရာ စည်းမျဉ်းများ စသည်တို့ကို လုပ်ဆောင်ရန် VictoriaMetrics အော်ပရေတာအတွက် မူဘောင်တစ်ခုကို တက်ကြွစွာတည်ဆောက်နေပါသည်။

အစုအဖွဲ့ အကောင်အထည်ဖော်မှု တိုးတက်စေရန် အဆိုပြုချက်များ ရှိပါသည်။ အဲဒါတွေကို အပေါ်မှာ ကျွန်တော် ရေးထားပါတယ်။

ပြီးတော့ ကျွန်တော် တကယ်ကို နှိမ့်ချချင်ပါတယ်။ ကျွန်ုပ်တို့၏အခြေအနေတွင်၊ ခေတ်ရေစီးကြောင်းများကိုကြည့်ရှုရန်အတွက် နှိမ့်ချနမူနာယူရန် သီးသန့်လိုအပ်ပါသည်။ အကြမ်းဖျင်းပြောရရင် တစ်နေ့တာမှာ မက်ထရစ်တစ်ခုက လုံလောက်ပါတယ်။ ဤလမ်းကြောင်းများသည် တစ်နှစ်၊ သုံး၊ ငါး၊ ဆယ်နှစ်အတွက် လိုအပ်သည်။ မက်ထရစ်တန်ဖိုးတစ်ခုသည် လုံလောက်သည်။

• Prometheus ကိုအသုံးပြုသောအခါတွင် ကျွန်ုပ်တို့၏လုပ်ဖော်ကိုင်ဖက်အချို့ရှိသကဲ့သို့ ကျွန်ုပ်တို့သည် နာကျင်မှုကိုသိပါသည်။
• ကျွန်ုပ်တို့ကိုယ်တိုင်အတွက် VictoriaMetrics ကိုရွေးချယ်ခဲ့သည်။
• ၎င်းသည် ဒေါင်လိုက်နှင့် အလျားလိုက် နှစ်ခုစလုံးကို ကောင်းမွန်စွာ တိုင်းတာသည်။
• ကျွန်ုပ်တို့သည် မတူညီသော အစိတ်အပိုင်းများကို အစုအဝေးရှိ နံပါတ်အမျိုးမျိုးသို့ ဖြန့်ဝေနိုင်သည်၊ ၎င်းတို့အား မန်မိုရီဖြင့် ကန့်သတ်ခြင်း၊ မမ်မိုရီထည့်ခြင်း စသည်ဖြင့် ပြုလုပ်နိုင်ပါသည်။

ကျွန်ုပ်တို့သည် ၎င်းကို အလွန်နှစ်သက်သောကြောင့် အိမ်တွင် VictoriaMetrics ကို အသုံးပြုပါမည်။ ဤအရာသည် အဘယ်အရာနှင့် ဖြစ်လာသနည်း။

https://t.me/VictoriaMetrics_ru1

VictoriaMetrics ချတ်၊ ကျွန်ုပ်၏အဆက်အသွယ်များ၊ LeroyMerlin နည်းပညာဆိုင်ရာ ရေဒါအတွက် QR ကုဒ်အချို့။

source: www.habr.com