HighLoad++، میخائیل ماکوروف، ماکسیم چرنتسوف (Intersvyaz): Zabbix، 100kNVPS در یک سرور

کنفرانس بعدی HighLoad++ در تاریخ 6 و 7 آوریل 2020 در سن پترزبورگ برگزار می شود. جزئیات و بلیط ها по ссылке. HighLoad++ Moscow 2018. سالن “مسکو”. 9 نوامبر، 15:00. پایان نامه ها و ارائه.

* نظارت - آنلاین و تجزیه و تحلیل.
* محدودیت های اساسی پلت فرم ZABBIX.
* راه حلی برای مقیاس بندی ذخیره سازی تجزیه و تحلیل.
* بهینه سازی سرور ZABBIX.
* بهینه سازی رابط کاربری
* کارکرد سیستم را تحت بارهای بیش از 40 هزار NVPS تجربه کنید.
* نتیجه گیری مختصر

میخائیل ماکوروف (از این پس - MM): - سلام به همه!

ماکسیم چرنتسوف (از این پس - MCH): - عصر بخیر!

MM: - اجازه بدهید ماکسیم را معرفی کنم. مکس یک مهندس با استعداد است، بهترین نتورکری که من می شناسم. ماکسیم در شبکه ها و خدمات، توسعه و عملیات آنها درگیر است.

MCH: - و من می خواهم در مورد میخائیل به شما بگویم. Mikhail یک توسعه دهنده C است. او چندین راه حل پردازش ترافیک پر بار برای شرکت ما نوشت. ما در اورال، در شهر مردان سرسخت چلیابینسک، در شرکت Intersvyaz زندگی و کار می کنیم. شرکت ما ارائه دهنده خدمات اینترنت و تلویزیون کابلی برای یک میلیون نفر در 16 شهر است.

MM: - و شایان ذکر است که Intersvyaz بسیار بیشتر از یک ارائه دهنده است، بلکه یک شرکت فناوری اطلاعات است. اکثر راه حل های ما توسط بخش فناوری اطلاعات ما ساخته شده است.

پاسخ: از سرورهایی که ترافیک را پردازش می کنند تا مرکز تماس و برنامه تلفن همراه. بخش فناوری اطلاعات اکنون حدود 80 نفر با شایستگی های بسیار بسیار متنوع دارد.

درباره Zabbix و معماری آن

MCH: - و اکنون سعی می کنم یک رکورد شخصی ایجاد کنم و در یک دقیقه بگویم Zabbix چیست (از این پس "Zabbix" نامیده می شود).

Zabbix خود را به عنوان یک سیستم نظارتی خارج از جعبه در سطح سازمانی قرار می دهد. دارای ویژگی‌های زیادی است که زندگی را آسان‌تر می‌کند: قوانین تشدید پیشرفته، API برای یکپارچه‌سازی، گروه‌بندی و تشخیص خودکار میزبان‌ها و معیارها. Zabbix به اصطلاح ابزارهای مقیاس بندی - پراکسی ها را دارد. Zabbix یک سیستم متن باز است.

مختصری در مورد معماری می توان گفت که از سه جزء تشکیل شده است:

• سرور. نوشته شده در C. با پردازش و انتقال اطلاعات نسبتاً پیچیده بین رشته ها. تمام پردازش ها در آن انجام می شود: از دریافت تا ذخیره به پایگاه داده.
• تمام داده ها در پایگاه داده ذخیره می شوند. Zabbix از MySQL، PostreSQL و Oracle پشتیبانی می کند.
• رابط وب به زبان PHP نوشته شده است. در اکثر سیستم ها با یک سرور آپاچی ارائه می شود، اما در ترکیب با nginx + php کارآمدتر کار می کند.

امروز می خواهیم یک داستان از زندگی شرکت خود در رابطه با Zabbix بگوییم ...

داستانی از زندگی شرکت Intersvyaz. چه داریم و به چه چیزهایی نیاز داریم؟

5 یا 6 ماه پیش یک روز بعد از کار...

MCH: - میشا، سلام! خوشحالم که توانستم شما را دستگیر کنم - یک مکالمه وجود دارد. باز هم با نظارت مشکل داشتیم. در یک تصادف بزرگ، همه چیز کند بود و هیچ اطلاعاتی در مورد وضعیت شبکه وجود نداشت. متأسفانه این اولین بار نیست که این اتفاق می افتد. من به کمک شما نیاز دارم. بیایید نظارت خود را تحت هر شرایطی کار کنیم!

MM: - اما بیایید اول همگام سازی کنیم. من چند سال است که آنجا را نگاه نکرده ام. تا آنجا که من به یاد دارم، ما Nagios را رها کردیم و حدود 8 سال پیش به Zabbix تغییر مکان دادیم. و اکنون به نظر می رسد که ما 6 سرور قدرتمند و حدود یک دوجین پروکسی داریم. آیا من چیزی را گیج می کنم؟

MCH: - تقریبا. 15 سرور که برخی از آنها ماشین های مجازی هستند. مهمترین چیز این است که ما را در لحظه ای که بیشتر به آن نیاز داریم نجات نمی دهد. مانند یک تصادف - سرورها کند می شوند و شما نمی توانید چیزی را ببینید. ما سعی کردیم پیکربندی را بهینه کنیم، اما این افزایش عملکرد بهینه را فراهم نکرد.

MM: - واضح است. آیا به چیزی نگاه کردید، آیا قبلاً چیزی را از دستگاه تشخیص کشف کرده اید؟

MCH: – اولین چیزی که باید با آن سر و کار داشته باشید پایگاه داده است. MySQL دائماً بارگذاری می شود و معیارهای جدیدی را ذخیره می کند و هنگامی که Zabbix شروع به تولید مجموعه ای از رویدادها می کند، پایگاه داده به معنای واقعی کلمه برای چند ساعت به overdrive می شود. قبلاً در مورد بهینه سازی پیکربندی به شما گفته بودم، اما به معنای واقعی کلمه امسال آنها سخت افزار را به روز کردند: سرورها بیش از صد گیگابایت حافظه و آرایه دیسک در RAID های SSD دارند - رشد خطی آن در دراز مدت هیچ فایده ای ندارد. چه کنیم؟

MM: - واضح است. به طور کلی MySQL یک پایگاه داده LTP است. ظاهراً دیگر برای ذخیره آرشیو معیارهای اندازه ما مناسب نیست. بیایید آن را بفهمیم.

MCH: - بیا!

ادغام Zabbix و Clickhouse در نتیجه هکاتون

پس از مدتی اطلاعات جالبی دریافت کردیم:

بیشتر فضای پایگاه داده ما توسط آرشیو متریک اشغال شده بود و کمتر از 1٪ برای پیکربندی، قالب ها و تنظیمات استفاده شده است. در آن زمان، بیش از یک سال بود که راه حل Big data را بر اساس Clickhouse اجرا می کردیم. جهت حرکت برای ما مشخص بود. در هکاتون بهاری ما، من ادغام Zabbix با Clickhouse را برای سرور و فرانت اند نوشتم. در آن زمان، Zabbix قبلاً از ElasticSearch پشتیبانی داشت و ما تصمیم گرفتیم آنها را با هم مقایسه کنیم.

مقایسه Clickhouse و Elasticsearch

MM: - برای مقایسه، ما همان باری را ایجاد کردیم که سرور Zabbix ارائه می‌کند و نحوه رفتار سیستم‌ها را بررسی کردیم. ما داده ها را در دسته های 1000 خطی با استفاده از CURL نوشتیم. ما قبلاً فرض می‌کردیم که Clickhouse برای نمایه بارگذاری که Zabbix انجام می‌دهد کارآمدتر خواهد بود. نتایج حتی از انتظارات ما هم فراتر رفت:

تحت شرایط آزمایشی مشابه، کلیک هاوس سه برابر بیشتر داده نوشت. در همان زمان، هر دو سیستم به طور بسیار کارآمد (مقدار کمی از منابع) هنگام خواندن داده ها مصرف می کردند. اما Elastics هنگام ضبط به مقدار زیادی پردازنده نیاز داشت:

در مجموع کلیک هاوس از نظر مصرف پردازنده و سرعت به طور قابل توجهی نسبت به الستیکس برتری داشت. در همان زمان، به دلیل فشرده سازی داده ها، Clickhouse 11 برابر کمتر از هارد دیسک استفاده می کند و تقریباً 30 برابر کمتر عملیات دیسک را انجام می دهد:

MCH: – بله، کار Clickhouse با زیرسیستم دیسک بسیار کارآمد پیاده سازی شده است. شما می توانید از دیسک های بزرگ SATA برای پایگاه های داده استفاده کنید و سرعت نوشتن صدها هزار خط در ثانیه داشته باشید. سیستم خارج از جعبه از اشتراک گذاری، تکثیر پشتیبانی می کند و پیکربندی آن بسیار آسان است. ما از استفاده از آن در طول سال راضی هستیم.

برای بهینه سازی منابع، می توانید Clickhouse را در کنار پایگاه داده اصلی موجود خود نصب کنید و در نتیجه در زمان CPU و عملیات دیسک بسیار صرفه جویی کنید. ما آرشیو معیارها را به خوشه های کلیک هاوس موجود منتقل کرده ایم:

ما پایگاه داده اصلی MySQL را آنقدر راحت کردیم که توانستیم آن را در یک ماشین با سرور Zabbix ترکیب کنیم و سرور اختصاصی MySQL را رها کنیم.

نظرسنجی در Zabbix چگونه کار می کند؟

4 ماه پیش

MM: - خوب، آیا می توانیم مشکلات پایه را فراموش کنیم؟

MCH: - مطمئنا همینطوره! مشکل دیگری که باید حل کنیم کندی جمع آوری داده ها است. اکنون تمام 15 سرور پراکسی ما با SNMP و فرآیندهای نظرسنجی بارگیری شده اند. و راهی جز نصب سرورهای جدید و جدید وجود ندارد.

MM: - عالی. اما ابتدا به ما بگویید که نظرسنجی در Zabbix چگونه کار می کند؟

MCH: - به طور خلاصه، 20 نوع معیار و ده ها راه برای به دست آوردن آنها وجود دارد. Zabbix می تواند داده ها را در حالت "درخواست پاسخ" جمع آوری کند یا از طریق "Trapper Interface" منتظر داده های جدید باشد.

شایان ذکر است که در Zabbix اصلی این روش (Trapper) سریعترین است.

سرورهای پروکسی برای توزیع بار وجود دارد:

پراکسی‌ها می‌توانند همان عملکردهای مجموعه را مانند سرور Zabbix انجام دهند، وظایفی را از آن دریافت کنند و معیارهای جمع‌آوری‌شده را از طریق رابط Trapper ارسال کنند. این روش رسمی توصیه شده برای توزیع بار است. پراکسی ها همچنین برای نظارت بر زیرساخت های راه دور که از طریق NAT یا یک کانال کند کار می کنند مفید هستند:

MM: - همه چیز با معماری روشن است. باید به منابع نگاه کنیم...

یکی دو روز بعد

داستان چگونه fping nmap برنده شد

MM: "فکر می کنم چیزی کشف کردم."

MCH: - به من بگو!

MM: - متوجه شدم که هنگام بررسی در دسترس بودن، Zabbix حداکثر 128 هاست را در یک زمان بررسی می کند. من سعی کردم این عدد را به 500 برسانم و فاصله بین بسته ها را در پینگ آنها حذف کنم - این کار را دو برابر کرد. اما من اعداد بزرگتر می خواهم.

MCH: - در تمرین من، گاهی اوقات باید در دسترس بودن هزاران هاست را بررسی کنم و هرگز چیزی سریعتر از nmap برای این کار ندیده ام. مطمئنم این سریع ترین راه است. بیایید آن را امتحان کنیم! ما باید تعداد میزبان ها را در هر تکرار به میزان قابل توجهی افزایش دهیم.

MM: – چک بیش از پانصد؟ 600؟

MCH: - حداقل دو هزار.

MM: - خوب. مهمترین چیزی که می خواستم بگویم این است که متوجه شدم اکثر نظرسنجی ها در Zabbix به صورت همزمان انجام می شود. حتما باید آن را به حالت ناهمزمان تغییر دهیم. سپس می‌توانیم تعداد معیارهای جمع‌آوری‌شده توسط نظرسنجی‌ها را به‌طور چشمگیری افزایش دهیم، به خصوص اگر تعداد معیارها را در هر تکرار افزایش دهیم.

MCH: - عالی! و وقتی که؟

MM: - طبق معمول دیروز.

MCH: - ما هر دو نسخه fping و nmap را با هم مقایسه کردیم:

در تعداد زیادی از میزبان ها، انتظار می رفت nmap تا پنج برابر موثرتر باشد. از آنجایی که nmap فقط در دسترس بودن و زمان پاسخ را بررسی می‌کند، ما محاسبه تلفات را به محرک‌ها منتقل کردیم و فواصل بررسی دسترس‌پذیری را به میزان قابل توجهی کاهش دادیم. ما تعداد بهینه میزبان برای nmap را حدود 4 هزار در هر تکرار یافتیم. Nmap به ما این امکان را می‌دهد که هزینه بررسی‌های موجود بودن CPU را سه برابر کاهش دهیم و فاصله زمانی را از 120 ثانیه به 10 کاهش دهیم.

بهینه سازی نظرسنجی

MM: سپس شروع به انجام نظرسنجی کردیم. ما عمدتاً به شناسایی SNMP و عوامل علاقه مند بودیم. در Zabbix نظرسنجی به صورت همزمان انجام می شود و اقدامات ویژه ای برای افزایش کارایی سیستم انجام شده است. در حالت سنکرون، در دسترس نبودن هاست باعث تخریب قابل توجه نظرسنجی می شود. یک سیستم کامل از ایالات وجود دارد، فرآیندهای خاصی وجود دارد - به اصطلاح نظرسنجی های غیرقابل دسترس، که فقط با میزبان های غیرقابل دسترسی کار می کنند:

این تفسیری است که ماتریس حالت را نشان می‌دهد، تمام پیچیدگی سیستم انتقال‌هایی که برای مؤثر ماندن سیستم مورد نیاز است. علاوه بر این، نظرسنجی همزمان خود بسیار کند است:

به همین دلیل است که هزاران جریان نظرسنجی روی ده ها پروکسی نتوانستند مقدار مورد نیاز داده را برای ما جمع آوری کنند. اجرای ناهمزمان نه تنها مشکلات تعداد رشته ها را حل کرد، بلکه سیستم حالت میزبان های غیرقابل دسترس را نیز به طور قابل توجهی ساده کرد، زیرا برای هر عددی که در یک تکرار نظرسنجی بررسی می شود، حداکثر زمان انتظار 1 تایم اوت بود:

علاوه بر این، سیستم نظرسنجی را برای درخواست‌های SNMP اصلاح و بهبود دادیم. واقعیت این است که اکثر مردم نمی توانند به چندین درخواست SNMP به طور همزمان پاسخ دهند. بنابراین، زمانی که نظرسنجی SNMP از همان میزبان به صورت ناهمزمان انجام می شود، یک حالت ترکیبی ایجاد کردیم:

این کار برای کل پک هاست انجام می شود. این حالت در نهایت کندتر از یک حالت کاملا ناهمزمان نیست، زیرا نظرسنجی یک و نیم صد مقدار SNMP هنوز بسیار سریعتر از 1 تایم اوت است.

آزمایش‌های ما نشان داده است که تعداد بهینه درخواست‌ها در یک تکرار تقریباً 8 هزار با نظرسنجی SNMP است. در مجموع، انتقال به حالت ناهمزمان به ما اجازه داد تا عملکرد نظرسنجی را 200 برابر، چند صد برابر افزایش دهیم.

MCH: - بهینه‌سازی‌های نظرسنجی حاصل نشان داد که ما نه تنها می‌توانیم از شر همه پراکسی‌ها خلاص شویم، بلکه فواصل بررسی‌ها را کاهش می‌دهیم و دیگر به پراکسی‌ها به عنوان راهی برای اشتراک‌گذاری بار نیازی نیست.

حدود سه ماه پیش

تغییر معماری - افزایش بار!

MM: - خوب، مکس، آیا زمان آن رسیده است که بازدهی داشته باشی؟ به یک سرور قدرتمند و یک مهندس خوب نیاز دارم.

MCH: - باشه، بیا برنامه ریزی کنیم. زمان آن فرا رسیده است که از نقطه مرگ 5 هزار متریک در ثانیه حرکت کنیم.

صبح بعد از ارتقا

MCH: - میشا، ما خودمان را به روز کردیم، اما تا صبح به عقب برگشتیم ... حدس بزنید به چه سرعتی رسیدیم؟

MM: – حداکثر 20 هزار

MCH: - آره، 25! متأسفانه ما در همان جایی هستیم که شروع کردیم.

MM: - چرا؟ آیا هیچ تشخیصی انجام دادید؟

MCH: - بله حتما! برای مثال، در اینجا یک تاپ جالب وجود دارد:

MM: - بیا تماشا کنیم من می بینم که ما تعداد زیادی از رشته های نظرسنجی را امتحان کرده ایم:

اما در عین حال آنها نتوانستند سیستم را حتی به نصف بازیافت کنند:

و عملکرد کلی بسیار کوچک است، حدود 4 هزار متریک در ثانیه:

چیز دیگری هست؟

MCH: - بله، خط یکی از نظرسنجی ها:

MM: - در اینجا به وضوح می توانید ببینید که روند رای گیری در انتظار "سمافورها" است. این قفل ها هستند:

MCH: - غیر واضح.

MM: - نگاه کنید، این شبیه وضعیتی است که در آن دسته ای از موضوعات سعی می کنند با منابعی کار کنند که فقط یک نفر می تواند در یک زمان با آنها کار کند. سپس تنها کاری که می توانند انجام دهند این است که این منبع را در طول زمان به اشتراک بگذارند:

و کل عملکرد کار با چنین منبعی با سرعت یک هسته محدود می شود:

دو راه برای حل این مشکل وجود دارد.

سخت افزار دستگاه را ارتقا دهید، به هسته های سریعتر بروید:

یا تغییر معماری و در همان زمان تغییر بار:

MCH: - به هر حال، در دستگاه آزمایش، ما از هسته های کمتری نسبت به جنگنده استفاده خواهیم کرد، اما آنها از نظر فرکانس در هر هسته 1,5 برابر سریعتر هستند!

MM: -روشن؟ شما باید به کد سرور نگاه کنید.

مسیر داده در سرور Zabbix

MCH: - برای فهمیدن آن، ما شروع به تجزیه و تحلیل نحوه انتقال داده ها در سرور Zabbix کردیم:

عکس باحالی، درسته؟ بیایید قدم به قدم آن را مرور کنیم تا کم و بیش روشن شود. موضوعات و سرویس هایی مسئول جمع آوری داده ها هستند:

آنها معیارهای جمع آوری شده را از طریق یک سوکت به مدیر Preprocessor منتقل می کنند، جایی که در یک صف ذخیره می شوند:

"مدیر پیش پردازنده" داده ها را به کارگران خود منتقل می کند، آنها دستورالعمل های پیش پردازش را اجرا می کنند و آنها را از طریق همان سوکت باز می گرداند:

پس از این، مدیر پیش پردازنده آنها را در حافظه پنهان تاریخ ذخیره می کند:

از آنجا توسط سینکرهای تاریخ گرفته می شوند، که عملکردهای بسیار زیادی را انجام می دهند: به عنوان مثال، محاسبه تریگرها، پر کردن حافظه پنهان مقدار و مهمتر از همه، ذخیره معیارها در ذخیره سازی تاریخچه. به طور کلی، فرآیند پیچیده و بسیار گیج کننده است.

MM: - اولین چیزی که دیدیم این بود که بیشتر رشته ها برای به اصطلاح "کش پیکربندی" (منطقه حافظه که در آن تمام تنظیمات سرور ذخیره می شود) رقابت می کنند. موضوعاتی که مسئولیت جمع آوری داده ها را بر عهده دارند، به ویژه بسیاری از موارد را مسدود می کنند:

... از آنجایی که پیکربندی نه تنها معیارها را با پارامترهای آنها ذخیره می کند، بلکه صف هایی را نیز ذخیره می کند که نظرسنجی ها از آنها اطلاعاتی در مورد کارهای بعدی دریافت می کنند. هنگامی که نظرسنجی های زیادی وجود دارد و یکی پیکربندی را مسدود می کند، بقیه منتظر درخواست ها هستند:

نظرسنجی ها نباید تعارض داشته باشند

بنابراین، اولین کاری که انجام دادیم این بود که صف را به 4 قسمت تقسیم کردیم و به نظرسنجی‌ها اجازه دادیم که این صف‌ها، این قسمت‌ها را همزمان، در شرایط امن مسدود کنند:

این امر رقابت را برای کش پیکربندی حذف کرد و سرعت نظرسنجی ها به طور قابل توجهی افزایش یافت. اما سپس با این واقعیت مواجه شدیم که مدیر پیش پردازشگر شروع به جمع آوری یک صف از مشاغل کرد:

مدیر پیش پردازنده باید بتواند اولویت بندی کند

این در مواردی اتفاق افتاد که او عملکرد نداشت. سپس تنها کاری که او می‌توانست انجام دهد این بود که درخواست‌ها را از فرآیندهای جمع‌آوری داده جمع‌آوری کند و بافر آنها را جمع کند تا زمانی که تمام حافظه را مصرف کند و از کار بیفتد:

برای حل این مشکل، یک سوکت دوم را اضافه کردیم که به طور خاص به کارگران اختصاص داده شده بود:

بنابراین، مدیر پیش پردازشگر این فرصت را داشت که کار خود را اولویت بندی کند و اگر بافر رشد کند، وظیفه کاهش سرعت حذف است و به کارگران این فرصت را می دهد که از این بافر استفاده کنند:

سپس متوجه شدیم که یکی از دلایل کاهش سرعت خود کارگران بودند، زیرا آنها برای منبعی رقابت می کردند که برای کارشان کاملاً بی اهمیت بود. ما این مشکل را به عنوان یک رفع اشکال ثبت کردیم و قبلاً در نسخه های جدید Zabbix حل شده است:

ما تعداد سوکت ها را افزایش می دهیم - نتیجه را می گیریم

علاوه بر این، مدیر پیش پردازنده خود به یک گلوگاه تبدیل شد، زیرا یک رشته است. این بر روی سرعت هسته استوار است و حداکثر سرعتی در حدود 70 هزار متریک در ثانیه دارد:

بنابراین، ما چهار کارگر، با چهار مجموعه سوکت، ساختیم:

و این به ما امکان داد تا سرعت را به حدود 130 هزار متریک افزایش دهیم:

غیر خطی بودن رشد با این واقعیت توضیح داده می شود که رقابت برای حافظه پنهان تاریخ ظاهر شده است. 4 مدیر پیش پردازشگر و سینکر تاریخ برای آن به رقابت پرداختند. در این مرحله، ما تقریباً 130 هزار متریک در ثانیه را در دستگاه آزمایش دریافت می‌کردیم که تقریباً 95 درصد پردازنده از آن استفاده می‌کرد:

حدود 2,5 ماه پیش

امتناع از snmp-community NVP ها را یک و نیم برابر افزایش داد

MM: - مکس، من به یک ماشین آزمایشی جدید نیاز دارم! ما دیگر در شرایط فعلی نمی گنجیم.

MCH: - الان چه داری؟

MM: – اکنون – 130 هزار NVP و یک پردازنده آماده برای قفسه.

MCH: - وای! سرد! صبر کن دو تا سوال دارم طبق محاسبات من، نیاز ما حدود 15-20 هزار متریک در ثانیه است. چرا بیشتر نیاز داریم؟

MM: "من می خواهم کار را تمام کنم." من می خواهم ببینم چقدر می توانیم از این سیستم بیرون بیاییم.

MCH: - ولی…

MM: "اما برای تجارت بی فایده است."

MCH: - واضح است. و سوال دوم: آیا ما می توانیم آنچه را که اکنون در اختیار داریم به تنهایی و بدون کمک توسعه دهنده پشتیبانی کنیم؟

MM: - فکر نمی کنم. تغییر نحوه عملکرد کش پیکربندی یک مشکل است. این تغییرات در بیشتر رشته ها را تحت تأثیر قرار می دهد و نگهداری آن بسیار دشوار است. به احتمال زیاد، حفظ آن بسیار دشوار خواهد بود.

MCH: "پس ما به نوعی جایگزین نیاز داریم."

MM: - چنین گزینه ای وجود دارد. ما می‌توانیم به هسته‌های سریع سوئیچ کنیم، در حالی که سیستم قفل جدید را کنار می‌گذاریم. ما همچنان عملکرد 60-80 هزار متریک خواهیم داشت. در همان زمان، ما می توانیم بقیه کد را ترک کنیم. کلیک هاوس و نظرسنجی ناهمزمان کار خواهند کرد. و نگهداری از آن آسان خواهد بود.

MCH: - حیرت آور! پیشنهاد می کنم اینجا توقف کنیم.

پس از بهینه سازی سمت سرور، بالاخره توانستیم کد جدید را وارد مرحله تولید کنیم. ما برخی از تغییرات را به نفع تغییر به ماشینی با هسته های سریع و به حداقل رساندن تعداد تغییرات کد کنار گذاشتیم. ما همچنین پیکربندی را ساده کرده‌ایم و ماکروها را در موارد داده حذف کرده‌ایم، زیرا قفل اضافی را معرفی می‌کنند.

به عنوان مثال، کنار گذاشتن ماکرو snmp-community، که اغلب در اسناد و نمونه‌ها یافت می‌شود، در مورد ما، سرعت بیشتر NVP‌ها را تا حدود 1,5 برابر ممکن کرد.

پس از دو روز تولید

حذف پاپ آپ های تاریخچه حوادث

MCH: - میشا، ما دو روز است که از سیستم استفاده می کنیم و همه چیز کار می کند. اما فقط زمانی که همه چیز کار می کند! ما برای انتقال بخش نسبتاً بزرگی از شبکه برنامه ریزی کرده بودیم و دوباره با دست بررسی کردیم که چه چیزی بالا رفت و چه چیزی نشد.

MM: - نمیشه! ما همه چیز را 10 بار بررسی کردیم. سرور حتی عدم دسترسی کامل به شبکه را فوراً کنترل می کند.

MCH: - بله، من همه چیز را می فهمم: سرور، پایگاه داده، بالا، austat، لاگ - همه چیز سریع است ... اما ما به رابط وب نگاه می کنیم و یک پردازنده "در قفسه" روی سرور وجود دارد و این:

MM: - واضح است. بیایید وب را تماشا کنیم. ما متوجه شدیم که در شرایطی که تعداد زیادی رویداد فعال وجود داشت، اکثر ویجت‌های زنده بسیار کند شروع به کار کردند:

دلیل این امر تولید پاپ‌آپ‌های تاریخچه حوادث بود که برای هر آیتم در لیست ایجاد می‌شود. بنابراین، ما نسل این ویندوزها را رها کردیم (5 خط در کد نظر داده شد) و این مشکلات ما را حل کرد.

زمان بارگذاری ویجت‌ها، حتی زمانی که کاملاً در دسترس نیستند، از چند دقیقه به 10-15 ثانیه قابل قبول برای ما کاهش یافته است و تاریخچه همچنان با کلیک روی زمان قابل مشاهده است:

بعد از کار. 2 ماه پیش

MCH: -میشا داری میری؟ ما باید حرف بزنیم.

MM: -من قصد نداشتم دوباره چیزی با Zabbix؟

MCH: - نه، راحت باش! فقط می خواستم بگویم: همه چیز کار می کند، متشکرم! من یک آبجو دارم.

Zabbix کارآمد است

Zabbix یک سیستم و عملکرد نسبتاً جهانی و غنی است. می توان از آن برای نصب های کوچک خارج از جعبه استفاده کرد، اما با افزایش نیازها، باید بهینه شود. برای ذخیره یک آرشیو بزرگ از معیارها، از یک فضای ذخیره سازی مناسب استفاده کنید:

• می توانید از ابزارهای داخلی به شکل ادغام با Elasticsearch یا آپلود تاریخچه در فایل های متنی (موجود از نسخه XNUMX) استفاده کنید.
• شما می توانید از تجربه و ادغام ما با کلیک هاوس استفاده کنید.

برای افزایش چشمگیر سرعت جمع‌آوری معیارها، آنها را با استفاده از روش‌های ناهمزمان جمع‌آوری کنید و از طریق رابط Trapper به سرور Zabbix انتقال دهید. یا می توانید از یک پچ برای ناهمزمان کردن نظرسنجی Zabbix استفاده کنید.

Zabbix به زبان C نوشته شده است و بسیار کارآمد است. حل چندین گلوگاه معماری به شما این امکان را می دهد که عملکرد آن را بیشتر افزایش دهید و طبق تجربه ما، بیش از 100 هزار معیار را در یک ماشین تک پردازنده به دست آورید.

همون پچ Zabbix

MM: - من می خواهم چند نکته را اضافه کنم. کل گزارش فعلی، همه آزمایش‌ها، اعداد برای پیکربندی که استفاده می‌کنیم داده شده است. ما اکنون تقریباً 20 هزار متریک در ثانیه از آن می گیریم. اگر می خواهید بفهمید که آیا این برای شما مفید است یا خیر، می توانید مقایسه کنید. آنچه امروز مورد بحث قرار گرفت در GitHub در قالب یک پچ ارسال شده است: github.com/miklert/zabbix

پچ شامل:

• ادغام کامل با Clickhouse (هم سرور Zabbix و هم Frontend)؛
• حل مشکلات با مدیر پیش پردازنده؛
• نظرسنجی ناهمزمان

این پچ با تمامی نسخه های 4 از جمله lts سازگار است. به احتمال زیاد با کمترین تغییرات روی نسخه 3.4 کار خواهد کرد.

با تشکر از توجه شما.

پرسش

سوال حضار (از این پس – الف): – ظهر بخیر! لطفا به من بگویید، آیا برنامه ای برای تعامل فشرده با تیم زبیکس دارید یا با آنها با شما، تا این یک وصله نباشد، بلکه رفتار عادی زبیکس باشد؟

MM: - بله، ما قطعاً برخی از تغییرات را انجام خواهیم داد. اتفاقی خواهد افتاد، چیزی در پچ باقی خواهد ماند.

پاسخ: - خیلی ممنون از گزارش عالی! لطفا به من بگویید، پس از اعمال پچ، پشتیبانی از Zabbix باقی می ماند و چگونه می توان به نسخه های بالاتر به روز رسانی را ادامه داد؟ آیا امکان آپدیت Zabbix بعد از پچ شما به 4.2، 5.0 وجود خواهد داشت؟

MM: - در مورد حمایت نمی توانم چیزی بگویم. اگر من جای پشتیبانی فنی Zabbix بودم، احتمالاً نه می گفتم، زیرا این کد شخص دیگری است. در مورد پایگاه کد 4.2، موضع ما این است: "ما با زمان حرکت خواهیم کرد و خود را در نسخه بعدی به روز خواهیم کرد." بنابراین، برای مدتی ما یک پچ برای نسخه های به روز ارسال خواهیم کرد. قبلاً در گزارش گفتم: تعداد تغییرات با نسخه ها هنوز بسیار کم است. من فکر می کنم انتقال از 3.4 به 4 حدود 15 دقیقه طول کشید. چیزی در آنجا تغییر کرد، اما خیلی مهم نیست.

پاسخ: – پس قصد دارید پچ خود را پشتیبانی کنید و می توانید با خیال راحت آن را در مرحله تولید نصب کنید و در آینده به نوعی به روز رسانی ها را دریافت کنید؟

MM: - ما به شدت آن را توصیه می کنیم. این خیلی از مشکلات ما را حل می کند.

MCH: - یک بار دیگر توجه را به این نکته جلب می کنم که تغییراتی که به معماری مربوط نمی شود و مربوط به بلوک یا صف نیست، ماژولار هستند و در ماژول های جداگانه هستند. حتی با تغییرات جزئی می توانید آنها را به راحتی حفظ کنید.

MM: - اگر به جزئیات علاقه دارید، "Clickhouse" از کتابخانه به اصطلاح تاریخ استفاده می کند. باز شده است - یک کپی از پشتیبانی Elastics است، یعنی قابل تنظیم است. نظرسنجی فقط نظرسنجی ها را تغییر می دهد. ما معتقدیم که این برای مدت طولانی کار خواهد کرد.

پاسخ: - خیلی ممنون. به من بگویید، آیا اسنادی از تغییرات ایجاد شده وجود دارد؟

MM: - مستندات یک پچ است. بدیهی است که با معرفی کلیک هاوس، با معرفی انواع جدید نظرسنجی، گزینه های پیکربندی جدیدی به وجود می آید. پیوند اسلاید آخر توضیح کوتاهی در مورد نحوه استفاده از آن دارد.

در مورد جایگزینی fping با nmap

پاسخ: - بالاخره چطور این را اجرا کردید؟ آیا می‌توانید مثال‌های خاصی بزنید: آیا تسمه‌دهنده و اسکریپت خارجی دارید؟ چه چیزی در نهایت به این سرعت تعداد زیادی از میزبان ها را بررسی می کند؟ چگونه این هاست ها را استخراج می کنید؟ آیا باید آنها را تغذیه کنیم تا به نحوی nmap داشته باشیم، آنها را از جایی بگیریم، بگذاریم، چیزی اجرا کنیم؟..

MM: - سرد. یک سوال بسیار درست! نکته این است. ما کتابخانه (پینگ ICMP، بخشی از Zabbix) را برای بررسی های ICMP، که تعداد بسته ها را نشان می دهد - یک (1) تغییر دادیم، و کد سعی می کند از nmap استفاده کند. یعنی این کار داخلی زبیکس است که تبدیل به کار داخلی پینگر شده است. بر این اساس، هیچ هماهنگی یا استفاده از یک تله مورد نیاز نیست. این به عمد انجام شد تا سیستم دست نخورده باقی بماند و مجبور نباشیم با همگام سازی دو سیستم پایگاه داده سر و کار داشته باشیم: چه چیزی را بررسی کنیم، از طریق نظرسنجی آپلود کنیم، و آیا آپلود ما خراب است؟.. این بسیار ساده تر است.

پاسخ: - آیا برای پروکسی ها هم کار می کند؟

MM: - بله، اما ما بررسی نکردیم. کد نظرسنجی هم در Zabbix و هم در سرور یکسان است. باید کار کند. اجازه دهید یک بار دیگر تاکید کنم: عملکرد سیستم به گونه ای است که نیازی به پروکسی نداریم.

MCH: - پاسخ صحیح به این سوال این است: "چرا با چنین سیستمی به پروکسی نیاز دارید؟" فقط به دلیل NAT یا نظارت از طریق نوعی کانال کند ...

پاسخ: - و اگر درست متوجه شده باشم از Zabbix به عنوان هشدار دهنده استفاده می کنید. یا گرافیک شما (جایی که لایه بایگانی است) به سیستم دیگری مانند Grafana منتقل شده است؟ یا از این قابلیت استفاده نمی کنید؟

MM: - بار دیگر تاکید می کنم: ما به یکپارچگی کامل دست یافته ایم. ما در حال ریختن تاریخ به کلیک‌هاوس هستیم، اما در عین حال پیش‌انداخت php را تغییر داده‌ایم. صفحه اصلی Php به Clickhouse می رود و تمام گرافیک ها را از آنجا انجام می دهد. در عین حال، صادقانه بگویم، ما بخشی داریم که داده‌ها را در سیستم‌های نمایش گرافیکی دیگر از همان Clickhouse، از همان داده‌های Zabbix می‌سازد.

MCH: – در «گرافان» نیز.

تصمیمات در مورد تخصیص منابع چگونه گرفته شد؟

پاسخ: - کمی از آشپزخانه داخلی خود را به اشتراک بگذارید. چگونه تصمیم گرفته شد که برای فرآوری جدی محصول، منابع تخصیص داده شود؟ اینها به طور کلی خطرات خاصی هستند. و لطفاً با توجه به اینکه قصد دارید از نسخه های جدید پشتیبانی کنید به من بگویید: این تصمیم از نظر مدیریت چگونه توجیه می کند؟

MM: - ظاهراً ما درام تاریخ را خیلی خوب تعریف نکردیم. ما در موقعیتی قرار گرفتیم که باید کاری انجام می شد و اساساً با دو تیم موازی رفتیم:

• یکی راه‌اندازی یک سیستم نظارتی با استفاده از روش‌های جدید بود: نظارت به عنوان یک سرویس، مجموعه استانداردی از راه‌حل‌های منبع باز که ترکیب می‌کنیم و سپس سعی می‌کنیم فرآیند کسب‌وکار را تغییر دهیم تا با سیستم نظارتی جدید کار کنیم.
• در همان زمان، ما یک برنامه نویس مشتاق داشتیم که این کار را (در مورد خودش) انجام می داد. اتفاقاً او برنده شد.

پاسخ: - و اندازه تیم چقدر است؟

MCH: - او پیش شماست.

پاسخ: - پس مثل همیشه به یک پرشور نیاز دارید؟

MM: - من نمی دانم یک پرشور چیست.

پاسخ: - در این مورد، ظاهراً شما. خیلی ممنون، شما عالی هستید.

MM: - با تشکر.

درباره وصله های Zabbix

پاسخ: - برای سیستمی که از پراکسی ها استفاده می کند (مثلاً در برخی از سیستم های توزیع شده)، آیا می توان مثلاً pollers، proxies و تا حدی پیش پردازنده خود Zabbix را تطبیق و وصله کرد. و تعامل آنها؟ آیا می توان پیشرفت های موجود را برای سیستمی با چندین پروکسی بهینه کرد؟

MM: – می دانم که سرور Zabbix با استفاده از یک پروکسی مونتاژ می شود (کد کامپایل و بدست می آید). ما این را در تولید آزمایش نکرده ایم. من در مورد این مطمئن نیستم، اما فکر می کنم مدیر پیش پردازنده در پروکسی استفاده نشده است. وظیفه پروکسی گرفتن مجموعه ای از معیارها از Zabbix، ادغام آنها (همچنین پیکربندی، پایگاه داده محلی) و بازگرداندن آن به سرور Zabbix است. خود سرور پس از دریافت آن، پیش پردازش را انجام می دهد.

علاقه به پروکسی ها قابل درک است. ما آن را بررسی می کنیم. این موضوع جالبی است.

پاسخ: - ایده این بود: اگر می‌توانید نظرسنجی‌ها را وصله کنید، می‌توانید آن‌ها را روی پراکسی وصله کنید و تعامل با سرور را وصله کنید و پیش‌پردازنده را برای این اهداف فقط روی سرور تطبیق دهید.

MM: - فکر می کنم حتی ساده تر است. شما کد را می گیرید، یک وصله اعمال می کنید، سپس آن را به روشی که نیاز دارید پیکربندی می کنید - سرورهای پراکسی را جمع آوری می کنید (مثلاً با ODBC) و کد وصله شده را در بین سیستم ها توزیع می کنید. در صورت لزوم - یک پروکسی جمع آوری کنید، در صورت لزوم - یک سرور.

پاسخ: - به احتمال زیاد، شما مجبور نخواهید بود که انتقال پروکسی را به سرور اضافه کنید؟

MCH: - نه، استاندارد است.

MM: - در واقع، یکی از ایده ها صدا نداشت. ما همیشه تعادل بین انفجار ایده ها و میزان تغییرات و سهولت پشتیبانی را حفظ کرده ایم.

چند تبلیغ 🙂

از اینکه با ما ماندید متشکرم آیا مقالات ما را دوست دارید؟ آیا می خواهید مطالب جالب تری ببینید؟ با ثبت سفارش یا معرفی به دوستان از ما حمایت کنید ابر VPS برای توسعه دهندگان از 4.99 دلار, یک آنالوگ منحصر به فرد از سرورهای سطح ورودی که توسط ما برای شما اختراع شده است: تمام حقیقت در مورد VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps از 19 دلار یا چگونه سرور را به اشتراک بگذاریم؟ (در دسترس با RAID1 و RAID10، حداکثر 24 هسته و حداکثر 40 گیگابایت DDR4).

Dell R730xd 2 برابر ارزان تر در مرکز داده Equinix Tier IV در آمستردام؟ فقط اینجا 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV از 199 دلار در هلند! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - از 99 دلار! در مورد بخوانید نحوه ساخت شرکت زیرساخت کلاس با استفاده از سرورهای Dell R730xd E5-2650 v4 به ارزش 9000 یورو برای یک پنی؟

منبع: www.habr.com