آشنایی با هشدار

ساخت وبلاگ

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

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

سیاستهای هشدار دهنده ای که برای ردیابی داده های متریک جمع آوری شده توسط نظارت بر ابر استفاده می شود ، سیاست های هشدار دهنده مبتنی بر متریک نامیده می شوند. بیشتر مستندات نظارت بر ابر در مورد سیاست های هشدار دهنده فرض می کنند که شما از سیاست های هشدار دهنده مبتنی بر متریک استفاده می کنید. برای یادگیری نحوه تنظیم یک خط مشی هشدار مبتنی بر متریک ، QuickStart را برای Compute Engine امتحان کنید.

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

هشدار چگونه کار می کند

هر خط مشی هشدار موارد زیر را مشخص می کند:

 

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

     

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

یک سیاست هشدار دهنده باید حداقل یک شرط داشته باشد. با این حال ، می توانید یک خط مشی را برای حاوی چندین شرایط پیکربندی کنید.

## پاسخ تأخیر HTTP این هشدار با استفاده از متغیر $ $ از پروژه $ سرچشمه گرفته است.

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

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

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

مثال

شما یک برنامه وب را بر روی نمونه ماشین مجازی موتور محاسباتی (VM) مستقر می کنید که یک برنامه وب را اجرا می کند. در حالی که شما انتظار دارید که تأخیر پاسخ HTTP در نوسان باشد ، می خواهید تیم پشتیبانی شما وقتی برنامه برای یک دوره زمانی قابل توجه تأخیر بالایی دارد ، پاسخ دهد.

برای اطمینان از اطلاع از تیم پشتیبانی شما در هنگام تجربه برنامه های شما ، سیاست هشدار زیر را ایجاد می کنید:

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

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

برنامه وب شما محبوب است و تأخیر پاسخ بیش از دو ثانیه رشد می کند. در اینجا نحوه پاسخگویی به سیاست هشدار شما آمده است:

  1. نظارت هنگامی که یک اندازه گیری تأخیر HTTP بالاتر از دو ثانیه دریافت می کند ، یک تایمر پنج دقیقه ای را شروع می کند.
  2. اگر هر اندازه گیری تأخیر دریافت شده طی پنج دقیقه آینده بالاتر از دو ثانیه باشد ، تایمر منقضی می شود. هنگامی که تایمر منقضی می شود ، شرط تحریک می شود و نظارت بر یک حادثه باز می شود و یک ایمیل به تیم پشتیبانی شما می فرستد.
  3. تیم پشتیبانی شما ایمیل را دریافت می کند ، وارد کنسول Google Cloud می شود و دریافت اعلان را تأیید می کند.
  4. به دنبال مستندات موجود در ایمیل اعلان ، تیم پشتیبانی شما قادر به پرداختن به علت تأخیر است. طی چند دقیقه ، تأخیر پاسخ HTTP به کمتر از دو ثانیه کاهش می یابد.
  5. هنگام نظارت ، اندازه گیری تأخیر HTTP کمتر از دو ثانیه دریافت می کند ، این حادثه را می بندد و یک اعلان را به تیم پشتیبانی شما ارسال می کند که این حادثه بسته است.

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

نحوه اضافه کردن یک سیاست هشدار دهنده

شما می توانید با استفاده از کنسول Google Cloud ، API مانیتورینگ ابر یا Google Cloud CLI ، یک خط مشی هشدار مبتنی بر متریک خود اضافه کنید:

  • هنگامی که از کنسول Google Cloud استفاده می کنید ، می توانید یک هشدار توصیه شده را فعال کنید یا می توانید با شروع از صفحه هشدارها نظارت بر ابر ، هشدار ایجاد کنید. برای اطلاعات ، با استفاده از کنسول Google Cloud ، به ایجاد خط مشی هشدار مبتنی بر متریک مراجعه کنید. هشدارهای توصیه شده برای برخی از محصولات Google Cloud در دسترس است. این هشدارها نیاز به پیکربندی حداقل دارند ، مانند اضافه کردن کانال های اعلان. به عنوان مثال ، پیوندهای صفحه مباحث Pub/Sub Lite به هشدارهایی که پیکربندی شده اند تا هنگام رسیدن به حد سهمیه به شما اطلاع دهند. به همین ترتیب ، صفحه نمونه های VM از درون پیوندهای نظارت به هشدار دادن به خط مشی هایی که برای نظارت بر استفاده از حافظه و تأخیر شبکه آن موارد پیکربندی شده اند. هر سیاستی که با استفاده از کنسول Google Cloud ایجاد می کنید ، می توانید با استفاده از کنسول Google Cloud یا API مانیتورینگ Cloud ، تغییر و مشاهده کنید. API مانیتورینگ ابر به شما امکان می دهد سیاست های هشدار دهنده ای ایجاد کنید که نسبت معیارها را کنترل می کند. هنگامی که این خط مشی ها از فیلترهای مانیتورینگ استفاده می کنند ، نمی توانید با استفاده از کنسول Google Cloud آنها را مشاهده یا اصلاح کنید.
  • هنگامی که از API مانیتورینگ ابر مستقیم یا هنگام استفاده از Google Cloud CLI استفاده می کنید ، می توانید سیاست های هشدار دهنده را ایجاد ، مشاهده و اصلاح کنید. برای اطلاعات بیشتر ، با استفاده از API مانیتورینگ Cloud یا Google Cloud CLI ، به ایجاد سیاست های هشدار دهنده مراجعه کنید. می توانید شرایطی را ایجاد کنید که یک متریک ، معیارهای مختلف یا نسبت معیارها را کنترل کند. هنگامی که از API مانیتورینگ Cloud استفاده می کنید ، می توانید با استفاده از نظارت بر زبان پرس و جو (MQL) یا با استفاده از فیلترهای نظارت ، این نسبت را مشخص کنید. برای نمونه ای از سیاستی که از فیلترهای نظارت استفاده می کند ، به نسبت متریک مراجعه کنید.

مانیتورینگ ابر از یک زبان بیانی و مبتنی بر متن پشتیبانی می کند که می تواند با کنسول Google Cloud و با API مانیتورینگ ابر استفاده شود. برای اطلاعات در مورد استفاده از این زبان با هشدار ، با استفاده از نظارت بر زبان پرس و جو (MQL) به ایجاد سیاست های هشدار دهنده مراجعه کنید.

می توانید با استفاده از Logs Explorer در ورود به سیستم Cloud یا با استفاده از API مانیتورینگ ، یک خط مشی هشدار مبتنی بر ورود به سیستم Google Cloud خود اضافه کنید. این محتوا در مورد سیاست های هشدار دهنده مبتنی بر ورود به سیستم صدق نمی کند. برای کسب اطلاعات در مورد خط مشی های هشدار دهنده مبتنی بر ورود به سیستم ، به نظارت بر سیاهههای مربوطه مراجعه کنید.

نحوه مدیریت سیاست های هشدار دهنده

برای کسب اطلاعات در مورد نحوه مشاهده لیستی از سیاست های هشدار دهنده مبتنی بر متریک پروژه ، و نحوه اصلاح این سیاست ها ، به موارد زیر مراجعه کنید:

  • مدیریت سیاست های هشدار با استفاده از کنسول Google Cloud
  • مدیریت سیاست های هشدار دهنده با استفاده از API Monitoring Cloud یا Google Cloud CLI

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

مجوز لازم برای ایجاد خط مشی های هشدار

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

این بخش نقش ها یا مجوزهای مورد نیاز برای ایجاد یک خط مشی هشدار را توضیح می دهد. برای اطلاعات دقیق درباره مدیریت هویت و دسترسی (IAM) برای نظارت بر ابر، به کنترل دسترسی مراجعه کنید.

هر نقش IAM یک شناسه و یک نام دارد. شناسه های نقش دارای فرم roles/monitoring. editor هستند و هنگام پیکربندی کنترل دسترسی به عنوان آرگومان به Google Cloud CLI ارسال می شوند. برای اطلاعات بیشتر، اعطا، تغییر و لغو دسترسی را ببینید. کنسول Google Cloud نام نقش ها را نمایش می دهد، مانند ویرایشگر نظارت.

نقش های مورد نیاز کنسول Google Cloud

برای ایجاد یک خط مشی هشدار، نام نقش IAM شما برای پروژه Google Cloud باید یکی از موارد زیر باشد:

  • ویرایشگر نظارت
  • مدیریت نظارت
  • صاحب پروژه

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

مجوزهای API مورد نیاز

برای استفاده از Cloud Monitoring API برای ایجاد خط مشی هشدار، شناسه نقش IAM شما برای پروژه Google Cloud باید یکی از موارد زیر باشد:

  • roles/monitoring. alertPolicyEditor: این شناسه نقش حداقل مجوزهایی را که برای ایجاد یک خط مشی هشدار لازم است را اعطا می کند. برای جزئیات بیشتر در مورد این نقش، نقش های هشدار از پیش تعریف شده را ببینید.
  • roles/monitoring. editor
  • roles/monitoring. admin
  • نقش/مالک

برای شناسایی مجوز مورد نیاز برای یک روش خاص Cloud Monitoring API، به مجوزهای Cloud Monitoring API مراجعه کنید. برای مشاهده لیستی از نقش ها و مجوزهای مرتبط با آنها، به نقش ها مراجعه کنید.

تعیین نقش شما

برای تعیین نقش خود برای یک پروژه با استفاده از کنسول Google Cloud، موارد زیر را انجام دهید:

  1. کنسول Google Cloud را باز کنید و پروژه Google Cloud را انتخاب کنید: به کنسول Google Cloud بروید
  2. برای مشاهده نقش خود، روی IAM & admin کلیک کنید. نقش شما در همان خط نام کاربری شما قرار دارد.

برای تعیین مجوزهای سطح سازمان خود، با سرپرست سازمان خود تماس بگیرید.

هزینه های مرتبط با سیاست های هشدار

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

محدودیت های زیر برای استفاده شما از خط مشی های هشدار و بررسی های زمان کار اعمال می شود:

 

دسته بندی ارزش نوع سیاست 1
خط مشی های هشدار (مجموع متریک و گزارش) در هر محدوده سنجه 2 500 متریک، گزارش
شرایط بر اساس خط مشی هشدار 6 متریک
حداکثر دوره زمانی که یک شرط عدم وجود متریک ارزیابی می کند 3 1 روز متریک
حداکثر مدت زمانی که یک شرایط آستانه متریک 3 ارزیابی می کند 23 ساعت 30 دقیقه متریک
حداکثر تعداد سری زمانی که توسط یک شرایط پیش بینی کنترل می شود 64 متریک
حداقل پنجره پیش بینی 1 ساعت (3600 ثانیه) متریک
حداکثر پنجره پیش بینی 7 روز (604. 800 ثانیه) متریک
کانال های اعلان در هر سیاست هشدار 16 متریک، گزارش
حداکثر نرخ اعلان ها 1 اعلان هر 5 دقیقه برای هر هشدار مبتنی بر ورود به سیستم ورود به سیستم
حداکثر تعداد اعلان ها 20 اعلان در روز برای هر هشدار مبتنی بر ورود به سیستم ورود به سیستم
حداکثر تعداد حوادث به طور همزمان در هر سیاست هشدار 1000 متریک
دوره ای که پس از آن یک حادثه بدون داده جدید به طور خودکار بسته می شود 7 روز متریک
حداکثر مدت حادثه در صورت عدم بسته شدن دستی 7 روز ورود به سیستم
حفظ حوادث بسته 13 ماه قابل اجرا نیست
حفظ حوادث باز نامعین قابل اجرا نیست
کانال های اعلان در هر محدوده معیارها 4000 قابل اجرا نیست
بررسی های به روز در هر اندازه گیری 4 100 قابل اجرا نیست
حداکثر تعداد پینگ های ICMP در هر بررسی به روزرسانی عمومی 3 قابل اجرا نیست

1 متریک: یک خط مشی هشدار بر اساس داده های متریک ؛ورود به سیستم: یک خط مشی هشدار دهنده بر اساس پیام های ورود به سیستم (هشدارهای مبتنی بر ورود به سیستم) 2 Apigee و Apigee Hybrid عمیقاً با نظارت ابر یکپارچه شده اند. حد هشدار دهنده برای کلیه سطوح اشتراک Apigee - Standard ، Enterprise و Enterprise Plus - همان است که برای نظارت بر ابر: 500 در هر محدوده اندازه گیری. 3 حداکثر مدت زمانی که یک شرط ارزیابی می کند ، مجموع دوره تراز و مقادیر پنجره مدت است. به عنوان مثال ، اگر دوره تراز به 15 ساعت تنظیم شود و پنجره مدت 15 ساعت تنظیم شده باشد ، برای ارزیابی شرایط به 30 ساعت داده نیاز است. 4 این حد مربوط به تعداد تنظیمات چک به روز است. هر پیکربندی چک به موقع شامل فاصله زمانی بین آزمایش وضعیت منبع مشخص شده است. برای اطلاعات بیشتر به مدیریت چک های Uptime مراجعه کنید.

چه بعدی است

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

    به جز آنچه در غیر این صورت ذکر شد ، محتوای این صفحه تحت مجوز Creative Commons Attribution 4. 0 مجوز دارد و نمونه های کد تحت مجوز Apache 2. 0 مجوز دارند. برای جزئیات بیشتر ، به سیاست های سایت Google Developers مراجعه کنید. جاوا یک علامت تجاری ثبت شده اوراکل و/یا شرکت های وابسته به آن است.

    آخرین به روز شده 2023-03-03 UTC.

تجارت با گزینه‌‌های باینری...
ما را در سایت تجارت با گزینه‌‌های باینری دنبال می کنید

برچسب : نویسنده : حمیدرضا پگاه بازدید : 27 تاريخ : چهارشنبه 7 تير 1402 ساعت: 18:46