Yuri Bushmelev "မှတ်တမ်းစုဆောင်းမှုနှင့် ပေးပို့မှုနယ်ပယ်ရှိ Rake Map" - အစီရင်ခံစာ၏ စာသားမှတ်တမ်း

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

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

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

ဤသည်မှာ Yuri Bushmelev ၏ "A Map of Rake in the Field of Log Collection and Delivery" ၏ အစီရင်ခံချက်နှင့် ပတ်သက်သည်။

ဘယ်သူ ဂရုစိုက်လဲ ကြောင်အောက်မှာ ကျေးဇူးပြုပြီး

ကျွန်တော့်နာမည် Yuri Bushmelev ပါ။ ကျွန်တော် Lazada မှာ အလုပ်လုပ်ပါတယ်။ ယနေ့ကျွန်ုပ်တို့၏ မှတ်တမ်းများကို မည်သို့ပြုလုပ်ပုံ၊ ၎င်းတို့ကို စုဆောင်းပုံနှင့် ထိုနေရာတွင် ရေးထားသည်များအကြောင်း ဆွေးနွေးပါမည်။

ငါတို့ဘယ်ကလာတာလဲ။ ငါတို့က ဘယ်သူလဲ။ Lazada သည် အရှေ့တောင်အာရှရှိ နိုင်ငံခြောက်နိုင်ငံတွင် နံပါတ် ၁ အွန်လိုင်းစတိုးဖြစ်သည်။ ဤနိုင်ငံအားလုံးကို ကျွန်ုပ်တို့၏ဒေတာစင်တာများတွင် ဖြန့်ဝေထားပါသည်။ လက်ရှိတွင် စုစုပေါင်း ဒေတာစင်တာ လေးခုရှိသည်။ ဒါက ဘာကြောင့် အရေးကြီးတာလဲ။ အဘယ်ကြောင့်ဆိုသော် အချို့သော ဆုံးဖြတ်ချက်များသည် စင်တာများကြား ချိတ်ဆက်မှု အလွန်အားနည်းနေသောကြောင့် ဖြစ်သည်။ ကျွန်ုပ်တို့တွင် မိုက်ခရိုဝန်ဆောင်မှုဗိသုကာတစ်ခုရှိသည်။ ကျွန်ုပ်တို့တွင် microservices 1 ရှိပြီးဖြစ်သည်ကိုတွေ့ရှိရသည့်အတွက် အံ့သြမိပါသည်။ မှတ်တမ်းများဖြင့် အလုပ်စလုပ်သောအခါတွင်၊ 4 သာရှိသေးသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့နှင့်အတူ နေထိုင်ပြီး ပေါင်းစည်းရမည့် PHP အမွေအနှစ်အမြောက်အမြားရှိပါသည်။ ဤအရာအားလုံးသည် စနစ်တစ်ခုလုံးအတွက် တစ်မိနစ်လျှင် မက်ဆေ့ချ်ပေါင်း 80 သန်းကျော်ကို လက်ရှိတွင်ထုတ်ပေးနေပါသည်။ ထို့အပြင်၊ ကျွန်ုပ်တို့သည် ဤအရာနှင့်အတူ မည်သို့နေထိုင်ရန် ကြိုးစားကြောင်း၊ အဘယ်ကြောင့် ဤကဲ့သို့ ဖြစ်သည်ကို ကျွန်ုပ်ပြပါမည်။

ကျွန်ုပ်တို့သည် ဤမက်ဆေ့ခ်ျ 6 သန်းကို တစ်နည်းနည်းဖြင့် နေထိုင်ရမည်ဖြစ်သည်။ သူတို့နဲ့ ငါတို့ ဘာလုပ်သင့်လဲ။ လိုအပ်သော စာတို ၆ သန်း

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

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

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

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

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

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

Lazada မှာ ဘယ်လို လုပ်ခဲ့သလဲ ၊ အဲဒါကို ဘယ်လို စတင်ခဲ့လဲ ဆိုတာကို ပြပါ့မယ်။

လွန်ခဲ့တဲ့တစ်နှစ်လောက်က ကျွန်တော် Lazada ကိုရောက်လာပြီး သစ်လုံးနဲ့ပတ်သက်တဲ့ ပရောဂျက်တစ်ခုဆီ ပို့လိုက်တယ်။ ဒီလိုမျိုး ဖြစ်ခဲ့တာ။ လျှောက်လွှာမှမှတ်တမ်းကို stdout နှင့် stderr သို့ရေးထားသည်။ အရာအားလုံးကို ခေတ်ဆန်တဲ့ပုံစံနဲ့ လုပ်ခဲ့တာပါ။ ဒါပေမယ့် နောက်ပိုင်းမှာ developer တွေက ဒါကို standard streams တွေကနေ ထုတ်ပစ်လိုက်ပြီး infrastructure specialists တွေက ဒါကို တစ်နည်းနည်းနဲ့ အဖြေရှာပါလိမ့်မယ်။ အခြေခံအဆောက်အအုံဆိုင်ရာ ကျွမ်းကျင်သူများနှင့် ဆော့ဖ်ဝဲရေးသားသူများကြားတွင် ထုတ်ပြန်သူများလည်း ရှိပါသည်- "အိုး... ကောင်းပြီ၊ အဲဒါကို အခွံတစ်ခုနဲ့ ဖိုင်တစ်ခုနဲ့ ထုပ်ရအောင်၊ ဒါပဲ" ဟု ပြောခဲ့သည်။ အဲဒါတွေအားလုံး ကွန်တိန်နာထဲမှာ ပါတဲ့အတွက် ကွန်တိန်နာကိုယ်တိုင် ထုပ်ပိုးပြီး အတွင်းထဲမှာ လမ်းညွှန်တစ်ခုကို ပုံဖော်ပြီး အဲဒီနေရာမှာ ထားလိုက်တယ်။ ထွက်လာတာကို လူတိုင်းသိသာမယ်ထင်ပါတယ်။

အနီးကပ်ကြည့်ကြပါစို့။ ဤမှတ်တမ်းများကို ကျွန်ုပ်တို့ မည်သို့ပေးပို့ခဲ့သနည်း။ တစ်စုံတစ်ယောက်က td-agent ကို ရွေးချယ်ခဲ့တယ်၊ ဒါက တကယ်ကို ကျွမ်းကျင်ပေမယ့် သိပ်တော့ မကျွမ်းကျင်ပါဘူး။ ဒီပရောဂျက်နှစ်ခုကြားက ဆက်စပ်မှုကို ကျွန်တော်နားမလည်သေးပေမယ့် သူတို့ဟာ အတူတူပဲလို့ ထင်ရပါတယ်။ Ruby ဖြင့်ရေးသားထားသော ဤကျွမ်းကျင်သော၊ မှတ်တမ်းဖိုင်များကိုဖတ်ပြီး ပုံမှန်အသုံးအနှုန်းအချို့ကို အသုံးပြု၍ JSON တွင် ခွဲခြမ်းစိတ်ဖြာပါသည်။ ထို့နောက် ၎င်းတို့ကို Kafka သို့ စေလွှတ်ခဲ့သည်။ ထို့အပြင်၊ Kafka တွင် API တစ်ခုစီအတွက် သီးခြားအကြောင်းအရာ 4 ခုရှိသည်။ အဘယ်ကြောင့် 4 အဘယ်ကြောင့်ဆိုသော် တိုက်ရိုက်ရှိနေသောကြောင့်၊ ဇာတ်ခုံရှိ၍ stdout နှင့် stderr ရှိသောကြောင့်ဖြစ်သည်။ Developer များက ၎င်းတို့ကို ဖန်တီးကြပြီး အခြေခံအဆောက်အအုံဆိုင်ရာ ကျွမ်းကျင်သူများက ၎င်းတို့ကို Kafka တွင် ဖန်တီးရမည်ဖြစ်သည်။ ထို့အပြင် Kafka ကို အခြားဌာနမှ ထိန်းချုပ်ထားသည်။ ထို့ကြောင့်၊ ၎င်းတို့သည် API တစ်ခုစီအတွက် ခေါင်းစဉ် 4 ခုဖန်တီးနိုင်ရန် လက်မှတ်တစ်ခုဖန်တီးရန် လိုအပ်ပါသည်။ လူတိုင်းက အဲဒါကို မေ့နေကြတယ်။ ယေဘူယျအားဖြင့် အမှိုက်နှင့် ပျော်စရာကောင်းသည်။

အဲဒါကို ငါတို့ ဘာဆက်လုပ်ခဲ့လဲ။ ငါတို့က Kafka ကိုပို့လိုက်တယ်။ ထို့နောက် Kafka မှ သစ်လုံးတစ်ဝက်သည် Logstash သို့ ပျံသန်းသွားသည်။ ကျန်တစ်ဝက်ကို သစ်လုံးများခွဲထားသည်။ အချို့က Graylog တစ်ခုသို့ ပျံသန်းကြပြီး အချို့သည် အခြား Graylog သို့ ပျံသန်းကြသည်။ ရလဒ်အနေဖြင့်၊ ဤအရာအားလုံးသည် Elasticsearch အစုအဝေးတစ်ခုသို့ ပျံသန်းသွားခဲ့သည်။ ဆိုလိုသည်မှာ ဤအရှုပ်အထွေးအားလုံးသည် ထိုနေရာတွင် ပြီးဆုံးသွားပါသည်။ မင်းအဲလိုမလုပ်သင့်ဘူး!

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

ဤတွင် (1,2,3) ကျွန်ုပ်တို့သည် ဖိုင်များကို ရေးကြပြီး၊ ဤနေရာတွင် တစ်ကြိမ်တည်းတွင် ထွန်သုံးခုရှိသည်။

ပထမ (၁) - အဲဒါတွေကို တစ်နေရာရာမှာ ရေးရမယ်။ API အား ဖိုင်တစ်ခုသို့ တိုက်ရိုက်ရေးနိုင်စေရန် အမြဲတမ်း မလိုလားအပ်ပေ။ API ကို ကွန်တိန်နာတစ်ခုတွင် သီးခြားခွဲထားရန် နှစ်လိုဖွယ်ကောင်းပြီး ၎င်းကို ဖတ်ရှုရန်သာရှိစေရန်အတွက် ပိုကောင်းသည်။ ကျွန်ုပ်သည် sysadmin ဖြစ်သည်၊ ထို့ကြောင့် ဤအရာများနှင့် ပတ်သက်၍ ကျွန်ုပ်တွင် အခြားရွေးချယ်စရာ အမြင်တစ်ခုရှိသည်။

ဒုတိယအချက် (၂၊၃) — ကျွန်ုပ်တို့တွင် API သို့ တောင်းဆိုမှုများ အများအပြားရှိသည်။ API သည် ဖိုင်သို့ ဒေတာများစွာ ရေးသည်။ ဖိုင်တွေ များလာတယ်။ အဲဒါတွေကို လှည့်ဖို့လိုတယ်။ မဟုတ်ရင် အဲဒီမှာ disk တွေ အလုံအလောက်ရှိမှာမဟုတ်ဘူး။ Shell မှတဆင့် လမ်းညွှန်သို့ ပြန်ညွှန်းခြင်းဖြင့် ၎င်းတို့ကို လှည့်ခြင်းသည် မကောင်းပါ။ ငါတို့က ဘယ်လိုမှ လှည့်လို့မရဘူး။ ဖော်ပြချက်များကို ပြန်ဖွင့်ရန် အပလီကေးရှင်းအား ကျွန်ုပ်တို့ မပြောနိုင်ပါ။ အဘယ်ကြောင့်ဆိုသော် ဆော့ဖ်ဝဲရေးသားသူများသည် မင်းအရူးတစ်ယောက်လို မင်းကိုကြည့်လိမ့်မည်- "အဘယ်အရာဖော်ပြချက်များ၊ ငါတို့သည် အရူးအမူးဖြစ်စေရန် ရေးလိုက်သည်"။ အခြေခံအဆောက်အအုံ ရေးဆွဲသူများသည် ဖိုင်၏မိတ္တူကို ရိုးရိုးရှင်းရှင်းပြုလုပ်ပြီး မူရင်းကို ဖြတ်တောက်ပေးသည့် logrotate တွင် copytruncate ပြုလုပ်ခဲ့သည်။ ထို့ကြောင့်၊ ဤကူးယူခြင်းလုပ်ငန်းစဉ်များကြားတွင် disk space သည် များသောအားဖြင့် ကုန်သွားပါသည်။

(4) ကျွန်ုပ်တို့တွင် မတူညီသော APIs များတွင် မတူညီသောပုံစံများရှိသည်။ ၎င်းတို့သည် အနည်းငယ်ကွဲပြားသော်လည်း regexp ကို ကွဲပြားစွာရေးသားရမည်ဖြစ်ပါသည်။ ဤအရာအားလုံးကို ရုပ်သေးက စီမံခန့်ခွဲသောကြောင့်၊ သူတို့၏ကိုယ်ပိုင်ထူးခြားချက်များဖြင့် အတန်းများစွာရှိသည်။ ထို့အပြင်၊ td-agent သည် အချိန်အများစုတွင် မှတ်ဉာဏ်ကို စားသုံးနိုင်သည်၊ စကားမပြောဘဲ၊ ၎င်းသည် အလုပ်လုပ်နေပြီး ဘာမှမလုပ်ကြောင်း ဟန်ဆောင်နိုင်သည်။ ဘာမှမလုပ်ဘူးဆိုပြီး အပြင်ကနေပြောဖို့ မဖြစ်နိုင်ဘူး။ အကောင်းဆုံးအခြေအနေတွင်၊ ၎င်းသည် ပျက်စီးသွားမည်ဖြစ်ပြီး တစ်စုံတစ်ဦးမှ ၎င်းကို နောက်မှ ကောက်ယူမည်ဖြစ်သည်။ ပို၍တိကျသည်မှာ၊ သတိပေးချက်တစ်ခုသည် ပျံသန်းလာပြီး တစ်စုံတစ်ဦးမှ ၎င်းကို ကိုယ်တိုင်ပြန်၍ ကောက်ယူသွားမည်ဖြစ်သည်။

(၆) အမှိုက်နှင့် ပျော်စရာအကောင်းဆုံးမှာ elasticsearch ဖြစ်သည်။ ဗားရှင်းဟောင်းဖြစ်သောကြောင့်ဖြစ်သည်။ ဘာကြောင့်လဲ ဆိုတော့ အဲဒီတုန်းက လှူတဲ့ ဆရာတွေ မရှိဘူး။ ကျွန်ုပ်တို့တွင် ကွဲပြားသော သစ်လုံးများ ရှိသည်၊ မတူညီသော အပလီကေးရှင်းများ၏ မှတ်တမ်းများကို တူညီသောနယ်ပယ်အမည်များဖြင့် ရေးသားနိုင်သော်လည်း တစ်ချိန်တည်းတွင် အတွင်း၌ မတူညီသောဒေတာများ ရှိနေနိုင်သည်။ ဆိုလိုသည်မှာ၊ မှတ်တမ်းတစ်ခုသည် နယ်ပယ်ရှိ Integer တစ်ခု၊ ဥပမာ၊ အဆင့်ဖြစ်သည်။ အဆင့်အကွက်တွင် အခြားမှတ်တမ်းတစ်ခုပါရှိသည်။ တည်ငြိမ်သောမြေပုံမရှိခြင်းတွင်၊ ထိုသို့သောအံ့သြဖွယ်ကောင်းသောအရာသည်ပေါ်လာသည်။ elasticsearch တွင် index လှည့်ပြီးနောက် ပထမမက်ဆေ့ချ်သည် စာကြောင်းတစ်ခုနှင့် ရောက်လာပါက၊ ကျွန်ုပ်တို့ ပုံမှန်အတိုင်း နေထိုင်နိုင်သည်။ ဒါပေမယ့် ပထမတစ်ခုက Integer နဲ့ရောက်လာရင် String တစ်ခုနဲ့ရောက်လာတဲ့ နောက်ဆက်တွဲမက်ဆေ့ချ်အားလုံးကို ရိုးရိုးရှင်းရှင်းပဲ စွန့်ပစ်လိုက်ပါ။ အကွက်အမျိုးအစားနှင့် မကိုက်ညီသောကြောင့်ဖြစ်သည်။

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

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

ဆက်လက်၍ ကျွန်ုပ်သည် မှတ်တမ်းများကို မှတ်တမ်းတင်ခြင်း၊ ပေးပို့ခြင်းနှင့် စုဆောင်းခြင်းနည်းလမ်းများအတွက် တစ်ခုတည်းသော စံနှုန်းတစ်ခုကို ထူထောင်လိုပါသည်။ တကယ်တော့ ဘယ်မှာရေးရမလဲ၊ ဘယ်လိုပို့ပေးရမလဲ။ တူညီသောစာကြည့်တိုက်ကို ပရောဂျက်များတွင် အသုံးပြုသောအခါ အကောင်းဆုံးအခြေအနေဖြစ်သည်။ Go အတွက် သီးခြား logging library တစ်ခု ရှိပြီး PHP အတွက် သီးခြား စာကြည့်တိုက် တစ်ခု ရှိပါသည်။ ငါတို့ရှိသမျှသည်၎င်းတို့ကိုသုံးသင့်သည်။ လောလောဆယ် ပြောရမယ်ဆိုရင် ကျွန်တော်တို့ ၈၀ ရာခိုင်နှုန်း အောင်မြင်တယ်။ ဒါပေမယ့် တချို့က cacti ကို ဆက်စားတယ်။

ထိုနေရာတွင် (လျှောတွင်) "Log Delivery SLA" သည် စတင်ပေါ်လာရုံသာဖြစ်သည်။ မရောက်သေးပေမယ့် အဲဒါကို ကျွန်တော်တို့ လုပ်ဆောင်နေပါတယ်။ အဘယ်ကြောင့်ဆိုသော် အကယ်၍ သင်သည် ထိုကဲ့သို့သော နေရာကို ဤကဲ့သို့သော ပုံစံဖြင့် ရေးပြီး တစ်စက္ကန့်လျှင် N မက်ဆေ့ဂျ်များထက် မပိုစေဘဲ ရေးပါက အလွန်အဆင်ပြေသည်ဟု ဆိုသောအခါ၊ ၎င်းကို ဖြစ်နိုင်ခြေရှိသော ထိုကဲ့သို့သော နေရာသို့ ပို့ပေးလိုက်ပါမည်။ ဒါက ခေါင်းကိုက်တာကို အများကြီး သက်သာစေပါတယ်။ SLA ရှိရင် အဲဒါ အရမ်းကောင်းပါတယ်။

ကျွန်ုပ်တို့သည် ပြဿနာကို မည်သို့စတင်ဖြေရှင်းခဲ့သနည်း။ အဓိက ပြဿနာက td-agent ပါ။ ကျွန်တော်တို့ရဲ့ သစ်လုံးတွေက ဘယ်ကိုသွားနေမှန်း မသိရသေးပါဘူး။ ပို့ဆောင်ပေးနေသလား။ စုဆောင်းနေကြသလား။ သူတို့အားလုံး ဘယ်မှာလဲ။ ထို့ကြောင့် ပထမအဆင့်မှာ td-agent ကို အစားထိုးရန်ဖြစ်သည်။ ဤနေရာတွင် မည်သည့်အရာဖြင့် အစားထိုးရမည်အတွက် ရွေးချယ်စရာများကို ကျွန်ုပ် အကျဉ်းချုပ် ဖော်ပြထားပါသည်။

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

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

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

သို့မဟုတ် သင့်ကိုယ်ပိုင် တစ်ခုခုကို ရေးပါသော်လည်း၊ ၎င်းအပြင် filebeat ကို ကျွန်ုပ်တို့ ပယ်ချပါသည်။ တစ်ခုခုရေးရင် လုပ်ငန်းအတွက် အသုံးဝင်တဲ့ တစ်ခုခုရေးတာ ပိုကောင်းပါတယ်။ သစ်လုံးပေးပို့ခြင်းအတွက် အဆင်သင့်လုပ်ထားသော အရာတစ်ခုကို ယူဆောင်သွားခြင်းက ပိုကောင်းပါတယ်။

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

rsyslog အကြောင်းအနည်းငယ်။ ပထမဆုံးအနေနဲ့ သူ့မှာ module တွေ အများကြီးရှိလို့ အရမ်းကောင်းပါတယ်။ ၎င်းတွင် လူသားဖတ်နိုင်သော RainerScript (ခေတ်မီဖွဲ့စည်းပုံသုံးဘာသာစကား) ပါရှိသည်။ အံ့သြဖွယ်ကောင်းသော အပိုဆုမှာ ကျွန်ုပ်တို့သည် ၎င်း၏ စံကိရိယာများဖြင့် td-agent အပြုအမူကို အတုယူနိုင်ပြီး အပလီကေးရှင်းများအတွက် ဘာမှမပြောင်းလဲပါ။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် td-agent ကို rsyslog သို့ပြောင်းပြီး အခြားအရာအားလုံးကို တစ်ယောက်တည်း ထားလိုက်ပါ။ ပြီးတော့ ကျွန်တော်တို့ ချက်ချင်း အလုပ် အရောက်ပို့ပေးတယ်။ နောက်တစ်ခု၊ mmnormalize သည် rsyslog တွင် အံ့သြဖွယ်ကောင်းသော အရာတစ်ခုဖြစ်သည်။ ၎င်းသည် သင့်အား မှတ်တမ်းများကို ခွဲခြမ်းစိပ်ဖြာရန် ခွင့်ပြုသော်လည်း Grok နှင့် regexp တို့နှင့် မဟုတ်ပါ။ ၎င်းသည် abstract syntax tree ကို ပြုလုပ်သည်။ ၎င်းသည် compiler မှ source codes များကို parses ကဲ့သို့ အကြမ်းဖျင်း မှတ်တမ်းများကို ခွဲခြမ်းစိပ်ဖြာသည်။ ၎င်းသည် သင့်အား အလွန်လျင်မြန်စွာ အလုပ်လုပ်နိုင်စေကာ CPU အနည်းငယ်ကို စားနိုင်စေကာ ယေဘူယျအားဖြင့် ၎င်းသည် အလွန်အေးမြသော အရာဖြစ်သည်။ အခြားသော ဘောနပ်စ်များလည်း အများအပြားရှိပါသည်။ သူတို့အပေါ်မှာ ငါနေမှာမဟုတ်ဘူး။

Rsyslog တွင် အခြားအားနည်းချက်များစွာရှိသည်။ ၎င်းတို့သည် ဘောနပ်စ်များနှင့် အတူတူပင်။ အဓိကပြဿနာမှာ ၎င်းကို မည်သို့ပြင်ဆင်ရမည်ကို သိရန် လိုအပ်ပြီး ဗားရှင်းတစ်ခုကို ရွေးချယ်ရန် လိုအပ်ပါသည်။

Unix socket တွင် မှတ်တမ်းများရေးရန် ဆုံးဖြတ်ခဲ့သည်။ ထို့အပြင် /dev/log အတွက်မဟုတ်ပါ၊ ကျွန်ုပ်တို့တွင် စနစ်မှတ်တမ်းများ ရှုပ်ယှက်ခတ်နေသောကြောင့် ဤပိုက်လိုင်းတွင် ဂျာနယ်ပါရှိပါသည်။ ဒါဆို custom socket မှာရေးကြည့်ရအောင်။ ၎င်းကို သီးခြားစည်းမျဥ်းတစ်ခုတွင် ပူးတွဲတင်ပြပါမည်။ ကျွန်တော်တို့ ဘာမှ အနှောင့်အယှက် ပေးမှာ မဟုတ်ဘူး။ အရာအားလုံး ပွင့်လင်းမြင်သာမှုရှိမည်။ အဲဒါ ငါတို့တကယ်လုပ်ခဲ့တာ။ အဆိုပါ sockets များပါရှိသော လမ်းညွှန်ကို စံသတ်မှတ်ထားပြီး ကွန်တိန်နာအားလုံးသို့ ထပ်ဆင့်ပို့ပါသည်။ ကွန်တိန်နာများသည် သူတို့လိုအပ်သော socket ကိုမြင်နိုင်သည်၊ ၎င်းကိုဖွင့်ပြီး ၎င်းထံသို့စာရေးနိုင်သည်။

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

Rsyslog သည် slide တွင်ဖော်ပြထားသောလုပ်ဆောင်ချက်များကိုလုပ်ဆောင်ပြီး relay သို့မဟုတ် Kafka သို့မှတ်တမ်းများပေးပို့သည်။ Kafka သည် နည်းလမ်းဟောင်းနှင့် ကိုက်ညီသည်။ Relay သည် မှတ်တမ်းများပေးပို့ရန် rsyslog သက်သက်ကို အသုံးပြုရန် ကြိုးစားနေပါသည်။ ပုံမှန် rsyslog ကိရိယာများကို အသုံးပြု၍ Message Queue မရှိဘဲ။ မူအရ၊

သို့သော် ၎င်းတို့ကို ဤအပိုင်းသို့ တွန်းပို့ပုံ (Logstash/Graylog/ES) နှင့် ကွဲလွဲမှုများ ရှိပါသည်။ ဤအပိုင်း (rsyslog-rsyslog) ကို ဒေတာစင်တာများကြားတွင် အသုံးပြုသည်။ ဤသည်မှာ ချုံ့ထားသော tcp လင့်ခ်တစ်ခုဖြစ်ပြီး၊ ၎င်းသည် ကျွန်ုပ်တို့အား bandwidth ကိုချွေတာနိုင်စေပြီး၊ ချန်နယ်ပိတ်သွားသောအခါတွင် အခြားဒေတာစင်တာမှ မှတ်တမ်းအချို့ကို ကျွန်ုပ်တို့လက်ခံရရှိမည့် ဖြစ်နိုင်ခြေကို တစ်နည်းနည်းဖြင့် တိုးစေသည်။ ဘာဖြစ်လို့လဲ ဆိုတော့ ကျွန်တော်တို့မှာ အင်ဒို နီးရှား ရှိတယ်ဆိုတော့ အကုန်လုံး မကောင်းဘူး။ အဲဒီ့မှာ ဒီပြဿနာက အမြဲရှိနေတယ်။

အပလီကေးရှင်းမှ မှတ်တမ်းတင်ထားသော မှတ်တမ်းများသည် မည်သို့ဖြစ်နိုင်ခြေရှိသဖြင့် ကျွန်ုပ်တို့ အမှန်တကယ် စောင့်ကြည့်နိုင်မည်ကို ကျွန်ုပ်တို့ စဉ်းစားခဲ့ကြပါသည်။ တိုင်းတာမှုများ ပြုလုပ်ရန် ဆုံးဖြတ်ခဲ့သည်။ Rsyslog တွင် ကောင်တာအချို့ပါရှိသည့် ၎င်း၏ကိုယ်ပိုင်စာရင်းအင်းစုဆောင်းမှု module ရှိသည်။ ဥပမာအားဖြင့်၊ ၎င်းသည် သင့်အား တန်းစီသည့်အရွယ်အစား သို့မဟုတ် လုပ်ဆောင်ချက်တစ်ခုတွင် မက်ဆေ့ချ်မည်မျှဝင်လာသည်ကို ပြသနိုင်သည်။ မင်းသူတို့ဆီက တစ်ခုခုယူလို့ရနေပြီ။ ထို့အပြင်၊ ၎င်းတွင် configure လုပ်နိုင်သော စိတ်ကြိုက်ကောင်တာများ ပါရှိပြီး ဥပမာအားဖြင့် အချို့ API မှ မှတ်တမ်းတင်ထားသော မက်ဆေ့ချ် အရေအတွက်ကို သင့်အား ပြသမည်ဖြစ်သည်။ ထို့နောက်၊ ကျွန်ုပ် Python တွင် rsyslog_exporter ကိုရေးပြီး အားလုံးကို Prometheus သို့ပို့ပြီး ဂရပ်ဖစ်များဖန်တီးပေးပါသည်။ Graylog မက်ထရစ်များကို အမှန်တကယ် အလိုရှိသော်လည်း ၎င်းတို့ကို စီစဉ်သတ်မှတ်ရန် အချိန်မရသေးပါ။

ဘာပြဿနာများ ဖြစ်ပေါ်လာတာလဲ။ ကျွန်ုပ်တို့၏ Live APIs များသည် တစ်စက္ကန့်လျှင် မက်ဆေ့ချ် 50k ရေးနေကြောင်း (ရုတ်တရက်!) တွေ့ရှိသောကြောင့် ပြဿနာများ ဖြစ်ပေါ်လာပါသည်။ ၎င်းသည် အဆင့်မတင်ဘဲ တိုက်ရိုက် API သာဖြစ်သည်။ Graylog သည် တစ်စက္ကန့်လျှင် 12k မက်ဆေ့ချ်များကိုသာ ပြသသည်။ ပြီးတော့ ကျိုးကြောင်းဆီလျော်တဲ့ မေးခွန်းတစ်ခု ပေါ်လာတယ်- ကျန်တာတွေ ဘယ်မှာလဲ။ Graylog သည် ရိုးရိုးရှင်းရှင်း မထိန်းနိုင်ခဲ့ကြောင်း ကျွန်ုပ်တို့ ကောက်ချက်ချခဲ့သည်။ ကျွန်ုပ်တို့ ကြည့်ရှုခဲ့ပြီး အမှန်တကယ်ပင် Graylog နှင့် Elasticsearch သည် ဤစီးဆင်းမှုကို မကိုင်တွယ်နိုင်ပါ။

နောက်တစ်ခုကတော့ ကျွန်တော်တို့ လမ်းတလျှောက်မှာ တခြားရှာဖွေတွေ့ရှိမှုတွေပါ။

socket များကို ပိတ်ဆို့ထားသည်။ ဒါက ဘယ်လိုဖြစ်တာလဲ။ ပေးပို့မှုအတွက် rsyslog ကိုအသုံးပြုနေချိန်၊ တစ်ချိန်ချိန်တွင် ဒေတာစင်တာများကြားရှိ ချန်နယ်များ ပြတ်တောက်သွားခဲ့သည်။ ပို့ဆောင်မှုကို တစ်နေရာတည်းတွင် ရပ်လိုက်ပြီး အခြားတစ်နေရာသို့ ပို့ဆောင်မှု ရပ်သွားပါသည်။ ဤအရာအားလုံးကို rsyslog socket သို့ရေးသော API ဖြင့်စက်ဆီသို့ရောက်ရှိသွားသည်။ တန်းစီတာက ဟိုမှာ ပြည့်နေတယ်။ ထို့နောက် default အားဖြင့် 128 packets ဖြစ်သော unix socket သို့ စာရေးရန် တန်းစီသည်။ ထို့နောက် အပလီကေးရှင်းတွင် နောက်ထပ် write() ကို ပိတ်ဆို့ထားသည်။ Go အပလီကေးရှင်းများတွင်အသုံးပြုသည့်စာကြည့်တိုက်ကိုကြည့်ရှုသောအခါ၊ socket သို့စာရေးခြင်းသည်ပိတ်ဆို့ခြင်းမုဒ်တွင်ဖြစ်ပေါ်ကြောင်းရေးထားသည်။ ဘယ်အရာမှ ပိတ်ဆို့ထားခြင်း မရှိတာ သေချာပါတယ်။ ဘာဖြစ်လို့လဲဆိုတော့ ကျွန်တော်ဖတ်တယ်။ Badushka အကြောင်း ဆောင်းပါးအဲဒါကို ဘယ်သူရေးတာလဲ။ ဒါပေမယ့် ခဏတော့ရှိတယ်။ ဤခေါ်ဆိုမှုတွင် အဆုံးမရှိသော လှည့်ပတ်မှုတစ်ခုလည်း ရှိခဲ့သည်၊ ၎င်းတွင် မက်ဆေ့ချ်တစ်ခုကို socket ထဲသို့ တွန်းပို့ရန် အဆက်မပြတ်ကြိုးစားနေပါသည်။ အဲဒါကို ကျွန်တော်တို့ သတိမထားမိဘူး။ စာကြည့်တိုက်ကို ပြန်ရေးရတယ်။ ထိုအချိန်မှစ၍၊ ၎င်းသည် အကြိမ်ပေါင်းများစွာ ပြောင်းလဲခဲ့သော်လည်း ယခုအခါ စနစ်ခွဲများအားလုံးတွင် သော့များကို ဖယ်ရှားနိုင်ပြီဖြစ်သည်။ ထို့ကြောင့်၊ သင်သည် rsyslog ကိုရပ်တန့်နိုင်ပြီး မည်သည့်အရာမျှ ပျက်စီးသွားမည်မဟုတ်ပေ။

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

နောက်မနှစ်မြို့ဖွယ်အခိုက်အတန့် - microservice ဗိသုကာတွင် 10-ဆ ချဲ့ထွင်ခြင်းသည် အလွန်လွယ်ကူပါသည်။ ကျွန်ုပ်တို့တွင် အဝင်တောင်းဆိုမှုများစွာမရှိသော်လည်း ဤမက်ဆေ့ချ်များ ပိုမိုလည်ပတ်နေသည့် ဂရပ်ဖစ်ကြောင့်၊ ဝင်ရောက်ခွင့်မှတ်တမ်းများကြောင့်၊ ကျွန်ုပ်တို့သည် အမှန်တကယ် မှတ်တမ်းတင်ခြင်းကို ဆယ်ဆခန့် တိုးမြင့်စေပါသည်။ ကံမကောင်းစွာဖြင့်၊ ကျွန်ုပ်တွင် ကိန်းဂဏာန်းများကို အတိအကျ တွက်ချက်ရန် အချိန်မရှိသော်လည်း မိုက်ခရိုဝန်ဆောင်မှုများသည် ထိုကဲ့သို့ဖြစ်သည်။ ဒါကို စိတ်ထဲမှာ ထားရမယ်။ ယခုအချိန်တွင် မှတ်တမ်းစုဆောင်းခြင်းစနစ်ခွဲသည် Lazada တွင် တင်ဆောင်မှုအများဆုံးဖြစ်သည်။

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

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

Logstash နှင့် Graylog ပါသော ဤအပိုင်းသည် အမှန်တကယ် ပေါ်လွင်နေပါသည်။ ဒါကြောင့် ဖယ်ရှားပစ်ဖို့ လိုပါတယ်။ ကျွန်ုပ်တို့သည် တစ်ခု သို့မဟုတ် အခြားတစ်ခုကို ရွေးချယ်ရန် လိုအပ်သည်။

Logstash နှင့် Kibana တို့ကို စွန့်ပစ်ရန် ဆုံးဖြတ်ခဲ့သည်။ ဘာဖြစ်လို့လဲဆိုတော့ ကျွန်တော်တို့မှာ လုံခြုံရေးဌာနရှိတယ်။ ချိတ်ဆက်မှုကဘာလဲ။ ချိတ်ဆက်မှုမှာ X-Pack မပါသော Kibana နှင့် Shield မပါဘဲ မှတ်တမ်းများသို့ ဝင်ရောက်ခွင့်ကို ခွဲခြားရန် ခွင့်မပြုပါ။ ဒီတော့ Graylog ကို ယူတယ်။ ဒါတွေအားလုံးရှိတယ်။ မကြိုက်ဘူး၊ ဒါပေမယ့် အလုပ်လုပ်တယ်။ ကျွန်ုပ်တို့သည် ဟာ့ဒ်ဝဲအသစ်ကို ဝယ်ယူခဲ့ပြီး ထိုနေရာတွင် လတ်ဆတ်သော Graylog တစ်ခုကို ထည့်သွင်းပြီး မှတ်တမ်းအားလုံးကို သီးခြား Graylog တစ်ခုသို့ တင်းကျပ်သောဖော်မတ်များဖြင့် ရွှေ့ထားသည်။ တူညီသောနယ်ပယ်အမျိုးမျိုးဖြင့် ပြဿနာကို အဖွဲ့အစည်းအလိုက် ဖြေရှင်းခဲ့သည်။

Graylog အသစ်တွင် အတိအကျပါဝင်သည် ။ ကျွန်ုပ်တို့သည် Docker တွင် အရာအားလုံးကို ရိုးရိုးရှင်းရှင်းရေးထားသည်။ ကျွန်ုပ်တို့သည် ဆာဗာများစွာကိုယူကာ Kafka ဖြစ်ရပ်သုံးခု၊ 7 Graylog ဆာဗာဗားရှင်း 2.3 (ကျွန်ုပ်တို့သည် Elasticsearch ဗားရှင်း 5 ကို လိုချင်သောကြောင့်) ထုတ်ပေးခဲ့သည်။ ကျွန်ုပ်တို့သည် ဤအရာအားလုံးကို HDD စီးနင်းမှုများတွင် မြှင့်တင်ခဲ့သည်။ တစ်စက္ကန့်လျှင် မက်ဆေ့ခ်ျ 100 အထိ အညွှန်းကိန်းနှုန်းကို ကျွန်ုပ်တို့ တွေ့ခဲ့ရသည်။ တစ်ပတ်လျှင် ဒေတာ 140 terabytes ကိန်းဂဏန်းကို ကျွန်ုပ်တို့ တွေ့ခဲ့ရသည်။

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

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

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

Graylog မှ မက်ထရစ်များကို စုဆောင်းပါ။

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

နောက်ဆုံးအနေနှင့်၊ ဤမျှလောက်ဝန်ဆောင်မှုပေးနိုင်သော developer များနှင့် SLA အချို့ကို လက်မှတ်ထိုးပါ။ စာများများရေးရင် တောင်းပန်ပါတယ်။

စာရွက်စာတမ်းတွေ ရေးပါ။

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

မေးခွန်းများကို.

မေးခွန်း: မယူဖို့ ဘာကြောင့် ဆုံးဖြတ်ခဲ့တာလဲ... (filebeat?)

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

မေးခွန်း: ဘာကြောင့် HDFS မှာ မှတ်တမ်းတွေ မရေးတာလဲ။

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

မေးခွန်း: ကော်လံဖော်မတ်သည် ပိုသင့်လျော်ပါမည်။

အဖွေ: အားလုံးနားလည်ပါတယ်။ ငါတို့အားလုံး အဲဒါအတွက်ပဲ။

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

အဖွေ: အချက်နှစ်ချက်ရှိတယ်။ ဦးစွာ၊ ကျွန်ုပ်တို့သည် မှတ်တမ်းပေးပို့ခြင်းကို အာမမခံနိုင်ကြောင်း လူတိုင်းကို ချက်ချင်းပြောပါမည်။ အဘယ်ကြောင့်ဆိုသော် developer များက "အဲဒီမှာ ငွေကြေးဒေတာကို စရေးကြရအောင်၊ တစ်ခုခုဖြစ်ရင် ငါတို့အတွက် တစ်နေရာရာမှာ ထားလိုက်မယ်" လို့ ပြောတဲ့အခါ၊ "ကောင်းပြီ၊ socket ဆီကို စာရေးပြီး စပြီး ပိတ်ဆို့လိုက်ရအောင်၊ အဲဒါကို ငါတို့ရဲ့ socket မှာ ထည့်ထားဖို့ အာမခံပြီး တစ်ဖက်က လက်ခံကြောင်း သေချာအောင် လုပ်ပါ။" အဲဒီအချိန်မှာ လူတိုင်းက မဟုတ်ဘူးလို့ ချက်ချင်းပြောတယ်။ မလိုအပ်ရင် ငါတို့အတွက် ဘာမေးခွန်းတွေရှိလဲ။ အကယ်၍ သင်သည် socket သို့စာရေးရန်အာမခံချက်မလိုချင်ပါက၊ အဘယ်ကြောင့်ကျွန်ုပ်တို့ပေးပို့မှုကိုအာမခံသင့်သနည်း။ ကျွန်တော်တို့ အကောင်းဆုံး ကြိုးစားထားပါတယ်။ ကျွန်ုပ်တို့သည် တတ်နိုင်သမျှ တတ်နိုင်သမျှ ပေးပို့ရန် အမှန်တကယ် ကြိုးစားသော်လည်း 100% အာမခံချက် မပေးပါ။ ထို့ကြောင့် ထိုနေရာတွင် ငွေကြေးဆိုင်ရာ အချက်အလက်များကို ရေးသားရန် မလိုအပ်ပါ။ ဤအတွက် ငွေပေးငွေယူ ဒေတာဘေ့စ်များ ရှိပါသည်။

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

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

မေးခွန်း: အချိန်တံဆိပ်တုံးသည် မီလီစက္ကန့်များဖြင့် ကွဲပြားနိုင်သည်။

အဖွေ: Timestamp ကို API ကိုယ်တိုင်ကထုတ်ပေးပါတယ်။ ဒါပဲအချက်ပါပဲ။ ကျွန်ုပ်တို့တွင် NTP ရှိသည်။ API သည် မက်ဆေ့ဂျ်တွင် ရှိပြီးသား အချိန်တံဆိပ်ကို ထုတ်ပေးသည်။ ၎င်းကို rsyslog မှထည့်မထားပါ။

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

အဖွေ: နီးပါး။ နိုင်ငံတစ်ခုစီသည် ဒေတာစင်တာတစ်ခုတွင် တည်ရှိသည်။ ကျွန်ုပ်တို့တွင် လောလောဆယ် ပျံ့နှံ့မှု မရှိသေးသောကြောင့် နိုင်ငံတစ်နိုင်ငံသည် မတူညီသော ဒေတာစင်တာများတွင် တည်ရှိနေပါသည်။ ထို့ကြောင့် ၎င်းတို့ကို ပေါင်းစပ်ရန် မလိုအပ်ပါ။ စင်တာတစ်ခုစီတွင် Log Relay တစ်ခုရှိသည်။ ၎င်းသည် Rsyslog ဆာဗာတစ်ခုဖြစ်သည်။ တကယ်တော့ စီမံခန့်ခွဲမှုစက် နှစ်ခု။ ၎င်းတို့ကို တူညီစွာ ပုံဖော်ထားသည်။ ဒါပေမယ့် အခုအချိန်မှာတော့ ယာဉ်ကြောပိတ်ဆို့မှုက သူတို့ထဲက တစ်ခုပဲ ဖြတ်သန်းနေတယ်။ ၎င်းသည် မှတ်တမ်းများအားလုံးကို စုစည်းထားသည်။ ကိစ္စရပ်တွင် ဒစ်ခ်တန်းစီရှိသည်။ ၎င်းသည် မှတ်တမ်းများကို ချုံ့ပြီး ၎င်းတို့ကို ဗဟိုဒေတာစင်တာ (စင်္ကာပူ) သို့ ပေးပို့ပြီးနောက် ၎င်းတို့ကို Graylog သို့ ပေးပို့သည်။ ဒေတာစင်တာတစ်ခုစီတွင်၎င်း၏ကိုယ်ပိုင်ဖိုင်သိုလှောင်မှုရှိသည်။ ချိတ်ဆက်မှု ပြတ်တောက်ပါက၊ ကျွန်ုပ်တို့တွင် မှတ်တမ်းများ ရှိသည်။ သူတို့အဲဒီမှာရှိနေမယ်။ အဲဒီမှာ ကယ်တင်ခြင်းခံရလိမ့်မယ်။

မေးခွန်း: အရေးပေါ်အခြေအနေတွေမှာ အဲဒီကနေ မှတ်တမ်းတွေရပါသလား။

အဖွေ: သင်သည် ထိုနေရာသို့ သွား၍ ကြည့်ရှုနိုင်ပါသည်။

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

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

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

အဖွေ: မှတ်ချက်တစ်ခု။

မေးခွန်း: ဒါက တစ်ကြောင်းပဲလား။

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

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

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

မေးခွန်း: ကျိုးနေတဲ့ JSON ကို ရေးသလား။

အဖွေ: ပက်ကေ့ချ်သည် ကြီးလွန်းသောကြောင့် ပျက်သွားသော JSON အား ထပ်ဆင့်လွှင့်စဉ်အတွင်း၌သော်လည်းကောင်း စွန့်ပစ်ပါမည်။ သို့တည်းမဟုတ် Graylog သည် JSON ကို ခွဲခြမ်းစိတ်ဖြာ၍မရသောကြောင့် ၎င်းကို စွန့်ပစ်ပါမည်။ သို့သော် ပြင်ဆင်ရန် လိုအပ်သော ဤနေရာတွင် ကွဲလွဲမှုများ ရှိပြီး အများအားဖြင့် ၎င်းတို့ကို rsyslog နှင့် ချိတ်ဆက်ထားသည်။ အဲဒီ့မှာ ကိစ္စတော်တော်များများကို ဖြည့်ထားပြီးသားဆိုတော့ ဆက်လက်လုပ်ဆောင်ဖို့ လိုပါသေးတယ်။

မေးခွန်း: ဘာလို့ Kafka လဲ။ RabbitMQ ကို စမ်းပြီးပြီလား။ Graylog သည် ထိုသို့သော load များအောက်တွင် အလုပ်မလုပ်ပါ။

အဖွေ: Graylog သည် ကျွန်ုပ်တို့အတွက် အလုပ်မဖြစ်ပါ။ Graylog သည် ကျွန်ုပ်တို့အတွက် အဆင်ပြေသည်။ ဒါဟာ တကယ်ကို ပြဿနာပါ။ ထူးခြားသောအရာတစ်ခုဖြစ်သည်။ တကယ်တော့ မလိုအပ်ပါဘူး။ ငါ rsyslog မှ elasticsearch သို့တိုက်ရိုက်ရေးပြီး Kibana ကိုကြည့်လိုသည်။ ဒါပေမယ့် လုံခြုံရေးအရ ပြဿနာကို ဖြေရှင်းဖို့ လိုပါတယ်။ Graylog ကို ဖယ်ထုတ်ပြီး Kibana ကို စတင်အသုံးပြုသောအခါတွင် ၎င်းသည် ကျွန်ုပ်တို့၏ ဖွံ့ဖြိုးတိုးတက်မှုအတွက် ဖြစ်နိုင်ချေရှိသော ရွေးချယ်မှုတစ်ခုဖြစ်သည်။ Logstash ကိုအသုံးပြုရာတွင် အရေးမကြီးပါ။ ဘာလို့လဲဆိုတော့ rsyslog နဲ့ အတူတူလုပ်လို့ရတယ်။ ၎င်းတွင် elasticsearch သို့စာရေးရန် module တစ်ခုရှိသည်။ ကျွန်ုပ်တို့သည် Graylog နှင့် တစ်နည်းနည်းဖြင့် နေထိုင်ရန် ကြိုးစားနေပါသည်။ အဲဒါကို နည်းနည်းလေးတောင် ပြင်ပြီးပြီ။ ဒါပေမယ့် တိုးတက်ဖို့ နေရာကျန်ပါသေးတယ်။

Kafka နှင့် ပတ်သက်. သမိုင်းကြောင်းအရ ဖြစ်ခဲ့တာပါ။ လာတုန်းကတော့ အဲဒါက ရှိပြီးသား၊ မှတ်တမ်းတွေလည်း ရေးပြီးသား။ ကျွန်ုပ်တို့သည် ကျွန်ုပ်တို့၏အစုအဝေးကို ရိုးရိုးရှင်းရှင်းတင်ပြီး မှတ်တမ်းများကို ၎င်းထံသို့ ရွှေ့ပါ။ အဲဒါကို စီမံခန့်ခွဲတယ်၊ ဘယ်လိုခံစားရတယ်ဆိုတာ သိတယ်။ RabbitMQ နှင့်ပတ်သက်၍… RabbitMQ ဖြင့် ကျွန်ုပ်တို့အတွက် အဆင်မပြေပါ။ ဒါပေမယ့် RabbitMQ က ကျွန်တော်တို့အတွက် အဆင်ပြေပါတယ်။ ကျွန်တော်တို့မှာ အဲဒါကို ထုတ်လုပ်မှုမှာ ရှိပြီး ပြဿနာတွေလည်း ရှိခဲ့ပါတယ်။ အခု မရောင်းခင်မှာ ငါတို့က အဲဒါကို တွေးပြီး ပုံမှန်အတိုင်းပဲ စလုပ်တော့မယ်။ ဒါပေမယ့် အရင်ကတော့ ထုတ်လုပ်ရေးလုပ်ဖို့ အဆင်သင့်မဖြစ်သေးပါဘူး။ နောက်တစ်ခုရှိသေးတယ်။ Graylog သည် AMQP ဗားရှင်း 0.9 ကိုဖတ်နိုင်ပြီး rsyslog သည် AMQP ဗားရှင်း 1.0 ကို ရေးသားနိုင်သည်။ ပြီးတော့ နှစ်ခုစလုံးကို လုပ်နိုင်တဲ့ အလယ်မှာ အဖြေမရှိဘူး။ တစ်ခု သို့မဟုတ် အခြားတစ်ခု ရှိပါသည်။ ထို့ကြောင့်၊ ယခုအချိန်တွင် Kafka သာဖြစ်သည်။ ဒါပေမယ့်လည်း သူ့မှာ ကိုယ်ပိုင် nuances တွေရှိပါတယ်။ ကျွန်ုပ်တို့အသုံးပြုသော rsyslog ဗားရှင်း၏ omkafka သည် ၎င်းကို rsyslog မှခြစ်ထုတ်လိုက်သော မက်ဆေ့ဂျ်ကြားခံတစ်ခုလုံးကို ဆုံးရှုံးနိုင်သောကြောင့်ဖြစ်သည်။ ငါတို့က အဲဒါကို လောလောဆယ် ပြင်နေတယ်။

မေးခွန်း: မင်းမှာ Kafka သုံးနေတာလား။ တခြားဘာမှ မသုံးဘူးလား။

အဖွေ: Kafka ကို Data Science အဖွဲ့မှ အသုံးပြုပါသည်။ ဤသည်မှာ လုံးဝသီးခြားပရောဂျက်တစ်ခုဖြစ်ပြီး ကံမကောင်းစွာဖြင့် ကျွန်တော်ဘာမှ မပြောနိုင်ပါ။ ကျွန်တော်မသိပါ။ Data Science အဖွဲ့၏ ထိန်းချုပ်မှုအောက်တွင်ရှိခဲ့သည်။ ကျွန်ုပ်တို့သည် လော့ဂ်အင်စတင်သောအခါ၊ ကျွန်ုပ်တို့၏ကိုယ်ပိုင်ထည့်သွင်းခြင်းမပြုရန် ၎င်းကိုအသုံးပြုရန် ဆုံးဖြတ်ခဲ့သည်။ ယခု ကျွန်ုပ်တို့သည် Graylog ကို အပ်ဒိတ်လုပ်ထားပြီး Kafka ဗားရှင်းဟောင်းရှိသောကြောင့် ကျွန်ုပ်တို့တွင် လိုက်ဖက်ညီမှု မရှိတော့ပါ။ ငါတို့ကိုယ်တိုင် စတင်ရမယ်။ တစ်ချိန်တည်းမှာပင်၊ API တစ်ခုစီအတွက် ဤအကြောင်းအရာလေးခုကို ဖယ်ရှားလိုက်ပါသည်။ တိုက်ရိုက်ထုတ်လွှင့်မှုအားလုံးအတွက် ကျယ်ပြန့်သောအကြောင်းအရာတစ်ခု၊ ဇာတ်ခုံအားလုံးအတွက် ကျယ်ပြန့်သောအကြောင်းအရာတစ်ခုကို ပြုလုပ်ခဲ့ပြီး အရာအားလုံးကို ထိုနေရာ၌သာ ပစ်ချခဲ့သည်။ Graylog သည် ဤအရာအားလုံးကို ပြိုင်တူထုတ်သည်။

မေးခွန်း: မင်းက ဘာကြောင့် ဒီ shamanism ကို ခြေစွပ်တွေနဲ့ လိုအပ်တာလဲ။ ကွန်တိန်နာများအတွက် syslog မှတ်တမ်းဒရိုက်ဗာကို သင်အသုံးပြုပြီးပြီလား။

အဖွေ: ဒီမေးခွန်းမေးနေတဲ့အချိန်မှာ Docker နဲ့ ကျွန်တော်တို့ရဲ့ဆက်ဆံရေးဟာ တင်းမာခဲ့ပါတယ်။ ၎င်းသည် Docker 1.0 သို့မဟုတ် 0.9 ဖြစ်သည်။ Docker ကိုယ်တိုင်က ထူးဆန်းတယ်။ ဒုတိယအနေနဲ့၊ သင်သည် ၎င်းကို မှတ်တမ်းများထဲသို့ တွန်းချပါက ... ၎င်းသည် Docker daemon မှတဆင့် မှတ်တမ်းများအားလုံးကို သူ့အလိုလိုဖြတ်သန်းသွားကြောင်း မသေချာသောသံသယတစ်ခုရှိသည်။ အကယ်၍ ကျွန်ုပ်တို့၏ API များထဲမှ တစ်ခုသည် ရူးသွပ်သွားပါက၊ အခြား API များသည် stdout နှင့် stderr တို့ကို မပို့နိုင်တော့သည့်အချက်ကို ကြုံတွေ့နေရသည်။ ဒါကဘာတွေဖြစ်မလဲမသိဘူး။ ဤနေရာတွင် Docker ၏ syslog driver ကိုအသုံးမပြုသင့်ဟု ခံစားရသည့်အဆင့်အပေါ် ကျွန်ုပ်သံသယရှိပါသည်။ ကျွန်ုပ်တို့၏လုပ်ငန်းဆောင်တာစစ်ဆေးမှုဌာနတွင် မှတ်တမ်းများပါရှိသော ကိုယ်ပိုင် Graylog အစုအဝေးရှိသည်။ ၎င်းတို့သည် Docker ၏ log drivers များကို အသုံးပြုပြီး အရာအားလုံး အဆင်ပြေနေပုံရသည်။ ဒါပေမယ့် သူတို့က GELF ကို Graylog နဲ့ ချက်ချင်းရေးတယ်။ ဒါတွေကို စတင်လုပ်ဆောင်တဲ့ အချိန်တုန်းကတော့ အဲဒါကို လုပ်ဆောင်ဖို့ပဲလိုတယ်။ နောက်ပိုင်းမှာ တစ်စုံတစ်ယောက်က လာလာပြီး အနှစ်တစ်ရာလောက် ကောင်းကောင်းအလုပ်လုပ်တယ်လို့ ပြောတဲ့အခါ၊ ငါတို့ ကြိုးစားမယ်။

မေးခွန်း: သင်သည် rsyslog တွင် ဒေတာစင်တာများအကြား ပေးပို့မှုပြုလုပ်သည်။ ဘာကြောင့် Kafka မှာ မလုပ်တာလဲ။

အဖွေ: တကယ်တော့ ငါတို့နှစ်ယောက်လုံးလုပ်တယ်။ အကြောင်းနှစ်ခုကြောင့်ပါ။ ချန်နယ်သည် လုံးဝသေသွားပါက၊ ကျွန်ုပ်တို့၏ မှတ်တမ်းများအားလုံးကို ဖိသိပ်ထားသည့်ပုံစံဖြင့်ပင် ၎င်းနှင့် အံကိုက်မဖြစ်ပါ။ ပြီးတော့ Kafka က သူတို့ကို လုပ်ငန်းစဉ်မှာ ရိုးရိုးရှင်းရှင်း ဆုံးရှုံးစေတယ်။ ဒီလိုနည်းနဲ့ ဒီသစ်တုံးတွေကို ရှင်းပစ်တယ်။ ဤကိစ္စတွင်ကျွန်ုပ်တို့သည် Kafka ကိုတိုက်ရိုက်အသုံးပြုသည်။ ကျွန်ုပ်တို့တွင် ကောင်းမွန်သောချန်နယ်တစ်ခုရှိပြီး ၎င်းကို ဖယ်ရှားလိုပါက ၎င်းတို့၏ rsyslog ကို အသုံးပြုပါသည်။ ဒါပေမယ့် တကယ်တမ်းတော့ သူ့ဟာသူ အဆင်မပြေတာတွေကို ဖြုတ်ချနိုင်အောင် သင်က configure လုပ်နိုင်ပါတယ်။ လောလောဆယ်တွင်၊ ကျွန်ုပ်တို့သည် အချို့နေရာများတွင် တိုက်ရိုက် rsyslog ပေးပို့ခြင်းနှင့် အခြားနေရာများတွင် Kafka ကို အသုံးပြုပါသည်။

source: www.habr.com