راتلونکی HighLoad++ کنفرانس به د اپریل په 6 او 7، 2020 کې په سینټ پیټرزبورګ کې ترسره شي توضیحات او ټکټونه . HighLoad++ مسکو 2018. هال "مسکو". د نومبر 9، 15:00. مقالې او .
* څارنه - آنلاین او تحلیلونه.
* د ZABBIX پلیټ فارم بنسټیز محدودیتونه.
* د تحلیلي ذخیره کولو اندازه کولو لپاره حل.
* د ZABBIX سرور اصلاح کول.
* د UI اصلاح کول.
* د 40k NVPS څخه ډیر بار لاندې د سیسټم چلولو تجربه وکړئ.
* لنډې پایلې.
میخایل ماکوروف (له دې وروسته - MM): - سلام و ټولو ته!
ماکسیم چیرنیتسوف (له دې وروسته - MCH): - بعد له غرمه مو پخیر!
MM: - اجازه راکړئ ماکسیم معرفي کړم. میکس یو تکړه انجنیر دی، تر ټولو ښه شبکه چې زه یې پیژنم. ماکسیم په شبکو او خدماتو کې دخیل دی، د دوی پراختیا او عملیات.
MCH: - او زه غواړم تاسو ته د میخایل په اړه ووایم. میخایل د C پراختیا کونکی دی. هغه زموږ د شرکت لپاره ډیری لوړ بار ټرافيکي پروسس کولو حلونه لیکلي. موږ په یورالونو کې ژوند کوو او کار کوو، د سختو سړیو چیلیابینسک ښار کې، د Intersvyaz شرکت کې. زموږ شرکت په 16 ښارونو کې د یو ملیون خلکو لپاره د انټرنیټ او کیبل تلویزیون خدمت چمتو کونکی دی.
MM: - او دا د ویلو وړ ده چې Intersvyaz یوازې د یو چمتو کونکي څخه ډیر دی، دا د معلوماتي ټکنالوجۍ شرکت دی. زموږ ډیری حلونه زموږ د آی ټي ډیپارټمنټ لخوا رامینځته شوي.
مګر: له سرورونو څخه د تلیفون مرکز او ګرځنده غوښتنلیک ته ترافیک پروسس کوي. د معلوماتي ټکنالوجۍ څانګه اوس شاوخوا 80 کسان لري چې خورا متنوع وړتیاوې لري.
د زیبکس او د هغې د جوړښت په اړه
MCH: - او اوس به زه هڅه وکړم چې یو شخصي ریکارډ جوړ کړم او په یوه دقیقه کې ووایم چې زبیکس څه شی دی (له دې وروسته د "زابیکس" په نوم یادیږي).
زیبکس ځان د تصدۍ په کچه د بکس څخه بهر د څارنې سیسټم په توګه موقعیت لري. دا ډیری ځانګړتیاوې لري چې ژوند اسانه کوي: د پرمختللو تېښتې قواعد، د ادغام لپاره API، د کوربه او میټریکونو ګروپ کول او اتوماتیک کشف. زیبکس د پیمانه کولو تش په نامه وسیلې لري - پراکسي. زبیبکس د خلاصې سرچینې سیسټم دی.
په لنډه توګه د معمارۍ په اړه. موږ کولی شو ووایو چې دا له دریو برخو څخه جوړ دی:
- سرور. په سی کې لیکل شوی. د تارونو تر مینځ د خورا پیچلي پروسس کولو او معلوماتو لیږد سره. ټول پروسس په دې کې ترسره کیږي: له ترلاسه کولو څخه ډیټابیس ته خوندي کولو پورې.
- ټول معلومات په ډیټابیس کې ساتل کیږي. Zabbix د MySQL، PostreSQL او اوریکل ملاتړ کوي.
- ویب انٹرفیس په PHP کې لیکل شوی. په ډیری سیسټمونو کې دا د اپاچي سرور سره راځي، مګر د nginx + php سره په ترکیب کې ډیر اغیزمن کار کوي.
نن موږ غواړو د زیبکس پورې اړوند زموږ د شرکت د ژوند څخه یوه کیسه ووایو ...
د Intersvyaz شرکت د ژوند یوه کیسه. موږ څه لرو او څه ته اړتیا لرو؟
5 یا 6 میاشتې مخکې. د کار نه یوه ورځ وروسته...
MCH: - میشا، سلام! زه خوښ یم چې ما تاسو نیولی - خبرې اترې شتون لري. موږ بیا د څارنې په برخه کې ستونزې درلودې. د یوې لویې حادثې په جریان کې، هرڅه سست وو او د شبکې د حالت په اړه هیڅ معلومات نشته. له بده مرغه، دا لومړی ځل نه دی چې دا پیښیږي. زه ستا مرستي ته اړتیا لرم. راځئ چې په هر ډول شرایطو کې زموږ د څارنې کار وکړو!
MM: - مګر راځئ چې لومړی همغږي کړو. ما په څو کلونو کې هلته نه دی لیدلی. تر هغه ځایه چې زه په یاد لرم، موږ ناګیوس پریښود او شاوخوا 8 کاله دمخه زیبکس ته لاړ. او اوس داسې ښکاري چې موږ 6 پیاوړي سرورونه او شاوخوا یو درجن پراکسي لرو. ایا زه یو څه ګډوډ یم؟
MCH: - تقریبا. 15 سرورونه، چې ځینې یې مجازی ماشینونه دي. ترټولو مهمه خبره دا ده چې دا هغه وخت موږ نه خوندي کوي کله چې موږ ورته اړتیا لرو. د حادثې په څیر - سرورونه ورو کوي او تاسو هیڅ شی نه ګورئ. موږ هڅه وکړه چې تشکیلات اصلاح کړو، مګر دا د فعالیت مطلوب زیاتوالی ندی وړاندې کړی.
MM: - دا صفا ده. ایا تاسو یو څه لیدلي، ایا تاسو دمخه د تشخیص څخه یو څه کیندلي؟
MCH: - لومړی شی چې تاسو ورسره معامله کوئ ډیټابیس دی. MySQL په دوامداره توګه بار شوی، نوي میټریکونه ذخیره کوي، او کله چې زیبکس د پیښو یوه ډله رامینځته کوي، ډیټابیس په لفظي توګه د څو ساعتونو لپاره ډیریږي. ما دمخه تاسو ته د تشکیلاتو اصلاح کولو په اړه ویلي وو ، مګر په حقیقت کې سږکال دوی هارډویر تازه کړی: سرورونه په SSD RAIDs کې له سل ګیګابایټ څخه ډیر حافظه او ډیسک سرې لري - په اوږد مهال کې د دې په لیکه کې وده کولو کې هیڅ معنی نلري. څه وکړو؟
MM: - دا صفا ده. په عموم کې، MySQL د LTP ډیټابیس دی. په ښکاره ډول، دا نور زموږ د اندازې د میترونو آرشیف ذخیره کولو لپاره مناسب ندي. راځئ چې دا معلومه کړو.
MCH: - راځه!
د هیکاتون په پایله کې د زیبکس او کلیک هاؤس ادغام
یو څه وروسته موږ په زړه پوري معلومات ترلاسه کړل:
زموږ په ډیټابیس کې ډیری ځای د میټریک آرشیف لخوا نیول شوی و او له 1٪ څخه کم د تشکیلاتو ، ټیمپلیټونو او تنظیماتو لپاره کارول شوی و. په هغه وخت کې، موږ د یو کال څخه زیات د کلک هاؤس پراساس د لوی ډیټا حل کار کاوه. د حرکت لار موږ ته څرګنده وه. زموږ په پسرلي هیکاتون کې ، ما د سرور او فرنټ اینډ لپاره د کلیک هاؤس سره د زبیکس ادغام لیکلی. په هغه وخت کې، زیبکس دمخه د ElasticSearch لپاره ملاتړ درلود، او موږ پریکړه وکړه چې دوی پرتله کړو.
د Clickhouse او Elasticsearch پرتله کول
MM: - د پرتله کولو لپاره، موږ ورته بار تولید کړی لکه څنګه چې د زیبکس سرور چمتو کوي او وګورئ چې سیسټمونه به څنګه چلند وکړي. موږ د CURL په کارولو سره د 1000 لینونو په بیچونو کې ډاټا لیکلي. موږ دمخه فرض کړی و چې کلیک هاؤس به د بار پروفایل لپاره ډیر موثر وي چې زیبکس یې کوي. پایلې حتی زموږ له تمو څخه ډیرې وې:
د ورته ازموینې شرایطو لاندې ، کلیک هاوس درې ځله ډیر معلومات لیکلي. په ورته وخت کې ، دواړه سیسټمونه خورا مؤثره مصرفوي (د سرچینو لږ مقدار) کله چې د معلوماتو لوستل. مګر Elastics د ثبت کولو پرمهال لوی مقدار پروسیسر ته اړتیا لري:
په مجموع کې، کلک هاؤس د پروسیسر مصرف او سرعت له مخې د Elastix څخه د پام وړ لوړ و. په ورته وخت کې، د ډیټا کمپریشن له امله، کلیک هاوس په هارډ ډرایو کې 11 ځله لږ کاروي او نږدې 30 ځله لږ ډیسک عملیات ترسره کوي:
MCH: - هو، د ډیسک فرعي سیسټم سره د کلک هاؤس کار په خورا مؤثره توګه پلي کیږي. تاسو کولی شئ د ډیټابیس لپاره لوی SATA ډیسکونه وکاروئ او په هره ثانیه کې د سلګونو زرو لیکو لیکلو سرعت ترلاسه کړئ. د بکس څخه بهر سیسټم د شارډینګ ، نقل کولو ملاتړ کوي او تنظیم کول خورا اسانه دي. موږ په ټول کال کې د دې کارولو څخه ډیر خوښ یو.
د منابعو د اصلاح کولو لپاره، تاسو کولی شئ د خپل موجوده اصلي ډیټابیس تر څنګ کلک هاؤس نصب کړئ او پدې توګه د CPU ډیر وخت او ډیسک عملیات خوندي کړئ. موږ د میټریکونو آرشیف موجوده کلک هاؤس کلسترونو ته لیږدولی دی:
موږ د MySQL اصلي ډیټابیس دومره آرام کړ چې موږ کولی شو دا په یو ماشین کې د زبکس سرور سره یوځای کړو او د MySQL لپاره وقف شوی سرور پریږدو.
په زبکس کې رایه اچونه څنګه کار کوي؟
4 میاشتې مخکې
MM: - ښه، ایا موږ کولی شو د اډې سره ستونزې هیر کړو؟
MCH: - دا د ډاډ لپاره دی! بله ستونزه چې موږ یې حل کولو ته اړتیا لرو ورو د معلوماتو راټولول دي. اوس زموږ ټول 15 پراکسي سرورونه د SNMP او رایې ورکولو پروسې سره ډیر شوي دي. او د نوي او نوي سرورونو نصبولو پرته بله لاره نشته.
MM: - غوره. مګر لومړی، موږ ته ووایه چې په زبیبکس کې رایې څنګه کار کوي؟
MCH: - په لنډه توګه، د میټریکونو 20 ډولونه او د دوی د ترلاسه کولو لپاره لسګونه لارې شتون لري. زیبکس کولی شي معلومات د "غوښتنې ځواب" حالت کې راټول کړي، یا د "ټریپر انٹرفیس" له لارې نوي معلوماتو ته انتظار وکړي.
د یادولو وړ ده چې په اصلي زیبکس کې دا طریقه (ټریپر) تر ټولو چټکه ده.
د بار ویشلو لپاره پراکسي سرورونه شتون لري:
پراکسي کولی شي د زبکس سرور په څیر د راټولولو ورته دندې ترسره کړي، له هغې څخه دندې ترلاسه کوي او د ټریپر انٹرفیس له لارې راټول شوي میټریکونه لیږل کیږي. دا د بار ویشلو لپاره په رسمي ډول وړاندیز شوی لاره ده. پراکسي د NAT یا سست چینل له لارې د لیرې پرتو زیربناوو د څارنې لپاره هم ګټور دي:
MM: - هرڅه د معمارۍ سره روښانه دي. موږ باید سرچینې وګورو ...
څو ورځې وروسته
د دې کیسه چې څنګه nmap fping وګټله
MM: "زه فکر کوم چې ما یو څه کیندل."
MCH: - ماته ووایاست!
MM: - ما وموندله چې کله د شتون چک کول، زیبکس په یو وخت کې اعظمي حد 128 کوربه ګوري. ما هڅه وکړه چې دا شمیره 500 ته لوړه کړم او د دوی په پینګ (پنګ) کې د انټر پیکټ وقفه لرې کړم - دا فعالیت دوه چنده کوي. مګر زه لوی شمیر غواړم.
MCH: - زما په عمل کې، زه ځینې وختونه باید د زرګونو کوربه شتون وګورم، او ما هیڅکله د دې لپاره د nmap څخه ګړندی هیڅ نه دی لیدلی. زه ډاډه یم چې دا ترټولو چټکه لاره ده. راځئ چې دا هڅه وکړو! موږ اړتیا لرو په هر تکرار کې د کوربه توب شمیر د پام وړ زیات کړو.
MM: - له پنځو سوو څخه ډیر چیک کړئ؟ ۶۰۰؟
MCH: - لږ تر لږه څو زره.
MM: - سمه ده. ترټولو مهم شی چې ما غوښتل ووایم هغه دا دی چې ما وموندله چې په زبکس کې ډیری رایې په همغږي ډول ترسره کیږي. موږ حتما اړتیا لرو چې دا په غیر متناسب حالت کې بدل کړو. بیا موږ کولی شو په ډراماتیک ډول د رای ورکونکو لخوا راټول شوي میټریکونو شمیر زیات کړو ، په ځانګړي توګه که موږ په هر تکرار کې د میټریک شمیر زیات کړو.
MCH: - غوره! او کله؟
MM: - د معمول په څیر، پرون.
MCH: - موږ د fping او nmap دواړه نسخې پرتله کړې:
په لوی شمیر کوربه کې، nmap تمه کیده چې تر پنځه ځله ډیر اغیزمن وي. څرنګه چې nmap یوازې شتون او د غبرګون وخت چک کوي، موږ د زیانونو محاسبه محرکاتو ته واړوله او د شتون چک وقفې مو د پام وړ کمې کړې. موږ د nmap لپاره د کوربه توب مطلوب شمیر موندلی چې په هر تکرار کې شاوخوا 4 زره وي. Nmap موږ ته اجازه راکړه چې د شتون چکونو CPU لګښت درې ځله کم کړو او وقفه له 120 ثانیو څخه 10 ته راکم کړو.
د رای ورکولو اصلاح کول
MM: "بیا مو رای ورکونه پیل کړه. موږ په عمده توګه د SNMP کشف او اجنټانو سره علاقه درلوده. په زبکس کې رایه اچونه په همغږي ډول ترسره کیږي او د سیسټم د موثریت د زیاتوالي لپاره ځانګړي تدابیر نیول شوي دي. په همغږي حالت کې، د کوربه نشتوالی د رایې ورکولو د پام وړ تخریب لامل کیږي. دلته د دولتونو بشپړ سیسټم شتون لري، ځانګړي پروسې شتون لري - د نه لاسرسي وړ رای ورکونکي چې یوازې د لاسرسي وړ کوربه سره کار کوي:
دا یو تبصره ده چې د دولت میټریکس ښیي، د لیږد سیسټم ټولې پیچلتیاوې چې د سیسټم اغیزمن پاتې کیدو لپاره اړین دي. سربیره پردې، همغږي رایه ورکول پخپله خورا ورو دي:
له همدې امله په لسګونو پراکسيونو کې د رای ورکونکو زرګونه جریان زموږ لپاره د اړتیا وړ ډیټا راټولولی نشي. غیر متناسب تطبیق نه یوازې د تارونو شمیر سره ستونزې حل کړې ، بلکه د شتون نه شتون لرونکي کوربه توب دولتي سیسټم هم د پام وړ ساده کړی ، ځکه چې د هرې شمیرې لپاره چې د رایې ورکولو په یوه تکرار کې چیک شوي ، د انتظار اعظمي وخت 1 وخت پای ته رسیدلی:
برسیره پردې، موږ د SNMP غوښتنو لپاره د رایې ورکولو سیسټم تعدیل او ښه کړی. حقیقت دا دی چې ډیری خلک نشي کولی په ورته وخت کې د ډیری SNMP غوښتنو ته ځواب ووایی. له همدې امله، موږ یو هایبرډ حالت جوړ کړ، کله چې د ورته کوربه SNMP رایه اچونه په غیر متناسب ډول ترسره کیږي:
دا د کوربه ټول بسته لپاره ترسره کیږي. دا حالت په نهایت کې د بشپړ غیر متناسب څخه ورو ندی ، ځکه چې د یو نیم سوه SNMP ارزښتونو رایه ورکول لاهم د 1 وخت پای څخه خورا ګړندي دي.
زموږ تجربو ښودلې چې په یو تکرار کې د غوښتنو مطلوب شمیر د SNMP رایې ورکولو سره نږدې 8 زره دی. په مجموع کې، غیر متناسب حالت ته لیږد موږ ته اجازه راکړه چې د رایې ورکولو فعالیت 200 ځله، څو سوه ځله ګړندی کړو.
MCH: - د رای ورکولو د پایلو اصلاح ښودلې چې موږ نه یوازې د ټولو پراکسيونو څخه خلاصون ترلاسه کولی شو ، بلکه د ډیری چیکونو لپاره وقفې هم راکموو ، او پراکسي به نور د بار شریکولو لپاره د یوې لارې په توګه اړتیا ونلري.
شاوخوا درې میاشتې مخکې
جوړښت بدل کړئ - بار زیات کړئ!
MM: - ښه، میکس، ایا دا وخت دی چې ګټور شي؟ زه یو پیاوړی سرور او یو ښه انجنیر ته اړتیا لرم.
MCH: - ښه، راځئ چې دا پلان کړو. دا ډیر وخت دی چې په هره ثانیه کې د 5 زره میټریک له مړینې نقطې څخه حرکت وکړئ.
سهار له پورته کولو وروسته
MCH: - میشا، موږ خپل ځان تازه کړ، مګر سهار موږ بیرته وګرځید ... اټکل وکړئ چې موږ څومره سرعت ترلاسه کړی؟
MM: - 20 زره اعظمي.
MCH: - هو، 25! له بده مرغه، موږ سم یو چیرته چې موږ پیل کړی.
MM: - ولې؟ ایا تاسو کوم تشخیص چلولی؟
MCH: - هو، یقینا! دلته، د مثال په توګه، یو په زړه پورې سر دی:
MM: - راځئ چې وګورو. زه ګورم چې موږ د رایې ورکولو لوی شمیر هڅه کړې ده:
مګر په ورته وخت کې دوی نشي کولی سیسټم حتی نیمایي هم ریسایکل کړي:
او عمومي فعالیت خورا کوچنی دی، په هره ثانیه کې شاوخوا 4 زره میټریکونه:
بل څه شته؟
MCH: - هو، د رای ورکوونکو څخه د یوې برخې سټریس:
MM: - دلته تاسو په روښانه توګه لیدلی شئ چې د رای ورکولو پروسه "سیمفورز" ته انتظار باسي. دا قفلونه دي:
MCH: - ناڅرګنده.
MM: - وګورئ، دا د داسې وضعیت سره ورته دی چیرې چې د تارونو یوه ډله هڅه کوي د سرچینو سره کار وکړي چې یوازې یو یې په یو وخت کې کار کولی شي. بیا ټول هغه څه چې دوی کولی شي دا سرچینې د وخت په تیریدو سره شریک کړي:
او د داسې یوې سرچینې سره د کار کولو ټول فعالیت د یو اصلي سرعت لخوا محدود دی:
د دې ستونزې د حل لپاره دوه لارې شتون لري.
د ماشین هارډویر لوړ کړئ، چټک کور ته لاړ شئ:
یا جوړښت بدل کړئ او په ورته وخت کې بار بدل کړئ:
MCH: - په هرصورت ، د ازموینې ماشین کې به موږ د جنګي یو په پرتله لږ کورونه وکاروو ، مګر دوی په هر کور کې 1,5 ځله ګړندي دي!
MM: - پاکه؟ تاسو اړتیا لرئ د سرور کوډ وګورئ.
په زیبکس سرور کې د معلوماتو لاره
MCH: - د دې معلومولو لپاره، موږ تحلیل پیل کړل چې څنګه د زبیبکس سرور دننه ډاټا لیږدول کیږي:
ښه انځور، سمه ده؟ راځئ چې ګام په ګام دې ته لاړ شو ترڅو دا لږ یا لږ روښانه شي. د معلوماتو راټولولو لپاره مسؤولیتونه او خدمات شتون لري:
دوی راټول شوي میټریکونه د ساکټ له لارې د پری پروسیسر مدیر ته لیږدوي، چیرې چې دوی په کتار کې خوندي شوي:
د "پری پروسیسر مدیر" خپلو کارمندانو ته معلومات لیږدوي، کوم چې د پروسس کولو دمخه لارښوونې اجرا کوي او د ورته ساکټ له لارې بیرته راستانه کوي:
له دې وروسته، د پروسیسر مدیر دوی د تاریخ په زیرمه کې ذخیره کوي:
له هغه ځایه دوی د تاریخ ډوبونکي لخوا اخیستل کیږي، کوم چې ډیری دندې ترسره کوي: د بیلګې په توګه، د محرکونو محاسبه کول، د ارزښت زیرمه ډکول او خورا مهم، د تاریخ ذخیره کې د میټریکونو خوندي کول. په عموم کې، پروسه پیچلې او خورا مغشوش ده.
MM: - لومړی شی چې موږ ولیدل هغه دا و چې ډیری تارونه د تش په نامه "کنفیګریشن کیچ" لپاره سیالي کوي (د حافظې ساحه چیرې چې د سرور ټول تشکیلات زیرمه شوي). هغه تارونه چې د معلوماتو راټولولو مسؤلیت لري په ځانګړي توګه ډیری بلاکونه کوي:
... ځکه چې تشکیلات نه یوازې د خپلو پیرامیټونو سره میټریکونه ذخیره کوي، بلکې قطارونه هم لري چې رایه ورکوونکي د دې په اړه معلومات اخلي چې بیا څه وکړي. کله چې ډیری رایې ورکوونکي شتون ولري او یو یې ترتیب بندوي، نور یې د غوښتنو انتظار کوي:
رایه ورکوونکي باید شخړه ونه کړي
له همدې امله، لومړی کار چې موږ یې وکړ هغه دا وو چې کتار په 4 برخو وویشو او رای ورکونکو ته اجازه ورکړو چې دا قطارونه بند کړي، دا برخې په ورته وخت کې، په خوندي شرایطو کې:
دا د ترتیب کولو کیچ لپاره سیالي لرې کړه، او د رای ورکوونکو سرعت د پام وړ لوړ شو. مګر بیا موږ د دې حقیقت سره مخ شو چې د پروسیسر مدیر د دندو قطار راټولول پیل کړل:
د پروسیسر مدیر باید وړتیا ولري چې لومړیتوب ورکړي
دا په داسې قضیو کې پیښ شوي چیرې چې هغه د فعالیت نشتوالی دی. بیا ټول هغه څه کولی شي د معلوماتو راټولولو پروسو څخه غوښتنې راټولې کړي او د دوی بفر اضافه کړي تر هغه چې دا ټول حافظه مصرف کړي او خراب شي:
د دې ستونزې د حل لپاره، موږ دوهم ساکټ اضافه کړ چې په ځانګړې توګه کارګرانو ته وقف شوی و:
په دې توګه، د پروسیسر مدیر فرصت درلود چې خپل کار ته لومړیتوب ورکړي او که چیرې بفر وده وکړي، دنده د لرې کولو ورو کول دي، کارګرانو ته فرصت ورکوي چې دا بفر واخلي:
بیا موږ وموندله چې د سستۍ یو لامل پخپله کارګران وو ، ځکه چې دوی د یوې سرچینې لپاره سیالي کوله چې د دوی کار لپاره په بشپړ ډول غیر مهم و. موږ دا ستونزه د بګ فکس په توګه مستند کړې ، او دا دمخه د زبیکس په نوي نسخو کې حل شوې ده:
موږ د ساکټونو شمیر زیاتوو - موږ پایله ترلاسه کوو
سربیره پردې ، د پروسیسر مدیر پخپله یو خنډ شو ، ځکه چې دا یو تار دی. دا په اصلي سرعت کې پاتې شوی، په هر ثانیه کې د 70 زره میټریک اعظمي سرعت ورکوي:
له همدې امله، موږ څلور جوړ کړل، د څلورو ساکټونو سره، کارګران:
او دې موږ ته اجازه راکړه چې سرعت نږدې 130 زره میټریکونو ته لوړ کړو:
د ودې غیر خطيتوب د دې حقیقت له مخې تشریح شوی چې د تاریخ کیچ لپاره سیالي ښکاره شوې. 4 پری پروسیسر مدیران او د تاریخ ډوب کونکو د دې لپاره سیالي وکړه. پدې وخت کې، موږ د ازموینې ماشین کې په هره ثانیه کې نږدې 130 زره میټریکونه ترلاسه کول، دا د نږدې 95٪ پروسیسر لخوا کارول:
شاوخوا 2,5 میاشتې دمخه
د snmp-ټولنې څخه انکار NVPs یو نیم چنده زیات کړي
MM: - میکس، زه یو نوی ټیسټ موټر ته اړتیا لرم! موږ نور په اوسني کې مناسب نه یو.
MCH: - ته اوس څه لرې؟
MM: - اوس - 130k NVPs او د شیلف چمتو پروسیسر.
MCH: - وا! ارام! انتظار وکړئ، زه دوه پوښتنې لرم. زما د محاسبې له مخې، زموږ اړتیا په هره ثانیه کې شاوخوا 15-20 زره میټریک دی. موږ ولې نور ته اړتیا لرو؟
MM: "زه غواړم دا کار پای ته ورسوم." زه غواړم وګورم چې موږ څومره کولی شو له دې سیسټم څخه وباسو.
MCH: - خو…
MM: "مګر دا د سوداګرۍ لپاره بې ګټې دی."
MCH: - دا صفا ده. او دویمه پوښتنه: ایا موږ کولی شو د هغه څه ملاتړ وکړو چې اوس یې په خپله لرو، د پراختیا کونکي له مرستې پرته؟
MM: - زه فکر نه کوم. د ترتیب کولو کیچ څنګه کار کوي بدلول یوه ستونزه ده. دا په ډیری تارونو کې بدلونونه اغیزه کوي او ساتل یې خورا ستونزمن دي. ډیری احتمال، د دې ساتل به خورا ستونزمن وي.
MCH: "بیا موږ یو ډول بدیل ته اړتیا لرو."
MM: - داسې یو اختیار شتون لري. موږ کولی شو ګړندي کور ته لاړ شو ، پداسې حال کې چې د نوي تالاشۍ سیسټم پریږدو. موږ به لاهم د 60-80 زره میټریک فعالیت ترلاسه کړو. په ورته وخت کې، موږ کولی شو ټول پاتې کوډ پریږدو. کلک هاؤس او غیر متناسب رایې به کار وکړي. او ساتل به یې اسانه وي.
MCH: - حیرانونکې! زه وړاندیز کوم چې موږ دلته ودریږو.
د سرور اړخ اصلاح کولو وروسته ، موږ په پای کې وکولی شو نوی کوډ تولید ته پیل کړو. موږ د ګړندي کور سره ماشین ته د بدلولو او د کوډ بدلونونو شمیر کمولو په ګټه ځینې بدلونونه پریښودل. موږ ترتیب هم ساده کړی او د ډیټا توکو کې میکرو له مینځه وړي چیرې چې امکان ولري ، ځکه چې دوی اضافي تالاشۍ معرفي کوي.
د مثال په توګه، د snmp-ټولنې میکرو پریښودل، کوم چې ډیری وختونه په اسنادو او مثالونو کې موندل کیږي، زموږ په قضیه کې د NVPs شاوخوا 1,5 ځله ګړندی کول ممکن کړي.
په تولید کې دوه ورځې وروسته
د پیښې تاریخ پاپ اپ لرې کول
MCH: - میشا، موږ د دوو ورځو لپاره سیسټم کاروو، او هرڅه کار کوي. مګر یوازې کله چې هرڅه کار کوي! موږ د شبکې د کافي لویې برخې د لیږد سره کار پلان کړی و، او موږ بیا په خپلو لاسونو سره وګورو چې څه پورته شوي او څه ندي.
MM: - نه شي کیدای! موږ هر څه 10 ځله معاینه کړل. سرور حتی د بشپړ شبکې نشتوالی په سمدستي توګه اداره کوي.
MCH: - هو، زه په هرڅه پوهیږم: سرور، ډیټابیس، ټاپ، آسټټ، لاګز - هرڅه ګړندي دي ... مګر موږ ویب انٹرفیس ګورو، او په سرور کې یو پروسیسر "شیلف کې" شتون لري او دا:
MM: - دا صفا ده. راځئ چې ویب وګورئ. موږ وموندله چې په داسې حالت کې چیرې چې ډیری فعالې پیښې شتون لري، ډیری ژوندی ویجټونه ډیر ورو کار پیل کړی:
د دې دلیل د پیښې تاریخ پاپ اپونو نسل و چې په لیست کې د هر توکي لپاره رامینځته کیږي. له همدې امله، موږ د دې وینډوز نسل پریښود (په کوډ کې 5 لینونه تبصره کړل)، او دې زموږ ستونزې حل کړې.
د ویجټونو لپاره د بارولو وخت، حتی کله چې په بشپړه توګه شتون نلري، د څو دقیقو څخه زموږ لپاره د منلو وړ 10-15 ثانیو ته راټیټ شوی، او تاریخ لاهم د وخت په کلیک کولو سره لیدل کیدی شي:
د کار وروسته. 2 میاشتې مخکې
MCH: - میشا، ته لاړې؟ موږ باید خبرې وکړو.
MM: - ما اراده نه درلوده. د زبیبکس سره یو څه بیا؟
MCH: - نه، آرام شه! ما یوازې غوښتل ووایم: هرڅه کار کوي ، مننه! زه یو بیر لرم.
زیبکس موثر دی
زبیبکس یو کافي نړیوال او بډایه سیسټم او فعالیت دی. دا د بکس څخه بهر د کوچنیو تاسیساتو لپاره کارول کیدی شي، مګر لکه څنګه چې اړتیاوې وده کوي، دا باید غوره شي. د میټریکونو لوی آرشیف ذخیره کولو لپاره، مناسب ذخیره وکاروئ:
- تاسو کولی شئ د Elasticsearch سره د ادغام یا متن فایلونو ته د تاریخ اپلوډ کولو په شکل کې جوړ شوي وسیلې وکاروئ (د XNUMX نسخه څخه شتون لري)؛
- تاسو کولی شئ د Clickhouse سره زموږ د تجربې او ادغام څخه ګټه پورته کړئ.
د میتریکونو راټولولو سرعت په ډراماتیک ډول لوړولو لپاره، د غیر متمرکز میتودونو په کارولو سره یې راټول کړئ او د ټرپر انٹرفیس له لارې د زبکس سرور ته انتقال کړئ؛ یا تاسو کولی شئ پیچ وکاروئ ترڅو د زیبکس رای ورکونکي غیر متناسب کړي.
زبیبکس په C کې لیکل شوی او خورا اغیزمن دی. د ډیری معمارۍ خنډونو حل کول تاسو ته اجازه درکوي د دې فعالیت نور هم لوړ کړئ او زموږ په تجربه کې ، په یو واحد پروسیسر ماشین کې له 100 زرو څخه ډیر میټریکونه ترلاسه کړئ.
ورته زبیبکس پیچ
MM: - زه غواړم یو څو ټکي اضافه کړم. ټول اوسنی راپور، ټولې ازموینې، شمیرې د هغه ترتیب لپاره ورکړل شوي چې موږ یې کاروو. موږ اوس له دې څخه په هره ثانیه کې شاوخوا 20 زره میټریکونه اخلو. که تاسو هڅه کوئ چې پوه شئ چې ایا دا به ستاسو لپاره کار وکړي، تاسو پرتله کولی شئ. هغه څه چې نن ورځ بحث شوي د پیچ په بڼه په GitHub کې پوسټ شوي:
په پیچ کې شامل دي:
- د کلک هاؤس سره بشپړ ادغام (دواړه زیبکس سرور او فرنټ اینڈ)؛
- د پری پروسیسر مدیر سره د ستونزو حل کول؛
- غیر متناسب رایه اچونه.
پیچ د ټولو نسخو 4 سره مطابقت لري، په شمول د lts. ډیری احتمال، د لږو بدلونونو سره دا به په 3.4 نسخه کار وکړي.
تاسو د پاملرنې څخه مو مننه.
پوښتنې
د لیدونکو څخه پوښتنه (له دې وروسته - الف): - ماسپښین ښه! مهرباني وکړئ ما ته ووایاست، ایا تاسو د زیبکس ټیم یا د دوی سره ستاسو سره د ژور تعامل لپاره پلان لرئ، ترڅو دا پیچ نه وي، مګر د زیبکس معمول چلند دی؟
MM: - هو، موږ به خامخا یو څه بدلونونه ترسره کړو. یو څه به پیښ شي، یو څه به په پیچ کې پاتې شي.
مګر: - د غوره راپور لپاره ډیره مننه! مهرباني وکړئ ما ته ووایاست، د پیچ پلي کولو وروسته، د زیبکس څخه ملاتړ به پاتې وي او څنګه لوړو نسخو ته تازه کولو ته دوام ورکړي؟ ایا دا به ممکنه وي چې زبکس ستاسو د پیچ وروسته 4.2، 5.0 ته تازه کړئ؟
MM: - زه د ملاتړ په اړه څه نه شم ویلای. که زه د زبکس تخنیکي ملاتړ وم، زه به شاید نه وایم، ځکه چې دا د بل چا کوډ دی. لکه څنګه چې د 4.2 کوډبیس لپاره، زموږ دریځ دا دی: "موږ به د وخت سره حرکت وکړو، او موږ به په راتلونکي نسخه کې خپل ځان تازه کړو." له همدې امله ، د یو څه وخت لپاره به موږ د تازه نسخو لپاره پیچ پوسټ کړو. ما دمخه په راپور کې وویل: د نسخو سره د بدلونونو شمیر لاهم خورا کوچنی دی. زه فکر کوم چې د 3.4 څخه تر 4 پورې لیږد موږ شاوخوا 15 دقیقې وخت نیولی. هلته یو څه بدل شوی، مګر ډیر مهم ندي.
مګر: - نو تاسو پلان لرئ چې د خپل پیچ ملاتړ وکړئ او تاسو کولی شئ دا په خوندي ډول په تولید کې نصب کړئ او په راتلونکي کې په یو ډول تازه معلومات ترلاسه کړئ؟
MM: - موږ یې په کلکه وړاندیز کوو. دا زموږ لپاره ډیری ستونزې حل کوي.
MCH: - یوځل بیا ، زه غواړم دې حقیقت ته متوجه شم چې هغه بدلونونه چې جوړښت پورې اړه نلري او د بلاک کولو یا قطارونو په اړه اندیښنه نلري ماډلر دي ، دوی په جلا ماډلونو کې دي. حتی د کوچنیو بدلونونو سره تاسو کولی شئ دوی په اسانۍ سره وساتئ.
MM: - که تاسو د توضیحاتو سره علاقه لرئ ، نو "کلک هاؤس" د تاریخ په نوم یاد شوي کتابتون کاروي. دا خلاص دی - دا د Elastics ملاتړ یوه کاپي ده، دا د ترتیب وړ دی. رایه ورکول یوازې رای ورکوونکي بدلوي. موږ باور لرو چې دا به د اوږدې مودې لپاره کار وکړي.
مګر: - ډیره مننه. ما ته ووایاست، ایا د بدلونونو کوم اسناد شتون لري؟
MM: - اسناد یو پیچ دی. په ښکاره ډول، د کلک هاؤس معرفي کولو سره، د نوي ډوله رای ورکوونکو په معرفي کولو سره، د نوي ترتیب کولو اختیارونه منځته راځي. د وروستي سلایډ لینک د دې کارولو څرنګوالي لنډ توضیحات لري.
د nmap سره د fping ځای په ځای کولو په اړه
مګر: - تاسو په پای کې دا څنګه پلي کوئ؟ ایا تاسو کولی شئ ځانګړي مثالونه ورکړئ: ایا تاسو سټریپرونه او بهرنی سکریپټ لرئ؟ د دومره لوی شمیر کوربه دومره ژر چک کول څه پای ته رسوي؟ تاسو دا کوربه څنګه وینئ؟ ایا موږ اړتیا لرو چې دوی ته خواړه ورکړو چې یو څه یې nmap کړو ، له کوم ځای څخه یې راوړو ، دننه یې کړو ، یو څه چل کړو؟
MM: - ارام. ډیره سمه پوښتنه! خبره دا ده. موږ د ICMP چکونو لپاره کتابتون (ICMP ping، د Zabbix برخه) بدل کړ، کوم چې د پاکټونو شمیر په ګوته کوي - یو (1)، او کوډ د nmap کارولو هڅه کوي. یعني دا د زیبکس داخلي کار دی چې د پنګر داخلي کار ګرځیدلی دی. په دې اساس، هیڅ همغږي یا د ټریپر کارولو ته اړتیا نشته. دا په عمدي توګه ترسره شوي ترڅو سیسټم سم پریږدي او د دوه ډیټابیس سیسټمونو ترکیب سره معامله ونشي: څه شی چیک کړئ ، د رای ورکونکي له لارې اپلوډ کړئ ، او ایا زموږ اپلوډ مات شوی؟ ... دا خورا ساده دی.
مګر: - ایا دا د پراکسي لپاره هم کار کوي؟
MM: - هو، مګر موږ چک نه کړ. د رای ورکولو کوډ په زبیکس او سرور دواړو کې یو شان دی. باید کار وکړي. اجازه راکړئ یوځل بیا ټینګار وکړم: د سیسټم فعالیت داسې دی چې موږ پراکسي ته اړتیا نلرو.
MCH: - د پوښتنې سم ځواب دا دی: "ولې تاسو د داسې سیسټم سره پراکسي ته اړتیا لرئ؟" یوازې د NAT یا د یو ډول سست چینل له لارې څارنې له امله ...
مګر: - او تاسو زبیکس د الرټر په توګه کاروئ، که زه په سمه توګه پوهیږم. یا ستاسو ګرافیک (چیرې چې د آرشیف پرت دی) بل سیسټم ته لیږدول شوي، لکه ګرافانا؟ یا تاسو دا فعالیت نه کاروئ؟
MM: - زه به یو ځل بیا ټینګار وکړم: موږ بشپړ ادغام ترلاسه کړی دی. موږ تاریخ په کلک هاؤس کې اچوو، مګر په ورته وخت کې موږ د پی ایچ پی فرنټ اینډ بدل کړی. د پی ایچ پی فرنټ اینډ کلیک هاوس ته ځي او له هغه ځایه ټول ګرافیک کوي. په ورته وخت کې، د ریښتیا کیدو لپاره، موږ یوه برخه لرو چې د ورته کلیک هاوس څخه په نورو ګرافیک ډیسک سیسټمونو کې ډاټا جوړوي، د ورته زیبکس ډاټا څخه.
MCH: - په "ګرافان" کې هم.
د منابعو د تخصیص په اړه څنګه پریکړې وشوې؟
مګر: - د خپل داخلي پخلنځي لږ څه شریک کړئ. څنګه پریکړه وشوه چې دا اړینه وه چې د محصول جدي پروسس لپاره سرچینې تخصیص شي؟ دا، په عمومي توګه، ځینې خطرونه دي. او مهرباني وکړئ ما ته ووایاست ، د دې حقیقت په شرایطو کې چې تاسو د نوي نسخو ملاتړ کوئ: دا پریکړه څنګه د مدیریت له نظره توجیه کوي؟
MM: - په ښکاره ډول، موږ د تاریخ ډرامه ښه نه ویلې. موږ ځان په داسې حالت کې وموند چې یو څه باید ترسره شي، او موږ په اصل کې د دوو موازي ټیمونو سره لاړو:
- یو یې د نوي میتودونو په کارولو سره د څارنې سیسټم پیل کړ: د خدمت په توګه څارنه، د خلاصې سرچینې حلونو معیاري سیټ چې موږ یې یوځای کوو او بیا د نوي څارنې سیسټم سره کار کولو لپاره د سوداګرۍ پروسې بدلولو هڅه کوو.
- په ورته وخت کې، موږ یو لیوالتیا پروګرامر درلود چې دا کار کوي (د ځان په اړه). داسې وشول چې هغه وګټله.
مګر: - او د ټیم اندازه څومره ده؟
MCH: - هغه ستاسو په مخ کې ده.
مګر: - نو، د تل په څیر، تاسو لیوالتیا ته اړتیا لرئ؟
MM: - زه نه پوهیږم چې لیوالتیا څه ده.
مګر: - په دې حالت کې، ظاهرا، تاسو. ډیره مننه، تاسو په زړه پوری یاست.
MM: - له تاسو مننه.
د زبیبکس لپاره د پیچونو په اړه
مګر: - د یو سیسټم لپاره چې پراکسي کاروي (د بیلګې په توګه، په ځینو ویشل شوي سیسټمونو کې)، ایا دا ممکنه ده چې پخپله د زبیکس پروسس کونکي، پراکسي او په جزوي توګه د پروسیسر تطبیق او پیچ کړئ؛ او د هغوی تعامل؟ ایا دا ممکنه ده چې د ډیری پراکسي سره د سیسټم لپاره موجوده پرمختګونه اصلاح کړئ؟
MM: - زه پوهیږم چې د زیبکس سرور د پراکسي په کارولو سره راټول شوی (کوډ ترتیب شوی او ترلاسه شوی). موږ دا په تولید کې نه ده ازمولې. زه پدې اړه ډاډه نه یم، مګر زه فکر کوم چې د پروسیسر مدیر په پراکسي کې نه کارول کیږي. د پراکسي دنده دا ده چې د زبکس څخه د میټریکونو سیټ واخلي، دوی سره یوځای کړي (دا ترتیب، محلي ډیټابیس هم ثبتوي) او بیرته یې د زیبکس سرور ته ورکړي. سرور به بیا پخپله پری پروسس کوي کله چې دا ترلاسه کړي.
د پراکسي سره علاقه د پوهیدو وړ ده. موږ به یې وګورو. دا یوه په زړه پورې موضوع ده.
مګر: - نظر دا و: که تاسو رایې ورکوونکي پیچ کولی شئ، تاسو کولی شئ دوی په پراکسي کې پیچ کړئ او د سرور سره تعامل پیچ کړئ، او یوازې په سرور کې د دې موخو لپاره پری پروسیسر تطبیق کړئ.
MM: - زه فکر کوم چې دا نور هم ساده دی. تاسو کوډ واخلئ، پیچ پلي کړئ، بیا یې هغه طریقه تنظیم کړئ چې تاسو ورته اړتیا لرئ - پراکسي سرورونه راټول کړئ (د مثال په توګه، د ODBC سره) او په سیسټمونو کې پیچ شوي کوډ وویشئ. که اړتیا وي - یو پراکسي راټول کړئ، چیرته چې اړتیا وي - یو سرور.
مګر: - ډیری احتمال ، تاسو اړتیا نلرئ سرور ته د پراکسي لیږد اضافه کړئ؟
MCH: - نه، دا معیاري ده.
MM: - په حقیقت کې، یو له نظرونو څخه غږ نه و. موږ تل د نظرونو د چاودنې او د بدلونونو مقدار او د مرستې اسانتیا تر مینځ توازن ساتلی دی.
ځینې اعلانونه 🙂
له موږ سره د پاتې کیدو لپاره مننه. ایا تاسو زموږ مقالې خوښوي؟ غواړئ نور په زړه پورې مینځپانګه وګورئ؟ د امر په ورکولو یا ملګرو ته وړاندیز کولو سره زموږ ملاتړ وکړئ ، , د ننوتلو کچې سرورونو یو ځانګړی انلاګ ، کوم چې زموږ لخوا ستاسو لپاره اختراع شوی و: (د RAID1 او RAID10 سره شتون لري، تر 24 کور پورې او تر 40GB DDR4 پورې).
ډیل R730xd په امستردام کې د Equinix Tier IV ډیټا مرکز کې 2 ځله ارزانه؟ یوازې دلته په هالنډ کې! ډیل R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - له $ 99 څخه! په اړه ولولئ
سرچینه: www.habr.com