پایش (monitoring) با Prometheus، نیسان آبیِ کوه و کمر

درباره‌ی Prometheus می‌خواندم که سیستمی‌ست برای پایش (monitoring) سرویس‌های توزیع‌شده یا اَبری، و همانندی‌اش با نمونه‌ی داخلی و قدیمی در گوگل به نام Borgmon برایم جالب بود. در این یادداشت به چند تجربه از سالیانِ کار با چنین سیستمی می‌پردازم. هر سرویس باآبرو و سرپا نیاز به چنین پایش سطح بالایی دارد، البته با آگاهی از تله‌ها.

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

• در مثال فروشگاه اینترنتی در این یادداشتِ پیشین، شاخص «تعداد کالای فیلتر شده در نتایج جستجو در سرور الف» را تجسم کنید که دارای دو بُعد «مخزن کالا» و «واسط کاربر» است. با این شاخص، می‌توانیم نمودار زمانیِ تعداد دفعه‌هایی که کالاهای مخزن «انبار / سِداِسمال / چارسوق / ائتلاف» به کاربران «وب / اندروید / آیفون» نمایش داده می‌شوند را جداگانه یا تجمیع‌شده ترسیم کنیم یا روی آن هشدار تعریف کنیم. بُعدها در واژه‌نامه‌ی Prometheus به نام برچسب (label) شناخته می‌شوند.

این شاخص‌ها از سرورها به بیرون صادر شده و به دست Prometheus گردآوری و تجمیع می‌شوند برای نمودارکشی و هشداردهی. برای آشنایی بیشتر این مفاهیم، از این راهنما آغاز کنید.

سیستم Prometheus به دست کارکنان پیشینِ گوگل که به SoundCloud رفته بودند و از نبودِ چنین امکان ساده و بنیادی برای پایش سیستم‌ها در سختی بودند، از روی Borgmon همانندسازی شد. این همانندی در نام‌ مولفه‌ها و مدل داده (data model) و ruleها و templateها و syntax جبر خطی و برچسب‌ها (labelها) و … نمایان است. در گوگل، Borgmon از سال ۲۰۰۴ برای پایش jobها در محیط عملیاتی گوگل به نام Borg (پدر Kubernetes) آغاز به کار کرد، و در سال ۲۰۱۰ تعطیل و وارد فاز نگهداری شد تا تیم‌ها به محصول جایگزینی به نام Monarch مهاجرت کنند (که بَعدتر به مشتریان ابری هم ارائه شد). به چند مورد کاستی در Borgmon (و متعاقبا در Prometheus) خواهم پرداخت. امروز تقریبا همه‌ی تیم‌ها روی Monarchاند ولی دو سه زیرسازمان بزرگ و حیاتی هنوز نه. دلایلش مفصل است ولی شبیه دلایل ماندگاری نیسان آبی.

خوبی‌های Borgmon و Prometheus روشن‌اند. مهم‌ترین ستون اتکاپذیری یک سرویس، دید داشتن به شکلی‌ست که این دو سیستم فراهم می‌کنند: پایش هزاران شاخص چندبُعدی. اگر به اهمیت این موضوع آشنا نیستید، فصل ۳.۳ از این یادداشتِ پیشین و فصل ۱ و ۲ از این یادداشت را ببینید.

اما کاستی‌هایی دارند که مرورشان نه برای پشیمان کردن از استفاده بلکه برای آگاهی از موانعِ پیش رو به ویژه زمانی که سیستم شما بزرگ و بالغ می‌شود است.

یک: Prometheus، تجمیع را در زمان گِردآوری (collection) شاخص‌ها از سرورها انجام می‌دهد، ولی روشِ کاراتَر، گردآوری به صورت خام و تجمیع در زمان درخواست (query) است. تجمیع یعنی چه؟ زمانی که ما نمودار نرخ (rate) رخدادِ الف بر ثانیه را ترسیم می‌کنیم، در واقع سرورها شمارِ الف از دید خودشان را به شکل خام--یعنی نه به شکل «نرخ بر ثانیه» بلکه به شکل یک شمارِ به طور پیوسته زیادشونده در طول عمر سرور--به سیستم پایش که هر دقیقه آن‌ها را نمونه‌برداری می‌کند صادر کرده‌اند. سیستم پایش، تفاوت این شمار بین لحظه‌ی کنونی و T ثانیه پیش را حساب کرده و تقسیم بر T کرده و به شکل «شمار بر ثانیه» در لحظه‌ی کنونی در سطح instance و job تجمیع می‌کند؛ نیز به همین شکل برای گونه‌های دیگرِ شاخص‌ها مانند «نسبتِ دو نرخ» یا «میانگین» یا «توزیع/histogram» که اندکی پیچیده‌تر هستند. انجام این کار در زمان گردآوری به جای زمان درخواست، یک عامل محدود کننده برای کاربرد است، زیرا در زمان درخواست، داده‌های خام دیگر وجود ندارند. یعنی باید از پیش و هنگام نوشتن ruleهای تجمیعِ سیستم پایش، به آن‌چه در آینده نیاز خواهید داشت فکر می‌کردید.

دو: به دلیل تجمیع در زمان گردآوری، بارِ سنگینی روی سرورهای Prometheus خواهد بود، به ویژه برای تجمیع شاخص‌های چندبُعدی که یعنی بیشتر شاخص‌ها؛ شاخص «تعداد کالای فیلتر شده در نتایج جستجو» که دارای دو بُعد «مخزن کالا» و «واسط کاربر» بود را به یاد بیاورید. بنابراین اگر اشتباه کنید و بُعدی تعریف کنید که کاردینالیتیِ شاخص را بزرگ کند--مثلا بُعد/برچسب «واسط کاربر» را به جای فقط {وب، اندروید، آیفون} با ۳ حالت ممکن به اشتباه شامل نام و نسخه‌ی مرورگر در نظر بگیرید با ۱۰۰۰ حالت ممکن که سپس در ترکیب با بُعدهای دیگر به طور نمایی بزرگ‌تر هم می‌شود--کل سیستم پایش شما دچار اختلال می‌شود؛ چنان‌که برای ما به دفعات رخ داده. این مساله شوخی‌بردار نیست و سلامت سرورهای پایش (Prometheus) از خودِ سیستمی که پایش می‌شود مهم‌تر است. ولی اگر تجمیع در زمان درخواست باشد، فقط درخواست شما به خطا می‌خورد ولی سیستم پایش سالم است. البته اگر این اشتباه زیادی بزرگ باشد، مثلا «ID کالا» را به عنوان یک برچسب/بُعد قرار دهید که کاردینالیتی میلیونی دارد، اصلا خود سرورهای شما برای شمارش و صادر کردن چنین map بزرگی به مشکل خواهند خورد و این یک خطای رایج در تعریف شاخص‌ها به دست مهدسانی‌ست که با سیستم‌های پایش آشنا نیستند. این هم برای ما به دفعات رخ داده.

سه: Prometheus مانند هم‌زادش Borgmon، برای پایش در مقیاس کوچک طراحی شده. یعنی چند سرور؟ برخلاف ادعاهایی که در مقاله‌های مربوط به Prometheus دیدم که تا چند هزار سرور مشکلی نخواهید داشت، توجه کنید که به تعداد سرور نیست بلکه به تعداد سِری‌های زمانی (timeseries) است، یعنی ادعای «چندهزار سرور» اگر با شاخص‌های اسکالر (بدون بُعد) باشد که احتمالا هست، یعنی احتمالا تنها چند ده سرور وقتی که پای شاخص‌های چندبُعدی در میان است. باید امتحان کنید و توانایی‌اش را بسنجید. ولی خلاصه Prometheus مقیاس‌پذیر نیست، چنان‌که Borgmon نیست و ما برای مقیاس‌پذیر کردنش زحمت زیادی می‌کشیم، مثلا shard کردن عملِ گردآوری (بدون هیچ‌گونه تجمیعی)‌ روی گروهی از سرورهای Borgmon، سپس ارسال به لایه‌ی دیگری از سرورهای Borgmon برای تجمیع در هر datacentre، سپس ارسال به لایه‌ی دیگری برای تجمیع جهانی. این امر نه تنها وقت و انرژی و منابع می‌گیرد، بلکه برای «همه» پیچیدگی به همراه دارد چون همه باید بدانند کدام داده را در کدام سرور می‌توان یافت.

چهار: اتکاپذیری (reliability) سرویس پایش، از اتکاپذیری خودِ سرویسی که پایش می‌شود مهم‌تر است. حتی jobهای Borgmon با اولویت بالاتری از jobهای خود سرویس‌ها در سیستم مدیریت jobها اجرا می‌شوند. Prometheus مانند هم‌زادش Borgmon، آسیب‌پذیری بالایی نسبت به رفتار سرویسی که پایش می‌کند دارد - مثال بالا از یک شاخص با کاردینالیتی بالا را ببینید. در واقع ما یک دم و دستگاهِ چند لایه‌ی Borgmon برای پایش سرویس‌ها داریم و یک سرویس Borgmon مجزا و ساده‌تر برای پایشِ ‌آن Borgmonها و نه هیچ چیز دیگری. همچنین هر سرویس/محصول باید به طور مجزا دم و دستگاه Borgmon خود را نگهداری کند که اصلا شایسته نیست. در واقع علی‌رغم ادعایی که در مقاله‌ها درباره‌ی هم‌بسته (federate) کردن Prometheus بین سرویس‌ها یا حتی بین شرکت‌ها دیده‌ام، یک سرویس «پایش ابری» با امکاناتی برای اتکاپذیری مستقل از مشتری (مثلا کنترل دامنه‌ی خطا و قناری/canary کردن ruleهای جدید و ...) با Prometheus شدنی نیست.

در گوگل، بسیاری از این کاستی‌ها در سیستم جایگزینی که اشاره شد (Monarch) برطرف شده، ولی این سیستم به طور عمومی در دسترس نیست و همانندی برایش ندیدم. آیا شما سراغ دارید؟

شما برای پایشِ یک سرویس آنلاین از چه سیستمی استفاده می‌کنید؟ اگر Prometheus، آیا به کاستی‌های بالا یا کاستی‌های دیگری برنخوردید؟ اگر سیستمی غیر از Prometheus، در مقایسه با Prometheus چگونه است؟