SRE (مهندسی قابلیت اطمینان سایت) رویکردی برای دسترسی به پروژه های وب است. این یک چارچوب برای DevOps در نظر گرفته می شود و نحوه موفقیت در استفاده از شیوه های DevOps را می گوید. این مقاله ترجمه می کند فصل 6 نظارت بر سیستم های توزیع شده کتاب مهندسی قابلیت اطمینان سایت از گوگل من خودم این ترجمه را تهیه کردم و به تجربه خودم در درک فرآیندهای نظارت تکیه کردم. در کانال تلگرام @monitorim_it и وبلاگ در مدیوم من همچنین پیوندی به ترجمه فصل 4 همین کتاب در مورد اهداف سطح خدمات ارسال کردم.

ترجمه گربه. از خواندن لذت ببرید!

تیم های Google SRE دارای اصول اولیه و بهترین شیوه ها برای ایجاد سیستم های نظارت و اعلان موفق هستند. این فصل توصیه هایی در مورد مشکلاتی که بازدیدکننده صفحه وب ممکن است با آن مواجه شود و نحوه حل مشکلاتی که نمایش صفحات وب را دشوار می کند ارائه می دهد.

تعاریف

هیچ واژگان واحدی برای بحث در مورد موضوعات مرتبط با نظارت وجود ندارد. حتی در گوگل، اصطلاحات زیر رایج نیستند، اما ما رایج ترین تفاسیر را فهرست می کنیم.

نظارت

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

مانیتورینگ جعبه سفید

نظارت بر اساس معیارهای نمایش داده شده توسط داخلی سیستم، از جمله گزارش‌ها، معیارهای نمایه کنترل کننده JVM یا HTTP که آمار داخلی را تولید می‌کنند.

نظارت بر جعبه سیاه

تست رفتار اپلیکیشن از دید کاربر.

داشبورد (داشبورد)

یک رابط (معمولاً یک رابط وب) که نمای کلی از شاخص های سلامت کلیدی خدمات را ارائه می دهد. داشبورد می تواند دارای فیلترها، قابلیت انتخاب معیارهایی برای نمایش و غیره باشد.این رابط برای شناسایی مهم ترین معیارها برای کاربران طراحی شده است. داشبورد همچنین می تواند اطلاعاتی را برای کارکنان پشتیبانی فنی نمایش دهد: یک صف درخواست، لیستی از خطاهای با اولویت بالا، یک مهندس اختصاص داده شده برای یک منطقه مسئولیت معین.

هشدار (اعلان)

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

علت اصلی (علت ریشه ای)

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

گره و ماشین (گره و ماشین)

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

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

فشار

هر گونه تغییر در پیکربندی نرم افزار

چرا نظارت لازم است

چندین دلیل وجود دارد که چرا برنامه ها باید نظارت شوند:

تجزیه و تحلیل روندهای بلند مدت

پایگاه داده چقدر بزرگ است و چقدر سریع در حال رشد است؟ تعداد کاربران روزانه چگونه تغییر می کند؟

مقایسه عملکرد

آیا پرس و جوها در Acme Bucket of Bytes 2.72 سریعتر از Ajax DB 3.14 هستند؟ پس از ظاهر شدن یک گره اضافی، درخواست‌ها چقدر بهتر ذخیره می‌شوند؟ آیا سایت نسبت به هفته گذشته کندتر شده است؟

هشدار (اعلان ها)

چیزی خراب است و کسی باید آن را تعمیر کند. یا چیزی به زودی خراب می شود و کسی باید آن را به زودی بررسی کند.

ایجاد داشبورد

داشبوردها باید به سوالات اساسی پاسخ دهند و شامل مواردی از آن باشند "4 سیگنال طلایی" - تاخیر (تاخیر)، ترافیک (ترافیک)، خطاها (خطاها) و مقدار بار (اشباع).

انجام تجزیه و تحلیل گذشته نگر (اشکال زدایی)

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

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

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

تعیین انتظارات معقول از سیستم نظارت

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

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

تیم Google SRE با درجات مختلف موفقیت با سلسله مراتب وابستگی پیچیده کار کرده است. ما به ندرت از قوانینی مانند "اگر متوجه شدم که پایگاه داده کند شده است، هشدار کاهش سرعت پایگاه داده دریافت می کنم، در غیر این صورت هشدار سایت کند دریافت می کنم" استفاده می کنیم. قوانین مبتنی بر وابستگی معمولاً به بخش‌های بدون تغییر سیستم ما اشاره می‌کنند، مانند سیستم فیلتر کردن ترافیک کاربر به مرکز داده. به عنوان مثال، "اگر فیلتر ترافیک مرکز داده پیکربندی شده است، در مورد تاخیر در پردازش درخواست های کاربر به من هشدار ندهید" یکی از قوانین رایج برای هشدارهای مرکز داده است. تیم‌های کمی در Google از سلسله مراتب وابستگی پیچیده پشتیبانی می‌کنند زیرا زیرساخت‌های ما دارای نرخ ثابتی از بازسازی مداوم است.

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

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

علائم در مقابل علل

سیستم مانیتورینگ شما باید به دو سوال پاسخ دهد: "چه چیزی خراب است" و "چرا خراب است".
"چی شکست" به علامت اشاره دارد و "چرا شکست" به علت اشاره دارد. جدول زیر نمونه هایی از این لینک ها را نشان می دهد.

علائم
علت

دریافت خطای HTTP 500 یا 404
سرورهای پایگاه داده از اتصال خودداری می کنند

پاسخ های آهسته سرور
استفاده زیاد از CPU یا کابل اترنت آسیب دیده

کاربران در قطب جنوب GIF گربه دریافت نمی کنند
CDN شما از دانشمندان و گربه سانان متنفر است، بنابراین برخی از IP ها در لیست سیاه قرار می گیرند

محتوای خصوصی در همه جا در دسترس است
انتشار یک نرم افزار جدید باعث شد فایروال تمام ACL ها را فراموش کند و به همه اجازه ورود دهد

"چرا" و "چرا" یکی از مهمترین عناصر سازنده برای ایجاد یک سیستم مانیتورینگ خوب با حداکثر سیگنال و حداقل نویز هستند.

جعبه سیاه در مقابل جعبه سفید

ما نظارت گسترده جعبه سفید را با نظارت ساده جعبه سیاه برای معیارهای مهم ترکیب می کنیم. ساده ترین راه برای مقایسه جعبه سیاه با جعبه سفید این است که جعبه سیاه بر علائم متمرکز است و به جای نظارت پیشگیرانه واکنشی است: "سیستم در حال حاضر به درستی کار نمی کند." جعبه سفید به قابلیت‌های بررسی داخلی سیستم‌ها بستگی دارد: گزارش‌های رویداد یا سرورهای وب. بنابراین، White-box به شما امکان می دهد مشکلات آینده، نقص هایی که شبیه ارسال مجدد یک درخواست هستند و غیره را شناسایی کنید.

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

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

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

چهار سیگنال طلایی

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

تاخیر انداختن

زمان مورد نیاز برای پردازش درخواست تمایز بین تاخیر درخواست های موفق و ناموفق مهم است. به عنوان مثال، خطای HTTP 500 ناشی از قطع شدن اتصال به پایگاه داده یا باطن دیگری را می توان خیلی سریع تشخیص داد، با این حال، خطای HTTP 500 می تواند نشان دهنده یک درخواست ناموفق باشد. یافتن تأثیر خطای 500 بر تأخیر کلی می تواند به نتیجه گیری های اشتباه منجر شود. از طرفی خطای کند حتی یک خطای سریع است! بنابراین، ردیابی تأخیر خطا به جای فیلتر کردن خطاها مهم است.

ترافیک

تعداد درخواست‌ها به سیستم شما، که با معیارهای سیستم سطح بالا اندازه‌گیری می‌شود. برای یک وب سرویس، این اندازه گیری معمولاً تعداد درخواست های HTTP در ثانیه تقسیم بر ماهیت درخواست ها (مثلاً محتوای ایستا یا پویا) را نشان می دهد. برای یک سیستم پخش صوتی، این اندازه گیری ممکن است بر روی نرخ I/O شبکه یا تعداد جلسات همزمان متمرکز شود. برای یک سیستم ذخیره‌سازی کلید-مقدار، این اندازه‌گیری می‌تواند تراکنش یا جستجو در هر ثانیه باشد.

خطاها

این میزان درخواست های ناموفق است، یا به طور صریح (به عنوان مثال، HTTP 500)، به طور ضمنی (به عنوان مثال، HTTP 200 اما همراه با محتوای بد)، یا بر اساس خط مشی (به عنوان مثال، "اگر پاسخی را در یک ثانیه دریافت کنید، هر یک ثانیه یک خطا است"). اگر کدهای پاسخ HTTP کافی برای بیان همه شرایط خرابی وجود نداشته باشد، ممکن است پروتکل‌های ثانویه (داخلی) برای تشخیص شکست جزئی مورد نیاز باشد. نظارت بر همه این درخواست‌های اشتباه می‌تواند اطلاعاتی نداشته باشد، در حالی که آزمایش‌های سیستمی سرتاسر می‌تواند به شما کمک کند تا متوجه شوید که محتوای اشتباهی را پردازش می‌کنید.

اشباع

این معیار نشان می دهد که چقدر از خدمات شما استفاده می شود. این یک معیار نظارت بر سیستم است که منابعی را شناسایی می کند که محدودترین هستند (به عنوان مثال، در یک سیستم با حافظه محدود، حافظه را نشان می دهد، در یک سیستم با I / O محدود، تعداد I / O را نشان می دهد). توجه داشته باشید که بسیاری از سیستم‌ها قبل از رسیدن به 100% مصرف، تخریب می‌شوند، بنابراین داشتن یک هدف استفاده ضروری است.

در سیستم‌های پیچیده، اشباع را می‌توان با اندازه‌گیری بار در سطح بالاتر تکمیل کرد: آیا سرویس شما می‌تواند ترافیک مضاعف را به درستی مدیریت کند، فقط 10٪ ترافیک بیشتر را مدیریت کند یا حتی ترافیک کمتری را نسبت به آنچه در حال حاضر می‌تواند مدیریت کند؟ برای سرویس‌های ساده‌ای که پارامترهایی که پیچیدگی درخواست را تغییر می‌دهند ندارند (مثلاً «چیزی به من نده» یا «من یک عدد صحیح یکنواخت منحصر به فرد می‌خواهم») که به ندرت پیکربندی را تغییر می‌دهند، ممکن است مقدار آزمایش بار استاتیک کافی باشد. همانطور که در پاراگراف قبل بحث شد، اکثر سرویس‌ها باید از سیگنال‌های غیرمستقیم مانند استفاده از CPU یا پهنای باند شبکه استفاده کنند که کران بالایی مشخص دارند. افزایش تاخیر اغلب شاخص اصلی اشباع است. اندازه گیری زمان پاسخ دهی صدک 99 در یک پنجره کوچک (مثلاً یک دقیقه) می تواند یک سیگنال اشباع بسیار زودرس بدهد.

در نهایت، اشباع نیز با پیش بینی اشباع قریب الوقوع مرتبط است، مانند: "به نظر می رسد پایگاه داده شما هارد دیسک شما را ظرف 4 ساعت پر می کند."

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

نگرانی در مورد دم (یا ابزار دقیق و عملکرد)

هنگام ساختن یک سیستم مانیتورینگ از ابتدا، وسوسه انگیز است که یک سیستم بر اساس میانگین ها ایجاد شود: تأخیر متوسط، متوسط ​​استفاده از CPU گره، یا میانگین اشغال پایگاه داده. خطر دو مثال آخر واضح است: پردازنده ها و پایگاه های داده به روشی بسیار غیرقابل پیش بینی از بین می روند. همین امر در مورد تاخیر نیز صدق می کند. اگر از وب سرویسی با تأخیر متوسط ​​100 میلی‌ثانیه با 1000 درخواست در ثانیه استفاده می‌کنید، 1 درصد درخواست‌ها می‌تواند 5 ثانیه طول بکشد. اگر کاربران به چندین چنین خدمات وب وابسته باشند، صدک 99 یک باطن منفرد می تواند به راحتی به میانگین زمان پاسخ رابط کاربری تبدیل شود.

ساده‌ترین راه برای تمایز بین میانگین آهسته و دنباله بسیار کند درخواست‌ها، جمع‌آوری اندازه‌گیری درخواست‌های بیان شده در آمار است (هیستوگرام‌ها ابزار مناسبی برای نمایش هستند)، به جای تاخیرهای واقعی: تعداد درخواست‌هایی که توسط سرویسی که دریافت کرده است ارائه شده است. بین 0 و 10 میلی ثانیه، بین 10 تا 30 میلی‌ثانیه، بین 30 تا 100 میلی‌ثانیه، بین 100 تا 300 میلی‌ثانیه، و غیره. گسترش کران‌های هیستوگرام تقریباً به صورت نمایی (با ضریب حدود 3) اغلب یک راه آسان برای تجسم توزیع درخواست‌ها است.

انتخاب دانه بندی مناسب برای اندازه گیری

عناصر مختلف سیستم باید با سطوح مختلف جزئیات اندازه گیری شوند. مثلا:

• تماشای استفاده از CPU در یک دوره زمانی، جهش های طولانی را نشان نمی دهد که منجر به تاخیر زیاد می شود.
• از سوی دیگر، برای وب سرویسی که بیش از 9 ساعت از کار افتادگی در سال را هدف قرار نمی دهد (99,9٪ زمان آپلود سالانه)، بررسی پاسخ HTTP 200 بیش از یک یا دو بار در دقیقه احتمالاً غیرضروری خواهد بود.
• به طور مشابه، بررسی فضای خالی روی هارد دیسک برای در دسترس بودن 99,9 درصد بیش از یک بار در هر 1-2 دقیقه احتمالاً غیر ضروری است.

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

1. مصرف CPU را هر ثانیه اندازه گیری کنید.
2. جزئیات را به 5 درصد کاهش دهید.
3. هر دقیقه معیارها را جمع آوری کنید.

این استراتژی به شما این امکان را می دهد که داده های بسیار گرانول را بدون تجربه هزینه های بالا برای تجزیه و تحلیل و ذخیره سازی جمع آوری کنید.

تا حد امکان ساده اما نه ساده تر

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

• با توجه به آستانه های مختلف برای تأخیر درخواست، در صدک های مختلف، در تمام انواع معیارهای مختلف، هشدار می دهد.
• نوشتن کد اضافی برای شناسایی و شناسایی علل احتمالی.
• برای هر یک از دلایل احتمالی مشکلات، داشبوردهای مرتبط ایجاد کنید.

منابع عارضه بالقوه هرگز به پایان نمی رسد. مانند همه سیستم های نرم افزاری، نظارت می تواند آنقدر پیچیده شود که شکننده، تغییر و نگهداری آن دشوار شود.

بنابراین، سیستم مانیتورینگ خود را طوری طراحی کنید که آن را تا حد امکان ساده کنید. هنگام انتخاب مواردی که باید ردیابی کنید، موارد زیر را در نظر داشته باشید:

• قوانینی که اغلب حوادث واقعی را ثبت می کنند باید تا حد امکان ساده، قابل پیش بینی و قابل اعتماد باشند.
• پیکربندی برای جمع‌آوری داده‌ها، تجمیع و هشدار که به ندرت انجام می‌شود (به عنوان مثال، کمتر از سه ماهه برای برخی تیم‌های SRE) باید حذف شود.
• معیارهایی که جمع‌آوری می‌شوند اما در هیچ پانل پیش‌نمایش نشان داده نمی‌شوند یا توسط هیچ هشداری استفاده نمی‌شوند، نامزد حذف هستند.

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

پیوند دادن اصول با هم

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

هنگام ایجاد قوانین نظارت و هشدار، پرسیدن سؤالات زیر می تواند به شما کمک کند از هشدارهای مثبت کاذب و هشدارهای غیر ضروری جلوگیری کنید:

• آیا این قانون وضعیت سیستم غیرقابل شناسایی را تشخیص می‌دهد که فوری است، به اقدام فراخوانده می‌شود و ناگزیر بر کاربر تأثیر می‌گذارد؟
• آیا می توانم این هشدار را نادیده بگیرم که بدانم خوش خیم است؟ چه زمانی و چرا می توانم این هشدار را نادیده بگیرم و چگونه می توانم از این سناریو اجتناب کنم؟
• آیا این هشدار به این معنی است که کاربران تحت تأثیر منفی قرار گرفته اند؟ آیا شرایطی وجود دارد که کاربران تحت تأثیر منفی قرار نگیرند، مثلاً به دلیل فیلتر ترافیک یا هنگام استفاده از سیستم های آزمایشی، هشدارهایی که باید فیلتر شوند؟
• آیا می توانم در پاسخ به این هشدار اقدامی انجام دهم؟ آیا این اقدامات فوری است یا می توان تا صبح صبر کرد؟ آیا خودکار کردن عمل امن است؟ آیا این اقدام یک راه حل بلند مدت خواهد بود یا یک راه حل کوتاه مدت؟
• برخی از افراد برای این موضوع هشدارهای متعددی دریافت می کنند، بنابراین آیا امکان کاهش تعداد وجود دارد؟

این سؤالات منعکس کننده فلسفه اساسی هشدارها و سیستم های هشدار هستند:

• هر بار که یک هشدار می آید، باید فوراً واکنش نشان دهم. من می توانم چندین بار در روز قبل از اینکه خسته شوم عجله کنم.
• هر هشدار باید به روز باشد.
• هر پاسخ به یک هشدار باید به مداخله انسانی نیاز داشته باشد. اگر امکان پردازش خودکار اعلان وجود داشته باشد، نباید بیاید.
• هشدارها باید درباره یک موضوع جدید یا رویدادی باشد که قبلاً اتفاق نیفتاده است.

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

نظارت طولانی مدت

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

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

Bigtable SRE: داستانی در مورد هشدار بیش از حد

زیرساخت داخلی Google معمولاً بر اساس سطح خدمات (SLO) ارائه و اندازه‌گیری می‌شود. سال‌ها پیش، SLO سرویس Bigtable بر اساس میانگین عملکرد یک تراکنش مصنوعی شبیه‌سازی مشتری در حال اجرا بود. به دلیل مشکلات موجود در Bigtable و سطوح پایین‌تر پشته ذخیره‌سازی، عملکرد متوسط ​​توسط یک دم «بزرگ» هدایت می‌شد: بدترین 5 درصد جستجوها اغلب به طور قابل توجهی کندتر از بقیه بودند.

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

برای اصلاح این وضعیت، تیم از یک رویکرد سه جانبه استفاده کرد: در حالی که سخت کار می‌کردیم تا عملکرد Bigtable را بهبود ببخشیم، به طور موقت صدک 75 را برای تاخیر پاسخ پرس و جو به عنوان هدف SLO خود تعیین کردیم. ما همچنین هشدارهای ایمیل را خاموش کردیم، زیرا تعداد آنها بسیار زیاد بود که اتلاف وقت برای تشخیص آنها غیرممکن بود.

این استراتژی به ما اجازه داد تا به جای رفع دائمی مشکلات تاکتیکی، شروع به رفع مشکلات طولانی مدت در Bigtable و لایه های پایینی ذخیره سازی کنیم. مهندسان در واقع زمانی می توانند کار را انجام دهند که همیشه با هشدار بمباران نمی شدند. در نهایت، تاخیر موقت در پردازش هشدارها به ما امکان داد تا کیفیت خدمات را بهبود بخشیم.

جی‌میل: پاسخ‌های انسانی الگوریتمی قابل پیش‌بینی

در همان ابتدا، Gmail بر روی یک سیستم کنترل فرآیند Workqueue اصلاح شده ساخته شد که برای دسته‌ای از تکه‌های فهرست جستجوی فرآیند ایجاد شده بود. Workqueue با فرآیندهای طولانی مدت تطبیق داده شد و متعاقباً در Gmail اعمال شد، اما رفع برخی از اشکالات در کد زمان‌بندی غیرشفاف بسیار سخت بود.

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

برای حل این مشکل، Gmail SRE ابزاری را برای کمک به اشکال‌زدایی زمان‌بندی به بهترین شکل ممکن برای به حداقل رساندن تأثیر روی کاربران ایجاد کرد. این تیم چندین بحث در مورد اینکه آیا می‌توان کل چرخه را از یافتن مشکل تا رفع آن تا یافتن راه‌حل بلندمدت خودکار کرد یا نه، داشت، اما برخی نگران بودند که چنین راه‌حلی رفع واقعی مشکل را به تاخیر بیندازد.

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

هشدارهای تکرار شونده و واکنش های الگوریتمی باید علامت قرمز باشد. عدم تمایل تیم شما به خودکارسازی این هشدارها به این معنی است که تیم اطمینان ندارد که بتواند به الگوریتم‌ها اعتماد کند. این یک مشکل جدی است که باید برطرف شود.

دراز مدت

یک موضوع مشترک مثال های Bigtable و Gmail را پیوند می دهد: رقابت بین در دسترس بودن کوتاه مدت و بلند مدت. اغلب یک تلاش قوی می تواند به یک سیستم شکننده کمک کند تا دسترسی بالایی داشته باشد، اما این مسیر معمولاً کوتاه مدت است، مملو از فرسودگی تیم و وابستگی به تعداد کمی از اعضای همین تیم قهرمان است.

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

نتیجه

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

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

ممنون که ترجمه را تا آخر خواندید. در کانال تلگرام من در مورد نظارت عضو شوید @monitorim_it и وبلاگ در مدیوم.

منبع: www.habr.com