Loki ထံမှ မှတ်တမ်းများ စုဆောင်းခြင်း။

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

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

Loki ဆိုတာဘာလဲ

Grafana Loki သည် ပြီးပြည့်စုံသော သစ်ခုတ်ခြင်းစနစ်အတွက် အစိတ်အပိုင်းများဖြစ်သည်။ အခြားအလားတူစနစ်များနှင့်မတူဘဲ Loki သည် log metadata များ (Prometheus ကဲ့သို့ပင်) အညွှန်းများ (Prometheus ကဲ့သို့) တစ်ခုတည်းသော log metadata များကိုသာအညွှန်းပြုလုပ်ခြင်းနှင့် logs များကိုသီးခြားအတုံးများအဖြစ်သို့ချုံ့ခြင်းအယူအဆအပေါ်အခြေခံသည်။

ပင်မစာမျက်နှာ, GitHub

Loki နဲ့ သင်ဘာတွေလုပ်နိုင်လဲဆိုတာကို ဖော်ပြချက်မတင်ခင်မှာ "မက်တာဒေတာတွေကိုသာ indexing လုပ်ခြင်းစိတ်ကူး" က ဘာကိုဆိုလိုသလဲဆိုတာကို ရှင်းပြချင်ပါတယ်။ nginx မှတ်တမ်းမှ စာကြောင်းတစ်ခု၏ ဥပမာကို အသုံးပြု၍ Elasticsearch ကဲ့သို့သော ရိုးရာဖြေရှင်းနည်းများတွင် Loki ချဉ်းကပ်မှုနှင့် အညွှန်းကိန်းချဉ်းကပ်နည်းကို နှိုင်းယှဉ်ကြည့်ကြပါစို့။

172.19.0.4 - - [01/Jun/2020:12:05:03 +0000] "GET /purchase?user_id=75146478&item_id=34234 HTTP/1.1" 500 8102 "-" "Stub_Bot/3.0" "0.001"

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

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

ကြီးမားသောအမြန်အညွှန်းကိန်းနှင့် သေးငယ်သောအပြိုင် brute-force အညွှန်းကြားတွင် ဤအပေးအယူသည် Loki သည် စနစ်၏ကုန်ကျစရိတ်ကို ထိန်းချုပ်နိုင်စေသည်။ ၎င်းကို သင့်လိုအပ်ချက်အရ လိုက်လျောညီထွေဖြစ်အောင် ပြင်ဆင်ပြီး ချဲ့နိုင်သည်။

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

မှတ်တမ်းရှာဖွေမှု

မှတ်တမ်းများကို အထူးအင်တာဖေ့စ် Grafana — Explorer တွင် သင်ရှာဖွေနိုင်သည်။ စုံစမ်းမှုများသည် Prometheus အသုံးပြုသော PromQL နှင့် အလွန်ဆင်တူသည့် LogQL ဘာသာစကားကို အသုံးပြုသည်။ မူအရ၊ ၎င်းကို ဖြန့်ဝေသည့် grep အဖြစ် ယူဆနိုင်သည်။

ရှာဖွေမှု အင်တာဖေ့စ်သည် ဤကဲ့သို့ ဖြစ်သည်-

စုံစမ်းမှုတွင် အပိုင်းနှစ်ပိုင်းပါဝင်သည်- ရွေးချယ်သူနှင့် စစ်ထုတ်မှု။ Selector သည် မှတ်တမ်းများတွင် သတ်မှတ်ပေးထားသော အညွှန်းမှတ်ထားသော မက်တာဒေတာ (အညွှန်းများ) ဖြင့် ရှာဖွေမှုတစ်ခုဖြစ်ပြီး စစ်ထုတ်မှုသည် ရွေးချယ်သူမှ သတ်မှတ်ထားသော မှတ်တမ်းများကို စစ်ထုတ်သည့် ရှာဖွေရေးစာကြောင်း သို့မဟုတ် regexp ဖြစ်သည်။ ပေးထားသောဥပမာတွင်- curly brackets တွင် - ရွေးချယ်သူ၊ အားလုံးပြီးနောက် - filter ကို။

{image_name="nginx.promtail.test"} |= "index"

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

ရွေးချယ်သူသည် ကောက်ကောက်ကောက်ကောက်များတွင် တန်ဖိုး၏သော့တန်ဖိုးဖြစ်သည်။ =, != အော်ပရေတာများ သို့မဟုတ် ပုံမှန်အသုံးအနှုန်းများကို အသုံးပြု၍ မတူညီသော ရှာဖွေမှုအခြေအနေများကို သင်ပေါင်းစပ်သတ်မှတ်နိုင်သည်-

{instance=~"kafka-[23]",name!="kafka-dev"} 
// Найдёт логи с лейблом instance, имеющие значение kafka-2, kafka-3, и исключит dev 

စစ်ထုတ်မှုသည် ရွေးချယ်သူမှရရှိသောဒေတာအားလုံးကို စစ်ထုတ်မည့် စာသား သို့မဟုတ် regexp ဖြစ်သည်။

မက်ထရစ်မုဒ်တွင် လက်ခံရရှိသည့်ဒေတာအပေါ်အခြေခံ၍ ad-hoc ဂရပ်ဖစ်များကို ရရှိနိုင်သည်။ ဥပမာအားဖြင့်၊ အညွှန်းစာတန်းပါရှိသော entry ၏ nginx မှတ်တမ်းများတွင် ဖြစ်ပျက်မှုအကြိမ်ရေကို ရှာတွေ့နိုင်သည်-

အင်္ဂါရပ်များအကြောင်း အပြည့်အစုံကို စာရွက်စာတမ်းများတွင် တွေ့နိုင်ပါသည်။ LogQL.

မှတ်တမ်း ပိုင်းခြားခြင်း။

မှတ်တမ်းများ စုဆောင်းရန် နည်းလမ်းများစွာ ရှိပါသည်။

• မှတ်တမ်းများစုဆောင်းခြင်းအတွက် stack ၏စံအစိတ်အပိုင်းတစ်ခုဖြစ်သော Promtail ၏အကူအညီဖြင့်။
• docker container မှ တိုက်ရိုက်အသုံးပြုခြင်း။ Loki Docker Logging Driver
• Loki သို့ဒေတာပေးပို့နိုင်သည့် Fluentd သို့မဟုတ် Fluent Bit ကိုသုံးပါ။ Promtail နှင့်မတူဘဲ၊ ၎င်းတို့တွင် မှတ်တမ်းအမျိုးအစားတိုင်းနီးပါးအတွက် အဆင်သင့်လုပ်ထားသော ခွဲခြမ်းစိတ်ဖြာမှုများရှိပြီး လိုင်းများစွာမှတ်တမ်းများကို ကိုင်တွယ်နိုင်သည်။

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

• ဒေတာအရင်းအမြစ်များကိုရှာပါ။
• ၎င်းတို့ထံ အညွှန်းများ ချိတ်ပါ။
• ဒေတာများကို Loki သို့ပေးပို့သည်။

လောလောဆယ် Promtail သည် ပြည်တွင်းဖိုင်များနှင့် systemd ဂျာနယ်မှ မှတ်တမ်းများကို ဖတ်နိုင်သည်။ မှတ်တမ်းများ စုဆောင်းသည့် စက်တိုင်းတွင် ၎င်းကို ထည့်သွင်းရပါမည်။

Kubernetes နှင့် ပေါင်းစည်းမှု ရှိနေသည်- Promtail သည် Kubernetes REST API မှတဆင့် အစုအဝေး၏ အခြေအနေကို အလိုအလျောက် ရှာဖွေပြီး node၊ ဝန်ဆောင်မှု သို့မဟုတ် pod မှ မှတ်တမ်းများကို စုဆောင်းကာ Kubernetes မှ မက်တာဒေတာကို အခြေခံ၍ အညွှန်းများ ချက်ချင်းတင်ခြင်း (pod အမည်၊ ဖိုင်အမည် စသည်ဖြင့်)။

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

1. အဆင့်ဆင့်ခွဲခြမ်းစိတ်ဖြာခြင်း။. ဤသည်မှာ RegEx နှင့် JSON ၏ အဆင့်ဖြစ်သည်။ ဤအဆင့်တွင်၊ ကျွန်ုပ်တို့သည် ထုတ်ယူထားသောမြေပုံဟုခေါ်သော မှတ်တမ်းများမှ အချက်အလက်များကို ထုတ်ယူပါသည်။ ထုတ်ယူထားသောမြေပုံသို့ကျွန်ုပ်တို့လိုအပ်သောအကွက်များကိုကူးယူရုံဖြင့် JSON မှထုတ်ယူနိုင်သည် သို့မဟုတ် ပုံမှန်အသုံးအနှုန်းများ (RegEx) မှတဆင့်အမည်တပ်ထားသောအဖွဲ့များကိုထုတ်ယူထားသောမြေပုံသို့ "မြေပုံဆွဲထားသည်" နေရာတွင်ထုတ်ယူနိုင်သည်။ ထုတ်ယူထားသောမြေပုံသည် သော့တန်ဖိုးသိုလှောင်မှုဖြစ်ပြီး သော့သည် အကွက်အမည်ဖြစ်ပြီး တန်ဖိုးသည် မှတ်တမ်းများမှ ၎င်း၏တန်ဖိုးဖြစ်သည်။
2. အဆင့်ဆင့်ပြောင်းလဲပါ။. ဤအဆင့်တွင် ရွေးချယ်စရာ နှစ်ခုရှိသည်- အသွင်ပြောင်းရန်၊ ကျွန်ုပ်တို့ သတ်မှတ်သည့် အသွင်ပြောင်းခြင်းဆိုင်ရာ စည်းမျဉ်းများနှင့် အရင်းအမြစ် - ထုတ်ယူထားသော မြေပုံမှ အသွင်ပြောင်းခြင်းအတွက် ဒေတာအရင်းအမြစ်။ ထုတ်ယူထားသောမြေပုံတွင် ထိုသို့သောအကွက်မရှိပါက၊ ၎င်းကို ဖန်တီးမည်ဖြစ်သည်။ ထို့ကြောင့်၊ ထုတ်ယူထားသောမြေပုံပေါ်တွင်အခြေခံခြင်းမရှိသောအညွှန်းများကိုဖန်တီးနိုင်သည်။ ဤအဆင့်တွင်၊ ကျွန်ုပ်တို့သည် အလွန်အစွမ်းထက်သော ထုတ်ယူထားသောမြေပုံကို အသုံးပြု၍ ဒေတာကို ကိုင်တွယ်နိုင်သည်။ Golang ပုံစံခွက်. ထို့အပြင်၊ ခွဲခြမ်းစိတ်ဖြာစဉ်အတွင်း ထုတ်ယူထားသောမြေပုံကို အပြည့်အ၀တင်ထားကြောင်း မှတ်သားထားရမည်ဖြစ်ပြီး၊ ဥပမာအားဖြင့် ၎င်းရှိတန်ဖိုးကို စစ်ဆေးရန် ဖြစ်နိုင်သည်- “{{if .tag}tag တန်ဖိုးရှိပါသည်{end}}”။ နမူနာပုံစံသည် အခြေအနေများ၊ ကွင်းဆက်များနှင့် အစားထိုးခြင်းနှင့် ဖြတ်တောက်ခြင်းကဲ့သို့သော string function အချို့ကို ပံ့ပိုးပေးသည်။
3. လုပ်ဆောင်ချက်အဆင့်ဆင့်. ဤအဆင့်တွင်၊ သင်သည် ထုတ်ယူထားသော အရာတစ်ခုခုကို လုပ်ဆောင်နိုင်သည်-
   • Loki မှ အညွှန်းပေးမည့် ထုတ်ယူထားသော ဒေတာမှ အညွှန်းတစ်ခု ဖန်တီးပါ။
   • မှတ်တမ်းမှ အဖြစ်အပျက်အချိန်ကို ပြောင်းပါ သို့မဟုတ် သတ်မှတ်ပါ။
   • Loki သို့သွားမည့် ဒေတာ (မှတ်တမ်းစာသား) ကို ပြောင်းပါ။
   • တိုင်းတာမှုများ ပြုလုပ်ပါ။
4. အဆင့်ဆင့်စီစစ်ခြင်း။. ကျွန်ုပ်တို့သည် /dev/null မလိုအပ်သော မှတ်တမ်းများကို ပေးပို့နိုင်သည် သို့မဟုတ် ၎င်းတို့ကို ဆက်လက်လုပ်ဆောင်ရန်အတွက် ၎င်းတို့ကို ပေးပို့နိုင်သည့် ပွဲစဉ်အဆင့်။

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

စမ်းသပ်မှုအတွက်၊ ပြင်ဆင်ထားသော nginx jwilder/nginx-proxy:alpine ရုပ်ပုံနှင့် nginx-proxy အဖြစ် HTTP မှတစ်ဆင့် သူ့ဘာသာသူ စုံစမ်းနိုင်သော daemon အသေးတစ်ခုကို ယူလိုက်ကြပါစို့။ daemon တွင် မတူညီသော အရွယ်အစား၊ မတူညီသော HTTP အခြေအနေများနှင့် မတူညီသော နှောင့်နှေးမှုများနှင့်အတူ အရွယ်အစားအမျိုးမျိုး၏ တုံ့ပြန်မှုများကို ပေးစွမ်းနိုင်သော daemon အများအပြားရှိသည်။

/var/lib/docker/containers/ လမ်းကြောင်းတစ်လျှောက်တွင် တွေ့ရှိနိုင်သည့် docker containers များမှ မှတ်တမ်းများကို စုဆောင်းပါမည်။ / -json.log

docker-compose.yml တွင်ကျွန်ုပ်တို့သည် Promtail ကိုတည်ဆောက်ပြီး config သို့လမ်းကြောင်းကိုသတ်မှတ်သည်-

promtail:
  image: grafana/promtail:1.4.1
 // ...
 volumes:
   - /var/lib/docker/containers:/var/lib/docker/containers:ro
   - promtail-data:/var/lib/promtail/positions
   - ${PWD}/promtail/docker.yml:/etc/promtail/promtail.yml
 command:
   - '-config.file=/etc/promtail/promtail.yml'
 // ...

promtail.yml သို့ မှတ်တမ်းများထဲသို့ လမ်းကြောင်းကို ထည့်ပါ (စာကြောင်းတစ်ကြောင်းတည်းတွင် တူညီသော config တွင် "docker" ရွေးစရာတစ်ခု ရှိသည်၊ သို့သော် ၎င်းသည် အလွန်ထင်ရှားမည်မဟုတ်ပါ)။

scrape_configs:
 - job_name: containers

   static_configs:
       labels:
         job: containerlogs
         __path__: /var/lib/docker/containers/*/*log  # for linux only

ဤဖွဲ့စည်းပုံကို ဖွင့်ထားသောအခါ၊ Loki သည် ကွန်တိန်နာအားလုံးမှ မှတ်တမ်းများကို လက်ခံရရှိမည်ဖြစ်သည်။ ၎င်းကိုရှောင်ရှားရန်၊ docker-compose.yml တွင် စမ်းသပ် nginx ၏ဆက်တင်များကို ကျွန်ုပ်တို့ပြောင်းလဲလိုက်သည် - tag အကွက်သို့ မှတ်တမ်းထည့်ခြင်း-

proxy:
 image: nginx.test.v3
//…
 logging:
   driver: "json-file"
   options:
     tag: "{{.ImageName}}|{{.Name}}"

promtail.yml ကို တည်းဖြတ်ပြီး ပိုက်လိုင်းကို စနစ်ထည့်သွင်းပါ။ မှတ်တမ်းများမှာ အောက်ပါအတိုင်းဖြစ်သည်။

{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /api/index HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.096"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.66740443Z"}
{"log":"u001b[0;33;1mnginx.1    | u001b[0mnginx.test 172.28.0.3 - - [13/Jun/2020:23:25:50 +0000] "GET /200 HTTP/1.1" 200 0 "-" "Stub_Bot/0.1" "0.000"n","stream":"stdout","attrs":{"tag":"nginx.promtail.test|proxy.prober"},"time":"2020-06-13T23:25:50.702925272Z"}

ပိုက်လိုင်းအဆင့်များ-

 - json:
     expressions:
       stream: stream
       attrs: attrs
       tag: attrs.tag

ကျွန်ုပ်တို့သည် အဝင် JSON မှ stream, attrs, attrs.tag အကွက်များ (ရှိပါက) ကို ထုတ်ယူပြီး ၎င်းတို့ကို ထုတ်ယူထားသောမြေပုံတွင် ထည့်သွင်းပါ။

 - regex:
     expression: ^(?P<image_name>([^|]+))|(?P<container_name>([^|]+))$
     source: "tag"

ထုတ်ယူထားသောမြေပုံတွင် tag အကွက်ကို ထည့်ထားနိုင်လျှင် regexp ကိုအသုံးပြု၍ ပုံနှင့် container ၏အမည်များကို ထုတ်ယူပါ။

 - labels:
     image_name:
     container_name:

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

 - match:
     selector: '{job="docker",container_name="",image_name=""}'
     action: drop

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

  - match:
     selector: '{image_name="nginx.promtail.test"}'
     stages:
       - json:
           expressions:
             row: log

image_name သည် nginx.promtail.test နှင့် ညီမျှသည့် မှတ်တမ်းအားလုံးအတွက်၊ ကျွန်ုပ်တို့သည် အရင်းအမြစ်မှတ်တမ်းမှ မှတ်တမ်းအကွက်ကို ထုတ်ယူပြီး ထုတ်ယူထားသောမြေပုံတွင် အတန်းသော့ဖြင့် ထည့်ထားသည်။

  - regex:
         # suppress forego colors
         expression: .+nginx.+|.+[0m(?P<virtual_host>[a-z_.-]+) +(?P<nginxlog>.+)
         source: logrow

ကျွန်ုပ်တို့သည် ပုံမှန်အသုံးအနှုန်းများဖြင့် ထည့်သွင်းသည့်စာကြောင်းကို ရှင်းလင်းပြီး nginx virtual host နှင့် nginx မှတ်တမ်းလိုင်းကို ဖယ်ရှားပါသည်။

     - regex:
         source: nginxlog
         expression: ^(?P<ip>[w.]+) - (?P<user>[^ ]*) [(?P<timestamp>[^ ]+).*] "(?P<method>[^ ]*) (?P<request_url>[^ ]*) (?P<request_http_protocol>[^ ]*)" (?P<status>[d]+) (?P<bytes_out>[d]+) "(?P<http_referer>[^"]*)" "(?P<user_agent>[^"]*)"( "(?P<response_time>[d.]+)")?

ပုံမှန်ဖော်ပြချက်များဖြင့် nginx မှတ်တမ်းကို ပိုင်းခြားပါ။

    - regex:
           source: request_url
           expression: ^.+.(?P<static_type>jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|pdf|txt|tar|wav|bmp|rtf|js|flv|swf|html|htm)$
     - regex:
           source: request_url
           expression: ^/photo/(?P<photo>[^/?.]+).*$
       - regex:
           source: request_url
           expression: ^/api/(?P<api_request>[^/?.]+).*$

တောင်းဆိုမှု_url ကိုခွဲခြမ်းစိတ်ဖြာပါ။ regexp ၏အကူအညီဖြင့်၊ ကျွန်ုပ်တို့သည် တောင်းဆိုချက်၏ရည်ရွယ်ချက်ကို ဆုံးဖြတ်သည်- statics၊ ဓာတ်ပုံများဆီသို့၊ API သို့ နှင့် ထုတ်ယူထားသောမြေပုံတွင် သက်ဆိုင်ရာသော့ကို သတ်မှတ်ပေးသည်။

       - template:
           source: request_type
           template: "{{if .photo}}photo{{else if .static_type}}static{{else if .api_request}}api{{else}}other{{end}}"

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

       - labels:
           api_request:
           virtual_host:
           request_type:
           status:

ကျွန်ုပ်တို့သည် ထုတ်ယူထားသောမြေပုံတွင် ထည့်သွင်းထားသောအရာအပေါ် အခြေခံ၍ api_request၊ virtual_host၊ request_type နှင့် အခြေအနေ (HTTP အခြေအနေ) ကို သတ်မှတ်ပါသည်။

       - output:
           source: nginx_log_row

အထွက်ကို ပြောင်းပါ။ ယခုအခါ ထုတ်ယူထားသော မြေပုံမှ သန့်စင်ထားသော nginx မှတ်တမ်းသည် Loki သို့ သွားပါသည်။

အထက်ဖော်ပြပါ config ကို run ပြီးနောက်၊ ဝင်ရောက်မှုတစ်ခုစီသည် log မှဒေတာအပေါ်အခြေခံ၍ အညွှန်းတပ်ထားသည်ကိုတွေ့မြင်နိုင်သည်။

တန်ဖိုးများစွာ (cardinality) ဖြင့် အညွှန်းများကို ထုတ်ယူခြင်းသည် Loki ကို သိသိသာသာ နှေးကွေးစေသည်ဟု မှတ်သားထားပါ။ ဆိုလိုသည်မှာ၊ ဥပမာ၊ user_id ကို အညွှန်းတွင် မထည့်သင့်ပါ။ ဆောင်းပါးတွင် ဤအကြောင်းပိုမိုဖတ်ပါ။Loki ရှိ အညွှန်းများသည် မှတ်တမ်းမေးမြန်းချက်များကို ပိုမိုမြန်ဆန်လွယ်ကူအောင် ပြုလုပ်နိုင်ပုံ” . သို့သော် ၎င်းသည် အညွှန်းများမပါဘဲ user_id ဖြင့် သင်ရှာဖွေနိုင်သည်ဟု မဆိုလိုပါ။ ရှာဖွေရာတွင် (ဒေတာအရ “ဖမ်း”) စစ်ထုတ်မှုများကို အသုံးပြုရန် လိုအပ်ပြီး ဤနေရာတွင် အညွှန်းကိန်းသည် stream identifier အဖြစ် လုပ်ဆောင်သည်။

မှတ်တမ်းပုံဖော်ခြင်း။

Loki သည် LogQL ကို အသုံးပြု၍ Grafana ဇယားများအတွက် ဒေတာရင်းမြစ်တစ်ခုအဖြစ် လုပ်ဆောင်နိုင်သည်။ အောက်ပါအင်္ဂါရပ်များကို ပံ့ပိုးထားသည်-

• နှုန်း - တစ်စက္ကန့်လျှင်မှတ်တမ်းအရေအတွက်;
• အချိန်နှင့်အမျှ ရေတွက်ခြင်း - ပေးထားသော အကွာအဝေးရှိ မှတ်တမ်းအရေအတွက်။

Sum၊ Avg နှင့် အခြားလုပ်ဆောင်ချက်များကို စုစည်းပေးပါသည်။ သင်သည် အတော်လေး ရှုပ်ထွေးသော ဂရပ်များကို ဖန်တီးနိုင်သည်၊ ဥပမာ၊ HTTP အမှားအယွင်း အရေအတွက်၏ ဂရပ်ဖစ်

Loki ၏ မူရင်းဒေတာရင်းမြစ်သည် Prometheus ၏ဒေတာရင်းမြစ်ထက် အနည်းငယ်လုပ်ဆောင်နိုင်စွမ်းနည်းပါးသည် (ဥပမာ၊ ဒဏ္ဍာရီကို သင်ပြောင်းလဲ၍မရပါ)၊ သို့သော် Loki သည် Prometheus အမျိုးအစားအရင်းအမြစ်အဖြစ် ချိတ်ဆက်နိုင်သည်။ ဒါက မှတ်တမ်းတင်ထားတဲ့ အပြုအမူ ဟုတ်မဟုတ်တော့ မသေချာပါဘူး၊ ဒါပေမယ့် developer တွေရဲ့ တုံ့ပြန်မှုကို ကြည့်ပြီး ဆုံးဖြတ်တာပါ"Loki ကို Prometheus ဒေတာအရင်းအမြစ်အဖြစ် ဘယ်လိုသတ်မှတ်မလဲ။ · စာစောင် #1222 · grafana/loki” ဥပမာအားဖြင့်၊ ၎င်းသည် လုံးဝတရားဝင်ဖြစ်ပြီး Loki သည် PromQL နှင့် အပြည့်အဝသဟဇာတဖြစ်သည်။

Prometheus အမျိုးအစားဖြင့် Loki ကို ဒေတာရင်းမြစ်အဖြစ် ထည့်သွင်းပြီး URL /loki ကို ထပ်ထည့်ပါ-

Prometheus မှ မက်ထရစ်များနှင့် အလုပ်လုပ်နေသကဲ့သို့ သင်သည် ဂရပ်များကို ဖန်တီးနိုင်သည်-

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

မက်ထရစ်များ

Loki သည် မှတ်တမ်းများမှ ကိန်းဂဏာန်းမက်ထရစ်များကို ထုတ်ယူပြီး Prometheus သို့ ပေးပို့နိုင်စေပါသည်။ ဥပမာအားဖြင့်၊ nginx မှတ်တမ်းတွင် တုံ့ပြန်မှုတစ်ခုလျှင် bytes အရေအတွက်ပါရှိပြီး၊ စံမှတ်တမ်းဖော်မတ်၏ အချို့သောမွမ်းမံမှုများနှင့်အတူ၊ တုံ့ပြန်ရန် အချိန်စက္ကန့်ပိုင်းအတွင်း ပါဝင်သည်။ ဤဒေတာကို ထုတ်ယူပြီး Prometheus သို့ ပေးပို့နိုင်ပါသည်။

promtail.yml တွင် အခြားအပိုင်းကို ထည့်ပါ-

- match:
   selector: '{request_type="api"}'
   stages:
     - metrics:
         http_nginx_response_time:
           type: Histogram
           description: "response time ms"
           source: response_time
           config:
             buckets: [0.010,0.050,0.100,0.200,0.500,1.0]
- match:
   selector: '{request_type=~"static|photo"}'
   stages:
     - metrics:
         http_nginx_response_bytes_sum:
           type: Counter
           description: "response bytes sum"
           source: bytes_out
           config:
             action: add
         http_nginx_response_bytes_count:
           type: Counter
           description: "response bytes count"
           source: bytes_out
           config:
             action: inc

ရွေးချယ်ခွင့်သည် ထုတ်ယူထားသောမြေပုံမှ အချက်အလက်များအပေါ် အခြေခံ၍ မက်ထရစ်များကို သတ်မှတ်ခြင်းနှင့် အပ်ဒိတ်လုပ်ရန် ခွင့်ပြုသည်။ ဤမက်ထရစ်များကို Loki သို့မပို့ပါ - ၎င်းတို့သည် Promtail /metrics အဆုံးမှတ်တွင် ပေါ်လာပါသည်။ ဤအဆင့်မှဒေတာကိုလက်ခံရရှိရန် Prometheus ကို configure လုပ်ရပါမည်။ အထက်ဖော်ပြပါ ဥပမာတွင်၊ request_type="api" အတွက် ကျွန်ုပ်တို့သည် histogram မက်ထရစ်ကို စုဆောင်းပါသည်။ ဤမက်ထရစ်အမျိုးအစားများဖြင့် ရာခိုင်နူန်းများကို ရရှိရန် အဆင်ပြေသည်။ တည်ငြိမ်မှုနှင့် ဓာတ်ပုံများအတွက်၊ ကျွန်ုပ်တို့သည် ပျမ်းမျှအားတွက်ချက်ရန် ဘိုက်များလက်ခံရရှိသည့် အတန်းအရေအတွက်နှင့် ဘိုက်များ၏ ပေါင်းလဒ်များကို စုဆောင်းပါသည်။

မက်ထရစ်များအကြောင်း ပိုမိုဖတ်ပါ။ ဒီမှာ.

Promtail တွင် ဆိပ်ကမ်းတစ်ခုဖွင့်ပါ-

promtail:
     image: grafana/promtail:1.4.1
     container_name: monitoring.promtail
     expose:
       - 9080
     ports:
       - "9080:9080"

promtail_custom prefix ပါရှိသော မက်ထရစ်များ ပေါ်လာကြောင်း သေချာစေပါသည်-

Prometheus ကို သတ်မှတ်ခြင်း။ အလုပ်အပေးအယူကို ထည့်ပါ-

- job_name: 'promtail'
 scrape_interval: 10s
 static_configs:
   - targets: ['promtail:9080']

ဂရပ်တစ်ခုဆွဲပါ၊

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

အတိုင်းအတာ

Loki သည် single binary mode နှင့် sharded (အလျားလိုက်-scalable mode) နှစ်မျိုးလုံးတွင်ရှိနိုင်သည်။ ဒုတိယကိစ္စတွင်၊ ၎င်းသည် ဒေတာများကို cloud တွင်သိမ်းဆည်းနိုင်ပြီး အပိုင်းများနှင့် အညွှန်းများကို သီးခြားသိမ်းဆည်းထားသည်။ ဗားရှင်း 1.5 တွင် တစ်နေရာတည်းတွင် သိမ်းဆည်းနိုင်မှုကို အကောင်အထည်ဖော်ထားသော်လည်း ၎င်းကို ထုတ်လုပ်ရာတွင် အသုံးပြုရန် အကြံပြုထားခြင်းမရှိသေးပေ။

အပိုင်းများကို S3-သဟဇာတရှိသော သိုလှောင်မှုတွင် သိမ်းဆည်းနိုင်သည်၊ အညွှန်းကိန်းများ သိမ်းဆည်းရန်အတွက်၊ အလျားလိုက် အတိုင်းအတာဖြင့် လုပ်နိုင်သော ဒေတာဘေ့စ်များ- Cassandra၊ BigTable သို့မဟုတ် DynamoDB ကို အသုံးပြုပါ။ Loki ၏အခြားအစိတ်အပိုင်းများ - ဖြန့်ဝေသူများ (စာရေးရန်အတွက်) နှင့် Querier (မေးမြန်းချက်များအတွက်) - နိုင်ငံမဲ့ဖြစ်ပြီး အလျားလိုက်အတိုင်း အတိုင်းအတာများဖြစ်သည်။

DevOpsDays Vancouver 2019 ကွန်ဖရင့်တွင် ပါဝင်သူ Callum Styan မှ Loki သည် ၎င်း၏ပရောဂျက်တွင် စုစုပေါင်းအရွယ်အစား၏ 1% ထက်နည်းသော အညွှန်းကိန်း petabytes ရှိကြောင်း ကြေငြာခဲ့သည်- "Loki သည် မက်ထရစ်များနှင့် မှတ်တမ်းများ ဆက်စပ်ပုံ — နှင့် သင့်ငွေကို သက်သာစေသည်။"။

Loki နှင့် ELK နှိုင်းယှဉ်

အညွှန်းအရွယ်အစား

ရလဒ်အညွှန်းအရွယ်အစားကို စမ်းသပ်ရန်၊ အထက် Pipeline ကို ပြင်ဆင်သတ်မှတ်ထားသည့် nginx ကွန်တိန်နာမှ မှတ်တမ်းများကို ကျွန်ုပ်ယူခဲ့သည်။ မှတ်တမ်းဖိုင်တွင် စုစုပေါင်းပမာဏ 406 MB ရှိသော စာကြောင်း 624 ပါရှိသည်။ မှတ်တမ်းများကို တစ်နာရီအတွင်း ထုတ်ပေးနိုင်ပြီး တစ်စက္ကန့်လျှင် စံချိန် ၁၀၀ ခန့်ရှိသည်။

မှတ်တမ်းမှ စာကြောင်းနှစ်ကြောင်း၏ ဥပမာတစ်ခု။

ELK ဖြင့် အညွှန်းရေးသောအခါ၊ ၎င်းသည် အညွှန်းအရွယ်အစား 30,3 MB ကိုပေးသည်-

Loki ကိစ္စတွင်၊ ၎င်းသည် အညွှန်းကိန်း 128 KB ခန့်နှင့် ဒေတာ 3,8 MB ခန့်ကို အပိုင်းလိုက်ပေးသည်။ မှတ်တမ်းသည် အတုအယောင် ဖန်တီးထားပြီး ဒေတာ အများအပြား မပါဝင်ကြောင်း သတိပြုသင့်သည်။ ဒေတာပါရှိသော မူရင်း Docker JSON မှတ်တမ်းရှိ ရိုးရှင်းသော gzip သည် 95,4% ကို ချုံ့ပေးကာ သန့်စင်ထားသော nginx မှတ်တမ်းကိုသာ Loki ကိုယ်တိုင်ထံသို့ ပေးပို့ထားသောကြောင့် ချုံ့မှုကို 4 MB အထိ နားလည်နိုင်ပါသည်။ Loki အညွှန်းများအတွက် တစ်မူထူးခြားသော တန်ဖိုးများ စုစုပေါင်း 35 ဖြစ်သည်၊ ၎င်းသည် အညွှန်း၏ သေးငယ်သော အရွယ်အစားကို ရှင်းပြသည်။ ELK အတွက်၊ မှတ်တမ်းကိုလည်း ရှင်းလင်းထားသည်။ ထို့ကြောင့် Loki သည် မူရင်းဒေတာကို 96% နှင့် ELK 70% ဖြင့် ချုံ့ခဲ့သည်။

မှတ်ဉာဏ်သုံးစွဲမှု

Prometheus နှင့် ELK အစုအဝေးတစ်ခုလုံးကို နှိုင်းယှဉ်ပါက Loki သည် အဆများစွာ "စားသည်" ဖြစ်သည်။ Go ဝန်ဆောင်မှုသည် Java ဝန်ဆောင်မှုထက်နည်းပြီး Heap Elasticsearch JVM ၏အရွယ်အစားနှင့် Loki အတွက် ခွဲဝေချထားပေးသည့်မှတ်ဉာဏ်ကို နှိုင်းယှဉ်ခြင်းသည် မှားယွင်းနေသော်လည်း Loki သည် မှတ်ဉာဏ်ပိုနည်းသည်ကို သတိပြုသင့်သည်။ သူ့ရဲ့ CPU အားသာချက်က သိပ်မသိသာပေမယ့်လည်း ရှိနေတယ်။

အရှိန်

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

မှတ်တမ်းရှာဖွေမှု

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

interface ကို

ပထမတော့ လှတယ် (တောင်းပန်ပါတယ်၊ သည်းမခံနိုင်ဘူး)။ Grafana သည် လှပသောအသွင်အပြင်ရှိသော်လည်း Kibana သည် ပို၍အလုပ်လုပ်သည်။

Loki ၏ အားသာချက်များနှင့် အားနည်းချက်များ

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

minuses များ၏ - စာရွက်စာတမ်းညံ့ဖျင်း။ Promtail ၏ အင်္ဂါရပ်များနှင့် လုပ်ဆောင်နိုင်စွမ်းများကဲ့သို့သော အချို့အရာများသည် ကုဒ်ကိုလေ့လာခြင်းလုပ်ငန်းစဉ်တွင်သာ ရှာဖွေတွေ့ရှိခဲ့ပြီး open-source ၏ အကျိုးကျေးဇူးများ။ နောက်ထပ်အားနည်းချက်ကတော့ ခွဲခြမ်းစိတ်ဖြာနိုင်မှု အားနည်းခြင်းပါပဲ။ ဥပမာအားဖြင့်၊ Loki သည် multiline မှတ်တမ်းများကို ခွဲခြမ်းစိတ်ဖြာ၍မရပါ။ ထို့အပြင်၊ အားနည်းချက်များတွင် Loki သည် ငယ်ရွယ်သောနည်းပညာဖြစ်သည် (ဖြန့်ချိရေး 1.0 သည် 2019 ခုနှစ် နိုဝင်ဘာလတွင်ဖြစ်သည်) ပါဝင်သည်။

ကောက်ချက်

Loki သည် မှတ်တမ်းပေါင်းစည်းခြင်း၊ မှတ်တမ်းရှာဖွေခြင်း၊ စောင့်ကြည့်ခြင်းနှင့် ခွဲခြမ်းစိတ်ဖြာခြင်းဆိုင်ရာ ပြဿနာများစွာကို ဖြေရှင်းနိုင်စေမည့် အသေးစားနှင့် အလတ်စားပရောဂျက်များအတွက် သင့်လျော်သည့် 100% စိတ်ဝင်စားဖွယ်နည်းပညာတစ်ခုဖြစ်သည်။

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

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

ဆောင်းပါးတွင် အသုံးပြုသည့် ကုဒ်ပါသော သိုလှောင်ခန်းသည် တည်ရှိပါသည်။ ဒီမှာ.

source: www.habr.com