چرا این موضوع مهم است؟
Prometheus rule یک expression را در بازه‌های زمانی ارزیابی می‌کند. شرط alert باید metric و context کافی داشته باشد و با for می‌توان از تبدیل spike کوتاه به incident جلوگیری کرد. labelها routing و grouping را در Alertmanager ممکن می‌کنند.
در یک سیستم واقعی، قبل از انتخاب ابزار باید مدل ذهنی درستی از لایه‌ها داشته باشید. هر بار که یک مشکل را فقط با یک command یا تنظیم حفظی حل می‌کنیم، دانش به نسخه و محیط خاص گره می‌خورد. روش بهتر این است که ورودی، state، policy، مسیر داده و خروجی را مشخص کنیم. بعد ابزار را برای مشاهدهٔ یکی از این لایه‌ها انتخاب کنیم. این رویکرد باعث می‌شود وقتی نسخه یا توزیع عوض شد، هنوز بدانیم دنبال چه evidenceای هستیم.
مدل معماری
در موضوع طراحی alertهای قابل اقدام در Prometheus و کاهش alert fatigue، componentها را روی یک مسیر ساده بکشید و مرز مسئولیت هرکدام را مشخص کنید. state پایدار، state runtime، dependency بیرونی و نقطهٔ اعمال policy را جدا کنید. وقتی diagram ساده دارید، خطا از یک «سیستم بزرگ و مبهم» به چند مرحلهٔ قابل آزمون تبدیل می‌شود.
روش عملی کار
برای هر alert یک owner، impact و runbook مشخص کنید. threshold را از SLO یا ظرفیت واقعی استخراج کنید، نه عدد تصادفی. alertهای warning و critical را به action متفاوت وصل کنید و message را شامل cluster/service/instance قابل جست‌وجو بسازید.
برای Production، تغییر باید قابل اندازه‌گیری و قابل برگشت باشد. baseline قبل از تغییر شامل نسخه، config مؤثر، log سالم، metric اصلی و یک تست end-to-end است. rollout را با canary شروع کنید؛ بعد از هر مرحله هم تست مثبت و هم تست منفی داشته باشید. اگر success criterion از قبل نوشته نشده باشد، بعد از اجرا به‌سادگی هر نتیجه‌ای را می‌توان «موفق» تفسیر کرد. rollback هم باید تمرین شود، نه اینکه فقط یک دستور روی کاغذ باشد.
از دید امنیت
Alert روی symptom مبهم یا metric پرنوسان به‌سرعت بی‌اعتماد می‌شود. cardinality زیاد در label، expression سنگین و duplicate alert از چند rule هم هزینهٔ monitoring را بالا می‌برد.
از دید امنیت، کم‌کردن سطح دسترسی مهم است اما availability و قابلیت عیب‌یابی هم جزو امنیت عملیاتی‌اند. secretها، tokenها، capabilityها، network path و logهای حساس را جدا بررسی کنید. هر exception باید owner، دلیل و تاریخ بازبینی داشته باشد. کنترل‌هایی که هیچ‌کس نمی‌تواند اثرشان را مشاهده یا علتشان را توضیح دهد، در زمان incident به مانع تبدیل می‌شوند.
آزمایشگاه پیشنهادی
یک metric آزمایشی بسازید، threshold را عمداً رد کنید و for را از صفر به چند دقیقه تغییر دهید. سپس grouping Alertmanager را تست و زمان از failure تا notification را ثبت کنید.
برای هر مرحله timestamp و خروجی را ذخیره کنید. یک failure کنترل‌شده ایجاد کنید تا مطمئن شوید monitoring واقعاً failure را می‌بیند. سپس سیستم را به baseline برگردانید و زمان recovery را ثبت کنید.
عیب‌یابی بر پایهٔ Evidence
Troubleshooting را با تغییر config شروع نکنید. اول محل دقیق failure را پیدا کنید: آیا ورودی وارد سیستم می‌شود؟ آیا state مورد انتظار ساخته شده؟ آیا policy اجازه می‌دهد؟ آیا خروجی از component خارج می‌شود؟ log، packet capture، metric و state API باید به یک timeline مشترک وصل شوند. نبودن event نیز evidence است؛ اگر request قبل از یک component دیده می‌شود و بعد از آن نه، دامنهٔ مسئله کوچک شده است.
Performance و ظرفیت
عملکرد را فقط با average نسنجید. p95/p99 latency، saturation، queue depth، retry و resource pressure تصویر بهتری می‌دهند. تغییری که در lab کوچک سریع است ممکن است زیر concurrency یا dataset واقعی bottleneck متفاوتی نشان دهد. capacity limitها را قبل از rollout بزرگ شناسایی کنید و alert را به thresholdهای قابل اقدام وصل کنید.
Production readiness
قبل از rollout نهایی، owner، change window، blast radius، success metric و rollback trigger باید مشخص باشند. اگر dependency خارجی دارید، رفتار هنگام timeout یا unavailable شدن آن را تست کنید. اگر config به چند host می‌رود، rollout مرحله‌ای و inventory دقیق لازم است. یک تغییر خوب باید observable، explainable و reversible باشد.
Runbook و انتقال دانش
در مستندسازی، فقط «چه دستورهایی اجرا شد» را ننویسید. سؤال، فرضیه، evidence مورد انتظار، نتیجه و دلیل تصمیم را ثبت کنید. اگر همکار دیگری بتواند با همان ورودی آزمایش را تکرار کند و به نتیجهٔ مشابه برسد، runbook ارزش عملیاتی دارد. اگر فقط نویسنده می‌داند چرا مرحله‌ای لازم است، دانش هنوز منتقل نشده است.
قبل از Production چه چیزی را اعتبارسنجی کنیم؟
نتیجهٔ Lab را مستقیم به Production تعمیم ندهید. یک change plan کوتاه بسازید که در آن دامنهٔ تغییر، owner، زمان اجرا، dependencyها، success metric و rollback trigger مشخص باشد. ابتدا روی canary یا درصد کوچکی از workload اجرا کنید و حداقل یک چرخهٔ واقعی restart، credential rotation یا deploy دوم را ببینید؛ بسیاری از خطاها در اولین اجرای سالم ظاهر نمی‌شوند. رفتار هنگام unavailable شدن dependency خارجی، پر شدن disk، timeout شبکه و ورودی نامعتبر را نیز بررسی کنید. اگر feature امنیتی است، test منفی باید نشان دهد مسیر غیرمجاز واقعاً بسته است؛ اگر feature performance است، benchmark باید با load و dataset نزدیک به واقعیت اجرا شود. در پایان، تصمیم rollout را با evidence ثبت کنید، نه با جملهٔ مبهم «به‌نظر خوب است».
نگهداری بلندمدت و بازبینی دوره‌ای
معماری بعد از deploy ثابت نمی‌ماند. نسخهٔ سیستم‌عامل، dependency، policy سازمان، certificate، endpoint و حجم workload تغییر می‌کنند. برای همین باید بازبینی دوره‌ای تعریف شود: نسخه‌های پشتیبانی‌نشده را پیدا کنید، exceptionهای قدیمی را ببندید، alertهای بی‌ارزش را حذف کنید و recovery را دوباره تمرین کنید. اگر configuration در Git نگهداری می‌شود، drift میان state واقعی و repository را اندازه بگیرید. اگر ابزار SaaS یا سرویس خارجی است، تغییر API، pricing، limit و مدل permission را دنبال کنید. مستندات باید تاریخ review داشته باشند تا تیم بداند کدام فرض‌ها هنوز معتبرند. نگهداری خوب یعنی سیستم بعد از شش ماه هم قابل توضیح و قابل بازیابی باشد، نه اینکه فقط روز اول deploy موفق بوده باشد.
جمع‌بندی
هدف این مقاله دربارهٔ طراحی alertهای قابل اقدام در Prometheus و کاهش alert fatigue ارائهٔ یک دستور جادویی نیست؛ هدف ساختن مدل ذهنی است. وقتی معماری را بفهمید، baseline داشته باشید و تغییر را با evidence کوچک کنید، ابزارها قابل تعویض می‌شوند اما روش حل مسئله باقی می‌ماند. منبع اصلی این مقاله از Prometheus انتخاب شده تا جزئیات فنی قابل پیگیری باشند.
چک‌لیست سریع
- مسئله را در یک جمله تعریف کن.
- component و مرز اعتماد را مشخص کن.
- baseline را قبل از تغییر ذخیره کن.
- یک test مثبت و یک test منفی بساز.
- تغییر را با canary شروع کن.
- evidence را timestampدار نگه دار.
- rollback را واقعاً تمرین کن.
- نتیجه و exceptionها را در runbook ثبت کن.
یک هشدار را از لحظه خرابی تا پیام نهایی دنبال کنید
فرض کنید نرخ خطای یک خدمت از حد قابل قبول عبور می‌کند. نخست باید نمونه‌های مربوط در زمان مناسب جمع‌آوری شوند. سپس عبارت قانون در دوره ارزیابی اجرا می‌شود و برای هر مجموعه برچسب واجد شرط، نمونه هشدار می‌سازد. اگر زمان انتظار تعریف شده باشد، شرط باید در ارزیابی‌های متوالی برقرار بماند تا هشدار فعال شود. پس از آن، Alertmanager با توجه به مسیر، گروه‌بندی و زمان انتظار خود تصمیم به ارسال اعلان می‌گیرد. بنابراین زمان رسیدن پیام فقط برابر مقدار for نیست؛ فاصله جمع‌آوری، ارزیابی و سیاست اعلان هم در آن نقش دارند.
برای آزمایش، از یک خدمت مصنوعی با نرخ خطای قابل کنترل استفاده کنید. ابتدا خطایی کوتاه‌تر از زمان انتظار ایجاد کنید و انتظار داشته باشید هشدار به مرحله ارسال نرسد. سپس خطا را به اندازه کافی ادامه دهید و زمان شروع مشکل، ورود به حالت انتظار، فعال شدن و دریافت پیام را جدا ثبت کنید. اگر پیام دیر رسید، همین زمان‌ها مشخص می‌کنند تأخیر در تشخیص بوده یا در تحویل اعلان. آزمایش صرف ارسال پیام آزمایشی، مسیر کامل تشخیص را پوشش نمی‌دهد.
برچسب ثابت، توضیح متغیر
هویت هشدار از مجموعه برچسب‌های آن تأثیر می‌گیرد. اگر مقدار لحظه‌ای اندازه‌گیری را به عنوان برچسب قرار دهید، با تغییر عدد ممکن است هویت تازه‌ای بسازید. چنین طراحی می‌تواند گروه‌بندی را به هم بزند و زمان انتظار را از نظر عملی بی‌اثر کند. اطلاعاتی مانند خدمت، محیط و شدت برای برچسب مناسب‌ترند؛ مقدار جاری، توضیح خطا و راهنمای اقدام را در توضیحات قرار دهید. همچنین برچسبی که مقدار آن از شناسه هر درخواست یا کاربر می‌آید، تعداد سری‌ها و هشدارها را بی‌جهت زیاد می‌کند.
در طراحی عبارت، مخرج نرخ خطا را فراموش نکنید. یک خطا از یک درخواست با صد خطا از هزاران درخواست از نظر اثر و اطمینان آماری یکسان نیست. برای خدمت کم‌ترافیک ممکن است یک پنجره کوتاه نتیجه ناپایدار بدهد. پنجره باید با الگوی مصرف و زمان قابل تحمل تشخیص هماهنگ شود. اگر معیار بر اساس شمارنده است، کاهش مقدار پس از راه‌اندازی دوباره را به عنوان موفقیت ناگهانی تفسیر نکنید؛ از تابع مناسب نرخ تغییر استفاده کنید و رفتار داده آزمایشی را بررسی کنید.
نبود داده را با سالم بودن اشتباه نگیرید
عبارتی که در نبود سری هیچ خروجی نمی‌دهد، الزاماً هشدار خرابی تولید نمی‌کند. اگر صادرکننده معیار یا خود مسیر جمع‌آوری قطع شود، قانون خطای خدمت ممکن است ساکت بماند. برای همین سلامت جمع‌آوری و سلامت خدمت دو مسئله جدا هستند. وضعیت هدف، تازگی داده و وجود سری مورد انتظار را بررسی کنید. با خاموش کردن عمدی هدف آزمایشی نشان دهید کدام هشدار مسئول این حالت است. اگر برای هر هدف یک قانون غیبت می‌سازید، تغییرات موجودی را هم در نظر بگیرید تا حذف برنامه‌ریزی‌شده یک نمونه طوفان هشدار ایجاد نکند.
هنگام خاموشی بزرگ، تعداد زیادی هشدار وابسته ممکن است از یک علت ریشه‌ای ناشی شوند. گروه‌بندی پیام‌ها می‌تواند تعداد اعلان‌ها را کم کند؛ مهار هشدار وابسته نیز می‌تواند مانع اعلام همزمان علائم فرعی شود. اما شرط مهار باید دقیق باشد. اگر هشدار یک مرکز داده باعث پنهان شدن خطای مرکز دیگر شود، کاهش سروصدا به قیمت از دست دادن دید رخ داده است. برای هر قاعده مهار، یک نمونه مجاز و یک نمونه غیرمرتبط آزمایش کنید.
راهنمای اقدام را جزئی از قانون بدانید
متن پیام باید پاسخ دهد چه چیزی آسیب دیده، چه کسی مسئول است و نخستین مشاهده مفید چیست. لینک یک داشبورد کلی با صدها نمودار کافی نیست. مسیر مستقیم به خدمت و بازه زمانی، همراه با یک راهنمای کوتاه بررسی وابستگی‌ها، زمان واکنش را کم می‌کند. در راهنما دستور مخرب یا افزایش ظرفیت نامحدود را به عنوان اقدام پیش‌فرض ننویسید. ابتدا مشاهده‌ای پیشنهاد کنید که دو علت محتمل را از هم جدا کند. پس از هر رخداد، بررسی کنید آیا هشدار پیش از گزارش کاربر رسیده و آیا گیرنده توان انجام اقدام مشخص داشته است؛ همین دو سؤال ارزش قانون را بهتر از تعداد پیام‌های ارسالی نشان می‌دهند.
