Prometheus ရဲ့ Data Type 4 ခု

ရှေ့တပိုင်းမှာတုန်းက ကျွန်တော်တို့တွေ Prometheus ကို ဘယ်လို install လုပ်ရမလဲဆိုတာရယ်၊ prometheus.yml ကို basic configuration လုပ်နည်းတွေ သိခဲ့ကြရတယ်။ ဒီနေ့အဆက်မှာ Prometheus ရဲ့ data type တွေအကြောင်း ပြောချင်တယ်။

Prometheus မှာ data type ၄ မျိုးရှိတဲ့အထဲက ပထမဆုံးတခုက gauge ဆိုတာဖြစ်တယ်။ gauge က metric တခုခုရဲ့ လက်ရှိ absolute တန်ဖိုးကို မှတ်တာဖြစ်တယ်။ ဥပမာ စက်တလုံးရဲ့ လက်ရှိ အပူချိန် ဘယ်လောက်ရှိတယ်ဆိုတာမျိုး။ ဒါမှမဟုတ် AI Image Generator အတွက် queue ထဲမှာ generate လုပ်စရာ task ဘယ်နှခုကျန်သေးတယ်ဆိုတာမျိုးပေါ့။ absolute တန်ဖိုးဖြစ်တဲ့အတွက် တန်ဖိုးက မြင့်သွားတာရော နိမ့်သွားတာပါ ဖြစ်နိုင်တယ်။

Prometheus မှာ metrics instrumentation ကို HTTP ပေါ်ကနေ plaintext နဲ့ transfer လုပ်တာဖြစ်လို့ Web ကနေ metric တွေအကုန်လုံးကို ၀င်ကြည့်လို့ ရပါတယ်။ ဟိုနေ့က ကျွန်တော်တို့ သုံးခဲ့တဲ့ sample server တွေထဲက တခုကို ဒီမှာ ဝင်ကြည့်ရင် gauge metric တခုဖြစ်တဲ့ demo_num_cpus ကိုဒီလိုပြထားတာ တွေ့ရမယ်။

# HELP demo_num_cpus The number of CPUs.
# TYPE demo_num_cpus gauge
demo_num_cpus 4

ဒုတိယတခုက counter လို့ခေါ်တယ်။ သူကကျ ရေတွက်တာပေါ့။ ဆိုင်စဖွင့်ကတည်းကနေ အခုချိန်ထိ customer ဘယ်နှယောက်ကို ရောင်းပေးခဲ့ပြီးပါပြီဆိုတာမျိုး။ ဒါမှမဟုတ် Backend တခုက HTTP request ဘယ်နှခုကို လက်ခံရရှိပြီးပြီဆိုတာမျိုး။ gauge နဲ့မတူတာက counter ဟာ တန်ဖိုးတက်လာတာပဲ ဖြစ်ရမယ်။ လျော့ကျသွားလို့မရဘူး။ လျော့သွားတယ်ဆိုရင် ဒါအဓိပ္ပါယ်မရှိဘူးပေါ့။

# HELP demo_cpu_usage_seconds_total The CPU usage in seconds split by mode.
#TYPE demo_cpu_usage_seconds_total counter
demo_cpu_usage_seconds_total{mode="idle"} 2.021391440375806e+07
demo_cpu_usage_seconds_total{mode="system"} 8.0854444173251875e+06
demo_cpu_usage_seconds_total{mode="user"} 1.212814197892936e+07

နောက်တခုက histogram တွေ။ တကယ်လို့ ကိုယ်က metric တခုကို range တွေသတ်မှတ်ပေးပြီး distribution ကြည့်ချင်တယ်ဆိုရင် histogram ကိုသုံးတယ်။ ဥပမာ ဆိုင်မှာ မုန့်လာဝယ်တဲ့အထဲက ဒေါ်လာ ၂၀ အောက်သုံးတာ ဘယ်နှယောက်၊ ဒေါ်လာ ၄၀ အောက်သုံးတာ ဘယ်နှယောက်၊ ဒေါ်လာ ၄၀ နဲ့အထက် ဝယ်တာက ဘယ်နှယောက်စသဖြင့်ပေါ့။ အဲလိုကြည့်ချင်တယ်ဆိုရင် histogram ရှိတယ်။ အဲဒီ ဒေါ်လာ ၂၀ အောက် ၄၀ အောက်ဆိုတဲ့ range တွေကိုတော့ bucket လို့ခေါ်တယ်။ bucket များရင် storage ပိုကုန်မယ်။ နည်းရင် data insight ကောင်းကောင်းမရဖြစ်မယ်ပေါ့။ ဒီတော့ သေချာစဥ်းစားပြီး bucket သတ်မှတ်ရမယ်။

# HELP demo_api_request_duration_seconds A histogram of the API HTTP request durations in seconds.
# TYPE demo_api_request_duration_seconds histogram
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.22168378200531003"} 1.82802031e+08
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.33252567300796504"} 1.82802031e+08
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.49878850951194753"} 1.82802031e+08
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="0.7481827642679213"} 1.82802031e+08
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="1.122274146401882"} 1.82802031e+08
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="1.683411219602823"} 1.82802031e+08
demo_api_request_duration_seconds_bucket{method="GET",path="/api/bar",status="200",le="+Inf"} 1.82802031e+08
demo_api_request_duration_seconds_sum{method="GET",path="/api/bar",status="200"} 3.2087850126682944e+06
demo_api_request_duration_seconds_count{method="GET",path="/api/bar",status="200"} 1.82802031e+08

တကယ်လို့ ကိုယ်က ဒေါ်လာ ၂၀ သုံးလား ၄၀ သုံးလားတွေ မသိချင်ဘူး။ ဆိုင်ကိုလာစားတဲ့သူ 99% ကဘယ်လောက်သုံးလဲ။ 75% ကဘယ်လောက်သုံးလဲ စသဖြင့် percentage အလိုက်ပဲ သိချင်တာဆိုရင် summary ကိုသုံးတယ်။ histogram လိုမျိုး insight မများတော့ပေမယ့် average ဘယ်လောက်ရှိလဲ best case ဘယ်လောက်ရှိလဲ စသဖြင့် သိနိုင်သေးတယ်။ storage လည်းသက်သာမယ်ပေါ့။

# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 4.7e-05
go_gc_duration_seconds{quantile="0.25"} 0.0001302
go_gc_duration_seconds{quantile="0.5"} 0.000202002
go_gc_duration_seconds{quantile="0.75"} 0.000275362
go_gc_duration_seconds{quantile="1"} 0.006545764
go_gc_duration_seconds_sum 1078.534885045
go_gc_duration_seconds_count 4.224344e+06

ဒါပေမယ့် သတိထားစရာတခု လမ်းကြုံပြောပြဦးမယ်။ Application တွေကို performance တိုင်းတာတဲ့အခါ response time နဲဲ့ပြောလေ့ရှိတယ်။ ဥပမာ ဒီ app ရဲ့ပျမ်းမျှ response time ကဘယ်နှစက္ကန့်ကြာပါတယ်ဆိုတာမျိုးပေါ့။ အဲဒီမှာ အများစုထင်တာက total duration ကို total count နဲ့စားလိုက်ရင် ရပြီလို့ ထင်ကြတယ်။ အဲလိုမဟုတ်ပါဘူး။ ဗမာလို ဘယ်လိုခေါ်လဲ မသိပေမယ့် statistics မှာ mean, median, mode ဆိုပြီး ငယ်ငယ်က သင်ဖူးခဲ့တာ မှတ်မိကြလိမ့်မယ်ထင်တယ်။ အပေါ်ကလို တွက်တာက mean လို့ခေါ်ပါတယ်။ ပျှမ်းမျှယူတယ်ပေါ့လေ။

ပြဿနာက request 5 ခုက 280 ms, 120 ms, 500 ms, 100 ms, 150 ms ဆိုပြီး ကြာခဲ့တယ်ဆိုပါတော့။ ဒါဆို ပျှမ်းမျှ 230 ms ဆိုပြီး ရလာပါမယ်။ ဒါပေမယ့် ဒီ scenario မှာဆိုရင် 230 ms က ဘယ် user ကမှကြုံခဲ့ရတာ မဟုတ်သလို user ဘယ်နှယောက်က ဒီပျမ်းမျှကို ခံစားခဲ့ရတာလဲဆိုတဲ့ အဖြေကိုလည်း မသိနိုင်ပါဘူး။ ပိုသင့်တော်တဲ့ အဖြေက ဒါတွေကို sort လိုက်ပြီး အလယ်ကိန်း median ကိုရှာတာပါပဲ။ အခုပေးထားတဲ့ အခြေအနေမှာဆိုရင် အဲဒါ 150 ms ဖြစ်တယ်။ ဒါဆို ကျွန်တော်တို့ ပြောနိုင်တာက request တွေရဲ့ 50% က 150 ms နဲ့အောက်ပဲ ကြာခဲ့တယ်ပေါ့။ အဲဒီကနေမှ 90%, 99% နဲ့ 99.9% စသဖြင့် tail latency ကိုတွက်လိုက်ရင် ကံဆိုးတဲ့ worse case တွေမှာတော့ outlier request တွေက ဘယ်လောက်ကြာခဲ့တယ်ဆိုတာမျိုးကို သိနိုင်မယ်။

နောက်တချက်က service တခုထက်မကကို aggregate လုပ်ပြီး performance တွက်ချင်တဲ့အခါမှာလည်း ပျှမ်းမျှတွေကို ပျှမ်းမျှခြင်း ပြန်ချလို့ ဘာအဓိပ္ပါယ်မှ မရှိပါဘူး။ service တခုချင်းစီက histogram bucket တွေကိုစုပြီး median တွက်မှသာ Gateway ကနေ ဒီ system ထဲကို ဝင်လာတဲ့ request တွေက Gateway ကိုပြန်ရောက်ဖို့ ​ဘယ်လောက်ကြာနေသလဲဆိုတာ နားလည်နိုင်မှာဖြစ်တယ်။

ဒါက Prometheus မှာပါတဲ့ data type 4 ခုပါ။ ကျွန်တော်တို့ နောက်တပိုင်းမှာ PromQL အကြောင်း ဆက်ကြပါမယ်။