Logs د سیسټم یوه مهمه برخه ده، تاسو ته اجازه درکوي چې پوه شئ چې دا کار کوي (یا کار نه کوي) لکه څنګه چې تمه کیږي. د مایکرو سرویس په جوړښت کې، د لاګونو سره کار کول د ځانګړي اولمپیاډ لپاره جلا ډسپلین کیږي. د پوښتنو یوه ډله باید په یو وخت کې حل شي:
- د غوښتنلیک څخه د لاګ لیکلو څرنګوالی؛
- چیرته لیکلو لپاره logs؛
- د ذخیره کولو او پروسس کولو لپاره د لاګونو رسولو څرنګوالی؛
- د لاګونو پروسس او ذخیره کولو څرنګوالی.
د اوسني مشهور کانټینر کولو ټیکنالوژیو کارول د ستونزې د حل لپاره د اختیارونو ساحې ته د ریک په سر کې شګه اضافه کوي.
دا هغه څه دي چې د یوري بوشمیلیف راپور "د لاګونو راټولولو او تحویلولو په برخه کې د ریکونو نقشه" په اړه دی.
د هر چا لپاره چې علاقه لري ، مهرباني وکړئ بلی وګورئ.
زما نوم یوري بوشمیلیف دی. زه په Lazada کې کار کوم نن به زه د دې په اړه وغږیږم چې څنګه موږ خپل لاګونه جوړ کړل، څنګه مو راټول کړل، او موږ هلته څه لیکو.
موږ د کوم ځای څخه یو؟ موږ څوک یو؟ Lazada په سویل ختیځ آسیا کې په شپږو هیوادونو کې لومړی نمبر آنلاین پرچون پلورونکی دی. دا ټول هیوادونه زموږ د معلوماتو مرکزونو کې ویشل شوي. اوس مهال په ټولیز ډول 1 د معلوماتو مرکزونه شتون لري ولې دا مهم دی؟ ځکه ځینې پرېکړې د دې لامل شوې چې د مرکزونو تر منځ ډېر کمزوری اړیکی شته. موږ د مایکرو سرویس جوړښت لرو. زه حیران وم چې وموندلم چې موږ دمخه 4 مایکرو خدمتونه لرو. کله چې ما د لاګونو سره کار پیل کړ، یوازې 80 یې شتون درلود، سربیره پردې د PHP میراث یوه لویه برخه ده، چې زه یې هم باید ورسره ژوند وکړم او ورسره یې وساتم. دا ټول اوس مهال په ټولیز ډول د سیسټم لپاره په یوه دقیقه کې له 20 ملیون څخه ډیر پیغامونه رامینځته کوي. بیا به زه وښیم چې موږ څنګه د دې سره ژوند کولو هڅه کوو، او ولې دا داسې ده.
تاسو باید یو څه د دې 6 ملیون پیغامونو سره ژوند وکړئ. موږ باید له دوی سره څه وکړو؟ 6 ملیون پیغامونه چې تاسو ورته اړتیا لرئ:
- له اپلیکیشن څخه لیږل
- د تحویل لپاره قبول کړئ
- د تحلیل او ذخیره کولو لپاره وړاندې کول.
- تحلیل کول
- په یو ډول یې ذخیره کړئ.
کله چې درې ملیونه پیغامونه راڅرګند شول، ما ورته وکتل. ځکه چې موږ یوازې د څو پیسو سره پیل کړی. دا روښانه ده چې د غوښتنلیک لاګونه هلته لیکل شوي. د مثال په توګه، زه نشم کولی د ډیټابیس سره وصل شم، زه توانیدلی وم چې ډیټابیس سره وصل کړم مګر ما هیڅ شی نشم لوستلی. مګر د دې سربیره، زموږ هر مایکرو خدمتونه د لاسرسي لاګ هم لیکي. هره غوښتنه چې مایکرو سرویس ته راځي په لاګ کې ثبت کیږي. موږ ولې دا کار کوو؟ پراختیا کونکي غواړي د تعقیب وړ وي. د لاسرسي هر لاګ د ټریسایډ ساحه لري چې په کارولو سره یې یو ځانګړی انٹرفیس بیا ټوله زنځیر خلاصوي او په ښکلي ډول ټریس ښیې. ټریس ښیې چې غوښتنه څنګه پرمخ لاړه، او دا زموږ پراختیا کونکو سره مرسته کوي چې ژر تر ژره د هر ډول ناپیژندل شوي کثافاتو سره معامله وکړي.
له دې سره څنګه ژوند وکړو؟ اوس زه به په لنډه توګه د اختیارونو ساحه تشریح کړم - دا ستونزه عموما څنګه حل کیږي. د لوګو راټولولو، لیږدولو او ذخیره کولو ستونزه څنګه حل کړئ.
د غوښتنلیک څخه څنګه لیکل؟ دا روښانه ده چې مختلفې لارې شتون لري. په ځانګړې توګه، غوره تمرین دی، لکه څنګه چې زموږ فیشن ملګري موږ ته وایي. دوه ډوله زاړه ښوونځي شتون لري، لکه څنګه چې زموږ نیکونو موږ ته وویل. نورې لارې هم شته.
د لوګو راټولولو وضعیت نږدې ورته دی. د دې ځانګړې برخې حل کولو لپاره ډیری اختیارونه شتون نلري. د دوی څخه لا دمخه شتون لري، مګر لاهم ډیر ندي.
مګر د سپارلو او وروسته تحلیل سره، د بدلونونو شمیر د چاودلو پیل کوي. زه به اوس هر اختیار تشریح نه کړم. زه فکر کوم چې اصلي اختیارونه هر چا ته ښه پیژندل شوي څوک چې موضوع سره علاقه لري.
زه به تاسو ته وښیم چې موږ دا په لازاډا کې څنګه ترسره کړل، او دا ټول څنګه پیل شول.
یو کال دمخه زه لازاده ته راغلم او د لوګو په اړه یوې پروژې ته واستول شوم. دا یو څه داسې وو. د غوښتنلیک لاګ stdout او stderr ته لیکل شوی و. هر څه په فیشني ډول ترسره شول. مګر بیا پراختیا کونکو دا د معیاري جریان څخه بهر وغورځاوه ، او بیا به په یو ډول د زیربنا متخصصین دا په ګوته کړي. د زیربنا متخصصینو او پراختیا کونکو ترمینځ ، داسې خوشې کونکي هم شتون لري چې ویلي یې دي: "هو ... سمه ده ، راځئ چې دوی یوازې د شیل سره په فایل کې لپاسه کړو ، او بس." او څرنګه چې دا ټول په یوه کانټینر کې وو، دوی دا پخپله په کانټینر کې وتړل، د کتلاګ دننه یې نقشه کړه او هلته یې واچوله. زما په اند دا د هرچا لپاره خورا څرګند دی چې له دې څخه څه راغلي.
راځئ چې د اوس لپاره لږ نور وګورو. موږ څنګه دا لاګونه وړاندې کړل؟ یو چا td-اجنټ غوره کړی، کوم چې په حقیقت کې روان دی، مګر په بشپړ ډول روان نه دی. زه لاهم د دې دوه پروژو ترمینځ اړیکې نه پوهیږم ، مګر داسې بریښي چې د ورته شی په اړه وي. او دا روانی ، په روبي کې لیکل شوی ، د لاګ فایلونه لوستل ، د یو ډول منظمیت په کارولو سره یې JSON کې تجزیه کړل. بیا ما دوی کافکا ته ولیږل. سربیره پردې، په کافکا کې موږ د هر API لپاره 4 جلا موضوعات درلودل. ولې 4؟ ځکه چې دلته ژوند شتون لري، سټینګ شتون لري، او ځکه چې دلته stdout او stderr شتون لري. پراختیا کونکي یې رامینځته کوي، او د زیربنا پراختیا کونکي باید دوی په کافکا کې رامینځته کړي. برسېره پر دې، کافکا د بلې څانګې لخوا کنټرول کېده. له همدې امله، دا اړینه وه چې یو ټکټ جوړ کړي ترڅو دوی د هرې api لپاره 4 موضوعات جوړ کړي. هرڅوک یې په اړه هیر کړل. په عمومي توګه، کثافات او ګډوډي وه.
له دې وروسته مو څه وکړل؟ موږ دا کافکا ته ولېږه. بیا د کافکا نیمایي لوګو لوګسټاش ته الوتنه وکړه. د لوګو بله نیمه برخه ویشل شوې وه. ځینې یې یو ګریلوګ ته الوتل، ځینې یې بل ګریلوګ ته. د پایلې په توګه، دا ټول یو د Elasticsearch کلستر ته لاړ. یعني دا ټول ګډوډي هلته پای ته ورسیده. داسې مه کوه!
دا هغه څه دي لکه څنګه چې تاسو یې له پورته څخه وګورئ. داسې مه کوه! دلته د ستونزې ساحې سمدلاسه د شمیرو سره په نښه شوي. په حقیقت کې ډیری یې شتون لري، مګر 6 واقعیا ستونزمن دي چې باید په اړه یې یو څه ترسره شي. زه به تاسو ته اوس په جلا توګه ووایم.
دلته (1,2,3) موږ فایلونه لیکو او په وینا یې دلته په یو وخت کې درې ریکونه شتون لري.
لومړی (1) دا دی چې موږ باید دوی یو ځای ولیکو. دا به تل د پام وړ نه وي چې API ته دا وړتیا ورکړي چې مستقیم فایل ته ولیکي. دا د پام وړ ده چې API په کانټینر کې جلا شي، یا حتی غوره، دا یوازې د لوستلو وړ وي. زه د سیسټم مدیر یم، نو زه د دې شیانو یو څه بدیل لید لرم.
دوهم ټکی (2,3) دا دی چې موږ ډیری غوښتنې لرو چې API ته راځي. API یو فایل ته ډیری معلومات لیکي. فایلونه وده کوي. موږ باید دوی وګرځوو. ځکه چې که نه نو تاسو به نشئ کولی هلته په کوم ډیسکونو کې ذخیره کړئ. د دوی ګرځول بد دي ځکه چې دوی د شیل له لارې لارښود ته د ریډائریکټ کولو سره رامینځته شوي. هیڅ لاره نشته چې موږ یې بیاکتنه وکړو. تاسو نشئ کولی غوښتنلیک ته ووایاست چې لاسونه بیا پرانیزي. ځکه چې پراختیا کونکي به تاسو ته داسې وګوري چې تاسو احمق یاست: "کوم تشریح کونکي؟ موږ عموما stdout ته لیکو." د زیربنا پراختیا کونکو د لوګروټیټ لپاره کاپيټرونکیټ رامینځته کړی ، کوم چې په ساده ډول د فایل کاپي کوي او اصلي نقل کوي. په دې اساس، د دې کاپي کولو پروسو ترمنځ د ډیسک ځای معمولا پای ته رسیږي.
(4) موږ په مختلفو APIs کې مختلف شکلونه درلودل. دوی یو څه توپیر درلود، مګر regexp باید په بل ډول ولیکل شي. څرنګه چې دا ټول د ګوډاګي لخوا کنټرول شوي، د ټولګیو یوه لویه ډله د دوی د کاکروچونو سره وه. برسېره پردې، ډیری وختونه د TD-Agent کولی شي حافظه وخوري، احمق وي، دا یوازې داسې ښکاریده چې دا کار کوي او هیڅ کار نه کوي. له بهر څخه دا ناشونې وه چې پوه شي چې هغه هیڅ نه کوي. په غوره توګه، هغه به ښکته شي او یو څوک به یې وروسته پورته کړي. په دقیق ډول، یو خبرتیا به راشي، او یو څوک به لاړ شي او د خپلو لاسونو سره به پورته کړي.
(۶) او تر ټولو کثافات او ضایعات elastic search و. ځکه چې دا پخوانۍ نسخه وه. ځکه چې په هغه وخت کې موږ وقف ماسټران نه درلودل. موږ متضاد لاګونه درلودل چې ساحې یې په ټپه ولاړې وې. د مختلف غوښتنلیکونو مختلف لاګونه د ورته ساحې نومونو سره لیکل کیدی شي ، مګر دننه مختلف معلومات کیدی شي. دا دی، یو لاګ په ساحه کې د انټیجر سره راځي، د بیلګې په توګه، کچه. بل لاګ د لیول په ساحه کې د سټینګ سره راځي. د جامد نقشې په نشتوالي کې، دا دومره په زړه پورې شی دی. که په elasticsearch کې د شاخص له ګرځولو وروسته، د تار سره یو پیغام لومړی راشي، بیا موږ په نورمال ډول ژوند کوو. مګر که لومړی له انټیجر څخه راشي، نو ټول راتلونکی پیغامونه چې د سټینګ څخه راغلي په ساده ډول رد شوي. ځکه چې د ساحې ډول سره سمون نه لري.
موږ دا پوښتنې پیل کړې. موږ پریکړه وکړه چې د تورونو په لټه کې نه یو.
خو یو څه باید وشي! ښکاره خبره دا ده چې موږ باید معیارونه جوړ کړو. موږ لا دمخه ځینې معیارونه درلودل. موږ یو څه وروسته پیل کړ. خوشبختانه، د ټولو APIs لپاره یو واحد لاګ بڼه لا دمخه په هغه وخت کې تصویب شوې وه. دا په مستقیم ډول د خدماتو ترمنځ د تعامل لپاره معیارونو کې لیکل شوی. په دې اساس، هغه کسان چې غواړي لاګونه ترلاسه کړي باید په دې بڼه یې ولیکي. که څوک په دې بڼه لاګونه نه لیکي، نو موږ هیڅ تضمین نه کوو.
بیا ، زه غواړم د ثبت کولو ، تحویلولو او راټولولو میتودونو لپاره یو متحد معیار رامینځته کړم. په حقیقت کې، دوی چیرته ولیکئ، او څنګه یې وړاندې کړئ. مثالی حالت هغه وخت دی کله چې پروژې ورته کتابتون کاروي. د Go لپاره جلا جلا کتابتون شتون لري، او د PHP لپاره جلا کتابتون. هرڅوک چې موږ یې لرو باید وکاروو. په اوس وخت کې، زه به ووایم چې موږ په دې کې 80 سلنه بریالي یو. مګر ځینې خلک د کیکټي خوړلو ته دوام ورکوي.
او هلته (په سلایډ کې) "د لاګونو تحویلولو لپاره SLA" په سختۍ سره څرګندیدل پیل کوي. دا لاهم شتون نلري، مګر موږ په دې کار کوو. ځکه چې دا خورا اسانه ده کله چې زیربنا ووایی چې که تاسو داسې او داسې یو ځای ته په داسې شکل کې ولیکئ او په هره ثانیه کې د N پیغامونو څخه ډیر نه وي، نو موږ به ډیر احتمال دا داسې ځای ته ورسوو. دا د سر درد ډیر آرام کوي. که چیرې یو SLA شتون ولري، نو دا خورا ښه دی!
موږ څنګه د ستونزې د حل لپاره پیل وکړ؟ اصلي ستونزه د td-agent سره وه. دا څرګنده نه وه چې زموږ ټاګونه چیرته لاړل. ایا دوی سپارل کیږي؟ ایا دوی ځي؟ په هرصورت دوی چیرته دي؟ له همدې امله، لومړی ټکی پریکړه وشوه چې د td-agent ځای ونیسي. ما په لنډ ډول د دې لپاره اختیارونه په ګوته کړل چې دلته یې د څه شی سره بدل کړئ.
روانی. لومړی، زه له هغه سره په پخوانۍ دنده کې مخامخ شوم، او هغه هم وخت په وخت هلته راوتلی و. دوهم، دا ورته شی دی، یوازې په پروفایل کې.
فایل بیټ. دا زموږ لپاره څومره اسانه وه؟ ځکه چې دا په Go کې دی، او موږ په Go کې ډیر مهارت لرو. په دې اساس، که څه هم پیښ شي، موږ کولی شو یو څه د ځان لپاره اضافه کړو. له همدې امله موږ نه شو اخیستی. نو د دې لپاره چې د ځان لپاره یې د بیا لیکلو پیل کولو لپاره هیڅ لالچ هم شتون ونلري.
د سیسټم مدیر لپاره ښکاره حل په دې مقدار کې هر ډول syslogs دي (syslog-ng/rsyslog/nxlog).
یا خپل یو څه ولیکئ، مګر موږ دا رد کړه، او همدارنګه د فایل بیټ. که تاسو یو څه لیکئ، نو دا غوره ده چې د سوداګرۍ لپاره ګټور څه ولیکئ. د لاګونو رسولو لپاره، دا غوره ده چې یو څه چمتو کړئ.
له همدې امله، انتخاب په حقیقت کې د syslog-ng او rsyslog ترمنځ انتخاب ته راغلی. ما په ساده ډول د rsyslog په لور تکیه وکړه ځکه چې موږ دمخه په Puppet کې د rsyslog لپاره ټولګي درلودل، او ما د دوی ترمنځ ښکاره توپیر ونه موند. syslog څه شی دی، syslog څه شی دی. هو، ځینې یې خراب اسناد لري، ځینې یې ښه دي. دا یو کولی شي دا په دې ډول ترسره کړي، او بل یې کولی شي په بل ډول ترسره کړي.
او د rsyslog په اړه لږ څه. لومړی، دا ښه دی ځکه چې دا ډیری ماډلونه لري. دا د انسان د لوستلو وړ RainerScript (د عصري ترتیب ژبه) لري. دا یو په زړه پوری بونس دی چې موږ کولی شو د معیاري وسیلو په کارولو سره د TD-Agent چلند تقلید کړو ، او د غوښتنلیکونو لپاره هیڅ شی نه دی بدل شوی. دا دی، موږ td-agent په rsyslog بدلوو، او نور هرڅه د اوس لپاره یوازې پریږدو. او موږ سمدلاسه کاري تحویل ترلاسه کوو. بل، mmnormalize په rsyslog کې یو په زړه پوری شی دی. دا تاسو ته اجازه درکوي چې لاګونه پارس کړئ، مګر د Grok او regexp سره نه. دا یو خلاص نحوي ونه جوړوي. دا لاګونه په ورته ډول تجزیه کوي لکه څنګه چې تالیف کونکي سرچینې تحلیلوي. دا تاسو ته اجازه درکوي خورا ګړندي کار وکړئ ، لږ CPU مصرف کړئ ، او په عموم کې ، دا واقعیا ښه شی دی. د نورو بونسونو یوه ډله شتون لري. زه به په دوی کې پاتې نه شم.
rsyslog ډیری نور زیانونه لري. دوی د بونس په څیر دي. اصلي ستونزې دا دي چې تاسو اړتیا لرئ پوه شئ چې دا څنګه پخلی کړئ، او تاسو اړتیا لرئ چې نسخه غوره کړئ.
موږ پریکړه وکړه چې موږ به د یونیکس ساکټ ته لاګونه ولیکئ. او په /dev/log کې نه، ځکه چې هلته موږ د سیسټم لاګونو ګډوډۍ لرو، ژورنال په دې پایپ لاین کې دی. نو راځئ چې دودیز ساکټ ته ولیکو. موږ به دا د جلا قواعدو سره ضمیمه کړو. راځئ چې په هیڅ شی کې مداخله ونه کړو. هر څه به شفاف او د پوهیدو وړ وي. دا هغه څه دي چې موږ یې وکړل. د دې ساکټونو سره لارښود معیاري شوی او ټولو کانټینرونو ته لیږل شوی. کانټینرونه کولی شي هغه ساکټ وګوري چې دوی ورته اړتیا لري، پرانیزئ او ولیکئ.
ولې فایل نه دی؟ ځکه چې هرڅوک یې لوستل ، کوم چې د ډاکر ته د فایل لیږلو هڅه وکړه ، او دا وموندل شوه چې د rsyslog بیا پیل کولو وروسته ، د فایل ډیسکریټر بدل شو ، او ډاکر دا فایل له لاسه ورکړ. دا بل څه خلاص ساتي، مګر ساکټ نه چیرې چې دوی لیکي. موږ پریکړه وکړه چې موږ به د دې ستونزې په شاوخوا کې کار وکړو، او په ورته وخت کې، موږ به د بلاک کولو ستونزې په شاوخوا کې کار وکړو.
Rsyslog هغه کړنې ترسره کوي چې په سلایډ کې ښودل شوي او یا هم ریلي یا کافکا ته لاګونه لیږي. کافکا پخوانۍ لاره تعقیبوي. ریل - ما هڅه وکړه چې د لاګ رسولو لپاره خالص rsyslog وکاروم. د پیغام کتار پرته، د معیاري rsyslog وسیلو په کارولو سره. په اصل کې، دا کار کوي.
مګر پدې برخه کې د دوی د هڅولو څرنګوالي په اړه لنډیز شتون لري (Logstash/Graylog/ES). دا برخه (rsyslog-rsyslog) د معلوماتو مرکزونو ترمنځ کارول کیږي. دلته یو کمپریس شوی tcp لینک دی، کوم چې موږ ته اجازه راکوي چې بینډ ویت خوندي کړو او په وینا یې، یو څه احتمال زیاتوي چې موږ به د بل ډیټا مرکز څخه ځینې لاګونه ترلاسه کړو کله چې چینل بند شي. ځکه چې موږ اندونیزیا لرو، چیرې چې هرڅه خراب دي. دا هغه ځای دی چې دوامداره ستونزه شتون لري.
موږ د دې په اړه فکر وکړ چې څنګه موږ واقعیا څارنه کولی شو څومره احتمال شتون لري چې هغه لاګونه چې موږ د غوښتنلیک څخه ثبت کړي پای ته ورسیږي؟ موږ پریکړه وکړه چې میټریک جوړ کړو. rsyslog خپل د احصایې راټولولو ماډل لري، کوم چې یو ډول شمیرونکي لري. د مثال په توګه، دا کولی شي تاسو ته د کتار اندازه وښيي، یا په داسې او داسې عمل کې څومره پیغامونه راغلي دي. تاسو کولی شئ دمخه له دوی څخه یو څه واخلئ. سربیره پردې ، دا دودیز کاونټرونه لري چې تنظیم کیدی شي ، او دا به تاسو ته وښیې ، د مثال په توګه ، د پیغامونو شمیر چې ځینې API ثبت کړي. بیا، ما په Python کې rsyslog_exporter ولیکه، او موږ دا ټول پرومیتیوس ته واستول او ګرافونه مو جوړ کړل. موږ واقعیا د ګریلوګ میټریکونه غوښتل ، مګر موږ لاهم د دوی تنظیم کولو لپاره وخت نه لرو.
ستونزې څه وې؟ ستونزې رامینځته شوې کله چې موږ وموندل (ناڅاپه!) چې زموږ ژوندی APIs په هره ثانیه کې 50k پیغامونه لیکي. دا یوازې یو ژوندی API دی پرته له سټیج کولو. او ګریلوګ موږ ته په هره ثانیه کې یوازې 12 زره پیغامونه ښیې. او یو معقول پوښتنه راپورته شوه: پاتې شوني چیرته دي؟ له کوم څخه موږ دې پایلې ته ورسیدو چې ګریلوګ په ساده ډول نشي کولی مقابله وکړي. موږ ولیدل، او، په حقیقت کې، ګریلوګ او ایلیسټیکسرچ نشي کولی دا جریان اداره کړي.
بیا، نور کشفونه چې موږ یې په لاره کې ترسره کړل.
ساکټ ته لیکونه بند شوي دي. دا څنګه وشول؟ کله چې زه د تحویل لپاره rsyslog کاروم ، په یو وخت کې د ډیټا مرکزونو ترمینځ چینل مات شو. تحویل په یو ځای کې ودرول شو ، تحویل په بل ځای کې ودرول شو. دا ټول د APIs سره ماشین ته رسیدلي چې د rsyslog ساکټ ته لیکي. هلته کتار ولاړ وو. بیا د یونیکس ساکټ ته د لیکلو کتار، کوم چې په ډیفالټ ډول 128 پاکټونه ډک شوي. او په اپلیکیشن کې بل لیک () بلاک شوی دی. کله چې موږ کتابتون ته وګورو چې موږ یې په Go غوښتنلیکونو کې کاروو، لیکل شوي چې ساکټ ته لیکل په غیر بلاک کولو حالت کې واقع کیږي. موږ ډاډه یو چې هیڅ شی بند نه دی. ځکه چې موږ لوستل چا په دې اړه لیکلي. مګر یوه شیبه شتون لري. د دې زنګ شاوخوا یو لامحدود لوپ هم و ، په کوم کې چې د ساکټ ته د پیغام اړولو دوامداره هڅه وه. موږ هغه ته پام نه کړ. ما باید کتابتون بیا ولیکل. له هغه وخت راهیسې دا څو ځله بدل شوی، مګر اوس موږ په ټولو فرعي سیسټمونو کې د بلاک کولو څخه خلاص شوي یو. له همدې امله، تاسو کولی شئ rsyslog ودروئ، او هیڅ شی به خراب نشي.
دا اړینه ده چې د قطارونو اندازه وڅیړئ، کوم چې په دې ریک کې د ګامونو څخه مخنیوي کې مرسته کوي. لومړی، موږ کولی شو څارنه وکړو کله چې موږ د پیغامونو له لاسه ورکولو پیل کوو. دوهم، موږ کولی شو څارنه وکړو چې موږ د سپارلو سره ستونزې لرو.
او یو بل ناخوښه شیبه - د مایکرو سرویس جوړښت کې 10 ځله پراخول خورا اسانه دي. موږ ډیری راتلوونکي غوښتنې نلرو، مګر د ګراف له امله چې دا پیغامونه نور هم سفر کوي، د لاسرسي لاګونو له امله، موږ واقعیا د لاګ بار شاوخوا لس ځله زیاتوو. له بده مرغه، ما د دقیقو شمیرو محاسبه کولو لپاره وخت نه درلود، مګر مایکرو خدمتونه هغه څه دي چې دوی دي. دا باید په ذهن کې وساتل شي. دا معلومه شوه چې دا مهال د لاګ راټولولو فرعي سیسټم په لازاډا کې ترټولو ډیر بار شوی.
د elasticsearch ستونزه څنګه حل کړو؟ که تاسو اړتیا لرئ ژر تر ژره لاګونه په یو ځای کې ترلاسه کړئ، نو د دې لپاره چې د ټولو ماشینونو شاوخوا وګرځئ او هلته یې راټول کړئ، د فایل ذخیره وکاروئ. دا د کار کولو تضمین دی. دا د هر سرور څخه ترسره کیدی شي. تاسو یوازې اړتیا لرئ هلته ډیسکونه وساتئ او سیسلاګ نصب کړئ. له دې وروسته، تاسو تضمین یاست چې ټول لاګونه په یو ځای کې ولرئ. بیا تاسو کولی شئ ورو ورو elasticsearch، graylog، او بل څه تنظیم کړئ. مګر تاسو به لا دمخه ټول لاګونه ولرئ ، او سربیره پردې ، تاسو کولی شئ دوی تر هغه ځایه ذخیره کړئ چې د ډیسک کافي صفونه شتون ولري.
زما د راپور په وخت کې، سکیم د دې په څیر پیل شو. موږ په عملي ډول فایل ته لیکل بند کړل. اوس، ډیری احتمال، موږ به پاتې نور بند کړو. په محلي ماشینونو کې چې API چلوي، موږ به فایلونو ته لیکل بند کړو. لومړی، د فایل ذخیره شتون لري، کوم چې خورا ښه کار کوي. دوهم، دا ماشینونه په دوامداره توګه د ځای څخه تیریږي؛ دا باید په دوامداره توګه وڅیړل شي.
دا برخه د Logstash او Graylog سره، دا واقعیا لرې کوي. له همدې امله، موږ باید له دې څخه ځان خلاص کړو. تاسو باید یو شی غوره کړئ.
موږ پریکړه وکړه چې Logstash او Kibana وباسو. ځکه چې موږ امنیتي څانګه لرو. کومه اړیکه؟ اړیکه دا ده چې کیبانا پرته له ایکس پیک او پرته شیلډ تاسو ته اجازه نه ورکوي چې لاګونو ته د لاسرسي حقونه توپیر کړئ. له همدې امله موږ ګریلوګ واخیست. دا ټول لري. زه دا نه خوښوم، مګر دا کار کوي. موږ نوی هارډویر اخیستی، تازه ګریلوګ مو هلته نصب کړ او ټول لاګونه مو د سختو بڼو سره جلا ګریلوګ ته انتقال کړل. موږ ستونزه په تنظیمي ډول د ورته ورته ساحو مختلف ډولونو سره حل کړه.
په نوي ګریلوګ کې واقعیا څه شامل دي. موږ یوازې په ډاکر کې هرڅه لیکلي. موږ د سرورونو یوه ډله واخیسته، د کافکا درې مثالونه مو راوبلل، د 7 ګریلوګ سرورونو نسخه 2.3 (ځکه چې موږ د Elasticsearch 5 نسخه غوښتل). دا ټول د HDD څخه د عملیاتو په جریان کې نیول شوي. موږ په هره ثانیه کې تر 100 زره پیغامونو پورې د شاخص کولو کچه ولیدله. موږ دا ارقام ولیدل چې په هره اونۍ کې 140 ټیرابایټ ډیټا.
او بیا ریک! موږ دوه پلورونکي لرو. موږ د 6 ملیون پیغامونو څخه هاخوا حرکت وکړ. ګریلوګ د ژاولو لپاره وخت نلري. یو څه موږ باید بیا ژوندي پاتې شو.
په دې توګه موږ ژوندي پاتې شو. موږ یو څو نور سرورونه او SSDs اضافه کړل. دا مهال موږ په دې ډول ژوند کوو. اوس موږ لا دمخه په هره ثانیه کې 160k پیغامونه ژاړو. موږ تر اوسه حد ته نه یو رسیدلي، نو دا روښانه نده چې موږ واقعیا څومره له دې څخه وتلی شو.
دا د راتلونکي لپاره زموږ پلانونه دي. له دې څخه، ترټولو مهم شاید لوړ شتون وي. موږ تر اوسه دا نه لرو. څو موټرونه په ورته ډول ترتیب شوي، مګر تر اوسه هر څه د یو موټر له لارې تیریږي. د دوی تر مینځ د ناکامۍ تنظیم کول وخت نیسي.
له ګریلوګ څخه میټریکونه راټول کړئ.
د نرخ حد جوړ کړئ ترڅو موږ یو لیونی API ولرو چې زموږ بینډ ویت او نور هرڅه نه وژني.
او په نهایت کې ، د پراختیا کونکو سره یو ډول SLA لاسلیک کړئ ترڅو موږ وکولی شو دا ډیر خدمت وکړو. که نور څه لیکم نو بخښنه غواړم.
او اسناد ولیکئ.
په لنډه توګه، د هرڅه پایلې چې موږ یې تجربه کړې. لومړی، معیارونه. دوهم، سیسلګ کیک دی. دریم، rsyslog په سمه توګه کار کوي لکه څنګه چې په سلایډ کې لیکل شوی. او راځئ چې پوښتنو ته لاړ شو.
پوښتنې.
پوښتنه: ولې مو د نه اخیستلو پریکړه وکړه ... (فایل بیټ؟)
ځواب: موږ اړتیا لرو چې فایل ته ولیکئ. ما واقعیا نه غوښتل. کله چې ستاسو API په هره ثانیه کې زرګونه پیغامونه لیکي، حتی که تاسو دا په یو ساعت کې یو ځل وګرځوئ، دا لاهم یو اختیار ندی. تاسو کولی شئ په پایپ کې ولیکئ. کوم ته چې پراختیا کونکو له ما څخه وپوښتل: "څه به پیښ شي که چیرې هغه پروسه چې موږ یې د حادثې لپاره لیکو؟" ما یوازې ونه موندل چې دوی ته څه ځواب ورکړم، او ویې ویل: "ښه، سمه ده، راځئ چې دا کار ونه کړو."
پوښتنه: تاسو ولې یوازې HDFS ته لاګ نه لیکئ؟
ځواب: دا بله مرحله ده. موږ په پیل کې د دې په اړه فکر کاوه، مګر دا مهال د دې کولو لپاره سرچینې شتون نلري، دا زموږ په اوږدمهاله حل کې ځړول کیږي.
پوښتنه: د کالم بڼه به ډیر مناسب وي.
ځواب: زه پوهیږم. موږ د دواړو لاسونو سره د هغې لپاره یو.
پوښتنه: تاسو rsyslog ته لیکئ. هلته تاسو کولی شئ دواړه TCP او UDP وکاروئ. مګر که UDP، نو تاسو څنګه د سپارلو تضمین کوئ؟
ځواب: دوه ټکي دي. لومړی، زه سمدلاسه ټولو ته وایم چې موږ د لاګونو تحویلي تضمین نه کوو. ځکه چې کله پراختیا کونکي راشي او ووایی: "راځئ هلته د مالي معلوماتو لیکل پیل کړئ ، او تاسو به یې زموږ لپاره یو ځای کېږدئ که چیرې یو څه پیښ شي ،" موږ دوی ته ځواب ورکوو ، "ښه! راځئ چې ساکټ ته د لیکلو بندول پیل کړو، او دا په معاملو کې ترسره کړئ، ترڅو تاسو تضمین یاست چې دا زموږ لپاره ساکټ کې واچوئ او ډاډ ترلاسه کړئ چې موږ یې له بلې خوا ترلاسه کوو. او په دې وخت کې، هرڅوک سمدستي نور ورته اړتیا نلري. که دا ضروري نه وي، نو موږ باید کومې پوښتنې وکړو؟ که تاسو نه غواړئ چې ساکټ ته د لیکلو تضمین وکړئ، نو موږ ولې د سپارلو تضمین ته اړتیا لرو؟ موږ خپله پوره هڅه کوو. موږ واقعیا هڅه کوو د امکان تر حده او په غوره ډول وړاندې کړو ، مګر موږ 100٪ تضمین نه ورکوو. له همدې امله، دلته د مالي معلوماتو لیکلو ته اړتیا نشته. د دې لپاره د معاملو سره ډیټابیسونه شتون لري.
پوښتنه: کله چې API په لاګ کې یو څه پیغام رامینځته کوي او مایکرو خدماتو ته کنټرول لیږدوي ، ایا تاسو له دې ستونزې سره مخ شوي یاست چې د مختلف مایکرو خدماتو څخه پیغامونه په غلط ترتیب کې راځي؟ دا د ګډوډۍ لامل کیږي.
ځواب: دا عادي خبره ده چې دوی په مختلف ترتیبونو کې راځي. تاسو اړتیا لرئ د دې لپاره چمتو اوسئ. ځکه چې د هرې شبکې تحویل امر نه تضمینوي، یا تاسو باید پدې اړه ځانګړي سرچینې مصرف کړئ. که موږ د فایل ذخیره واخلو، نو هر API خپل فایل ته لاګونه خوندي کوي. یا بلکه، هلته rsyslog دوی په لارښودونو کې ترتیبوي. هر API خپل لاګونه لري، چیرې چې تاسو لاړ شئ او وګورئ، او بیا تاسو کولی شئ په دې لاګ کې د مهال ویش په کارولو سره پرتله کړئ. که دوی په ګریلوګ کې وګوري ، نو دوی هلته د مهال ویش لخوا ترتیب شوي. هلته به هر څه سم وي.
پوښتنه: د مهال ویش کیدای شي په ملی ثانیو کې توپیر ولري.
ځواب: د وخت سټمپ پخپله د API لخوا رامینځته شوی. دا په حقیقت کې، ټول ټکی دی. موږ NTP لرو. API پخپله پیغام کې یو مهال ویش رامینځته کوي. rsyslog دا نه اضافه کوي.
پوښتنه: د معلوماتو د مرکزونو تر منځ تعامل ډېر روښانه نه دی. د معلوماتو په مرکز کې، دا روښانه ده چې لاګونه څنګه راټول شوي او پروسس شوي. د معلوماتو د مرکزونو ترمنځ تعامل څنګه ترسره کیږي؟ یا د معلوماتو هر مرکز خپل ژوند ژوند کوي؟
ځواب: تقریبا. زموږ په هیواد کې، هر هیواد په یو ډیټا مرکز کې موقعیت لري. دا مهال ، موږ دومره خپرونه نلرو چې یو هیواد په مختلف ډیټا مرکزونو کې موقعیت لري. له همدې امله، د دوی سره یوځای کولو ته اړتیا نشته. هر مرکز دننه د ننوتلو ریل لري. دا د Rsyslog سرور دی. په حقیقت کې دوه مدیریت ماشینونه. دوی ورته چلند لري. مګر د اوس لپاره، ترافیک یوازې د دوی څخه یو له لارې تیریږي. دا ټول لاګونه راټولوي. هغه یوازې په قضیه کې د ډیسک قطار لري. دا لاګونه ډاونلوډ کوي او د مرکزي معلوماتو مرکز (سینګاپور) ته یې لیږي ، چیرې چې دوی بیا ګریلوګ ته لیږل کیږي. او هر ډیټا مرکز خپل د فایل ذخیره لري. په هغه صورت کې چې زموږ اړیکه له لاسه ورکړي، موږ هلته ټول لاګونه لرو. دوی به هلته پاتې شي. دوی به هلته ذخیره شي.
پوښتنه: د غیر معمولي حالتونو په صورت کې، تاسو له هغه ځای څخه لاګ ترلاسه کوئ؟
ځواب: تاسو کولی شئ هلته لاړ شئ (د فایل ذخیره کولو ته) او وګورئ.
پوښتنه: تاسو څنګه څارنه کوئ چې تاسو لاګ له لاسه نه ورکوئ؟
ځواب: موږ په حقیقت کې دوی له لاسه ورکوو، او موږ یې څارنه کوو. د څارنې چارې یوه میاشت وړاندې پیل شوې وې. هغه کتابتون چې د Go APIs کاروي میټریکونه لري. هغه کولی شي حساب کړي چې څو ځله یې ساکټ ته لیکلو توان نه درلود. اوس مهال هلته یو هوښیار هوریستیک شتون لري. هلته یو بفر شتون لري. دا هڅه کوي چې له دې څخه ساکټ ته یو پیغام ولیکي. که چیرې بفر ډیریږي، دا د دوی په غورځولو پیل کوي. او هغه حساب کوي چې څومره یې غورځولي دي. که چیرې میټرونه هلته تیریدل پیل کړي، موږ به د هغې په اړه پوه شو. دوی اوس پرومیتیس ته هم راځي، او تاسو کولی شئ په ګرافانا کې ګرافونه وګورئ. تاسو کولی شئ خبرتیاوې تنظیم کړئ. خو دا لا څرګنده نه ده چې دوی به چا ته واستوي.
پوښتنه: په لچکدار لټون کې تاسو د بې ځایه کیدو سره لاګونه ذخیره کوئ. تاسو څومره نقلونه لرئ؟
ځواب: یوه کرښه.
پوښتنه: ایا دا یوازې یوه کرښه ده؟
ځواب: دا څښتن او نقل دی. معلومات په دوه نقلونو کې ساتل کیږي.
پوښتنه: ایا تاسو په یو ډول د rsyslog بفر اندازه تنظیم کړې؟
ځواب: موږ ډیټاګرامونه د ګمرک یونیکس ساکټ ته لیکو. دا سمدلاسه په موږ باندې د 128 کیلوبایټ محدودیت وضع کوي. موږ نشو کولی په دې اړه نور څه ولیکم. موږ دا په معیار کې لیکلي دي. هغه کسان چې غواړي ذخیره کولو ته لاړ شي 128 کیلوبایټ ولیکئ. کتابتونونه، سربیره پردې، پرې شوي، او یو بیرغ ایښودل شوی چې پیغام پرې شوی. د پیغام لپاره زموږ معیار پخپله یو ځانګړی ساحه لري چې دا ښیې چې ایا دا د ثبت کولو پرمهال قطع شوی یا نه. نو موږ فرصت لرو چې دا شیبه هم تعقیب کړو.
پوښتنه: ایا تاسو مات شوی JSON لیکئ؟
ځواب: مات شوی JSON به د ریل په جریان کې له مینځه یوړل شي ځکه چې کڅوړه ډیره لویه ده. یا ګریلوګ به رد شي ځکه چې دا نشي کولی JSON تجزیه کړي. مګر دلته لنډیزونه شتون لري چې باید تنظیم شي، او ډیری یې د rsyslog سره تړلي دي. ما لا دمخه هلته ډیری مسلې ډکې کړې، کوم چې لاهم کار کولو ته اړتیا لري.
پوښتنه: ولې کافکا؟ ایا تاسو RabbitMQ هڅه کړې؟ ایا ګریلوګ د داسې بارونو لاندې ناکام کیږي؟
ځواب: دا زموږ لپاره د ګریلوګ سره کار نه کوي. او ګریلوګ زموږ لپاره شکل اخلي. هغه واقعیا ستونزه ده. هغه یو عجیب شی دی. او، په حقیقت کې، دا اړتیا نلري. زه به غوره کړم چې له rsyslog څخه مستقیم elasticsearch ته ولیکم او بیا کیبانا ته وګورم. خو موږ باید دا مسله د امنیتي ساتونکو سره حل کړو. دا زموږ د پراختیا لپاره ممکنه اختیار دی، کله چې موږ ګریلوګ وباسو او کیبانا وکاروو. د Logstash کارولو لپاره هیڅ معنی نشته. ځکه چې زه د rsyslog سره ورته کار کولی شم. او دا د elasticsearch لپاره لیکلو لپاره ماډل لري. موږ هڅه کوو چې د ګریلوګ سره یو څه ژوند وکړو. موږ حتی دا یو څه تنظیم کړی. مګر لاهم د پرمختګ لپاره ځای شتون لري.
د کافکا په اړه دا په تاریخي ډول پیښیږي. کله چې زه ورسیدم، دا لا دمخه هلته و، او لاګونه لا دمخه لیکل شوي وو. موږ په ساده ډول خپل کلستر پورته کړ او لاګونه یې په کې لیږدول. موږ د هغه مدیریت یو، موږ پوهیږو چې هغه څنګه احساس کوي. لکه څنګه چې د RabbitMQ لپاره ... دا زموږ لپاره د RabbitMQ سره کار نه کوي. او RabbitMQ زموږ لپاره شکل اخلي. موږ دا په تولید کې لرو، او د هغې سره ستونزې وې. اوس، د پلور دمخه، دوی به هغه زړه راښکونکي کړي، او هغه به په عادي توګه کار پیل کړي. مګر مخکې له دې زه چمتو نه وم چې دا تولید ته خوشې کړم. یو بل ټکی هم شته. ګریلوګ کولی شي د AMQP 0.9 نسخه ولولي، او rsyslog کولی شي د AMQP 1.0 نسخه ولیکي. او په مینځ کې یو واحد حل شتون نلري چې دواړه کولی شي. دا یو یا بل دی. نو په اوس وخت کې یوازې کافکا. مګر دا خپل ځانګړتیاوې هم لري. ځکه چې د rsyslog د نسخې omkafka چې موږ یې کاروو کولی شي ټول پیغام بفر له لاسه ورکړي چې دا د rsyslog څخه راوتلی. د اوس لپاره موږ د هغې سره مخ شو.
پوښتنه: ایا تاسو کافکا کاروئ ځکه چې تاسو یې دمخه درلوده؟ نور د کوم هدف لپاره نه کارول کیږي؟
ځواب: کافکا، چې وه، د ډیټا ساینس ټیم لخوا کارول کیږي. دا یوه بشپړه جلا پروژه ده، چې له بده مرغه زه یې په اړه څه نه شم ویلای. زه نه پوهیږم. دا د ډیټا ساینس ټیم لخوا پرمخ وړل کیده. کله چې لاګونه جوړ شول، موږ پریکړه وکړه چې دا وکاروو ترڅو خپل ځان نصب نه کړو. اوس موږ ګریلوګ تازه کړی، او موږ مطابقت له لاسه ورکړی دی ځکه چې دا د کافکا پخوانی نسخه لري. موږ باید خپل ځان پیل کړو. په ورته وخت کې، موږ د هر API لپاره د دې څلورو موضوعاتو څخه خلاص شو. موږ د ټولو ژوندیو لپاره یوه پراخه موضوع جوړه کړه، د ټولو سټینګ لپاره یوه پراخه پراخه موضوع او یوازې هرڅه هلته واچول. ګریلوګ دا ټول په موازي ډول سکریپ کوي.
پوښتنه: ولې موږ د ساکټونو سره دې شیمانیزم ته اړتیا لرو؟ ایا تاسو د کانټینرونو لپاره د سیسلاګ لاګ ډرایور کارولو هڅه کړې؟
ځواب: په هغه وخت کې چې موږ دا پوښتنه وکړه، د ډاکر سره زموږ اړیکې ترینګلې وې. دا ډاکر 1.0 یا 0.9 و. ډاکر پخپله عجیب و. دوهم، که تاسو لاګونه هم په دې کې فشار کړئ ... زه یو نا تایید شوی شک لرم چې دا ټول لاګونه پخپله د ډاکر ډیمون له لارې تیریږي. که یو API لیونی شي ، نو پاتې APIs پدې حقیقت کې بند پاتې دي چې دوی نشي کولی stdout او stderr واستوي. زه نه پوهیږم چې دا به چیرته رهبري کړي. زه د احساس په کچه شک لرم چې پدې ځای کې د ډاکر سیسلاګ ډرایور کارولو ته اړتیا نشته. زموږ د فعالې ازموینې څانګه د لاګونو سره خپل ګریلوګ کلستر لري. دوی د ډاکر لاګ ډرایورونه کاروي او داسې ښکاري چې هرڅه سم وي. مګر دوی سمدلاسه ګریلوګ ته GELF لیکي. په هغه وخت کې چې موږ دا ټول پیل کړل، موږ یوازې دا کار کولو ته اړتیا درلوده. شاید وروسته، کله چې یو څوک راشي او ووایي چې دا سل کاله ښه کار کوي، موږ به هڅه وکړو.
پوښتنه: تاسو د rsyslog په کارولو سره د معلوماتو مرکزونو تر مینځ تحویل کوئ. ولې کافکا نه؟
ځواب: موږ په حقیقت کې دواړه کوو. د دوو دلیلونو لپاره. که چینل په بشپړه توګه مړ وي، نو زموږ ټول لاګونه، حتی په کمپریس شوي بڼه کې به د هغې له لارې نه تیریږي. او کافکا تاسو ته اجازه درکوي په ساده ډول دوی په پروسه کې له لاسه ورکړي. په دې توګه موږ د دې لوګو څخه خلاصون ترلاسه کوو. موږ یوازې کافکا په مستقیم ډول په دې قضیه کې کاروو. که موږ یو ښه چینل لرو او غواړو چې دا وړیا کړو، نو موږ د دوی rsyslog کاروو. مګر په حقیقت کې ، تاسو کولی شئ دا تنظیم کړئ ترڅو دا پخپله هغه څه پریږدي چې له لارې مناسب ندي. په اوس وخت کې، موږ یوازې په مستقیم ډول د rsyslog تحویلي کاروو، او کافکا چیرته.
سرچینه: www.habr.com