CIAN တွင် ကျွန်ုပ်တို့သည် မှတ်တမ်းများ၏ terabytes ကို မည်သို့ ထိန်းကျောင်းခဲ့သနည်း။

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

ငါတို့ဘယ်ကစခဲ့တာလဲ။

လွန်ခဲ့သည့်နှစ်အနည်းငယ်အတွင်း cian.ru ပေါ်တွင်တင်ဆောင်မှုသည် အလွန်လျင်မြန်စွာကြီးထွားလာခဲ့ပြီး 2018 ခုနှစ် တတိယသုံးလပတ်တွင် အရင်းအမြစ်အသွားအလာသည် တစ်လလျှင် ထူးခြားသောအသုံးပြုသူ 11.2 သန်းအထိရောက်ရှိခဲ့သည်။ ထိုအချိန်တွင်၊ အရေးကြီးသောအခိုက်အတန့်များတွင် ကျွန်ုပ်တို့သည် မှတ်တမ်းများ၏ 40% အထိ ဆုံးရှုံးသွားသောကြောင့် အဖြစ်အပျက်များကို မြန်မြန်ဆန်ဆန် မဖြေရှင်းနိုင်ဘဲ ၎င်းတို့အား ဖြေရှင်းရန် အချိန်များစွာနှင့် ကြိုးစားအားထုတ်မှုတို့ကို ကုန်ဆုံးစေသည်။ ကျွန်ုပ်တို့သည်လည်း ပြဿနာ၏အကြောင်းရင်းကို မကြာခဏရှာမတွေ့နိုင်ဘဲ အချိန်အတန်ကြာပြီးနောက် ပြန်ဖြစ်လာမည်ဖြစ်သည်။ ဒါဟာ ငရဲဖြစ်ပြီး အဲဒါနဲ့ ပတ်သက်ပြီး တစ်ခုခုလုပ်ရမှာပေါ့။

ထိုအချိန်တွင်၊ ကျွန်ုပ်တို့သည် မှတ်တမ်းများသိမ်းဆည်းရန်အတွက် ElasticSearch ဗားရှင်း 10 နှင့် စံညွှန်းဆက်တင်များပါရှိသော ဒေတာ node 5.5.2 ခုကို အသုံးပြုထားသည်။ လူကြိုက်များပြီး တတ်နိုင်သောဖြေရှင်းချက်အဖြစ် လွန်ခဲ့သည့်တစ်နှစ်ကျော်က မိတ်ဆက်ခဲ့သည်- ထို့နောက် သစ်လုံးများ၏စီးဆင်းမှုသည် ကြီးမားခြင်းမရှိပါ၊ စံမဟုတ်သောဖွဲ့စည်းပုံများပါရှိလာရန် အကြောင်းမရှိပေ။ 

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

အရှိန်အဟုန်ဖြင့် ကြီးထွားလာသော စိန်ခေါ်မှုများ

လုပ်ငန်းစဉ်နှစ်ခုသည် တစ်ခုနှင့်တစ်ခု ထပ်နေသောကြောင့် ထုတ်လုပ်လိုက်သော မှတ်တမ်းများ၏ ပမာဏသည် အလွန်လျင်မြန်စွာ တိုးလာပါသည်။ တစ်ဖက်တွင်၊ ဝန်ဆောင်မှုအသုံးပြုသူအရေအတွက် တိုးလာခဲ့သည်။ အခြားတစ်ဖက်တွင်၊ ကျွန်ုပ်တို့သည် C# နှင့် Python တို့တွင် ကျွန်ုပ်တို့၏ monoliths အဟောင်းများကို မြင်နိုင်သော microservice ဗိသုကာတစ်ခုသို့ တက်ကြွစွာကူးပြောင်းစပြုလာသည်။ monolith ၏ အစိတ်အပိုင်းများကို အစားထိုးသည့် ဒါဇင်များစွာသော မိုက်ခရိုဝန်ဆောင်မှုအသစ်များသည် အခြေခံအဆောက်အအုံအစုအဝေးအတွက် သိသိသာသာ မှတ်တမ်းများ ပိုမိုထုတ်ပေးသည်။ 

၎င်းသည် အစုအဝေးကို လက်တွေ့ကျကျ မစီမံခန့်ခွဲနိုင်သော အနေအထားသို့ ပို့ဆောင်ပေးခဲ့သည်။ မှတ်တမ်းများသည် တစ်စက္ကန့်လျှင် မက်ဆေ့ခ်ျ 20 နှုန်းဖြင့် စတင်ရောက်ရှိသောအခါ၊ မကြာခဏ အသုံးမဝင်သော လှည့်ခြင်းများသည် shards အရေအတွက် 6 သို့ တိုးလာပြီး node တစ်ခုလျှင် shards 600 ကျော်ရှိသည်။ 

၎င်းသည် RAM ခွဲဝေမှုတွင် ပြဿနာများဖြစ်ပေါ်စေပြီး node တစ်ခုပျက်သွားသောအခါ၊ shards များအားလုံးသည် တစ်ပြိုင်နက်တည်း ရွေ့လျားလာပြီး၊ traffic များကို များပြားစေကာ အခြား node များကို loading ပြုလုပ်ခြင်းဖြင့် cluster သို့ data ရေးရန် မဖြစ်နိုင်လုနီးပါးဖြစ်စေခဲ့သည်။ အဲဒီကာလမှာ ကျွန်တော်တို့ဟာ သစ်တုံးမပါဘဲ ကျန်ရစ်ခဲ့တယ်။ ဆာဗာတွင် ပြဿနာရှိပါက၊ ကျွန်ုပ်တို့သည် အခြေခံအားဖြင့် အစုအဝေး၏ 1/10 ကို ဆုံးရှုံးခဲ့ရသည်။ သေးငယ်သော အညွှန်းကိန်းများစွာသည် ရှုပ်ထွေးမှုကို ပေါင်းထည့်ထားသည်။

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

မှတ်တမ်းများ ဆုံးရှုံးမှုကို လုံးဝဖယ်ရှားရန်နှင့် ELK အစုအဝေးသို့ ၎င်းတို့၏ ပေးပို့သည့်အချိန်ကို အင်အားပြနေချိန်တွင် အများဆုံး 15 မိနစ်အထိ လျှော့ချရန် ရည်မှန်းချက်ကို ချမှတ်ထားပါသည် (နောက်ပိုင်းတွင် ဤကိန်းဂဏန်းကို ပြည်တွင်း KPI အဖြစ် မှီခိုနေရသည်)။

လည်ပတ်မှု ယန္တရားအသစ်နှင့် ပူနွေးသော ဆုံမှတ်များ

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

ဤအဆင့်တွင် အကြီးစားအသွင်ပြောင်းမှုမှာ အလယ်အလတ်ကြားခံအဖြစ် ညှိနှိုင်းရေးမှူးနှင့်အတူ node သုံးခုပေါ်တွင် Apache Kafka ကို အကောင်အထည်ဖော်ခြင်းဖြစ်သည်။ ElasticSearch နှင့် ပြဿနာများအတွင်း မှတ်တမ်းများ ဆုံးရှုံးခြင်းမှ မက်ဆေ့ချ်ပွဲစားသည် ကျွန်ုပ်တို့ကို ကယ်တင်ခဲ့သည်။ တစ်ချိန်တည်းမှာပင်၊ ကျွန်ုပ်တို့သည် အစုအဝေးသို့ node 2 ခုကိုပေါင်းထည့်ပြီး data center ရှိ မတူညီသော racks တွင်ရှိသော "hot" node သုံးခုပါသည့် ပူနွေးသောဗိသုကာအဖြစ်သို့ ပြောင်းခဲ့သည်။ မည်သည့်အခြေအနေမျိုးတွင်မဆို မဆုံးရှုံးသင့်သော မျက်နှာဖုံးကို အသုံးပြု၍ မှတ်တမ်းများကို ၎င်းတို့ထံ ပြန်ညွှန်းခဲ့သည် - nginx နှင့် အပလီကေးရှင်း အမှားအယွင်းမှတ်တမ်းများ။ မှတ်တမ်းအသေးစားများကို ကျန်ရှိသော node များသို့ ပို့လိုက်သည် - အမှားပြင်ဆင်ခြင်း၊ သတိပေးချက် စသည်တို့ကို ပေးပို့ပြီး 24 နာရီအကြာတွင်၊ "hot" node များမှ အရေးကြီးသော မှတ်တမ်းများကို လွှဲပြောင်းပေးပါသည်။

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

အစုလိုက် ပိုမိုကောင်းမွန်အောင် ပြုလုပ်ခြင်း။

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

ဥပမာအားဖြင့်၊ လည်ပတ်မှု config အတွက်၊

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

rollover alias မရှိပါက၊ အမှားအယွင်းဖြစ်သွားသည်-

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

ကျွန်ုပ်တို့သည် ဤပြဿနာအတွက် ဖြေရှင်းချက်ကို ချန်ထားခဲ့ကာ နောက်ထပ်ပြဿနာတစ်ခုအား ဖြေရှင်းခဲ့သည်- ကျွန်ုပ်တို့သည် အဝင်မှတ်တမ်းများကို လုပ်ဆောင်ပေးသည့် (မလိုအပ်သော အချက်အလက်များကို ဖယ်ရှားပြီး ကြွယ်ဝစေသည်) ဟူသော Logstash ၏ ဆွဲငင်ယုဂ်သို့ ပြောင်းခဲ့သည်။ ကျွန်ုပ်တို့သည် ၎င်းကို docker-compose မှတစ်ဆင့် စတင်သည့် docker တွင် ထားရှိကာ၊ logstash-exporter ကိုလည်း ထိုနေရာတွင် ထားရှိကာ၊ log stream ၏လည်ပတ်မှုကို စောင့်ကြည့်ရန်အတွက် Prometheus သို့ မက်ထရစ်များကို ပေးပို့ပေးပါသည်။ ဤနည်းဖြင့် ကျွန်ုပ်တို့သည် မှတ်တမ်းအမျိုးအစားတစ်ခုစီကို လုပ်ဆောင်ရန် တာဝန်ရှိသော logstash ဖြစ်ရပ်အရေအတွက်ကို ချောမွေ့စွာပြောင်းလဲရန် အခွင့်အရေးပေးခဲ့သည်။

ကျွန်ုပ်တို့သည် အစုအဝေးကို ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်နေစဉ်၊ cian.ru ၏ လမ်းကြောင်းသည် တစ်လလျှင် ထူးခြားသောအသုံးပြုသူ 12,8 သန်းအထိ တိုးလာသည်။ ရလဒ်အနေနှင့်၊ ကျွန်ုပ်တို့၏အသွင်ကူးပြောင်းမှုများသည် ထုတ်လုပ်မှုပြောင်းလဲမှုများ၏နောက်ကွယ်တွင် အနည်းငယ်ရှိနေကြောင်း တွေ့ရှိရပြီး "ပူနွေးသော" nodes များသည် ဝန်ကိုမထိန်းနိုင်ဘဲ မှတ်တမ်းများပေးပို့မှုတစ်ခုလုံးကို နှေးကွေးစေသည့်အချက်နှင့် ရင်ဆိုင်ခဲ့ရသည်။ ကျွန်ုပ်တို့သည် မအောင်မြင်ဘဲ "hot" ဒေတာကို လက်ခံရရှိခဲ့သည်၊ သို့သော် ကျန်အရာများကို ပေးပို့ရာတွင် ဝင်ရောက်စွက်ဖက်ကာ အညွှန်းကိန်းများကို အညီအမျှ ဖြန့်ဝေနိုင်ရန် လူကိုယ်တိုင် လှည့်ပတ်လုပ်ဆောင်ရပါမည်။ 

တစ်ချိန်တည်းမှာပင်၊ အစုအဝေးရှိ logstash ဖြစ်ရပ်များ၏ ဆက်တင်များကို ချဲ့ထွင်ခြင်းနှင့် ပြောင်းလဲခြင်းတို့သည် ဒေသခံ docker-compose ဖြစ်သည်ဟူသောအချက်ကြောင့် ရှုပ်ထွေးခဲ့ပြီး လုပ်ဆောင်ချက်များအားလုံးကို ကိုယ်တိုင်လုပ်ဆောင်ခဲ့သည် (အဆုံးအသစ်များထည့်ရန်၊ အားလုံးကို ကိုယ်တိုင်ဖြတ်သန်းရန် လိုအပ်ပါသည်။ ဆာဗာများနှင့် docker-compose up -d နေရာတိုင်းတွင်ပြုလုပ်ပါ။

မှတ်တမ်းပြန်လည်ဖြန့်ဝေခြင်း။

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

ကျွန်ုပ်တို့သည် ဟာ့ဒ်ဝဲအပ်ဒိတ်ဖြင့် နောက်တစ်ကြိမ် ထပ်လုပ်ပါသည်။ ကျွန်ုပ်တို့သည် ညှိနှိုင်းရေးမှူးငါးဦးမှ သုံးဦးသို့ပြောင်းကာ ဒေတာဆုံမှတ်များကို အစားထိုးကာ ငွေကြေးနှင့် သိုလှောင်မှုနေရာတို့၌ အနိုင်ရခဲ့သည်။ node များအတွက် configuration နှစ်ခုကိုအသုံးပြုသည်- 

• "hot" nodes အတွက်- E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (Hot3 အတွက် 1 နှင့် Hot3 အတွက် 2)။
• "နွေးထွေးသော" ဆုံမှတ်များအတွက်- E3-1230 v6 / 4Tb SSD / 32 Gb x 4 ။

ဤအစီအစဥ်တွင်၊ ကျွန်ုပ်တို့သည် ရှေ့လိုင်း nginx မှတ်တမ်းများကဲ့သို့ နေရာယူထားသည့် microservices ၏ဝင်ရောက်ခွင့်မှတ်တမ်းများဖြင့် အညွှန်းကိန်းကို "hot" node သုံးခု၏ ဒုတိယအုပ်စုသို့ ရွှေ့လိုက်ပါသည်။ ယခုအခါ ကျွန်ုပ်တို့သည် “hot” node များတွင် ဒေတာကို နာရီ 20 ကြာ သိမ်းဆည်းထားပြီး ကျန်မှတ်တမ်းများဆီသို့ ၎င်းတို့အား “နွေး” သည့်နေရာများသို့ လွှဲပြောင်းပါ။ 

၎င်းတို့၏ လည်ပတ်မှုကို ပြန်လည်သတ်မှတ်ခြင်းဖြင့် သေးငယ်သော အညွှန်းများ ပျောက်ဆုံးသွားသည့် ပြဿနာကို ကျွန်ုပ်တို့ ဖြေရှင်းခဲ့သည်။ ယခုအခါတွင် ဒေတာအနည်းငယ်သာရှိသော်လည်း မည်သည့်အခြေအနေမျိုးတွင်မဆို ၂၃ နာရီတိုင်း အညွှန်းကိန်းများကို လှည့်ပတ်နေပါသည်။ ဤအရာသည် shards အရေအတွက်အနည်းငယ်တိုးလာသည် (၎င်းတို့ထဲမှ 23 ခန့်ရှိသည်)၊ သို့သော် cluster performance ၏ရှုထောင့်မှကြည့်လျှင်၎င်းသည်သည်းခံနိုင်သည်။ 

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

ဤပြန်ဆိုချက်သည် semi-automatic scaling မရှိခြင်းပြဿနာကိုလည်း ဖြေရှင်းပေးပါသည်။ ဒါကိုလုပ်ဖို့၊ ကျွန်ုပ်တို့ဟာ ထုတ်လုပ်မှုမှာ ဖြန့်ကျက်ထားပြီးသားနဲ့ ဆင်တူတဲ့ အခြေခံအဆောက်အဦ Nomad cluster ကို ဖြန့်ကျက်ထားပါတယ်။ ယခုအချိန်တွင်၊ Logstash ပမာဏသည် ဝန်ပေါ် မူတည်၍ အလိုအလျောက်ပြောင်းလဲခြင်းမရှိသော်လည်း၊ ကျွန်ုပ်တို့သည် ဤသို့လာပါမည်။

အနာဂတျအတှကျအစီအစဉျမြား

အကောင်အထည်ဖော်ထားသော ဖွဲ့စည်းမှုပုံစံစကေးများကို စုံလင်စွာ ချိန်ညှိထားပြီး ယခု ကျွန်ုပ်တို့သည် ဒေတာ 13,3 TB - အရေးပေါ်သတိပေးချက်များကို ခွဲခြမ်းစိတ်ဖြာမှုအတွက် လိုအပ်သော မှတ်တမ်းများအားလုံးကို 4 ရက်ကြာ သိမ်းဆည်းထားပါသည်။ ကျွန်ုပ်တို့သည် မှတ်တမ်းအချို့ကို Graphite သို့ထည့်သည့် မက်ထရစ်များအဖြစ်သို့ ပြောင်းလဲပါသည်။ အင်ဂျင်နီယာများ၏အလုပ်ပိုမိုလွယ်ကူစေရန်အတွက်၊ သာမန်ပြဿနာများ၏တစ်ပိုင်းအလိုအလျောက်ပြုပြင်ခြင်းအတွက် အခြေခံအဆောက်အအုံအစုအဝေးအတွက် မက်ထရစ်များနှင့် scripts များရှိသည်။ လာမည့်နှစ်အတွက် စီစဉ်ထားသည့် ဒေတာ node အရေအတွက်ကို တိုးမြှင့်ပြီးနောက်၊ ကျွန်ုပ်တို့သည် 4 ရက်မှ 7 ရက်အထိ ဒေတာသိုလှောင်မှုသို့ ပြောင်းပါမည်။ ကျွန်ုပ်တို့သည် အဖြစ်အပျက်များကို တတ်နိုင်သမျှ အမြန်ဆုံးစုံစမ်းရန် အမြဲကြိုးစားနေပြီး ရေရှည်စုံစမ်းစစ်ဆေးမှုများအတွက် တယ်လီမီတာဒေတာပါရှိသောကြောင့် လုပ်ငန်းလည်ပတ်မှုလုပ်ငန်းအတွက် ၎င်းသည် လုံလောက်မည်ဖြစ်သည်။ 

2019 ခုနှစ် အောက်တိုဘာလတွင်၊ cian.ru သို့ လမ်းကြောင်းသည် တစ်လလျှင် ထူးခြားသောအသုံးပြုသူ 15,3 သန်းအထိ တိုးလာခဲ့သည်။ ဤသည်မှာ သစ်လုံးများပေးပို့ခြင်းအတွက် ဗိသုကာဆိုင်ရာဖြေရှင်းချက်၏ လေးနက်သောစမ်းသပ်မှုတစ်ခု ဖြစ်လာခဲ့သည်။ 

ယခု ကျွန်ုပ်တို့သည် ElasticSearch ကို ဗားရှင်း 7 သို့ အပ်ဒိတ်လုပ်ရန် ပြင်ဆင်နေပါသည်။ သို့သော်၊ ၎င်းတို့သည် ဗားရှင်း 5.5 မှ ပြောင်းရွှေ့ပြီး ဗားရှင်း 6 တွင် ရပ်ဆိုင်းထားသည်ဟု ကြေညာထားသောကြောင့် ၎င်းအတွက် ElasticSearch တွင် အညွှန်းများစွာ၏ မြေပုံဆွဲခြင်းကို အပ်ဒိတ်လုပ်ရမည်ဖြစ်ပါသည်။ ၇)။ ဆိုလိုသည်မှာ အပ်ဒိတ်လုပ်ငန်းစဉ်အတွင်း ပြဿနာကိုဖြေရှင်းပြီးချိန်တွင် ကျွန်ုပ်တို့အား မှတ်တမ်းများမပါဘဲ ထွက်ခွာသွားမည့် force majeure တစ်မျိုးမျိုးရှိနေမည်မှာ သေချာပါသည်။ ဗားရှင်း 7 တွင်၊ ကျွန်ုပ်တို့သည် ပိုမိုကောင်းမွန်သော အင်တာဖေ့စ်နှင့် စစ်ထုတ်မှုအသစ်များဖြင့် Kibana ကို စောင့်မျှော်နေပါသည်။ 

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

source: www.habr.com