تصویر کلی
Prometheus سرور اصلی را برای Scrape و ذخیره Time Series به‌کار می‌گیرد و اجزایی مثل Exporter، Pushgateway و Alertmanager در اطراف آن قرار می‌گیرند.
برای فهم این موضوع بهتر است اجزا را به‌عنوان یک مسیر ببینیم، نه مجموعه‌ای از گزینه‌های مستقل. در Production معمولاً مشکل زمانی شکل می‌گیرد که تنظیم روی دیسک، وضعیت Runtime و فرض تیم درباره رفتار سیستم با هم یکی نیستند. به همین دلیل مشاهده وضعیت مؤثر، Log و Metric باید کنار Configuration بررسی شود.
اجزای اصلی و مرز مسئولیت
مدل Pull باعث می‌شود وضعیت Target و خطای Scrape بخشی از داده عملیاتی قابل مشاهده باشد؛ Pushgateway بیشتر برای Jobهای کوتاه‌عمر طراحی شده است.
در طراحی عملی، برای هر جزء یک سؤال روشن بنویسید: چه ورودی می‌گیرد، چه خروجی تولید می‌کند، چه Stateای نگه می‌دارد و در خرابی چه کسی مسئول Recovery است. این مدل ساده کمک می‌کند خطاهای شبکه، هویت، ذخیره‌سازی یا Replication به‌اشتباه به جزء دیگری نسبت داده نشوند.
خطاهای رایج
Recording Rule و Alert Rule باید با Cardinality، دوره ارزیابی و هدف عملیات هماهنگ شوند؛ Prometheus سیستم صورتحساب با دقت تراکنشی نیست.
خطای دیگر، فعال‌کردن قابلیت پیشرفته بدون تعریف معیار موفقیت است. قبل از تغییر، Baseline بگیرید؛ بعد از تغییر همان Signalها را مقایسه کنید. اگر سیستم توزیع‌شده است، Failure Modeهای قطع شبکه، Restart، Lag، Timeout و از دست‌رفتن Dependency را نیز آزمایش کنید.
چک‌لیست عملی
- نسخه و Configuration مؤثر را ثبت کنید، نه فقط فایل مورد انتظار را.
- مسیر داده و کنترل را جدا رسم کنید.
- Health، Latency، Error Rate و ظرفیت را قبل و بعد از تغییر مقایسه کنید.
- برای تغییرات Stateful، Backup/Restore یا Rollback واقعی را آزمایش کنید.
- دسترسی مدیریتی را حداقل کنید و Log تصمیم‌ها را نگه دارید.
- مستندات همان نسخه محصول را مرجع نهایی قرار دهید.
تمرین IROSG
یک محیط کوچک آزمایشی بسازید و فقط یک Failure را تزریق کنید؛ مثلاً قطع Upstream، حذف یک Replica، خطای DNS یا تغییر Route. قبل از آزمایش بنویسید انتظار دارید کدام Metric و Log تغییر کند. بعد نتیجه واقعی را با انتظار مقایسه کنید. این تمرین معمولاً سریع‌تر از حفظ‌کردن Optionها، مدل ذهنی سیستم را اصلاح می‌کند.
مرجع
این راهنما بر پایه مستندات رسمی Prometheus نوشته شده و مثال‌های عملی تحریریه برای آموزش دفاعی و عملیاتی هستند.
یک نمونه از تولید معیار تا پاسخ پرس‌وجو
فرض کنید برنامه وب تعداد درخواست‌ها و مدت پاسخ را در یک مسیر معیار ارائه می‌کند. Prometheus باید نخست مقصد این مسیر را بشناسد، سپس در فاصله‌های تعیین‌شده به آن مراجعه کند و نمونه‌ها را بخواند. هر نمونه با نام معیار، مجموعه برچسب و زمان در مدل سری زمانی قرار می‌گیرد. بعداً یک پرس‌وجو می‌تواند نرخ درخواست، نسبت خطا یا توزیع زمان پاسخ را از این داده محاسبه کند. این زنجیره ساده چند مسئولیت جدا دارد: تولید درست معیار، کشف مقصد، دسترسی شبکه، دریافت موفق و نگهداری داده. خطای هر مرحله می‌تواند نمودار نهایی را تغییر دهد.
در آزمایش، یک خدمت با شمارنده ساده بسازید و تعداد مشخصی درخواست ارسال کنید. مقدار خام را روی مسیر معیار ببینید، سپس وضعیت هدف را در Prometheus بررسی کنید و در پایان پرس‌وجوی نرخ را اجرا کنید. مقدار خام شمارنده و نرخ یکسان نیستند؛ شمارنده مجموع رخدادها از زمان آغاز فرایند را نشان می‌دهد، در حالی که نرخ تغییر در زمان را بیان می‌کند. پس از راه‌اندازی دوباره برنامه، رفتار شمارنده و تابع نرخ را مشاهده کنید. این تمرین از تفسیر کاهش شمارنده به عنوان کاهش واقعی تقاضا جلوگیری می‌کند.
کشف خدمت و آماده بودن هدف
کشف خدمت اطلاعات هدف‌های احتمالی را فراهم می‌کند، اما وجود یک هدف در فهرست کشف به معنی قابل دریافت بودن آن نیست. نشانی، درگاه، مسیر، گواهی و مجوز باید با خدمت واقعی سازگار باشند. برچسب‌های حاصل از کشف نیز ممکن است برای انتخاب یا بازنویسی هدف استفاده شوند. یک قاعده بازنویسی اشتباه می‌تواند هدف را کنار بگذارد یا برچسب مهمی را حذف کند. هنگام ناپدید شدن نمودار، ابتدا بررسی کنید هدف اصلاً در مجموعه نهایی جمع‌آوری حضور دارد یا نه.
برای خوشه پویا، هدف‌ها مرتب ایجاد و حذف می‌شوند. استفاده از نشانی ثابت یک پاد موقت معمولاً شکننده است. در مقابل، کشف بسیار گسترده می‌تواند خدماتی را جمع‌آوری کند که قصد پایش آن‌ها را ندارید. دامنه کشف را با مالکیت و نیاز واقعی هماهنگ کنید. در یک آزمون، نمونه‌ای تازه ایجاد و سپس حذف کنید و زمان اضافه شدن و کنار رفتن آن از جمع‌آوری را ببینید. این زمان بر سرعت تشخیص اختلال و معنای نبود داده اثر دارد.
مدل برچسب و هزینه تعداد سری‌ها
هر ترکیب متفاوت برچسب، سری زمانی جدا می‌سازد. برچسب‌هایی مانند محیط، خدمت و روش درخواست معمولاً دامنه قابل کنترل دارند. شناسه کاربر، نشانی کامل شامل پارامتر و شناسه یکتای درخواست می‌توانند تعداد ترکیب‌ها را بسیار زیاد کنند. این افزایش فقط به فضای دیسک محدود نیست؛ حافظه، پردازش پرس‌وجو و انتقال داده نیز تحت تأثیر قرار می‌گیرند. پیش از افزودن برچسب، بپرسید چند مقدار ممکن دارد و آیا همان سؤال را می‌توان با گزارش یا ردیابی پاسخ داد.
برای مثال، به جای مسیر کامل یک سفارش، مسیر قالبی مربوط به دریافت سفارش را معیار کنید. جزئیات هر سفارش را در سامانه‌ای مناسب جست‌وجوی رخداد نگه دارید. در آزمایش ظرفیت، فقط تعداد هدف‌ها را نشمارید؛ تعداد سری فعال و نرخ تولید نمونه نیز مهم‌اند. دو خدمت با تعداد نمونه اجرایی برابر ممکن است حجم پایش بسیار متفاوتی داشته باشند. تغییر برچسب باید مانند تغییر طرح داده بازبینی شود، چون اثر آن ممکن است پس از انتشار در مقیاس واقعی آشکار شود.
انتخاب نوع معیار
شمارنده برای رخدادهایی مناسب است که در طول عمر فرایند افزایش می‌یابند، مانند تعداد درخواست. سنجه برای مقدار جاری مانند طول صف یا تعداد اتصال باز مناسب است. برای زمان پاسخ یا اندازه پیام، مدل توزیع اهمیت پیدا می‌کند؛ میانگین به تنهایی تجربه درخواست‌های کند را پنهان می‌کند. انتخاب سطل‌های هیستوگرام باید با محدوده مورد انتظار و پرسش عملیاتی هماهنگ باشد. اگر همه درخواست‌ها در یک سطل بسیار بزرگ بیفتند، قدرت تفکیک کم می‌شود. اگر تعداد سطل‌ها بی‌دلیل زیاد باشد، تعداد سری‌ها افزایش می‌یابد.
در طراحی معیار، واحد را روشن و ثابت نگه دارید. مخلوط کردن میلی‌ثانیه و ثانیه یا بایت و کیلوبایت می‌تواند آستانه هشدار را چند برابر جابه‌جا کند. نام و توضیح معیار باید برای تیم دیگر نیز قابل فهم باشد. برای معیار تجاری، تعریف رخداد را دقیق بنویسید: آیا درخواست ناموفق هم در مجموع شمرده می‌شود؟ آیا تکرار داخلی یک درخواست دوباره حساب می‌شود؟ بدون این تعریف، نسبت خطای محاسبه‌شده ممکن است از نظر ریاضی درست و از نظر معنایی گمراه‌کننده باشد.
قوانین ثبت و قوانین هشدار
یک پرس‌وجوی سنگین که در چند داشبورد تکرار می‌شود ممکن است به قانون ثبت مناسب نیاز داشته باشد. قانون ثبت، نتیجه محاسبه را به صورت سری تازه نگه می‌دارد و می‌تواند استفاده بعدی را ساده‌تر کند. اما نام‌گذاری و برچسب نتیجه باید دقیق باشد تا معلوم باشد چه تجمیعی انجام شده است. حذف برچسب محیط یا منطقه هنگام تجمیع ممکن است تفاوت محلی را پنهان کند. پیش از جایگزین کردن پرس‌وجوی اصلی، نتیجه قانون را با داده نمونه و چند وضعیت مرزی مقایسه کنید.
قانون هشدار نقش متفاوتی دارد: شرایط نیازمند اقدام را شناسایی می‌کند. ارسال اعلان به گیرنده، گروه‌بندی و سکوت‌گذاری در لایه Alertmanager انجام می‌شود. اگر شرط فعال است ولی پیام نرسیده، باید مرز میان تشخیص و تحویل را بررسی کنید. آزمایش کامل شامل ایجاد علامت واقعی، مشاهده وضعیت هشدار و دریافت اعلان است. دکمه ارسال پیام آزمایشی فقط بخش آخر را می‌سنجد و صحت عبارت یا جمع‌آوری داده را اثبات نمی‌کند.
نبود داده و خطای ابزار پایش
نمودار صاف روی صفر ممکن است سالم بودن خدمت را نشان دهد، ولی نمودار بدون نمونه معنای دیگری دارد. باید میان صفر واقعی، هدف حذف‌شده، دریافت ناموفق و سری قدیمی تمایز بگذارید. در پرس‌وجوهایی که چند سری را ترکیب می‌کنند، نبود یک طرف ممکن است کل نتیجه را حذف کند. برای رفع این وضعیت، ابتدا معنا را مشخص کنید و سپس رفتار جایگزینی داده را طراحی کنید. تبدیل همه نبودها به صفر می‌تواند خرابی پایش را به عنوان سلامت نمایش دهد.
خود Prometheus نیز باید پایش شود. فشار حافظه، پر شدن دیسک، زمان طولانی ارزیابی و عقب افتادن جمع‌آوری می‌توانند کیفیت داده را کاهش دهند. اگر سامانه پایش تنها ناظر خودش باشد، خرابی کامل آن ممکن است بی‌صدا بماند. یک مسیر مستقل برای تشخیص نبود آن در نظر بگیرید. همچنین دسترسی نوشتن به تنظیمات و قواعد را محدود کنید؛ تغییر یک قانون می‌تواند حساسیت عملیات را بدون تغییر خود خدمت کاهش دهد.
ذخیره‌سازی، نگهداری و انتقال
دوره نگهداری باید با نیاز تحلیل و ظرفیت واقعی هماهنگ باشد. کاهش نگهداری برای رفع فوری کمبود دیسک ممکن است داده لازم بررسی حادثه را حذف کند. پیش از بحران، نرخ رشد و فضای آزاد را پایش کنید. اگر داده به مقصد دیگری ارسال می‌شود، صف و خطاهای انتقال را نیز ببینید. موفقیت جمع‌آوری محلی الزاماً به معنی کامل بودن نسخه دوردست نیست. در قطعی طولانی، رفتار بافر و ظرفیت مقصد تعیین می‌کند چه مقدار داده حفظ خواهد شد.
Prometheus را جایگزین همه انواع ثبت رویداد ندانید. برای حسابرسی کامل رخدادهای منفرد یا محاسبه مالی که از دست رفتن یک رخداد قابل قبول نیست، مدل نمونه‌برداری معیار به تنهایی کافی نیست. از آن برای مشاهده وضعیت و روند و تشخیص مسئله استفاده کنید و جزئیات لازم را در سامانه مناسب نگه دارید. معیار پذیرش معماری این است که تیم بتواند از یک نمودار غیرعادی به هدف، معیار و علت جمع‌آوری برسد و بداند کدام نتیجه قطعی و کدام نتیجه وابسته به نمونه‌های موجود است.
بازبینی یک داشبورد تازه
پیش از تحویل داشبورد، هر نمودار را به یک سؤال مشخص وصل کنید. نمودار تعداد درخواست باید معلوم کند مجموع کدام نمونه‌ها و کدام محیط را نمایش می‌دهد. نمودار تأخیر باید واحد، بازه محاسبه و نوع تجمیع را روشن کند. از یک بازه زمانی سالم و یک بازه خطای ساختگی برای بررسی استفاده کنید. اگر با حذف یک هدف نمودار ناگهان بهتر می‌شود، احتمال دارد خرابی جمع‌آوری از محاسبه حذف شده باشد. این آزمون کوچک نشان می‌دهد آیا تصویر ارائه‌شده واقعاً وضعیت خدمت را بیان می‌کند یا فقط وضعیت هدف‌هایی را که هنوز موفق به ارسال داده هستند.
