آیا نظارت مرده است؟ - زنده باد نظارت

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

من معتقدم در سازماندهی یک سیستم نظارتی مناسب مشکل وجود دارد. اگر مشکلی وجود نداشت، سخنرانی من شامل یک پایان نامه بود: "لطفاً Prometheus + Grafana و پلاگین های 1، 2، 3 را نصب کنید." متاسفانه دیگه اینطوری کار نمیکنه و مشکل اصلی این است که همه همچنان به چیزی که در سال 2008 وجود داشت، از نظر اجزای نرم افزاری، اعتقاد دارند.

در مورد سازماندهی سیستم نظارت، جرأت می کنم بگویم که ... پروژه هایی با نظارت صالح وجود ندارد. و وضعیت به قدری بد است که اگر چیزی سقوط کند، این خطر وجود دارد که مورد توجه قرار نگیرد - از این گذشته، همه مطمئن هستند که "همه چیز تحت نظر است."
شاید همه چیز تحت نظر باشد. اما چگونه؟

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

خوب. ما به روش قدیمی نظارت می کنیم. و در حال حاضر در حال تغییر است و معلوم می شود که شما سرویس A را زیر نظر گرفته اید که تبدیل به سرویس B شده است که با سرویس C تعامل دارد. اما تیم توسعه به شما می گوید: "نرم افزار را نصب کنید، باید همه چیز را نظارت کند!"

پس چه چیزی تغییر کرده است؟ - همه چیز عوض شده!

2008 همه چیز خوب است

چند توسعه دهنده، یک سرور، یک سرور پایگاه داده وجود دارد. همه چیز از اینجا می رود. ما اطلاعاتی داریم، zabbix، Nagios، cacti را نصب می کنیم. و سپس هشدارهای واضحی را بر روی CPU، عملکرد دیسک و فضای دیسک تنظیم می کنیم. ما همچنین چند بررسی دستی انجام می دهیم تا مطمئن شویم که سایت پاسخ می دهد و سفارشات به پایگاه داده می رسد. و بس - ما کم و بیش محافظت می‌شویم.

اگر میزان کاری را که مدیر در آن زمان برای ارائه نظارت انجام داده است مقایسه کنیم، 98٪ از آن به صورت خودکار بوده است: شخصی که نظارت را انجام می دهد باید نحوه نصب Zabbix، نحوه پیکربندی آن و پیکربندی هشدارها را بداند. و 2% - برای بررسی های خارجی: اینکه سایت پاسخ دهد و درخواستی را به پایگاه داده بدهد که سفارشات جدید رسیده است.

2010 بار در حال افزایش است

ما شروع به گسترش وب، اضافه کردن یک موتور جستجو می کنیم. ما می خواهیم مطمئن شویم که کاتالوگ محصولات شامل همه محصولات است. و آن جستجوی محصول کار می کند. اینکه پایگاه داده کار می‌کند، سفارش‌ها انجام می‌شود، سایت به صورت خارجی پاسخ می‌دهد و از دو سرور پاسخ می‌دهد و کاربر از سایت بیرون نمی‌رود در حالی که به سرور دیگری متعادل می‌شود و غیره. موجودیت های بیشتری وجود دارد.

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

اما در همان زمان، کار روی انجام بررسی‌های خارجی، ایجاد مجموعه‌ای از اسکریپت‌های جستجوی نمایه‌گر جستجو، مجموعه‌ای از اسکریپت‌ها برای بررسی اینکه آیا جستجو در طول فرآیند نمایه‌سازی تغییر می‌کند، مجموعه‌ای از اسکریپت‌ها که بررسی می‌کنند کالاها به خدمات تحویل و غیره و غیره

توجه: من "مجموعه ای از فیلمنامه ها" را 3 بار نوشتم. یعنی مسئول نظارت دیگر کسی نیست که به سادگی zabbix را نصب کند. این شخصی است که شروع به کدنویسی می کند. اما هنوز چیزی در ذهن تیم تغییر نکرده است.

اما جهان در حال تغییر است و پیچیده تر و پیچیده تر می شود. یک لایه مجازی سازی و چندین سیستم جدید اضافه شده است. آنها شروع به تعامل با یکدیگر می کنند. چه کسی گفته است "بوی میکروسرویس می آید؟" اما هر سرویس به طور جداگانه مانند یک وب سایت به نظر می رسد. می توانیم به آن روی بیاوریم و بفهمیم که اطلاعات لازم را ارائه می دهد و به تنهایی کار می کند. و اگر مدیری هستید که دائماً درگیر پروژه ای هستید که به مدت 5-7-10 سال در حال توسعه بوده است، این دانش جمع می شود: یک سطح جدید ظاهر می شود - شما آن را متوجه شدید، سطح دیگری ظاهر می شود - شما آن را متوجه شدید ...

اما به ندرت کسی یک پروژه را برای 10 سال همراهی می کند.

رزومه مانیتورینگمن

فرض کنید به یک استارت‌آپ جدید رسیدید که بلافاصله 20 توسعه‌دهنده را استخدام کرد، 15 میکروسرویس نوشت و شما یک مدیر هستید که به او گفته می‌شود: «CI/CD بسازید. لطفا." شما CI/CD ساخته‌اید و ناگهان می‌شنوید: «برای ما سخت است که با تولید در یک «مکعب» کار کنیم، بدون اینکه بفهمیم برنامه چگونه در آن کار می‌کند. برای ما یک جعبه شنی در همان "مکعب" درست کنید.
شما در این مکعب یک جعبه شنی درست می کنید. آنها بلافاصله به شما می گویند: "ما یک پایگاه داده مرحله ای می خواهیم که هر روز از زمان تولید به روز شود، به طوری که بفهمیم که روی پایگاه داده کار می کند، اما در عین حال پایگاه داده تولید را خراب نمی کند."

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

و همکاران من طرح معمول را از سر خود بیرون می آورند و می گویند: "خب، اینجا همه چیز روشن است! برنامه ای نصب کنید که همه اینها را نظارت کند.» بله، بله: Prometheus + Grafana + افزونه ها.
و آنها اضافه می کنند: "دو هفته فرصت دارید، مطمئن شوید که همه چیز امن است."

در خیلی از پروژه هایی که می بینیم یک نفر برای نظارت اختصاص داده می شود. تصور کنید بخواهیم یک نفر را برای 2 هفته مانیتورینگ استخدام کنیم و برایش رزومه بنویسیم. با توجه به همه چیزهایی که تا به حال گفتیم این فرد باید چه مهارت هایی داشته باشد؟

• او باید نظارت و ویژگی های عملکرد زیرساخت های آهنی را درک کند.
• او باید ویژگی های نظارت بر Kubernetes را درک کند (و همه می خواهند به "مکعب" بروند، زیرا می توانید از همه چیز انتزاع کنید، پنهان کنید، زیرا مدیر با بقیه کار خواهد کرد) - خود، زیرساخت آن، و نحوه نظارت بر برنامه ها را درک کند. داخل.
• او باید درک کند که خدمات به روش‌های خاصی با یکدیگر ارتباط برقرار می‌کنند و ویژگی‌های نحوه تعامل سرویس‌ها با یکدیگر را بداند. کاملاً امکان پذیر است که پروژه ای را ببینید که در آن برخی از سرویس ها به طور همزمان با هم ارتباط برقرار می کنند، زیرا راه دیگری وجود ندارد. به عنوان مثال، backend از طریق REST، از طریق gRPC به سرویس کاتالوگ می رود، لیستی از محصولات را دریافت می کند و آن را برمی گرداند. شما نمی توانید اینجا صبر کنید. و با سایر خدمات به صورت ناهمزمان کار می کند. انتقال سفارش به سرویس تحویل، ارسال نامه و غیره.
  احتمالاً قبلاً از این همه شنا شنا کرده اید؟ و ادمین که باید این را نظارت کند، گیج تر شد.
• او باید بتواند به درستی برنامه ریزی و برنامه ریزی کند - همانطور که کار بیشتر و بیشتر می شود.
• بنابراین او باید یک استراتژی از سرویس ایجاد شده ایجاد کند تا بفهمد چگونه به طور خاص آن را نظارت کند. او نیاز به درک معماری پروژه و توسعه آن + درک فناوری های مورد استفاده در توسعه دارد.

بیایید یک مورد کاملاً عادی را به خاطر بسپاریم: برخی از سرویس ها در PHP هستند، برخی از سرویس ها در Go هستند، برخی از سرویس ها در JS هستند. آنها به نوعی با یکدیگر کار می کنند. این همان جایی است که اصطلاح "microservice" از اینجا می آید: سیستم های منفرد زیادی وجود دارد که توسعه دهندگان نمی توانند پروژه را به عنوان یک کل درک کنند. بخشی از تیم سرویس هایی را در JS می نویسند که به تنهایی کار می کنند و نمی دانند بقیه سیستم چگونه کار می کند. بخش دیگر سرویس‌ها را در پایتون می‌نویسد و در نحوه عملکرد سایر سرویس‌ها دخالت نمی‌کند؛ آنها در منطقه خودشان جدا هستند. مورد سوم نوشتن خدمات به زبان PHP یا چیز دیگری است.
همه این 20 نفر به 15 سرویس تقسیم می شوند و فقط یک ادمین وجود دارد که باید همه اینها را درک کند. متوقف کردن! ما فقط سیستم را به 15 میکروسرویس تقسیم کردیم زیرا 20 نفر نمی توانند کل سیستم را درک کنند.

ولی یه جورایی باید نظارت بشه...

نتیجه چیست؟ در نتیجه، یک نفر وجود دارد که همه چیزهایی را که کل تیم توسعه دهندگان نمی توانند درک کنند، ارائه می دهد، و در عین حال او نیز باید بداند و بتواند آنچه را که در بالا ذکر کردیم - زیرساخت سخت افزاری، زیرساخت Kubernetes و غیره را انجام دهد.

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

نظارت بر یک پروژه نرم افزاری مدرن به خودی خود یک پروژه نرم افزاری است

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

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

و اگر در مرحله‌ای که زمان کوتاهی تا انتشار باقی مانده است، این را به ادمین و توسعه‌دهندگان نیز بدهید، شخص باید کل این پروتکل را درک کند. آن ها پروژه ای در این مقیاس زمان قابل توجهی را می طلبد و این باید در توسعه سیستم لحاظ شود.
اما خیلی وقت ها به خصوص در استارتاپ ها شاهد هستیم که چگونه نظارت به بعد موکول می شود. "اکنون ما یک Proof of Concept درست می کنیم، با آن راه اندازی می کنیم، اجازه می دهیم سقوط کند - ما آماده قربانی هستیم. و سپس ما همه چیز را زیر نظر خواهیم گرفت.» وقتی (یا اگر) پروژه شروع به کسب درآمد کرد، کسب و کار می خواهد ویژگی های بیشتری را اضافه کند - زیرا شروع به کار کرده است، بنابراین باید بیشتر گسترش یابد! و شما در نقطه ای هستید که ابتدا باید همه چیزهای قبلی را زیر نظر داشته باشید، که نه 1٪ از زمان، بلکه خیلی بیشتر طول می کشد. و به هر حال، توسعه دهندگان برای نظارت مورد نیاز خواهند بود، و راحت تر است که به آنها اجازه دهید روی ویژگی های جدید کار کنند. در نتیجه، ویژگی های جدید نوشته می شود، همه چیز خراب می شود و شما در یک بن بست بی پایان قرار می گیرید.

بنابراین چگونه می توان یک پروژه را از ابتدا نظارت کرد، و اگر پروژه ای دریافت کردید که نیاز به نظارت دارد، اما نمی دانید از کجا شروع کنید، چه کاری باید انجام دهید؟

ابتدا باید برنامه ریزی کنید.

انحراف غزلی: اغلب آنها با نظارت بر زیرساخت شروع می شوند. به عنوان مثال، ما Kubernetes را داریم. بیایید با نصب Prometheus با Grafana، نصب افزونه هایی برای نظارت بر "مکعب" شروع کنیم. نه تنها توسعه دهندگان، بلکه مدیران نیز این روش تاسف بار را دارند: "ما این افزونه را نصب خواهیم کرد، اما افزونه احتمالاً می داند چگونه این کار را انجام دهد." مردم دوست دارند با کارهای ساده و سرراست شروع کنند تا با کارهای مهم. و نظارت بر زیرساخت آسان است.

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

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

1. من معتقدم که باید نظارت را دقیقاً از نقطه ورود کاربر شروع کنید. اگر کاربر نمی بیند که برنامه کار می کند، همین است، این یک شکست است. و سیستم نظارت باید ابتدا در این مورد هشدار دهد.
2. و تنها در این صورت است که می توانیم زیرساخت ها را نظارت کنیم. یا به صورت موازی انجام دهید. با زیرساخت آسان تر است - در اینجا ما در نهایت می توانیم zabbix را نصب کنیم.
3. و اکنون باید به ریشه های برنامه بروید تا بفهمید کجا کار نمی کند.

ایده اصلی من این است که نظارت باید موازی با روند توسعه باشد. اگر حواس تیم نظارت را برای کارهای دیگر (ایجاد CI/CD، sandboxing، سازماندهی مجدد زیرساخت) منحرف کنید، نظارت شروع به تاخیر می کند و ممکن است هرگز به پیشرفت نرسید (یا دیر یا زود مجبور خواهید بود آن را متوقف کنید).

همه چیز بر اساس سطوح

من سازماندهی یک سیستم نظارتی را اینگونه می بینم.

1) سطح برنامه:

• نظارت بر منطق تجاری برنامه؛
• نظارت بر معیارهای سلامت خدمات؛
• نظارت بر ادغام

2) سطح زیرساخت:

• نظارت بر سطح ارکستراسیون؛
• نظارت بر نرم افزار سیستم؛
• نظارت بر سطح آهن

3) دوباره سطح کاربرد - اما به عنوان یک محصول مهندسی:

• جمع آوری و نظارت بر گزارش های برنامه؛
• APM;
• ردیابی

4) هشدار:

• سازماندهی سیستم هشدار؛
• سازماندهی نظام وظیفه؛
• سازماندهی یک "پایگاه دانش" و گردش کار برای پردازش حوادث.

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

لایه کاربردی - نظارت منطق تجاری

در اینجا ما در مورد بررسی این واقعیت صحبت می کنیم که برنامه برای کاربر کار می کند.

این سطح باید در مرحله توسعه انجام شود. به عنوان مثال، ما یک Prometheus مشروط داریم: به سروری می‌رود که بررسی‌ها را انجام می‌دهد، نقطه پایانی را می‌کشد، و نقطه پایانی می‌رود و API را بررسی می‌کند.

هنگامی که اغلب از برنامه نویسان خواسته می شود صفحه اصلی را نظارت کنند تا مطمئن شوند سایت کار می کند، برنامه نویسان دسته ای را ارائه می دهند که هر بار که نیاز دارند از کارکرد API مطمئن شوند می توانند آن را بکشند. و برنامه نویسان در این لحظه هنوز /api/test/helloworld را می گیرند و می نویسند
تنها راه برای اطمینان از اینکه همه چیز کار می کند؟ - نه!

• ایجاد چنین چک هایی اساسا وظیفه توسعه دهندگان است. تست های واحد باید توسط برنامه نویسانی که کد را می نویسند نوشته شود. زیرا اگر آن را به ادمین فاش کردید، "رفیق، در اینجا لیستی از پروتکل های API برای همه 25 عملکرد وجود دارد، لطفاً همه چیز را زیر نظر داشته باشید!" - هیچ چیز درست نمی شود.
• اگر "سلام جهان" را چاپ کنید، هیچ کس نمی داند که API باید کار کند و کار می کند. هر تغییر API باید منجر به تغییر در چک شود.
• اگر قبلاً چنین مشکلی دارید، ویژگی ها را متوقف کنید و توسعه دهندگانی را اختصاص دهید که این چک ها را بنویسند، یا ضررها را بپذیرید، بپذیرید که هیچ چیز بررسی نشده و شکست خواهد خورد.

نکات فنی:

• مطمئن شوید که یک سرور خارجی برای سازماندهی چک ها سازماندهی کنید - باید مطمئن باشید که پروژه شما برای دنیای خارج قابل دسترسی است.
• بررسی ها را در کل پروتکل API سازماندهی کنید، نه فقط نقاط پایانی فردی.
• با نتایج آزمایش یک نقطه پایانی پرومتئوس ایجاد کنید.

لایه کاربردی - نظارت بر معیارهای سلامت

اکنون ما در مورد معیارهای سلامت خارجی خدمات صحبت می کنیم.

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

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

• هر تغییر API باید منجر به تغییر در چک شود.
• فوراً با معیارهای سلامت یک سرویس جدید ایجاد کنید.
• یک ادمین می تواند به توسعه دهندگان بیاید و بپرسد "چند ویژگی را به من اضافه کنید تا همه چیز را بفهمم و اطلاعاتی در مورد آن به سیستم نظارتم اضافه کنم." اما توسعه‌دهندگان معمولاً پاسخ می‌دهند: «دو هفته قبل از انتشار چیزی اضافه نمی‌کنیم».
  مدیران توسعه بدانند که چنین ضررهایی وجود دارد، مدیریت مدیران توسعه هم بدانند. زیرا وقتی همه چیز سقوط می کند، هنوز کسی تماس می گیرد و خواستار نظارت بر "سرویس در حال سقوط" است (ج)
• به هر حال، توسعه دهندگان را برای نوشتن افزونه برای Grafana اختصاص دهید - این کمک خوبی برای مدیران خواهد بود.

لایه برنامه - نظارت بر یکپارچه سازی

نظارت یکپارچه بر نظارت بر ارتباطات بین سیستم‌های حیاتی تجاری متمرکز است.

به عنوان مثال، 15 سرویس وجود دارد که با یکدیگر در ارتباط هستند. اینها دیگر سایت های جداگانه ای نیستند. آن ها ما نمی‌توانیم سرویس را به تنهایی انجام دهیم، /helloworld را دریافت کنیم و بفهمیم که سرویس در حال اجرا است. از آنجا که وب سرویس سفارش باید اطلاعات مربوط به سفارش را به اتوبوس ارسال کند - از اتوبوس، سرویس انبار باید این پیام را دریافت کند و بیشتر با آن کار کند. و سرویس توزیع ایمیل باید این را به نحوی بیشتر پردازش کند و غیره.

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

کاری که توصیه می کنم انجام دهید:

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

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

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

لایه زیرساخت

نظارت بر زیرساخت ها چیزی است که از دیرباز به عنوان نظارت بر خود مطرح بوده است.

• نظارت بر زیرساخت می تواند و باید به عنوان یک فرآیند جداگانه راه اندازی شود.
• شما نباید با نظارت بر زیرساخت در یک پروژه در حال اجرا شروع کنید، حتی اگر واقعاً بخواهید. این یک درد برای همه deops است. "ابتدا من خوشه را نظارت خواهم کرد، زیرساخت را نظارت خواهم کرد" - i.e. اول، آنچه در زیر وجود دارد را نظارت می کند، اما وارد برنامه نمی شود. زیرا برنامه برای devops یک چیز غیرقابل درک است. برای او فاش شد، و او نمی‌داند چگونه کار می‌کند. و زیرساخت را درک می کند و با آن شروع می کند. اما نه - شما همیشه باید ابتدا برنامه را نظارت کنید.
• در مورد تعداد هشدارها زیاده روی نکنید. با توجه به پیچیدگی سیستم های مدرن، هشدارها دائما در حال پرواز هستند و شما باید به نوعی با این دسته از هشدارها زندگی کنید. و فرد در حال تماس، با نگاهی به صد مورد از هشدارهای بعدی، تصمیم خواهد گرفت "من نمی خواهم به آن فکر کنم." هشدارها فقط باید در مورد چیزهای مهم اطلاع دهند.

سطح کاربرد به عنوان یک واحد تجاری

امتیاز کلیدی:

• ELK. این استاندارد صنعتی است. اگر به دلایلی گزارش‌ها را جمع‌آوری نمی‌کنید، فوراً این کار را شروع کنید.
• APM APM های خارجی به عنوان راهی برای بستن سریع نظارت برنامه (NewRelic، BlackFire، Datadog). می توانید این مورد را به طور موقت نصب کنید تا حداقل به نحوی بفهمید که چه اتفاقی برای شما می افتد.
• ردیابی. در ده‌ها میکروسرویس، شما باید همه چیز را ردیابی کنید، زیرا درخواست دیگر به خودی خود زندگی نمی‌کند. اضافه کردن بعداً بسیار دشوار است ، بنابراین بهتر است فوراً ردیابی را در توسعه برنامه ریزی کنید - این کار و ابزار توسعه دهندگان است. اگر هنوز آن را اجرا نکرده اید، آن را اجرا کنید! Jaeger/Zipkin را ببینید

هشدار دهنده

• سازماندهی یک سیستم اطلاع رسانی: در شرایط نظارت بر یک سری موارد، باید یک سیستم یکپارچه برای ارسال اعلان ها وجود داشته باشد. شما می توانید در Grafana. در غرب، همه از PagerDuty استفاده می کنند. هشدارها باید واضح باشند (مثلاً از کجا آمده اند...). و توصیه می شود کنترل کنید که اصلاً اعلان ها دریافت شوند
• سازماندهی یک نظام وظیفه: هشدارها نباید برای همه ارسال شود (یا همه در یک جمعیت واکنش نشان می دهند یا هیچ کس واکنشی نشان نمی دهد). توسعه‌دهندگان همچنین باید آماده باشند: حتماً حوزه‌های مسئولیت را تعریف کنید، دستورالعمل‌های واضحی ارائه دهید و در آن بنویسید که دقیقاً با چه کسی در روزهای دوشنبه و چهارشنبه تماس بگیرند، و با چه کسی در روز سه‌شنبه و جمعه تماس بگیرند (در غیر این صورت، آنها حتی با کسی تماس نخواهند گرفت. رویداد یک مشکل بزرگ - آنها از بیدار کردن شما می ترسند یا مزاحم شما می شوند: مردم معمولاً دوست ندارند با دیگران تماس بگیرند و از خواب بیدار شوند، به خصوص در شب). و توضیح دهید که درخواست کمک نشان دهنده بی کفایتی نیست ("من درخواست کمک می کنم، یعنی من کارگر بدی هستم")، درخواست کمک را تشویق کنید.
• سازماندهی یک "پایگاه دانش" و گردش کار برای پردازش حادثه: برای هر حادثه جدی، باید یک پس از مرگ برنامه ریزی شود و به عنوان یک اقدام موقت، اقداماتی که حادثه را حل می کند باید ثبت شود. و آن را عملی کن که هشدارهای مکرر گناه است. آنها باید در کار کد یا زیرساخت رفع شوند.

پشته فناوری

بیایید تصور کنیم که پشته ما به صورت زیر است:

• جمع آوری داده ها - Prometheus + Grafana;
• تجزیه و تحلیل ورود به سیستم - ELK؛
• برای APM یا Tracing - Jaeger (Zipkin).

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

چند نکته فنی که اخیراً همه جا می بینم:

پرومتئوس را به داخل کوبرنتس هل می دهند - چه کسی این را به ذهنش رسانده است؟! اگر خوشه شما خراب شود، چه خواهید کرد؟ اگر یک خوشه پیچیده در داخل دارید، پس باید نوعی سیستم نظارتی در داخل خوشه وجود داشته باشد، و برخی در خارج، که داده ها را از داخل خوشه جمع آوری می کند.

در داخل خوشه ما سیاهههای مربوط و هر چیز دیگری را جمع آوری می کنیم. اما سیستم نظارت باید بیرون باشد. اغلب اوقات، در یک خوشه که در آن Promtheus به صورت داخلی نصب شده است، سیستم هایی نیز وجود دارند که بررسی های خارجی عملکرد سایت را انجام می دهند. اگر اتصالات شما با دنیای خارج قطع شده باشد و برنامه کار نکند چه؟ به نظر می رسد که همه چیز در داخل خوب است، اما این کار را برای کاربران آسان تر نمی کند.

یافته ها

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

این نسخه توسعه یافته گزارش در کنفرانس Saint Highload++ است.

اگر به ایده ها و افکار من در مورد آن و موضوعات مرتبط علاقه دارید، در اینجا می توانید کانال را بخوانید ؟؟؟؟

منبع: www.habr.com