نام من آنتون بادرین است. من در مرکز فناوری عالی کار می کنم و مدیریت سیستم را انجام می دهم. یک ماه پیش، کنفرانس شرکتی ما به پایان رسید، جایی که ما تجربه انباشته شده خود را با جامعه فناوری اطلاعات شهرمان به اشتراک گذاشتیم. من در مورد نظارت بر برنامه های کاربردی وب صحبت کردم. این متریال برای سطح متوسط یا متوسط در نظر گرفته شده بود که این فرآیند را از ابتدا نساخته بودند.
سنگ بنای هر سیستم نظارتی حل مشکلات تجاری است. نظارت به خاطر نظارت برای کسی جالب نیست. کسب و کار چه می خواهد؟ به طوری که همه چیز به سرعت و بدون خطا کار می کند. کسب‌وکارها می‌خواهند فعال باشند، به طوری که ما خودمان مشکلات موجود در سرویس را شناسایی کرده و در اسرع وقت آنها را برطرف کنیم. اینها در واقع مشکلاتی هستند که من تمام سال گذشته در پروژه ای برای یکی از مشتریانمان حل کردم.
проекте О
این پروژه یکی از بزرگترین برنامه های وفاداری در کشور است. ما به زنجیره‌های خرده‌فروشی کمک می‌کنیم تا دفعات فروش را از طریق ابزارهای بازاریابی مختلف مانند کارت‌های جایزه افزایش دهند. در مجموع، این پروژه شامل 14 برنامه کاربردی است که بر روی ده سرور اجرا می شوند.
در طول فرآیند مصاحبه، بارها متوجه شدم که مدیران همیشه به درستی به نظارت بر برنامه‌های کاربردی وب نمی‌پردازند: بسیاری هنوز بر معیارهای سیستم عامل تمرکز می‌کنند و گهگاه خدمات را نظارت می‌کنند.
در مورد من، سیستم نظارت مشتری قبلاً مبتنی بر Icinga بود. به هیچ وجه مشکلات فوق را حل نکرد. اغلب خود مشتری ما را در مورد مشکلات آگاه می کرد و اغلب ما به سادگی اطلاعات کافی برای رسیدن به ته دلیل را نداشتیم.
علاوه بر این، درک روشنی از بیهودگی توسعه بیشتر آن وجود داشت. فکر می کنم کسانی که با Icinga آشنا هستند مرا درک کنند. بنابراین، تصمیم گرفتیم که سیستم نظارت بر برنامه های تحت وب را برای پروژه به طور کامل بازطراحی کنیم.
تیتان فرزند پاپتوس
ما پرومتئوس را بر اساس سه شاخص اصلی انتخاب کردیم:
- تعداد زیادی از معیارهای موجود. در مورد ما 60 هزار نفر از آنها وجود دارد. البته شایان ذکر است که ما از اکثریت قریب به اتفاق آنها (احتمالاً حدود 95٪) استفاده نمی کنیم. از طرف دیگر، همه آنها نسبتاً ارزان هستند. برای ما، این افراط دیگر در مقایسه با Icinga که قبلاً استفاده شده بود است. در آن، افزودن معیارها دردسر خاصی داشت: موارد موجود گران بودند (فقط به کد منبع هر افزونه نگاه کنید). هر افزونه ای یک اسکریپت در Bash یا Python بود که راه اندازی آن از نظر منابع مصرفی گران است.
- این سیستم مقدار نسبتا کمی از منابع را مصرف می کند. 600 مگابایت رم، 15 درصد یک هسته و دوجین IOPS برای همه معیارهای ما کافی است. البته، شما باید صادرکننده های متریک را اجرا کنید، اما همه آنها در Go نوشته شده اند و همچنین انرژی زیادی ندارند. من فکر نمی کنم که در واقعیت های مدرن این یک مشکل باشد.
- امکان مهاجرت به Kubernetes را فراهم می کند. با در نظر گرفتن برنامه های مشتری، انتخاب بدیهی است.
ELK
قبلا، ما گزارش‌ها را جمع‌آوری یا پردازش نمی‌کردیم. کاستی ها برای همه روشن است. ما ELK را انتخاب کردیم زیرا قبلاً با این سیستم تجربه داشتیم. ما فقط گزارش های برنامه را در آنجا ذخیره می کنیم. معیار اصلی انتخاب جستجوی متن کامل و سرعت آن بود.
Сlickhouse
در ابتدا، انتخاب بر روی InfluxDB افتاد. ما نیاز به جمع‌آوری گزارش‌های Nginx، آمار از pg_stat_statements و ذخیره داده‌های تاریخی Prometheus را دریافتیم. ما Influx را دوست نداشتیم زیرا به طور دوره ای مقدار زیادی از حافظه را مصرف می کند و از کار می افتد. علاوه بر این، من می خواستم پرس و جوها را با remote_addr گروه بندی کنم، اما گروه بندی در این DBMS فقط توسط برچسب ها انجام می شود. برچسب ها گران هستند (حافظه)، تعداد آنها به صورت مشروط محدود است.
جستجوی خود را دوباره شروع کردیم. آنچه مورد نیاز بود یک پایگاه داده تحلیلی با حداقل مصرف منابع بود، ترجیحا با فشرده سازی داده ها روی دیسک.
کلیک هاوس تمام این معیارها را دارد و ما هرگز از انتخاب خود پشیمان نشده ایم. ما هیچ مقدار فوق العاده ای از داده را در آن نمی نویسیم (تعداد درج ها فقط حدود پنج هزار در دقیقه است).
NewRelic
NewRelic از لحاظ تاریخی با ما بوده است زیرا انتخاب مشتری بوده است. ما از آن به عنوان APM استفاده می کنیم.
Zabbix
ما از Zabbix به طور انحصاری برای نظارت بر جعبه سیاه API های مختلف استفاده می کنیم.
تعریف رویکرد نظارتی
ما می خواستیم کار را تجزیه کنیم و از این طریق رویکرد نظارت را سیستماتیک کنیم.
برای انجام این کار، سیستم خود را به سطوح زیر تقسیم کردم:
- سخت افزار و VMS؛
- سیستم عامل؛
- خدمات سیستم، پشته نرم افزار؛
- کاربرد؛
- منطق تجارت.
چرا این رویکرد راحت است:
- ما می دانیم که چه کسی مسئول کار هر سطح است و بر این اساس می توانیم هشدار ارسال کنیم.
- ما می‌توانیم از ساختار هنگام سرکوب هشدارها استفاده کنیم - ارسال یک هشدار در مورد در دسترس نبودن پایگاه داده زمانی که ماشین مجازی به طور کلی در دسترس نیست، عجیب است.
از آنجایی که وظیفه ما شناسایی تخلفات در عملکرد سیستم است، باید در هر سطح مجموعه خاصی از معیارها را برجسته کنیم که ارزش توجه به آنها هنگام نوشتن قوانین هشدار را دارد. در مرحله بعد، اجازه دهید سطوح "VMS"، "سیستم عامل" و "سرویس های سیستم، پشته نرم افزار" را مرور کنیم.
ماشین های مجازی
هاست به ما یک پردازنده، دیسک، حافظه و شبکه اختصاص می دهد. و با دو مورد اول مشکل داشتیم. بنابراین، معیارها:
زمان دزدیده شده CPU - وقتی یک ماشین مجازی در آمازون خریداری می کنید (به عنوان مثال t2.micro)، باید درک کنید که یک هسته پردازشگر کامل به شما اختصاص داده نمی شود، بلکه فقط یک سهمیه از زمان آن به شما اختصاص می یابد. و هنگامی که آن را به پایان رساندید، پردازنده از شما گرفته می شود.
این معیار به شما امکان می دهد چنین لحظاتی را ردیابی کنید و تصمیم بگیرید. به عنوان مثال، آیا لازم است تعرفه‌ای سنگین‌تر گرفته شود یا پردازش وظایف پس‌زمینه و درخواست‌های API در سرورهای مختلف توزیع شود؟
زمان انتظار IOPS + CPU - به دلایلی، بسیاری از هاست های ابری با ارائه نکردن IOPS کافی گناه می کنند. علاوه بر این، یک برنامه با IOPS پایین برای آنها استدلال نمی کند. بنابراین، ارزش جمع آوری CPU iowait را دارد. با این جفت نمودار - با IOPS کم و انتظار I/O زیاد - می توانید از قبل با میزبان صحبت کرده و مشکل را حل کنید.
سیستم عامل
معیارهای سیستم عامل:
- مقدار حافظه موجود بر حسب درصد؛
- فعالیت استفاده swap: vmstat swapin, swapout;
- تعداد اینودهای موجود و فضای خالی در سیستم فایل به درصد
- بار متوسط؛
- تعداد اتصالات در دو حالت؛
- کنتراک پر بودن جدول;
- کیفیت شبکه را می توان با استفاده از ابزار ss، بسته iproute2 کنترل کرد - نشانگر اتصالات RTT را از خروجی آن دریافت کنید و آن را بر اساس پورت مقصد گروه بندی کنید.
همچنین در سطح سیستم عامل، ما چنین موجودی را به عنوان فرآیندها داریم. مهم است که در سیستم مجموعه ای از فرآیندها را شناسایی کنید که نقش مهمی در عملکرد آن دارند. اگر مثلاً چندین pgpool دارید، باید برای هر یک از آنها اطلاعات جمع آوری کنید.
مجموعه معیارها به شرح زیر است:
- پردازنده
- حافظه در درجه اول ساکن است.
- IO - ترجیحاً در IOPS؛
- FileFd - باز کردن و محدود کردن.
- شکست های قابل توجه صفحه - از این طریق می توانید بفهمید که چه فرآیندی در حال تعویض است.
ما تمام نظارت ها را در Docker مستقر می کنیم و از Advisor برای جمع آوری داده های متریک استفاده می کنیم. در سایر ماشین‌ها از صادرکننده فرآیند استفاده می‌کنیم.
خدمات سیستم، پشته نرم افزار
هر برنامه ویژگی های خاص خود را دارد و تشخیص مجموعه خاصی از معیارها دشوار است.
مجموعه جهانی عبارت است از:
- نرخ درخواست؛
- تعداد اشتباهات؛
- تاخیر؛
- اشباع
برجسته ترین نمونه های ما از نظارت در این سطح Nginx و PostgreSQL هستند.
بیشترین بارگذاری سرویس در سیستم ما پایگاه داده است. در گذشته، ما اغلب در فهمیدن اینکه پایگاه داده چه کاری انجام می دهد، مشکل داشتیم.
ما شاهد بار زیاد روی دیسک‌ها بودیم، اما لاگ‌های کند واقعاً چیزی را نشان نمی‌داد. ما این مشکل را با استفاده از pg_stat_statements، نمایی که آمار پرس و جو را جمع آوری می کند، حل کردیم.
این تمام چیزی است که مدیر نیاز دارد.
ما نمودارهایی از فعالیت درخواست های خواندن و نوشتن می سازیم:
همه چیز ساده و واضح است، هر درخواست رنگ خاص خود را دارد.
یک مثال به همان اندازه قابل توجه، لاگ های Nginx است. تعجب آور نیست که افراد کمی آنها را تجزیه می کنند یا در لیست موارد ضروری ذکر می کنند. قالب استاندارد چندان آموزنده نیست و نیاز به گسترش دارد.
من شخصا درخواست_time، upstream_response_time، body_bytes_sent، request_length، request_id را اضافه کردم. زمان پاسخ و تعداد خطاها را رسم می کنیم:
ما نمودارهای زمان پاسخ و تعداد خطاها را می سازیم. یاد آوردن؟ آیا در مورد اهداف تجاری صحبت کردم؟ به سرعت و بدون خطا؟ قبلاً با دو نمودار به این موضوعات پرداخته ایم. و شما می توانید با استفاده از آنها با مدیران کشیک تماس بگیرید.
اما یک مشکل دیگر باقی می ماند - برای اطمینان از حذف سریع علل حادثه.
حل و فصل حادثه
کل فرآیند از شناسایی تا حل یک مشکل را می توان به چند مرحله تقسیم کرد:
- شناسایی مشکل؛
- اطلاع رسانی به مدیر وظیفه؛
- پاسخ به یک حادثه؛
- از بین بردن علل
مهم این است که ما باید این کار را در اسرع وقت انجام دهیم. و اگر در مراحل شناسایی مشکل و ارسال اعلان نتوانیم زمان زیادی به دست آوریم - در هر صورت دو دقیقه برای آنها صرف می شود، در این صورت موارد بعدی به سادگی زمینی برای بهبود هستند.
بیایید تصور کنیم که تلفن افسر وظیفه زنگ خورد. او چه خواهد کرد؟ به دنبال پاسخ سوالات باشید - چه چیزی شکست، کجا شکست، چگونه واکنش نشان دهید؟ در اینجا نحوه پاسخ به این سؤالات آمده است:
ما به سادگی تمام این اطلاعات را در متن اعلان قرار می دهیم، به آن پیوندی به یک صفحه ویکی می دهیم که نحوه پاسخ به این مشکل، نحوه حل آن و تشدید آن را توضیح می دهد.
من هنوز چیزی در مورد لایه برنامه و منطق تجاری نگفته ام. متأسفانه، برنامه های ما هنوز مجموعه معیارها را پیاده سازی نکرده اند. تنها منبع هر گونه اطلاعات از این سطوح، لاگ ها هستند.
یکی دو نکته.
ابتدا لاگ های ساخت یافته بنویسید. نیازی به درج متن در متن پیام نیست. این امر گروه بندی و تجزیه و تحلیل آنها را دشوار می کند. Logstash طول می کشد تا همه اینها را عادی کند.
ثانیاً از سطوح شدت به درستی استفاده کنید. هر زبان استاندارد خاص خود را دارد. من شخصاً چهار سطح را تشخیص می دهم:
- بدون خطا؛
- خطای سمت مشتری؛
- اشتباه با ماست، ما پول را از دست نمی دهیم، ریسک نمی کنیم.
- اشتباه با ماست، ما پول را از دست می دهیم.
بگذارید خلاصه کنم. شما باید سعی کنید نظارت را بر اساس منطق تجاری ایجاد کنید. سعی کنید خود برنامه را زیر نظر داشته باشید و با معیارهایی مانند تعداد فروش، تعداد ثبت نام کاربران جدید، تعداد کاربران فعال فعلی و غیره کار کنید.
اگر کل کسب و کار شما یک دکمه در مرورگر است، باید نظارت داشته باشید که آیا کلیک می کند و به درستی کار می کند یا خیر. بقیه چیزها مهم نیست.
اگر این را ندارید، می‌توانید مانند ما، سعی کنید آن را در گزارش‌های برنامه، گزارش‌های Nginx و غیره دنبال کنید. شما باید تا حد امکان به برنامه نزدیک باشید.
معیارهای سیستم عامل البته مهم هستند، اما تجارت به آنها علاقه ندارد، ما برای آنها پولی دریافت نمی کنیم.
منبع: www.habr.com