Prometheus၊ Clickhouse နှင့် ELK တွင် စောင့်ကြည့်လေ့လာခြင်းကို ကျွန်ုပ်တို့ မည်သို့တည်ဆောက်ခဲ့သနည်း။

ကျွန်တော့်နာမည် Anton Baderin ပါ။ ကျွန်တော် High Technology Center မှာ အလုပ်လုပ်ပြီး System Administration လုပ်ပါတယ်။ လွန်ခဲ့သောတစ်လက၊ ကျွန်ုပ်တို့၏ကော်ပိုရိတ်ကွန်ဖရင့်သည် ပြီးဆုံးခဲ့ပြီး၊ ကျွန်ုပ်တို့၏စုဆောင်းထားသောအတွေ့အကြုံကို ကျွန်ုပ်တို့မြို့၏အိုင်တီအသိုင်းအဝန်းနှင့် မျှဝေခဲ့ပါသည်။ ဝဘ်အက်ပလီကေးရှင်းများကို စောင့်ကြည့်ခြင်းအကြောင်း ပြောခဲ့သည်။ ဤလုပ်ငန်းစဉ်ကို အစမှမတည်ဆောက်ဘဲ အငယ်တန်း သို့မဟုတ် အလယ်တန်းအဆင့်အတွက် ရည်ရွယ်ပါသည်။

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

စီမံကိန်းအကြောင်း

ပရောဂျက်သည် နိုင်ငံအတွင်း အကြီးမားဆုံး သစ္စာစောင့်သိမှု အစီအစဉ်များထဲမှ တစ်ခုဖြစ်သည်။ ဘောနပ်စ်ကတ်များကဲ့သို့သော စျေးကွက်ချဲ့ထွင်ရေးကိရိယာအမျိုးမျိုးဖြင့် လက်လီရောင်းချသည့်လုပ်ငန်းခွဲများကို ကျွန်ုပ်တို့ ကူညီပေးပါသည်။ စုစုပေါင်း၊ ပရောဂျက်တွင် ဆာဗာဆယ်ခုတွင် လုပ်ဆောင်သည့် အက်ပ် ၁၄ ခု ပါဝင်သည်။

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

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

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

Prometheus

ကျွန်ုပ်တို့သည် အဓိကညွှန်းကိန်းသုံးခုအပေါ် အခြေခံ၍ Prometheus ကိုရွေးချယ်ခဲ့သည်

1. ရနိုင်သော မက်ထရစ်များ အများအပြား။ ငါတို့ကိစ္စမှာ ၆၀ဝဝ ရှိတယ်။ ဟုတ်ပါတယ်၊ အဲဒါတွေကို အများစု (၉၅%) လောက် မသုံးဘူးဆိုတာ မှတ်သားထိုက်ပါတယ်။ အခြားတစ်ဖက်တွင်၊ ၎င်းတို့အားလုံးသည်အတော်လေးစျေးပေါသည်။ ကျွန်ုပ်တို့အတွက်၊ ၎င်းသည်ယခင်အသုံးပြုထားသော Icinga နှင့် နှိုင်းယှဉ်ပါက အခြားအစွန်းရောက်မှုဖြစ်သည်။ ၎င်းတွင်၊ မက်ထရစ်များထည့်ခြင်းသည် ဝေဒနာတစ်ခုဖြစ်သည်- ရှိပြီးသားအရာများသည် စျေးကြီးသည် (မည်သည့် plugin ၏အရင်းအမြစ်ကုဒ်ကိုမဆိုကြည့်ပါ)။ မည်သည့် plugin မဆို Bash သို့မဟုတ် Python တွင် script တစ်ခုဖြစ်ခဲ့သည်၊ ၎င်းသည် အရင်းအနှီးများသုံးစွဲမှုအရ စျေးကြီးသည်။
2. ဤစနစ်သည် အရင်းအမြစ်အနည်းငယ်ကို သုံးစွဲသည်။ RAM 600 MB၊ core တစ်ခု၏ 15% နှင့် IOPS ဒါဇင်နှစ်ဆယ်သည် ကျွန်ုပ်တို့၏မက်ထရစ်များအားလုံးအတွက် လုံလောက်ပါသည်။ ဟုတ်ပါတယ်၊ သင်သည် မက်ထရစ်ပို့ကုန်လုပ်ငန်းရှင်များကို လုပ်ဆောင်ရန် လိုအပ်သော်လည်း ၎င်းတို့အားလုံးကို Go တွင် ရေးသားထားပြီး ပါဝါဆာလောင်မှုလည်း မရှိပါ။ ခေတ်သစ်လက်တွေ့မှာတော့ ဒါက ပြဿနာတစ်ခုလို့ မထင်ဘူး။
3. Kubernetes သို့ပြောင်းရွှေ့နိုင်စွမ်းကိုပေးသည်။ ဖောက်သည်၏အစီအစဥ်များကို ထည့်သွင်းစဉ်းစားပါက ရွေးချယ်မှုသည် ထင်ရှားသည်။

ဆတ်

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

ကလစ်တိုက်

အစတွင်၊ ရွေးချယ်မှုသည် InfluxDB တွင်ကျဆင်းခဲ့သည်။ Nginx မှတ်တမ်းများ၊ pg_stat_statements များမှ စာရင်းအင်းများ စုဆောင်းရန်နှင့် Prometheus သမိုင်းဆိုင်ရာ အချက်အလက်များကို သိမ်းဆည်းရန် လိုအပ်ကြောင်း ကျွန်ုပ်တို့ သဘောပေါက်ထားပါသည်။ အခါအားလျော်စွာ မှတ်ဉာဏ်ပမာဏများစွာကို စားသုံးပြီး ပျက်စီးသွားသောကြောင့် Influx ကို ကျွန်ုပ်တို့ မကြိုက်ပါ။ ထို့အပြင်၊ ကျွန်ုပ်သည် remote_addr ဖြင့် မေးခွန်းများကို အုပ်စုဖွဲ့ချင်သော်လည်း ဤ DBMS တွင် အုပ်စုဖွဲ့ခြင်းသည် တဂ်များဖြင့်သာ ဖြစ်သည်။ တဂ်များသည် စျေးကြီးသည် (မှတ်ဉာဏ်)၊ ၎င်းတို့၏ အရေအတွက်ကို သတ်မှတ်ချက်အရ ကန့်သတ်ထားသည်။

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

Clickhouse သည် ဤသတ်မှတ်ချက်များနှင့် ကိုက်ညီပြီး ကျွန်ုပ်တို့၏ရွေးချယ်မှုကို ဘယ်တော့မှ နောင်တမရပါ။ ကျွန်ုပ်တို့သည် ၎င်းထဲသို့ ထူးထူးခြားခြား ဒေတာပမာဏကို မရေးပါ (ထည့်သွင်းမှုအရေအတွက်သည် တစ်မိနစ်လျှင် ငါးထောင်ခန့်သာ)။

NewRelic

NewRelic သည် ဖောက်သည်၏ရွေးချယ်မှုဖြစ်သောကြောင့် ကျွန်ုပ်တို့နှင့်အတူ သမိုင်းကြောင်းရှိခဲ့သည်။ ကျွန်ုပ်တို့သည် ၎င်းကို APM အဖြစ်အသုံးပြုသည်။

Zabbix

ကျွန်ုပ်တို့သည် API အမျိုးမျိုး၏ Black Box ကို စောင့်ကြည့်ရန် Zabbix ကို သီးသန့်အသုံးပြုပါသည်။

စောင့်ကြည့်လေ့လာရေးနည်းလမ်းကို သတ်မှတ်ခြင်း။

ကျွန်ုပ်တို့သည် လုပ်ငန်းကို ပြိုကွဲစေလိုပြီး စောင့်ကြည့်လေ့လာခြင်းဆိုင်ရာ ချဉ်းကပ်မှုကို စနစ်တကျ ပြုလုပ်လိုပါသည်။

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

• ဟာ့ဒ်ဝဲနှင့် VMS;
• ကွန်ပျူတာစက်လည်ပတ်ရေးစနစ်ပရိုဂရမ်;
• စနစ်ဝန်ဆောင်မှုများ၊ software stack;
• လျှောက်လွှာ;
• စီးပွားရေးယုတ္တိဗေဒ။

ဒီနည်းလမ်းက ဘာကြောင့် အဆင်ပြေရတာလဲ။

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

ကျွန်ုပ်တို့၏တာဝန်မှာ စနစ်၏လုပ်ဆောင်မှုတွင် ချိုးဖောက်မှုများကို ဖော်ထုတ်ရန်ဖြစ်သောကြောင့်၊ အဆင့်တစ်ခုစီတွင် သတိပေးချက်စည်းမျဉ်းများရေးသားသည့်အခါ ဂရုပြုသင့်သည့် တိုင်းတာမှုအချို့ကို မီးမောင်းထိုးပြရမည်ဖြစ်သည်။ ထို့နောက် “VMS”၊ “Operating System” နှင့် “System services၊ software stack” အဆင့်များကို ဖြတ်သန်းကြပါစို့။

စက်အတုများ

Hosting သည် ကျွန်ုပ်တို့အား ပရိုဆက်ဆာ၊ ဒစ်ခ်၊ မမ်မိုရီနှင့် ကွန်ရက်တစ်ခုကို ခွဲဝေပေးသည်။ ပြီးတော့ ပထမနှစ်ယောက်နဲ့လည်း ပြဿနာတက်ခဲ့တယ်။ ထို့ကြောင့်၊ တိုင်းတာချက်များ-

CPU ခိုးယူခံရသည့်အချိန် - Amazon (ဥပမာ t2.micro၊ ဥပမာ) တွင် virtual machine တစ်ခုကို သင်ဝယ်သောအခါတွင် သင်သည် ပရိုဆက်ဆာ core တစ်ခုလုံးကို ခွဲဝေပေးမထားသော်လည်း ၎င်း၏အချိန်ခွဲတမ်းတစ်ခုသာဖြစ်ကြောင်း နားလည်ထားသင့်သည်။ ၎င်းကိုသင်ကုန်ခမ်းသောအခါ၊ ပရိုဆက်ဆာကို သင့်ထံမှ ဖယ်ထုတ်မည်ဖြစ်သည်။

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

IOPS + CPU iowait အချိန် - အကြောင်းတစ်ခုခုကြောင့်၊ များစွာသော cloud hosting များသည် IOPS အလုံအလောက်မပေးခြင်းကြောင့် အပြစ်ရှိသည်။ ထို့အပြင်၊ IOPS နည်းပါးသောအချိန်ဇယားသည် ၎င်းတို့အတွက် အငြင်းအခုံမဟုတ်ပါ။ ထို့ကြောင့်၊ CPU iowait ကိုစုဆောင်းရကျိုးနပ်သည်။ ဤဂရပ်အတွဲဖြင့် - IOPS အနိမ့်နှင့် I/O မြင့်မားသောစောင့်ဆိုင်းခြင်းဖြင့် - သင်သည် hosting နှင့် စကားပြောပြီး ပြဿနာကို ဖြေရှင်းနိုင်နေပြီဖြစ်သည်။

operating system ကို

လည်ပတ်မှုစနစ်တိုင်းထွာချက်များ-

• % တွင် ရနိုင်သော memory ပမာဏ၊
• လဲလှယ်အသုံးပြုမှုလုပ်ဆောင်ချက်- vmstat swapin၊ swapout၊
• % တွင် ဖိုင်စနစ်တွင် ရနိုင်သော inode အရေအတွက်နှင့် နေရာလွတ်များ
• ပျမ်းမျှဝန်;
• နှစ်ပြည်နယ်ရှိ ဆက်သွယ်မှုအရေအတွက်၊
• ဇယားပြည့်စုံမှုကို ထိန်းချုပ်ပါ။
• ss utility၊ iproute2 ပက်ကေ့ခ်ျကို အသုံးပြု၍ ကွန်ရက်၏ အရည်အသွေးကို ၎င်း၏ အထွက်မှ RTT ချိတ်ဆက်မှုများ၏ ညွှန်ပြချက်ကို ရယူပြီး ၎င်းကို dest port ဖြင့် အုပ်စုဖွဲ့ပါ။

လည်ပတ်မှုစနစ်အဆင့်တွင်လည်း ကျွန်ုပ်တို့တွင် လုပ်ငန်းစဉ်များကဲ့သို့သော အရာတစ်ခုရှိသည်။ ၎င်း၏လုပ်ငန်းဆောင်တာတွင် အရေးကြီးသောအခန်းကဏ္ဍမှပါဝင်သည့် လုပ်ငန်းစဉ်အစုအဝေးကို စနစ်တွင် ခွဲခြားသတ်မှတ်ရန် အရေးကြီးပါသည်။ ဥပမာအားဖြင့်၊ သင့်တွင် pgpool များစွာရှိလျှင် ၎င်းတို့တစ်ခုစီအတွက် အချက်အလက်စုဆောင်းရန် လိုအပ်ပါသည်။

တိုင်းတာမှုအစုသည် အောက်ပါအတိုင်းဖြစ်သည်။

• စီပီယူ;
• မှတ်ဉာဏ်သည် အဓိကအားဖြင့် နေထိုင်သူဖြစ်သည်။
• IO - ဖြစ်နိုင်ရင် IOPS;
• FileFd - ဖွင့်ပြီးကန့်သတ်;
• သိသာထင်ရှားသော စာမျက်နှာပျက်ကွက်များ - ဤနည်းဖြင့် သင်သည် အဘယ်လုပ်ငန်းစဉ်ကို လဲလှယ်နေသည်ကို နားလည်နိုင်သည်။

ကျွန်ုပ်တို့သည် Docker တွင် စောင့်ကြည့်မှုအားလုံးကို ဖြန့်ကျက်ပြီး မက်ထရစ်ဒေတာစုဆောင်းရန် Advisor ကို အသုံးပြုပါသည်။ အခြားစက်များတွင် ကျွန်ုပ်တို့သည် process-exporter ကိုအသုံးပြုသည်။

စနစ်ဝန်ဆောင်မှုများ၊ ဆော့ဖ်ဝဲအစုအဝေး

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

universal set မှာ-

• တောင်းဆိုမှုနှုန်း;
• အမှားအရေအတွက်;
• စောင့်နေချိန်;
• ရွှဲ။

ဤအဆင့်တွင် စောင့်ကြည့်ခြင်း၏ အထူးခြားဆုံး ဥပမာများမှာ Nginx နှင့် PostgreSQL ဖြစ်သည်။

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

ဒစ်များပေါ်တွင် မြင့်မားသော load တစ်ခုကို ကျွန်ုပ်တို့တွေ့မြင်ခဲ့ရသော်လည်း နှေးကွေးသောမှတ်တမ်းများသည် အမှန်တကယ်တွင် ဘာမှပြသခြင်းမရှိပါ။ မေးခွန်းစာရင်းဇယားများကို စုဆောင်းသည့် မြင်ကွင်းတစ်ခုဖြစ်သည့် pg_stat_statements ကို အသုံးပြု၍ ဤပြဿနာကို ဖြေရှင်းခဲ့သည်။

ဒါပဲ admin ရဲ့ လိုအပ်ချက်ပါ။

ကျွန်ုပ်တို့သည် ဖတ်ရှုခြင်းနှင့် ရေးခြင်းတောင်းဆိုမှုများ၏ လုပ်ဆောင်မှုဆိုင်ရာ ဂရပ်များကို ဖန်တီးသည်-

အရာအားလုံးရိုးရှင်းပြီးရှင်းပါတယ်၊ တောင်းဆိုချက်တစ်ခုစီမှာသူ့ရဲ့ကိုယ်ပိုင်အရောင်ရှိပါတယ်။

ထပ်တူထပ်မျှ ထင်ရှားသော ဥပမာမှာ Nginx မှတ်တမ်းများဖြစ်သည်။ လူအနည်းငယ်က ၎င်းတို့ကို ခွဲခြမ်းစိတ်ဖြာပြီး မရှိမဖြစ်စာရင်းတွင် ဖော်ပြထားခြင်းမှာ အံ့သြစရာမဟုတ်ပါ။ စံဖော်မတ်သည် အလွန်သတင်းအချက်အလတ်မရှိသောကြောင့် ချဲ့ထွင်ရန် လိုအပ်သည်။

ပုဂ္ဂိုလ်ရေးအရ ကျွန်ုပ်သည် request_time၊ upstream_response_time၊ body_bytes_sent၊ request_length၊ request_id ကိုထည့်ထားပါသည်။ ကျွန်ုပ်တို့သည် တုံ့ပြန်မှုအချိန်နှင့် အမှားအယွင်းအရေအတွက်ကို တွက်ချက်ပါသည်-

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

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

အဖြစ်အပျက်ဖြေရှင်းမှု

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

• ပြဿနာကိုဖော်ထုတ်;
• တာဝန်စီမံခန့်ခွဲသူထံ အသိပေးချက်၊
• အဖြစ်အပျက်တစ်ခုအပေါ်တုံ့ပြန်မှု;
• အကြောင်းတရားများပပျောက်ရေး။

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

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

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

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

အချက်နှစ်ချက်။

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

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

1. အမှားအယွင်းမရှိ၊
2. client ဘက်မှအမှားအယွင်း;
3. အမှားက ငါတို့ဘက်မှာရှိတယ်၊ ငါတို့ပိုက်ဆံမဆုံးရှုံးဘူး၊
4. အမှားက ငါတို့ဘက်က ပိုက်ဆံဆုံးရှုံးတယ်။

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

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

သင့်တွင် ၎င်းမရှိပါက၊ ကျွန်ုပ်တို့ပြုလုပ်ခဲ့သည့်အတိုင်း အပလီကေးရှင်းမှတ်တမ်းများ၊ Nginx မှတ်တမ်းများနှင့် အခြားအရာများတွင် ၎င်းကို အမီလိုက်နိုင်ရန် သင်ကြိုးစားနိုင်ပါသည်။ သင်သည် အပလီကေးရှင်းနှင့် တတ်နိုင်သမျှ နီးကပ်နေသင့်သည်။

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

source: www.habr.com