ټولو ته سلام، زما نوم الکساندر دی، زه په CIAN کې د انجنیر په توګه کار کوم او د سیسټم اداره کولو او د زیربناوو پروسو اتومات کولو کې دخیل یم. په تیرو مقالو کې یوې ته په نظرونو کې ، موږ څخه وغوښتل شو چې ووایو چیرې چې موږ هره ورځ 4 TB لاګونه ترلاسه کوو او موږ ورسره څه کوو. هو، موږ ډیری لاګونه لرو، او د دوی د پروسس کولو لپاره یو جلا زیربنا کلستر رامینځته شوی، کوم چې موږ ته اجازه راکوي چې ژر تر ژره ستونزې حل کړو. پدې مقاله کې به زه د دې په اړه وغږیږم چې څنګه موږ دا د یو کال په جریان کې د ډیټا د تل وده کونکي جریان سره کار کولو لپاره تطابق کړی.
چیرته مو پیل کړی؟
په تیرو څو کلونو کې، په cian.ru باندې بار په چټکۍ سره وده کړې، او د 2018 په دریم ربع کې، د سرچینو ټرافيک په میاشت کې 11.2 ملیون ځانګړي کاروونکو ته رسیدلی. په هغه وخت کې، په نازکو شیبو کې موږ تر 40٪ پورې لاګ له لاسه ورکړ، له همدې امله موږ نشو کولی د پیښو سره په چټکۍ سره معامله وکړو او د دوی په حل کولو کې ډیر وخت او هڅې مصرف کړو. موږ ډیری وختونه د ستونزې لامل نشو موندلی، او دا به یو څه وروسته بیا تکرار شي. دا دوزخ و او باید د هغې په اړه یو څه ترسره شي.
په هغه وخت کې، موږ د لاګونو ذخیره کولو لپاره د معیاري شاخص ترتیباتو سره د ElasticSearch نسخه 10 سره د 5.5.2 ډیټا نوډونو کلستر کارول. دا یو کال دمخه د مشهور او ارزانه حل په توګه معرفي شوی و: بیا د لاګ جریان دومره لوی نه و ، د غیر معیاري تشکیلاتو سره د راتلو هیڅ معنی نه وه.
د راتلونکو لاګونو پروسس کول د Logstash لخوا د پنځو ElasticSearch همغږي کونکو په مختلفو بندرونو کې چمتو شوي. یو شاخص، د اندازې په پام کې نیولو پرته، پنځه شارډونه لري. یو ساعت او ورځنی حرکت تنظیم شوی و، په پایله کې، په هر ساعت کې شاوخوا 100 نوي شارډونه په کلستر کې ښکاره شول. پداسې حال کې چې ډیری لاګونه شتون نلري، کلستر ښه کاپي کړې او هیچا یې ترتیباتو ته پام نه دی کړی.
د چټکې ودې ننګونې
د تولید شوي لاګونو حجم خورا ګړندی وده وکړه ، ځکه چې دوه پروسې یو له بل سره تړلې وې. له یوې خوا، د خدماتو کاروونکو شمیر ډیر شوی. له بلې خوا ، موږ په فعاله توګه د مایکرو سرویس معمارۍ ته اړول پیل کړل ، په C# او Python کې زموږ زاړه مونولیتونه ولیدل. څو درجن نوي مایکرو خدمتونه چې د مونولیت برخې یې ځای په ځای کړې د زیربناوو کلستر لپاره د پام وړ نور لاګونه رامینځته کړي.
دا پیمانه وه چې موږ یې هغه ځای ته رسولو چیرې چې کلستر په عملي توګه د مدیریت وړ نه و. کله چې لاګونه په یوه ثانیه کې د 20 زره پیغامونو په اندازې سره رسیدل پیل کړل، په پرله پسې ډول بې ګټې ګرځیدل د شارډونو شمیر 6 زرو ته لوړ کړ، او په هر نوډ کې له 600 څخه ډیر شارډونه شتون درلود.
دا د RAM تخصیص سره ستونزې رامینځته کړې ، او کله چې نوډ خراب شو ، ټول شارډونه په ورته وخت کې حرکت کول پیل کړل ، د ترافیک ضرب کول او نور نوډونه پورته کول ، کوم چې کلسټر ته د معلوماتو لیکل نږدې ناممکن کړل. او په دې موده کې موږ پرته له لوګو پاتې وو. او که چیرې د سرور سره ستونزه وي، موږ اساسا د کلستر 1/10 له لاسه ورکړ. د کوچني شاخصونو لوی شمیر پیچلتیا اضافه کړه.
د لاګونو پرته، موږ د پیښې په دلیلونو نه پوهیږو او ژر یا وروسته کولی شو یو ځل بیا په ورته ریک باندې ګام پورته کړو، او زموږ د ټیم په نظریه کې دا د منلو وړ نه و، ځکه چې زموږ ټول کاري میکانیزمونه یوازې د برعکس کولو لپاره ډیزاین شوي - هیڅکله تکرار نه شي. ورته ستونزې. د دې کولو لپاره، موږ د لاګونو بشپړ حجم او د دوی تحویل ته نږدې په ریښتیني وخت کې اړتیا درلوده ، ځکه چې د دندې انجینرانو یوې ډلې نه یوازې د میټریکونو څخه بلکه د لاګ څخه هم خبرتیاوې څارلې. د ستونزې د کچې د پوهیدو لپاره، په هغه وخت کې د لوګو ټول حجم هره ورځ شاوخوا 2 TB وو.
موږ یو هدف ټاکلی ترڅو د لاګونو ضایع په بشپړ ډول له مینځه ویسي او د ELK کلستر ته د دوی تحویلي وخت د ځواک ماجرا پرمهال اعظمي 15 دقیقو ته راکم کړي (موږ وروسته د داخلي KPI په توګه پدې شمیره تکیه وکړه).
د نوي گردش میکانیزم او ګرم ګرم نوډونه
موږ د 5.5.2 څخه تر 6.4.3 پورې د ElasticSearch نسخه تازه کولو سره د کلستر تبادله پیل کړه. یوځل بیا زموږ نسخه 5 کلستر مړ شو ، او موږ پریکړه وکړه چې دا بند کړو او په بشپړ ډول یې تازه کړو - لاهم لاګونه شتون نلري. نو موږ دا لیږد یوازې په څو ساعتونو کې وکړ.
په دې مرحله کې ترټولو لوی بدلون د اپاچي کافکا پلي کول وو چې په دریو نوډونو کې د منځګړیتوب بفر په توګه همغږي کونکي سره. د پیغام بروکر موږ د ElasticSearch سره د ستونزو پرمهال د لاګونو له لاسه ورکولو څخه وژغورل. په ورته وخت کې ، موږ کلستر ته 2 نوډونه اضافه کړل او د ډیټا مرکز کې په مختلف ریکونو کې موقعیت لرونکي درې "ګرم" نوډونو سره ګرم - ګرم جوړښت ته لاړ. موږ د ماسک په کارولو سره دوی ته لاګونه لیږلي چې باید په هیڅ حالت کې له لاسه ورنکړل شي - نګینکس ، او همدارنګه د غوښتنلیک غلطی لاګونه. کوچني لاګونه پاتې نوډونو ته لیږل شوي - ډیبګ ، خبرداری ، او نور ، او د 24 ساعتونو وروسته ، د "ګرم" نوډونو څخه "مهم" لاګونه لیږدول شوي.
د دې لپاره چې د کوچنیو شاخصونو شمیر زیات نه شي، موږ د وخت له گردش څخه د رول اوور میکانیزم ته واړوو. په فورمونو کې ډیری معلومات شتون درلود چې د شاخص اندازې لخوا گردش خورا معتبر نه دی ، نو موږ پریکړه وکړه چې په شاخص کې د اسنادو شمیر لخوا گردش وکاروو. موږ هر شاخص تحلیل کړ او د اسنادو شمیر مو ثبت کړ چې وروسته یې گردش باید کار وکړي. په دې توګه، موږ د غوره شارډ اندازې ته رسیدلي یو - له 50 GB څخه ډیر نه.
د کلستر اصلاح کول
په هرصورت، موږ په بشپړه توګه له ستونزو څخه خلاص نه یو. له بده مرغه، کوچني شاخصونه لاهم ښکاره شوي: دوی ټاکل شوي حجم ته ندي رسیدلي، نه وګرځیدلي، او د دریو ورځو څخه زاړه شاخصونو د نړیوال پاکولو لخوا حذف شوي، ځکه چې موږ د نیټې له مخې گردش لرې کړ. دا د دې حقیقت له امله د معلوماتو ضایع کیدو لامل شو چې د کلستر څخه شاخص په بشپړ ډول ورک شو، او د غیر موجود شاخص ته د لیکلو هڅه د کیورټر منطق مات کړ چې موږ یې د مدیریت لپاره کاروو. د لیکلو لپاره عرف په یوه شاخص کې بدل شو او د رول اوور منطق یې مات کړ، د ځینو شاخصونو غیر کنټرول شوي وده تر 600 GB پورې.
د مثال په توګه، د گردش ترتیب لپاره:
с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
که چیرې د رول اوور عرف نه و، یوه تېروتنه رامنځته شوه:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
موږ د دې ستونزې حل د راتلونکي تکرار لپاره پریښود او بله مسله مو په لاس کې واخیسته: موږ د لوګسټاش پل منطق ته لاړو، کوم چې د راتلونکو لاګونو پروسس کوي (د غیر ضروري معلوماتو لرې کول او بډایه کول). موږ دا په ډاکر کې کیښود، کوم چې موږ د ډاکر - کمپوز له لارې پیل کوو، او موږ هلته د لوګسټاش صادرونکی هم ځای په ځای کړی، کوم چې د لاګ جریان عملیاتي څارنې لپاره پرومیټیوس ته میټریک لیږي. پدې توګه موږ ځان ته دا فرصت ورکړ چې د هر ډول لاګ پروسس کولو لپاره مسؤل د لوګسټاش مثالونو شمیر په اسانۍ سره بدل کړو.
پداسې حال کې چې موږ کلستر ته وده ورکوو، د cian.ru ترافیک په میاشت کې 12,8 ملیون ځانګړي کاروونکو ته لوړ شو. د پایلې په توګه، دا معلومه شوه چې زموږ بدلونونه په تولید کې د بدلونونو څخه یو څه شاته وو، او موږ د دې حقیقت سره مخ شو چې "ګرم" نوډونه نشي کولی د بار سره مقابله وکړي او د لاګونو بشپړ تحویل ورو کړي. موږ پرته له ناکامۍ "ګرم" معلومات ترلاسه کړل، مګر موږ باید د پاتې نورو تحویلۍ کې مداخله وکړو او لاسي رول اوور ترسره کړو ترڅو شاخصونه په مساوي ډول توزیع کړو.
په ورته وخت کې، په کلستر کې د لوګسټاش مثالونو ترتیب کول او بدلول د دې حقیقت له مخې پیچلي وو چې دا یو محلي ډاکر-کمپوز و، او ټولې کړنې په لاسي ډول ترسره شوې (د نوي پایونو اضافه کولو لپاره، دا اړینه وه چې په لاسي ډول د ټولو څخه تیر شي. سرورونه او هرچیرې د ډاکر - کمپوز اپ -d ترسره کړئ).
بیا توزیع ننوتل
د دې کال په سپتمبر کې، موږ لاهم د مونولیت کمولو، په کلستر باندې بار په زیاتیدو و، او د لاګ جریان په هره ثانیه کې 30 زره پیغامونو ته رسیدل.
موږ راتلونکی تکرار د هارډویر تازه کولو سره پیل کړ. موږ له پنځو همغږي کونکو څخه درې ته واړوو ، د ډیټا نوډونه مو بدل کړل او د پیسو او ذخیره کولو ځای په شرایطو کې مو وګټل. د نوډونو لپاره موږ دوه تشکیلات کاروو:
- د "ګرم" نوډونو لپاره: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 د Hot1 لپاره او 3 د Hot2 لپاره).
- د "ګرم" نوډونو لپاره: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
په دې تکرار کې، موږ شاخص د مایکرو خدماتو د لاسرسي لاګونو سره لیږدول، کوم چې د فرنټ لاین نګینکس لاګونو په څیر ورته ځای نیسي، د دریو "ګرم" نوډونو دویم ګروپ ته. موږ اوس په "ګرم" نوډونو کې د 20 ساعتونو لپاره ډیټا ذخیره کوو، او بیا یې د "ګرم" نوډونو پاتې لوګو ته لیږدوو.
موږ د کوچني شاخصونو د ورکیدو ستونزه د دوی د گردش له سره تنظیم کولو سره حل کړه. اوس شاخصونه په هر حالت کې په هر 23 ساعتونو کې څرخیږي، حتی که لږ معلومات شتون ولري. دا د شارډونو شمیر لږ څه زیات کړ (د دوی شاوخوا 800 وو)، مګر د کلستر فعالیت له نظره دا د زغم وړ دی.
د پایلې په توګه، په کلستر کې شپږ "ګرم" او یوازې څلور "ګرم" نوډونه وو. دا د اوږدې مودې په اوږدو کې په غوښتنو کې د لږ ځنډ لامل کیږي، مګر په راتلونکي کې د نوډونو زیاتول به دا ستونزه حل کړي.
دې تکرار د نیمه اتوماتیک پیمانه نشتوالي ستونزه هم حل کړه. د دې کولو لپاره، موږ د کوماډ کلستر زیربنا ځای پرځای کړه - هغه څه ته ورته چې موږ دمخه په تولید کې ځای په ځای کړي یو. د اوس لپاره، د Logstash اندازه په اتوماتيک ډول د بار په اساس نه بدلیږي، مګر موږ به دې ته ورسیږو.
د راتلونکي لپاره پلانونه
د تطبیق شوي ترتیب اندازه په سمه توګه، او اوس موږ د 13,3 TB ډیټا ذخیره کوو - د 4 ورځو لپاره ټول لاګونه، کوم چې د خبرتیا بیړني تحلیل لپاره اړین دي. موږ ځینې لاګونه په میټریکونو بدلوو، کوم چې موږ په ګرافیت کې اضافه کوو. د انجنیرانو کار اسانه کولو لپاره، موږ د زیربناوو کلستر لپاره میټریکونه او د عامو ستونزو نیمه اتوماتیک ترمیم لپاره سکریپټونه لرو. د ډیټا نوډونو شمیر زیاتولو وروسته ، کوم چې د راتلونکي کال لپاره پلان شوی ، موږ به د 4 څخه تر 7 ورځو پورې ډیټا ذخیره کولو ته واړوو. دا به د عملیاتي کار لپاره کافي وي، ځکه چې موږ تل هڅه کوو چې پیښې ژر تر ژره وڅیړو، او د اوږدې مودې تحقیقاتو لپاره د ټیلی میټري ډاټا شتون لري.
د اکتوبر په 2019 کې، cian.ru ته ترافیک لا دمخه په میاشت کې 15,3 ملیون ځانګړي کاروونکو ته وده کړې. دا د لاګونو رسولو لپاره د معماري حل یوه جدي ازموینه شوه.
اوس موږ چمتو کوو چې ElasticSearch 7 نسخه ته تازه کړو. په هرصورت، د دې لپاره موږ باید په ElasticSearch کې د ډیری شاخصونو نقشه تازه کړو، ځکه چې دوی د 5.5 نسخه څخه لیږدول شوي او په 6 نسخه کې د رد شوي په توګه اعلان شوي (دوی په ساده ډول په نسخه کې شتون نلري. ۷). دا پدې مانا ده چې د تازه کولو پروسې په جریان کې به خامخا یو ډول ځواک ماجرا وي ، کوم چې به موږ د لاګ پرته پریږدي پداسې حال کې چې مسله حل کیږي. د 7 نسخه، موږ ډیری د کبانا ته د ښه شوي انٹرفیس او نوي فلټرونو سره سترګې په لار یو.
موږ خپل اصلي هدف ترلاسه کړ: موږ د لاګونو له لاسه ورکول بند کړل او د زیربنا کلستر د ځنډ وخت په اونۍ کې له 2-3 حادثو څخه په میاشت کې د څو ساعتونو ساتنې کار ته راکم کړ. په تولید کې دا ټول کار تقریبا ناڅرګند دی. په هرصورت، اوس موږ کولی شو په سمه توګه وټاکو چې زموږ د خدماتو سره څه پیښیږي، موږ کولی شو په چټکتیا سره دا په خاموش حالت کې وکړو او اندیښنه ونلرئ چې لاګونه به ورک شي. په عموم کې، موږ مطمین، خوشحاله او د نویو ګټو لپاره چمتووالی لرو، چې وروسته به یې په اړه خبرې وکړو.
سرچینه: www.habr.com