Yury Bushmelev "သစ်လုံးစုဆောင်းခြင်းနှင့်ပေးပို့ခြင်းနယ်ပယ်ရှိလူယုတ်မာများ၏မြေပုံ" - အစီရင်ခံစာ၏စာသားမှတ်တမ်း

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

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

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

Yuri Bushmelev ၏ "သစ်လုံးများ စုဆောင်းခြင်းနှင့် ပို့ဆောင်ခြင်းနယ်ပယ်ရှိ ထွန်တုံးတစ်တုံး၏မြေပုံ"

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

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

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

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

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

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

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

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

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

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

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

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

နည်းနည်းထပ်ကြည့်ရအောင်။ ဤမှတ်တမ်းများကို ကျွန်ုပ်တို့ မည်သို့ပေးပို့ခဲ့သနည်း။ တစ်စုံတစ်ယောက်သည် 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 ကို ကွန်တိန်နာတစ်ခုတွင် သီးခြားခွဲထားရန်နှင့် ၎င်းကို ဖတ်ရန်သာဖြစ်ရန် လိုလားပါသည်။ ကျွန်ုပ်သည် စနစ်စီမံခန့်ခွဲသူတစ်ဦးဖြစ်သောကြောင့် ဤအရာများနှင့်ပတ်သက်၍ ကျွန်ုပ်တွင် အခြားရွေးချယ်စရာအမြင်တစ်ခုရှိသည်။

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

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

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

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

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

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

ထိုနေရာတွင် (ဆလိုက်ပေါ်တွင်) “မှတ်တမ်းပေးပို့ခြင်းအတွက် SLA” သည် စတင်ပေါ်လာရုံသာဖြစ်သည်။ မရောက်သေးပေမယ့် အဲဒါကို ကျွန်တော်တို့ လုပ်ဆောင်နေပါတယ်။ Infra က ဒီလိုပုံစံနဲ့ ဒီလိုပုံစံနဲ့ ရေးပြီး အဲဒီနေရာကို စက္ကန့်မှာ N ထက်မပိုစေရဘူးလို့ ပြောတဲ့အခါ အရမ်းအဆင်ပြေတဲ့အတွက် အဲဒါကို အဲဒီနေရာမှာ ပို့ပေးဖို့ ဖြစ်နိုင်တယ်။ ခေါင်းကိုက်ခြင်းကို များစွာ သက်သာစေပါသည်။ SLA ရှိရင် အရမ်းကောင်းတယ်။

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

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

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

sysadmin အတွက် သိသာထင်ရှားသော ဖြေရှင်းချက်မှာ ဤပမာဏရှိ syslog အမျိုးအစားအားလုံး (syslog-ng/rsyslog/nxlog) ဖြစ်သည်။

သို့မဟုတ် သင့်ကိုယ်ပိုင် တစ်ခုခုကို ရေးပါ၊ သို့သော် ကျွန်ုပ်တို့ ၎င်းကို ဖယ်ထားသည့်အပြင် 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 code ကိုခွဲခြမ်းစိပ်ဖြာသည့်နည်းအတိုင်း မှတ်တမ်းများကို ခွဲခြမ်းစိပ်ဖြာသည်။ ၎င်းသည် သင့်အား အလွန်လျင်မြန်စွာ အလုပ်လုပ်နိုင်စေကာ CPU အနည်းငယ်ကို စားနိုင်စေပြီး ယေဘုယျအားဖြင့် ၎င်းသည် အလွန်အေးမြသော အရာတစ်ခုဖြစ်သည်။ အခြားသော ဘောနပ်စ်များလည်း အများအပြားရှိပါသည်။ သူတို့အပေါ်မှာ ငါနေမှာမဟုတ်ဘူး။

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

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

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

Rsyslog သည် slide တွင်ဖော်ပြထားသောလုပ်ဆောင်ချက်များကိုလုပ်ဆောင်ပြီး relay သို့မဟုတ် Kafka သို့မှတ်တမ်းများပေးပို့သည်။ Kafka က လမ်းဟောင်းကို လိုက်နေပါတယ်။ Rayleigh - မှတ်တမ်းများပေးပို့ရန် စစ်မှန်သော 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 သည် တစ်စက္ကန့်လျှင် မက်ဆေ့ချ် ၁၂ဝဝဝ သာပြသသည်။ အကြွင်းအကျန်တွေ ဘယ်မှာလဲ၊ Graylog သည် ရိုးရိုးရှင်းရှင်း ထိန်းကျောင်းနိုင်မည်မဟုတ်ကြောင်း ကျွန်ုပ်တို့ကောက်ချက်ချခဲ့သည်။ ကျွန်ုပ်တို့သည် Elasticsearch နှင့်အတူ Graylog ကိုကြည့်ရှုခဲ့ပြီး၊ အမှန်ပင် ဤစီးဆင်းမှုကို မကျွမ်းကျင်ခဲ့ပါ။

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

အဖွေ: ကျွန်တော်နားလည်ပါတယ်။ ကျွန်ုပ်တို့သည် လက်နှစ်ဘက်စလုံးဖြင့် "အတွက်" ဖြစ်သည်။

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

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

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

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

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

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

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

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

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

အဖွေ: သင်သည် ထိုနေရာ (ဖိုင်သိုလှောင်ခန်းသို့) သွား၍ ကြည့်ရှုနိုင်သည်။

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

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

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

အဖွေ: ပုံတူတစ်ခု။

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

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

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

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

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

အဖွေပက်ကက်သည် ကြီးလွန်းသောကြောင့် ပျက်သွားသော JSON ကို ထပ်ဆင့်လွှင့်စဉ်တွင်သော်လည်းကောင်း စွန့်ပစ်ပါမည်။ သို့မဟုတ်ပါက JSON ကို ခွဲခြမ်းစိတ်ဖြာနိုင်မည်မဟုတ်သောကြောင့် Graylog ကို ဖြုတ်ချပါမည်။ သို့သော် ပြင်ဆင်ရန် လိုအပ်သော ဤနေရာတွင် ကွဲလွဲမှုများ ရှိပြီး အများအားဖြင့် ၎င်းတို့ကို 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 အဖွဲ့မှ ဦးစီးဆောင်ရွက်ခဲ့သည်။ သစ်လုံးများစတင်သောအခါတွင် ၎င်းတို့သည် ၎င်းတို့ကိုယ်ပိုင်မထားရှိရန် ဆုံးဖြတ်ခဲ့ကြသည်။ ယခု ကျွန်ုပ်တို့သည် Graylog ကို အပ်ဒိတ်လုပ်ထားပြီး Kafka ဗားရှင်းဟောင်းရှိသောကြောင့် ကျွန်ုပ်တို့တွင် လိုက်ဖက်ညီမှု မရှိတော့ပါ။ ငါတို့ကိုယ်တိုင်လုပ်ရမယ်။ တစ်ချိန်တည်းမှာပင်၊ API တစ်ခုစီအတွက် ဤအကြောင်းအရာလေးခုကို ဖယ်ရှားလိုက်ပါသည်။ တိုက်ရိုက်ထုတ်လွှင့်မှုအားလုံးအတွက် ကျယ်ပြန့်သောထိပ်တစ်ခု၊ ဇာတ်ခုံအားလုံးအတွက် ကျယ်ပြန့်သောထိပ်တစ်ပိုင်းကို ပြုလုပ်ခဲ့ပြီး ထိုနေရာ၌ အရာအားလုံးကို ရိုက်ကူးခဲ့သည်။ Graylog သည် ဤအရာအားလုံးကို ပြိုင်တူထုတ်သည်။

မေးခွန်း: အဘယ်ကြောင့် ငါတို့သည် ဤ shamanism ကိုခြေစွပ်များနှင့်အတူလိုအပ်သနည်း။ ကွန်တိန်နာများအတွက် syslog log driver ကို သင်အသုံးပြုပြီးပြီလား။

အဖွေ: ဒီမေးခွန်းမေးတဲ့ အချိန်မှာ၊ 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 ကို အသုံးပြုပါသည်။ ဒါပေမယ့် တကယ်တမ်းကျတော့ အဲဒါကို မပြီးပြတ်အောင် ထိန်းထားနိုင်တယ်။ လောလောဆယ်တွင် ကျွန်ုပ်တို့သည် rsyslog ပေးပို့မှုကို တိုက်ရိုက်တစ်နေရာ၊ Kafka တစ်နေရာတွင်သာ အသုံးပြုနေပါသည်။

source: www.habr.com