زما نوم انتون بدرین دی. زه د عالي ټیکنالوژۍ په مرکز کې کار کوم او د سیسټم اداره کوم. یوه میاشت دمخه ، زموږ د کارپوریټ کنفرانس پای ته ورسید ، چیرې چې موږ د خپل ښار د معلوماتي ټیکنالوژۍ ټولنې سره خپلې راټولې شوې تجربې شریکې کړې. ما د ویب غوښتنلیکونو د څارنې په اړه خبرې وکړې. مواد د جونیئر یا منځنۍ کچې لپاره و، چا چې دا پروسه له سکریچ څخه نه ده جوړه کړې.
د څارنې د هر سیسټم بنسټ د سوداګرۍ ستونزې حل کول دي. د څارنې لپاره د هیچا په ګټه نه دی. سوداګري څه غواړي؟ نو هر څه ګړندي او پرته له خطا کار کوي. سوداګرۍ غواړي فعال وي، ترڅو موږ پخپله په خدمت کې ستونزې وپیژنو او ژر تر ژره یې حل کړو. دا په حقیقت کې هغه ستونزې دي چې ما تیر کال زموږ د یو پیرودونکي لپاره په یوه پروژه کې حل کړې.
د پروژې په اړه
دا پروژه په هیواد کې د وفادارۍ ترټولو لوی پروګرامونه دي. موږ د پرچون زنځیرونو سره د بازار موندنې مختلف وسیلو لکه د بونس کارتونو له لارې د پلور فریکونسۍ زیاتولو کې مرسته کوو. په مجموع کې، په پروژه کې 14 غوښتنلیکونه شامل دي چې په لسو سرورونو کې پرمخ ځي.
د مرکې پروسې په جریان کې، ما په مکرر ډول ولیدل چې مدیران تل د ویب غوښتنلیکونو څارنه په سمه توګه نه کوي: ډیری لاهم د عملیاتي سیسټم میټریکونو تمرکز کوي او کله ناکله د خدماتو څارنه کوي.
زما په قضیه کې، د پیرودونکي نظارت سیسټم دمخه د Icinga پراساس و. دا پورته ستونزې په هیڅ ډول حل نه کړي. ډیری وختونه پیرودونکي پخپله موږ ته د ستونزو په اړه خبر ورکوي، او ډیری وختونه، موږ په ساده ډول د دلیل پای ته رسیدو لپاره کافي معلومات نه درلودل.
برسېره پر دې، د دې د نور پرمختګ بې ګټې روښانه پوهه وه. زه فکر کوم هغه څوک چې د Icinga سره اشنا دي زه به پوه شي. نو، موږ پریکړه وکړه چې د پروژې لپاره د ویب غوښتنلیک نظارت سیسټم په بشپړه توګه بیا ډیزاین کړو.
Prometheus
موږ Prometheus د دریو اصلي شاخصونو پراساس غوره کړ:
- د شته میټریکونو لوی شمیر. زموږ په قضیه کې د دوی 60 زره شتون لري. البته، دا د یادونې وړ ده چې موږ د دوی ډیری برخه نه کاروو (شاید شاوخوا 95٪). له بلې خوا، دوی ټول نسبتا ارزانه دي. زموږ لپاره، دا د پخوانۍ کارول شوي Icinga په پرتله بل سخت دی. په دې کې، د میټریکونو اضافه کول یو ځانګړی درد و: موجود یې ګران وو (یوازې د هر پلگ ان سرچینې کوډ وګورئ). هر پلگ ان په باش یا پایتون کې سکریپټ و، چې پیل یې د مصرف شوي سرچینو له مخې ګران دی.
- دا سیسټم نسبتا لږې سرچینې مصرفوي. 600 MB رام، د یو کور 15٪ او یو څو درجن IOPS زموږ د ټولو میټریکونو لپاره کافي دي. البته، تاسو باید د میټریک صادرونکي چل کړئ، مګر دا ټول په Go کې لیکل شوي او د بریښنا لوږه هم نه ده. زه فکر نه کوم چې په عصري واقعیتونو کې دا یوه ستونزه ده.
- Kubernetes ته د مهاجرت وړتیا چمتو کوي. د پیرودونکي پلانونو په پام کې نیولو سره، انتخاب څرګند دی.
ELK
مخکې، موږ لاګونه راټول یا پروسس نه کړل. نیمګړتیاوې د هرچا لپاره روښانه دي. موږ ELK غوره کړی ځکه چې موږ دمخه د دې سیسټم سره تجربه درلوده. موږ یوازې هلته د غوښتنلیک لاګ ذخیره کوو. د انتخاب اصلي معیارونه د بشپړ متن لټون او سرعت و.
د کلي کور
په پیل کې، انتخاب په InfluxDB کې راوتلی. موږ د Nginx لاګونو راټولولو اړتیا احساس کړه، د pg_stat_statements څخه احصایې، او د پرومیتیس تاریخي ډاټا ذخیره کول. موږ انفلکس نه خوښوو ځکه چې دا وخت په وخت د لوی حافظې مصرف کول پیل کړل او خراب شو. برسېره پردې، ما غوښتل چې د ریموټ_addr لخوا پوښتنې ګروپي کړم، مګر پدې DBMS کې ګروپ کول یوازې د ټاګونو لخوا دي. ټاګونه ګران دي (یاداشت)، د دوی شمیر په مشروط ډول محدود دی.
موږ بیا خپل لټون پیل کړ. هغه څه ته اړتیا وه چې د لږترلږه سرچینو مصرف سره تحلیلي ډیټابیس و ، په غوره توګه په ډیسک کې د ډیټا کمپریشن سره.
کلک هاؤس دا ټول معیارونه پوره کوي، او موږ هیڅکله په خپل انتخاب پښیمانه نه یو. موږ په دې کې د معلوماتو غیر معمولي مقدار نه لیکو (د ننوتلو شمیر یوازې په یوه دقیقه کې شاوخوا پنځه زره دی).
نیو ریلیک
نیو ریلیک په تاریخي ډول زموږ سره و ځکه چې دا د پیرودونکي انتخاب و. موږ دا د APM په توګه کاروو.
زبیبکس
موږ د مختلف APIs تور بکس څارلو لپاره په ځانګړي ډول زبیبکس کاروو.
د څارنې د طریقې تعریف
موږ غوښتل چې دا دنده تخریب کړو او په دې توګه د څارنې طریقه سیستماتیک کړو.
د دې کولو لپاره، ما زموږ سیسټم په لاندې کچو ویشلی:
- هارډویر او VMS؛
- عملیاتي سیسټم؛
- د سیسټم خدمتونه، سافټویر سټیک؛
- غوښتنلیک
- د سوداګرۍ منطق.
ولې دا طریقه مناسبه ده:
- موږ پوهیږو چې څوک د هرې کچې کار لپاره مسؤل دی او د دې پراساس موږ کولی شو خبرتیاوې واستوو؛
- موږ کولی شو جوړښت وکاروو کله چې د خبرتیاو فشار راوړو - دا به عجیب وي چې د ډیټابیس نه شتون په اړه خبرداری واستوو کله چې په ټوله کې مجازی ماشین شتون نلري.
څرنګه چې زموږ دنده د سیسټم په عملیاتو کې د سرغړونو پیژندل دي، موږ باید په هره کچه د میټریکونو یو ټاکلی سیټ روښانه کړو چې د خبرتیا قواعدو لیکلو په وخت کې د پام وړ ارزښت لري. بیا، راځئ چې د "VMS"، "عملیاتي سیسټم" او "سیسټم خدمتونه، سافټویر سټیک" کچې ته لاړ شو.
مجازی ماشینونه
کوربه موږ ته پروسیسر، ډیسک، حافظه او شبکه تخصیص کوي. او موږ د لومړي دوه سره ستونزې درلودې. نو، میټریکونه:
د CPU غلا وخت - کله چې تاسو په ایمیزون (t2.micro، د مثال په توګه) کې یو مجازی ماشین واخلئ، تاسو باید پوه شئ چې تاسو د بشپړ پروسیسر کور نه اختصاص شوي، مګر یوازې د هغې وخت کوټه. او کله چې تاسو دا ختم کړئ، پروسیسر به ستاسو څخه لیرې شي.
دا میټریک تاسو ته اجازه درکوي چې داسې شیبې تعقیب کړئ او پریکړې وکړئ. د مثال په توګه، ایا دا اړینه ده چې یو غټ تعرفه واخلئ یا د شالید دندو پروسس او د API غوښتنې مختلف سرورونو ته توزیع کړئ؟
IOPS + CPU iowait وخت - د ځینو دلیلونو لپاره، ډیری کلاوډ کوربه د کافي IOPS نه چمتو کولو سره ګناه کوي. سربیره پردې، د ټیټ IOPS سره مهالویش د دوی لپاره دلیل ندی. له همدې امله، دا د CPU iowait راټولولو ارزښت لري. د دې جوړه ګرافونو سره - د ټیټ IOPS او لوړ I/O انتظار سره - تاسو کولی شئ دمخه د کوربه توب سره خبرې وکړئ او ستونزه حل کړئ.
چليز غونډال
د عملیاتي سیسټم معیارونه:
- په٪ کې د شته حافظې مقدار؛
- د تبادلې کارونې فعالیت: vmstat swapin، swapout؛
- د موجود انډونو شمیر او د فایل سیسټم په % کې خالي ځای
- اوسط بار
- په دوه حالتونو کې د اړیکو شمیر؛
- د جدول بشپړتیا سره مقابله؛
- د شبکې کیفیت د ss یوټیلیټ په کارولو سره څارل کیدی شي، iproute2 بسته - د دې محصول څخه د RTT اړیکو شاخص ترلاسه کړئ او د ډیسټ پورټ لخوا یې ګروپ کړئ.
همدارنګه د عملیاتي سیسټم په کچه موږ د پروسې په څیر داسې یو وجود لرو. دا مهمه ده چې په سیسټم کې د پروسو یوه ټولګه وپیژندل شي چې د هغې په عملیاتو کې مهم رول لوبوي. که، د مثال په توګه، تاسو ډیری pgpools لرئ، نو تاسو اړتیا لرئ چې د هر یو لپاره معلومات راټول کړئ.
د میټریکونو ټولګه په لاندې ډول ده:
- سی پی یو؛
- حافظه په اصل کې اوسیدونکي ده؛
- IO - په غوره توګه په IOPS کې؛
- FileFd - خلاص او محدود؛
- د پام وړ مخ ناکامۍ - پدې توګه تاسو کولی شئ پوه شئ چې کومه پروسه بدلیږي.
موږ ټول نظارت په ډاکر کې ځای په ځای کوو ، او موږ د میټریک ډیټا راټولولو لپاره مشاور کاروو. په نورو ماشینونو کې موږ د پروسې صادرونکي کاروو.
د سیسټم خدمتونه، سافټویر سټیک
هر غوښتنلیک خپل ځانګړتیاوې لري، او دا ستونزمنه ده چې د میټریکونو ځانګړي سیټ واحد کړئ.
نړیواله ټولګه ده:
- د غوښتنې کچه؛
- د غلطیو شمیر؛
- ځنډ
- سنتریت
په دې کچه د څارنې زموږ ترټولو غوره مثالونه Nginx او PostgreSQL دي.
زموږ په سیسټم کې ترټولو بار شوي خدمت ډیټابیس دی. په تیرو کې، موږ ډیری وختونه د دې په موندلو کې ستونزه درلوده چې ډیټابیس څه کوي.
موږ په ډیسکونو کې لوړ بار ولید ، مګر ورو لاګ واقعیا هیڅ ونه ښیې. موږ دا ستونزه د pg_stat_statements په کارولو سره حل کړه، یو لید چې د پوښتنو احصایې راټولوي.
دا ټول د مدیر اړتیاوې دي.
موږ د غوښتنې لوستلو او لیکلو فعالیت ګراف جوړوو:
هر څه ساده او روښانه دي، هره غوښتنه خپل رنګ لري.
یو مساوي د پام وړ مثال د نګینکس لاګونه دي. دا د حیرانتیا خبره نده چې لږ شمیر خلک یې تحلیلوي یا یې د اړتیاوو په لیست کې ذکر کوي. معیاري بڼه خورا معلوماتي نه ده او باید پراخه شي.
په شخصي توګه، ما د غوښتنې_ وخت، د پورته کولو_ ځواب_ وخت، د بدن_بایټ_ لیږل، غوښتنه_ اوږدوالی، غوښتنه_ id اضافه کړه. موږ د ځواب وخت او د غلطیو شمیره په ګوته کوو:
موږ د ځواب وخت او د غلطیو شمیر ګرافونه جوړوو. په یاد دي؟ ایا ما د سوداګرۍ اهدافو په اړه خبرې وکړې؟ په چټکۍ سره او پرته له غلطیو؟ موږ دمخه دا مسلې په دوه چارټونو پوښلي دي. او تاسو کولی شئ دمخه د دوی په کارولو سره مدیرانو ته وظیفه زنګ ووهئ.
مګر یوه بله ستونزه پاتې ده - د پیښې د لاملونو د چټک له منځه وړلو ډاډ ترلاسه کول.
د پیښې حل
د ستونزې له پیژندلو څخه تر حل پورې ټوله پروسه په څو مرحلو ویشل کیدی شي:
- د ستونزې پیژندل؛
- د وظیفې مدیر ته خبرتیا؛
- د پیښې ځواب؛
- د لاملونو له منځه وړل.
دا مهمه ده چې موږ باید دا ژر تر ژره ترسره کړو. او که چیرې د ستونزې پیژندلو او د خبرتیا لیږلو مرحلو کې موږ ډیر وخت نه شو ترلاسه کولی - په هر حالت کې به دوه دقیقې په دوی مصرف شي ، نو بیا وروسته بیا د پرمختګ لپاره په ساده ډول ناپاکه ساحه ده.
راځئ یوازې تصور وکړو چې د دندې افسر تلیفون زنګ راغی. هغه به څه کوي؟ د پوښتنو ځوابونو لپاره وګورئ - څه مات شو، چیرته مات شو، څنګه غبرګون وښود؟ دلته موږ دې پوښتنو ته څنګه ځواب ورکوو:
موږ په ساده ډول دا ټول معلومات د خبرتیا په متن کې شاملوو، د ویکي پاڼې ته یو لینک ورکړئ چې دا تشریح کوي چې څنګه دې ستونزې ته ځواب ووایی، څنګه یې حل کړئ او څنګه یې پراختیا ومومي.
ما لاهم د غوښتنلیک پرت او سوداګرۍ منطق په اړه څه ندي ویلي. له بده مرغه، زموږ غوښتنلیکونه لاهم د میټریک راټولول نه پلي کوي. د دې کچو څخه د هر ډول معلوماتو یوازینۍ سرچینه لاګونه دي.
یو څو ټکي.
لومړی، جوړښت شوي لاګونه ولیکئ. د پیغام په متن کې د شرایطو شاملولو ته اړتیا نشته. دا د دوی ګروپ او تحلیل ستونزمن کوي. Logstash دا ټول نورمال کولو لپاره ډیر وخت نیسي.
دوهم، د شدت کچه په سمه توګه وکاروئ. هره ژبه خپل معیار لري. په شخصي توګه، زه څلور درجې توپیر کوم:
- کومه تېروتنه؛
- د پیرودونکي اړخ تېروتنه؛
- تېروتنه زموږ په غاړه ده، موږ پیسې له لاسه نه ورکوو، موږ خطرونه نه لرو؛
- غلطي زموږ په غاړه ده، موږ پیسې له لاسه ورکوو.
اجازه راکړئ چې لنډیز وکړم. تاسو اړتیا لرئ د سوداګرۍ منطق پراساس د نظارت رامینځته کولو هڅه وکړئ. هڅه وکړئ پخپله غوښتنلیک وڅارئ او د ورته میټریکونو سره کار وکړئ لکه د پلور شمیره ، د نوي کارونکي راجسټریشن شمیر ، د اوسني فعال کاروونکو شمیر ، او داسې نور.
که ستاسو ټوله سوداګرۍ په براوزر کې یو تڼۍ وي، تاسو اړتیا لرئ څارنه وکړئ چې ایا دا کلیک کوي او په سمه توګه کار کوي. پاتې ټول مهم نه دي.
که تاسو دا نلرئ ، تاسو کولی شئ د دې سره د غوښتنلیک لاګونو ، نګینکس لاګونو ، او داسې نورو کې د ترلاسه کولو هڅه وکړئ ، لکه څنګه چې موږ وکړل. تاسو باید د امکان تر حده غوښتنلیک ته نږدې اوسئ.
د عملیاتي سیسټم میټریکونه یقینا مهم دي، مګر سوداګرۍ ورسره علاقه نلري، موږ د دوی لپاره پیسې نه ورکوو.
سرچینه: www.habr.com