اینکه چه بازه ای برای تابع rate استفاده شود میتواند سوال برانگیز شود.
به صورت یک قانون کلی میتوان گفت بازه مربوط به rate باید حداقل 4 برابر scrape interval باشد. در این صورت در سناریوهای مختلف به مشکل نمیخوریم و در برابر یک scrape ناموفق مقاوم خواهیم بود.
در نظر بگیریم که scrape interval ما ده ثانیه باشد و scrapeها در زمان t=0 شروع شده باشند. تابع rate حداقل به دو نمونه نیاز دارد تا بتواند کار کند، پس برای یک query در زمان t=10 نیازمند گذشتن یک دوره
scrape interval هستیم. در زمان t=20، ممکن است scrape به صورت کامل ingest نشده باشد. این مسئله راجع به scrape interval سوم یعنی تا زمان t=30 هم ممکن است صادق باشد، پس برای اطمینان خاطر جهت همین مسئله به سه بازه scrape interval نیاز داریم. در نهایت در صورتی که میخواهیم نسبت به یک failed scrape هم مقاوم باشیم لازم است یک scrape interval دیگر را نیز در نظر بگیریم که در مجموع به 4 scrape interval میرسیم. معمولا برای رند کردن این عدد بازه یک دقیقه در نظر گرفته میشود.
مسئله دیگر این است که اگر برای مثال جهت گراف کردن از query_range استفاده میکنیم، این رنج باید حداقل اندازه یک step باشد در غیر این صورت بعضی از داده ها در نظر گرفته نمی شوند. متغیر rate__interval__$ مربوط به گرافانا میتواند در این شرایط مفید واقع شود.
از طرف دیگر نباید بازه range را بیش از حد بزرگ در نظر گرفت. برای نمونه اگر برای یک rate بازه ای یک ساعته در نظر بگیریم و بر اساس آن اخطار اعلان کنیم همه چیز خوب پیش میرود اما در صورتی که شرط مربوط متوقف شود لازم است یک ساعت منتظر بمانیم تا اخطار از بین برود. پس از یک طرف بازه های طولانی تر موجب می شوند که نقاط trend بهتر شناسایی شوند اما از طرف دیگر زمان بازخورد دادن را زیاد میکند.
ضمنا در صورتی که میخوایم در بازه های مختلف میانگین گیری کنید، برای هر بازه‌ی ممکن recording rules نسازید. این کار ضمن اینکه پر زحمت و خطابرانگیز است، گیج کننده هم هست و نگه داری سختی هم در پیش خواهد داشت. بهتر است در بازه های معقولی مثل یک دقیقه دو دقیقه یا پنج دقیقه recording rule بسازید و برای بازه های طولانی تر از avg_over_time بر روی آن ها جهت بهره بری روی گراف ها و اخطارها استفاده کنید.
کل مطلب را به این صورت میتوان خلاصه کرد که بازه هایی حداقل چهار برابر scrape_interval استفاده کنید، در سازمانتان از یک یا چند بازه زمانی ثابت در recording rules استفاده کنید و برای بازه های طولانی تر از avg_over_time استفاده کنید.
