Prometheus နဲ့ Monitoring အခြေခံ

monitoring ဆိုတာ application security ကိုမြင်တတ်ကြသလိုမျိုး ဆော့ဝဲရဲ့ ရေးစရာရှိသမျှ အကုန်ရေးပြီး functional ဖြစ်ပြီဆိုတော့မှ နောက်ကနေ လိုက်ထည့်ဖို့ စဥ်းစားဖြစ်ကြတဲ့ ခေါင်းစဥ်ပေါ့။ အဲလိုမလုပ်သင့်ဘူးဆိုတာတော့ ရှေ့မှာ ပြောခဲ့ပြီးပါပြီ။

Prometheus က metric-monitoring tool တခုပါ။ အဲဒါ ဘာထူးလဲဆိုရင် log ထုတ်တဲ့ ကိစ္စမျိုးက prometheus ရဲ့တာဝန် မဟုတ်ဘူး။ ဒါကိုနားလည်အောင် monitoring နဲ့ medium 4 ခုကို အခြေခံလောက် ရှင်းမှဖြစ်မယ်။ monitoring ရဲ့အရိုးရှင်းဆုံးပုံစံက software အလုပ်လုပ်နေလား၊ မလုပ်နေဘူးလား သိရဖို့ပါ။ ဒါကြောင့် pinging script နဲ့ traffic profiling script တွေက monitoring ရဲ့ primitive နမူနာတွေဖြစ်တယ်။

တကယ်လည်း profiling script ဒါမှမဟုတ် profiling က monitoring ရဲ့အစဖြစ်ခဲ့တာပါ။ Android Studio ထဲမှာဆိုရင် profiling အတွက် tool တွေအကုန် အဆင်သင့်ပါတယ်။ profiling ဆိုတာက program နဲ့ machine ထဲ ဘာတွေ အသေးစိတ်ဖြစ်နေသလဲ ဥပမာ request throttled rate, memory နဲ့ CPU consumption, app component reRender စသဖြင့် ကြည့်တာပါပဲ။

နောက်တခုက log တွေပါ။ Error log တွေက အများစုနဲ့ ရင်းနှီးကြပါတယ်။ try, catch, finally မှာ log တွေထုတ်ပြီး ပြန်စစ်တာမျိုးက တွေ့ရများတယ်။ ဥပမာ ပိုက်ဆံနဲ့ ပတ်သက်တဲ့ app တွေမှာ transaction failed သွားတဲ့ log တွေကို ပြန်ကြည့်နိုင်ဖို့ သိပ်အရေးကြီးပါတယ်။ အဲဒီအပြင် error မဟုတ်တဲ့ Info log နဲ့ Debug log တွေကိုလည်း ထုတ်လို့ရပါတယ်။ ခုနက profiling နဲ့ မတူတာက logging က event-based ဖြစ်သွားတဲ့အတွက် (ဥပမာ error တကြိမ်တက်ရင် log 1 ခု၊ နှစ်ကြိမ်တက်ရင် log နှစ်ခု ထွက်မှာဖြစ်လို့) storage ကို ဂရုစိုက်ရပါတယ်။ ဒီ log တွေကို ကောင်းကောင်းသုံးနိုင်ဖို့ log rotation, log ingestion တွေပါ ထပ်ပြင်ဆင်ဖို့ လိုအပ်တယ်။

တတိယက tracing ပါ။ tracing ဆိုတာ business action တခုကို ကိုယ့် program ထဲ ခြေရာခံတာဖြစ်တယ်။ ဥပမာ user က shopping cart ကို check out လုပ်မယ့် request ပို့လိုက်တဲ့အခါ request က identity gateway ကနေ orchestrator ဆီကို ဘယ်အချိန်မှာရောက်တယ်။ orchestrator ကတဆင့် users, warehouse, payment, shipping နဲ့ notification service တွေကို ထပ်ချိတ်တာ ဘယ်လောက်ကြာတယ်။ အဲဒါရဲ့ ရလဒ်က success လား fail လား စသဖြင့်ပေါ့။

နောက်ဆုံးတခုက metric ပါ။

request တခု fail သွားတဲ့အခါ အဲဒီ request ရဲ့ method, path, remote origin နဲ့ credentials စတာတွေကို log ကတာဝန်ယူပြီး မှတ်လိမ့်မယ်။ tracing ကအဲဒီ request ရဲ့ရှေ့နဲ့နောက် context တွေကို နားလည်နိုင်အောင် တာဝန်ယူလိမ့်မယ်။ profiling ကဒီ request fail သွားတဲ့ အချိန်ဝန်းကျင်လောက်မှာ ရှိခဲ့တဲ့ environment အနေအထားကို ပုံဖော်ပေးလိမ့်မယ်။

ဒါပေမယ့် metric ကတော့ စုစုပေါင်း request ဘယ်နှခုရှိလဲ။ ဘယ်နှခု 200 Status Ok ဖြစ်ခဲ့လဲ။ ဘယ်နှခုက 404 Not Found ဖြစ်ခဲ့လဲ။ ဘယ်နှခု Internal Server Error ထိခဲ့လဲဆိုတဲ့ data (metric) ကိုစုပါတယ်။ database connection ဘယ်နှခုက idle လဲ။ connection pool ပြည့်နေလို့ စောင့်ခဲ့ရတဲ့အချိန် ပျှမ်းမျှ ဘယ်လောက်ရှိလဲ။ ဒီမေးခွန်းတွေ ဖြေဖို့အတွက် metric monitoring system တွေဆောက်ကြပါတယ်။ Prometheus ကအဲဒီလို tool ပါ။

Prometheus ရဲ့ design က pull based server ဖြစ်တာကြောင့် ဘယ် machine/program တွေဆီက data ယူရမှာလဲဆိုတာ သိနိုင်အောင် registration လုပ်ဖို့လိုတယ်။ အဲဒီအတွက် သူ့မှာ service discovery ပါပါတယ်။ data လာတောင်းရင်ပေးနိုင်ဖို့ application တွေဖက်ကလည်း client library သုံးပြီး အသင့်ပြင်ထားရပါတယ်။ ဒါကို instrumentation လုပ်တယ် ခေါ်ပါတယ်။ ဒါပေမယ့် ကိုယ့် application တွေက metric ကို prometheus format မဟုတ်ပဲ တခြား ပုံစံနဲ့ instrument ဖို့လိုလို့ ဒါမှမဟုတ် 3rd party app တွေ ဥပမာ Proxy နဲ့ Database ဆီက metric တွေလိုချင်လို့ဆိုတဲ့အခါမျိုးတွေမှာတော့ exporter လို့ခေါ်တဲ့ adapter ကို သုံးနိုင်တယ်။

prometheus မှာ database လည်းပါတယ်။ ဒါကြောင့် metric အကုန်လုံးကို local မှာတင်သိမ်းထားနိုင်သလို remote storage ကိုလှမ်းသိမ်းချင်လည်း ရပါတယ်။ နောက်တချက်က prometheus မှာ PromQL ဆိုတာရှိပါတယ်။ recording နဲ့ alerting rule တွေကို သတ်မှတ်ထားရင် အဲဒီ rule တွေအတိုင်း query ဆွဲပြီး ဖတ်လို့ရသလို threshold ကျော်ရင် alert ပါဆောက်ခိုင်းလို့ရပါတယ်။ alert တွေကိုတော့ alert manager ကတာဝန်ယူပြီး mail ပို့တာ၊ issue ဖွင့်တာ စသဖြင့် လုပ်ခိုင်းလို့ရပါတယ်။

ခဏတဖြုတ် ad hoc ဝင်ကြည့်ချင်ရင် ကြည့်နိုင်အောင် graph mode ပါပါတယ်။ အသေးစိတ် visualization လုပ်ဖို့အတွက်ဆိုရင်တော့ external tool တခုခုကို သုံးပြီး prometheus ရဲ့ database ကို source အဖြစ် ပြန်ယူသင့်ပါတယ်။ အဲဒီနေရာမှာတော့ Grafana ကနာမည်ကျော်ပါတယ်။