1. مقدمه
آخرین به روز رسانی: 2023-07-28
Google Cloud Operations Suite چیست؟
Google Cloud Operations Suite پلتفرمی است که در آن می‌توانید عملکرد برنامه را در محیط Google Cloud خود نظارت، عیب‌یابی و بهبود بخشید. ستون‌های کلیدی مجموعه عملیات ابری شامل مانیتورینگ ابری، ثبت گزارش ابری و ردیابی ابری است.
برای دریافت نمای کلی از عملیات Google Cloud این ویدیو را ببینید.
چیزی که خواهی ساخت
در این لبه کد، شما قصد دارید یک API نمونه را در Google Cloud مستقر کنید. سپس چندین ویژگی را در Cloud Monitoring در مقابل API بررسی و پیکربندی خواهید کرد.
چیزی که یاد خواهید گرفت
- استفاده از Google Cloud's Cloud Shell برای استقرار یک برنامه نمونه در Cloud Run.
- استفاده از ویژگی‌های Google Cloud Monitoring مانند داشبورد، هشدارها، بررسی‌های آپتایم، نظارت بر SLI/SLO و موارد دیگر.
آنچه شما نیاز دارید
- نسخه اخیر Chrome (74 یا بالاتر)
- یک حساب Google Cloud و پروژه Google Cloud
2. راه اندازی و الزامات
تنظیم محیط خود به خود
اگر قبلاً یک حساب Google (Gmail یا Google Apps) ندارید، باید یک حساب ایجاد کنید . به کنسول Google Cloud Platform ( consol.cloud.google.com ) وارد شوید و یک پروژه جدید ایجاد کنید.
- نام پروژه نام نمایشی برای شرکت کنندگان این پروژه است. این یک رشته کاراکتری است که توسط API های Google استفاده نمی شود. شما می توانید آن را در هر زمان به روز کنید.
- شناسه پروژه باید در تمام پروژه‌های Google Cloud منحصربه‌فرد باشد و تغییرناپذیر باشد (پس از تنظیم نمی‌توان آن را تغییر داد). Cloud Console به طور خودکار یک رشته منحصر به فرد تولید می کند. معمولاً برای شما مهم نیست که چیست. در اکثر کد لبه‌ها، باید به شناسه پروژه اشاره کنید (معمولاً به عنوان PROJECT_ID شناخته می‌شود). اگر شناسه تولید شده را دوست ندارید، ممکن است یک شناسه تصادفی دیگر ایجاد کنید. از طرف دیگر، می‌توانید خودتان را امتحان کنید و ببینید آیا در دسترس است یا خیر. پس از این مرحله نمی توان آن را تغییر داد و در طول مدت پروژه باقی می ماند.
- برای اطلاع شما، یک مقدار سوم وجود دارد، یک شماره پروژه که برخی از API ها از آن استفاده می کنند. در مورد هر سه این مقادیر در مستندات بیشتر بیاموزید.
احتیاط: شناسه پروژه باید در سطح جهانی منحصر به فرد باشد و پس از انتخاب شما توسط شخص دیگری قابل استفاده نباشد. شما تنها کاربر آن شناسه هستید. حتی اگر پروژه ای حذف شود، ID هرگز نمی تواند دوباره استفاده شود
- در مرحله بعد، برای استفاده از منابع Cloud/APIها باید صورتحساب را در کنسول Cloud فعال کنید . اجرا کردن از طریق این کد لبه نباید هزینه زیادی داشته باشد، اگر اصلاً باشد. برای اینکه منابع را خاموش کنید تا بیش از این آموزش متحمل صورتحساب نشوید، می توانید منابعی را که ایجاد کرده اید حذف کنید یا کل پروژه را حذف کنید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان 300 دلاری هستند.
Google Cloud Shell Setup
در حالی که Google Cloud و Google Cloud Trace می‌توانند از راه دور از لپ‌تاپ شما کار کنند، در این نرم‌افزار از Google Cloud Shell استفاده می‌کنیم، یک محیط خط فرمان که در Cloud اجرا می‌شود.
برای فعال کردن Cloud Shell از Cloud Console، کافی است روی Activate Cloud Shell کلیک کنید (تنها چند لحظه طول می‌کشد تا محیط را فراهم کرده و به آن متصل شوید).
اگر قبلاً Cloud Shell را راه‌اندازی نکرده‌اید، یک صفحه میانی (در زیر تاشو) برای شما نمایش داده می‌شود که آن را توصیف می‌کند. اگر اینطور است، روی Continue کلیک کنید (و دیگر آن را نخواهید دید). در اینجا به نظر می رسد که آن صفحه یک بار مصرف:
تهیه و اتصال به Cloud Shell فقط باید چند لحظه طول بکشد.
این ماشین مجازی با تمام ابزارهای توسعه مورد نیاز شما بارگذاری شده است. این دایرکتوری اصلی 5 گیگابایتی دائمی را ارائه می دهد و در Google Cloud اجرا می شود و عملکرد شبکه و احراز هویت را بسیار افزایش می دهد. بیشتر، اگر نه همه، کار شما در این کد لبه را می توان به سادگی با یک مرورگر یا Chromebook انجام داد.
پس از اتصال به Cloud Shell، باید ببینید که قبلاً احراز هویت شده اید و پروژه قبلاً روی ID پروژه شما تنظیم شده است.
برای تایید احراز هویت، دستور زیر را در Cloud Shell اجرا کنید:
پس از اتصال به Cloud Shell، باید ببینید که قبلاً احراز هویت شده اید و پروژه قبلاً روی PROJECT_ID شما تنظیم شده است.
gcloud auth list
خروجی فرمان
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
خروجی فرمان
[core] project = <PROJECT_ID>
اگر به دلایلی پروژه تنظیم نشد، به سادگی دستور زیر را صادر کنید:
gcloud config set project <PROJECT_ID>
Cloud Shell همچنین برخی از متغیرهای محیطی را به صورت پیش‌فرض تنظیم می‌کند که ممکن است هنگام اجرای دستورات آینده مفید باشند.
echo $GOOGLE_CLOUD_PROJECT
خروجی فرمان
<PROJECT_ID>
نمونه برنامه های کاربردی
ما هر آنچه برای این پروژه نیاز دارید را در یک مخزن Git قرار داده ایم. مخزن شامل چند نمونه برنامه است و می توانید از هر یک از آنها برای این تمرین استفاده کنید.
لینک مخزن گیت: https://github.com/rominirani/cloud-code-sample-repository
3. برنامه API را مستقر کنید
نمونه برنامه یا API در مورد چیست؟
برنامه ما یک برنامه ساده Inventory API است که یک نقطه پایانی REST API را با چند عملیات برای فهرست کردن اقلام موجودی و دریافت تعداد موجودی اقلام خاص نشان می دهد.
هنگامی که API را مستقر می کنیم و فرض می کنیم که در https://<somehost> میزبانی می شود، می توانیم به صورت زیر به نقاط پایانی API دسترسی داشته باشیم:
- https://<somehost>/inventory
این همه اقلام محصول را با سطوح موجودی موجود فهرست می کند.
- https://<somehost>/inventory/{productid}
این یک رکورد واحد با سطح موجودی محصول و موجودی آن محصول را فراهم می کند.
داده های پاسخ برگشتی در قالب JSON هستند.
داده های نمونه و درخواست/پاسخ API
این برنامه برای ساده نگه داشتن کارها توسط یک پایگاه داده در باطن ارائه نمی شود. این شامل 3 شناسه محصول نمونه و سطح موجودی موجود آنها است.
شناسه محصول | سطح موجودی در دست |
I-1 | 10 |
I-2 | 20 |
I-3 | 30 |
نمونه درخواست و پاسخ API در زیر نشان داده شده است:
درخواست API | پاسخ API |
https://<somehost>/inventory | [ { "I-1": 10، "I-2": 20، "I-3": 30 }] |
https://<somehost>/inventory/I-1 | { "productid": "I-1", "qty": 10} |
https://<somehost>/inventory/I-2 | { "productid": "I-2", "qty": 20} |
https://<somehost>/inventory/I-200 | { "productid": I-200، "qty": -1} |
Repository را شبیه سازی کنید
در حالی که Google Cloud را می توان از راه دور از لپ تاپ شما کار کرد، در این کد لبه از Google Cloud Shell استفاده خواهید کرد، یک محیط خط فرمان که در Cloud اجرا می شود.
از کنسول GCP روی نماد Cloud Shell در نوار ابزار بالا سمت راست کلیک کنید:
تهیه و اتصال به محیط فقط چند لحظه طول می کشد. وقتی تمام شد، باید چیزی شبیه به این را ببینید:
این ماشین مجازی با تمام ابزارهای توسعه که شما نیاز دارید بارگذاری شده است. این یک فهرست اصلی 5 گیگابایتی دائمی را ارائه می دهد و در Google Cloud اجرا می شود و عملکرد و احراز هویت شبکه را تا حد زیادی افزایش می دهد. تمام کارهای شما در این آزمایشگاه به سادگی با یک مرورگر قابل انجام است.
gcloud را راه اندازی کنید
در Cloud Shell، ID پروژه خود را تنظیم کرده و آن را به عنوان متغیر PROJECT_ID ذخیره کنید.
PROJECT_ID=[YOUR-PROJECT-ID]
gcloud config set project $PROJECT_ID
حال دستور زیر را اجرا کنید:
$ git clone https://github.com/rominirani/cloud-code-sample-repository.git
با این کار یک پوشه با عنوان cloud-code-sample-repository در این پوشه ایجاد می شود.
(اختیاری) برنامه را در Cloud Shell اجرا کنید
با دنبال کردن مراحل زیر می توانید برنامه را به صورت محلی اجرا کنید:
- از ترمینال، با دستور زیر به نسخه Python API بروید:
$ cd cloud-code-sample-repository
$ cd python-flask-api
- در ترمینال دستور زیر را ارائه دهید (در زمان نگارش، Cloud Shell با Python 3.9.x نصب شده است و ما از نسخه پیش فرض استفاده می کنیم. اگر قصد دارید آن را به صورت محلی روی لپ تاپ خود اجرا کنید، می توانید با Python 3.8+ استفاده کنید. ) :
$ python app.py
- می توانید دستور زیر را برای راه اندازی سرور پایتون به صورت محلی اجرا کنید.
- با این کار سروری در پورت 8080 راه اندازی می شود و می توانید آن را به صورت محلی از طریق ویژگی Web Preview Cloud Shell آزمایش کنید. مطابق شکل زیر روی دکمه پیش نمایش وب کلیک کنید:
در پورت 8080 روی Preview کلیک کنید.
- با این کار یک پنجره مرورگر باز می شود. خطای 404 را خواهید دید و این مشکلی ندارد. URL را تغییر دهید و آن را به داشتن /inventory بعد از نام میزبان تغییر دهید.
به عنوان مثال در دستگاه من، به نظر می رسد این است:
https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory
با این کار لیست اقلام موجودی همانطور که قبلا توضیح داده شد نمایش داده می شود:
- اکنون می توانید با رفتن به ترمینال و فشار دادن Ctrl-C سرور را متوقف کنید
برنامه را مستقر کنید
اکنون این برنامه API را در Cloud Run مستقر خواهیم کرد. این فرآیند شامل استفاده از سرویس گیرنده خط فرمان glcoud برای اجرای فرمان استقرار کد در Cloud Run بود.
از ترمینال دستور gcloud زیر را بدهید:
$ gcloud run deploy --source .
با این کار چندین سوال از شما پرسیده می شود (در صورت درخواست مجوز، لطفا ادامه دهید) و برخی از نکات در زیر ذکر شده است. بسته به پیکربندی و اگر قبلاً APIهای خاصی را در پروژه Google Cloud خود فعال کرده باشید، ممکن است همه سؤالات را دریافت کنید یا نگیرید.
- نام سرویس (python-flask-api): یا با این پیش فرض بروید یا چیزی مانند my-inventory-api را انتخاب کنید
- API [run.googleapis.com] در پروژه [project-number] فعال نیست. آیا می‌خواهید فعال کنید و دوباره امتحان کنید (چند دقیقه طول می‌کشد)؟ (y/N)؟ Y
- لطفاً یک منطقه را مشخص کنید: با دادن شماره، منطقه مورد نظر خود را انتخاب کنید.
- API [artifactregistry.googleapis.com] در پروژه [project-number] فعال نیست. آیا می‌خواهید فعال کنید و دوباره امتحان کنید (چند دقیقه طول می‌کشد)؟ (y/N)؟ Y
- استقرار از منبع به یک مخزن Artifact Registry Docker برای ذخیره کانتینرهای ساخته شده نیاز دارد. یک مخزن به نام [cloud-run-source-deploy] در منطقه [us-west1] ایجاد خواهد شد.
آیا می خواهید ادامه دهید (Y/n)؟ Y
- فراخوان‌های احراز هویت نشده به [my-inventory-api] (y/N) اجازه داده شود؟ Y
در نهایت، این فرآیند دریافت کد منبع شما، ذخیره سازی آن، فشار دادن آن به رجیستری Artifact و سپس استقرار سرویس Cloud Run + ویرایش را آغاز می کند. شما باید در این فرآیند صبور باشید (3-4 دقیقه طول می کشد) و باید مشاهده کنید که با نشانی اینترنتی سرویس به شما نشان داده شده است.
یک نمونه اجرا در زیر نشان داده شده است:
برنامه را تست کنید
اکنون که برنامه را در Cloud Run مستقر کرده ایم، می توانید به صورت زیر به برنامه API دسترسی داشته باشید:
- URL سرویس را در مرحله قبل یادداشت کنید. برای مثال در تنظیمات من، به صورت
https://my-inventory-api-bt2r5243dq-uw.a.run.appنشان داده می شود. بیایید این را <SERVICE_URL> بنامیم. - یک مرورگر باز کنید و به 3 URL زیر برای نقاط پایانی API دسترسی پیدا کنید:
- <SERVICE_URL>/موجودی
- <SERVICE_URL>/inventory/I-1
- <SERVICE_URL>/inventory/I-100
باید مطابق مشخصاتی باشد که در بخش قبلی با نمونه درخواست و پاسخ API ارائه کرده بودیم.
جزئیات خدمات را از Cloud Run دریافت کنید
ما سرویس API خود را در Cloud Run، یک محیط محاسباتی بدون سرور، مستقر کردیم. ما می‌توانیم در هر زمانی از سرویس Cloud Run از طریق کنسول Google Cloud بازدید کنیم.
از منوی اصلی به Cloud Run بروید. با این کار لیست سرویس هایی که در Cloud Run اجرا می کنید نمایش داده می شود. باید سرویسی را که به تازگی مستقر کرده اید ببینید. بسته به نامی که انتخاب کرده اید، باید چیزی شبیه به این ببینید:
برای مشاهده جزئیات روی نام سرویس کلیک کنید. جزئیات نمونه در زیر نشان داده شده است:
به URL توجه کنید، که چیزی نیست جز نشانی اینترنتی سرویس که می توانید آن را به مرورگر وارد کنید و به Inventory API که ما به تازگی راه اندازی کرده ایم، دسترسی پیدا کنید. به راحتی به معیارها و سایر جزئیات نگاه کنید.
بیایید وارد شویم و اکنون با Google Cloud Operations Suite شروع کنیم.
4. یک داشبورد راه اندازی کنید
یکی از ویژگی‌های مناسبی که Cloud Monitoring ارائه می‌کند، داشبوردهای خارج از جعبه (OOTB) در منابع متعدد در Google Cloud است. این باعث می شود که راه اندازی اولیه داشبوردها با معیارهای استاندارد، فرآیندی سریع و راحت باشد.
اجازه دهید نحوه انجام این کار را برای سرویس API که به تازگی در Cloud Run اجرا کرده ایم، انجام دهیم.
داشبورد سفارشی برای خدمات ما
از آنجایی که ما سرویس API خود را در Cloud Run مستقر کرده‌ایم، اجازه دهید نحوه راه‌اندازی داشبوردهایی را بررسی کنیم که می‌توانند به تجسم معیارهای مختلف کمک کنند، که برخی از آنها شامل تأخیر سرویس است.
ابتدا، از کنسول، مطابق شکل زیر به Monitoring → Overview مراجعه کنید:
نمای کلی چندین چیز را نشان می دهد که شما در مانیتورینگ پیکربندی می کردید، مانند داشبورد، هشدار، بررسی آپتایم و غیره.
در حال حاضر، اجازه دهید از منوی اصلی کناری روی داشبوردها کلیک کنیم. این ما را به صفحه زیر می برد:
بر روی SAMPLE LIBRARY کلیک کنید. با این کار فهرستی از داشبوردهای خارج از جعبه (OOTB) که در Google Cloud در دسترس هستند، در منابع متعدد نمایش داده می شود. به طور خاص، لیست را به پایین اسکرول کنید و Google Cloud Run را مطابق شکل زیر انتخاب کنید.
با این کار فهرستی از داشبوردهای استاندارد موجود برای Google Cloud Run نمایش داده می شود. از آنجایی که سرویس خود را در Cloud Run مستقر کرده ایم، به آن علاقه مندیم.
یک داشبورد برای Cloud Run Monitoring خواهید دید. برای مشاهده لیست نمودارهای استاندارد (متریک) که برای Cloud Run Monitoring در دسترس هستند، روی پیوند PREVIEW کلیک کنید. برای وارد کردن همه این نمودارها به یک داشبورد سفارشی، به سادگی روی IMPORT SAMPLE DASHBOARD کلیک کنید. این یک صفحه داشبورد با نامی از قبل پر شده برای همان شکل زیر نشان می دهد:
می‌توانید با کلیک بر روی فلش چپ ، که در سمت چپ نام داشبورد، سمت راست در سمت چپ بالا قرار دارد، به عقب برگردید. این منجر به لیستی از داشبوردها می‌شود که باید بتوانید داشبورد جدیدی را که ایجاد کرده‌اید مشاهده کنید.
روی پیوند داشبورد کلیک کنید و می توانید معیارهای متعددی را که خارج از جعبه در دسترس هستند نظارت کنید. این معیارها شامل تأخیر، تعداد درخواست، معیارهای کانتینر و موارد دیگر است.
همچنین می‌توانید با انتخاب نماد ستاره مانند شکل زیر، هر یک از داشبورد را به‌عنوان مورد علاقه علامت‌گذاری کنید:
این کار داشبورد را به صفحه نمای کلی مانیتورینگ اضافه می کند و راهی آسان برای پیمایش به داشبوردهای پرکاربرد می شود.
فوق العاده! شما به تازگی یک داشبورد سفارشی برای نظارت بر خدمات Cloud Run خود اضافه کرده اید. آفرین !
5. بررسی های Uptime
در این بخش، می‌خواهیم یک بررسی آپتایم برای سرویس API خود که مستقر کرده‌ایم تنظیم کنیم. بررسی عمومی زمان کار می‌تواند درخواست‌هایی را از چندین مکان در سراسر جهان به آدرس‌های اینترنتی در دسترس عمومی یا منابع Google Cloud صادر کند تا ببیند آیا منبع پاسخ می‌دهد یا خیر.
منبع در این مورد سرویس API است که ما در Cloud Run مستقر کرده ایم. URL یک نقطه پایانی خاص خواهد بود که سرویس API برای نشان دادن سلامت سرویس در معرض نمایش قرار می دهد.
در کد سرویس API نمونه، نقطه پایانی /healthy را در معرض دید قرار داده ایم که مقدار رشته ای " All Izz Well " را برمی گرداند. بنابراین تنها کاری که باید انجام دهیم این است که یک چک آپتایم تعریف کنیم که چیزی شبیه به https://<SERVICE_URL>/healthy داشته باشد و بررسی کند که آیا رشته "All Izz Well" برگردانده شده است یا خیر.
یک کانال اعلان ایجاد کنید
قبل از ایجاد بررسی آپتایم، مهم است که ابتدا کانال های اطلاع رسانی را پیکربندی کنیم. کانال اطلاع رسانی رسانه ای است که در صورت بروز حادثه/مشکلی در مورد هر یک از منابع تحت نظارت ما به شما هشدار داده می شود. نمونه ای از کانال اطلاع رسانی ایمیل است و در صورت وجود هشدار و غیره ایمیل هایی دریافت خواهید کرد.
در حال حاضر، ما قصد داریم یک کانال اعلان ایمیل را پیکربندی کنیم و آن را با آدرس ایمیل خود پیکربندی کنیم تا در صورت هرگونه هشداری که سیستم ما ایجاد می کند و آن را پیکربندی می کنیم، به ما اطلاع داده شود.
برای ایجاد یک کانال اعلان، مراحل زیر را دنبال کنید:
همانطور که در زیر نشان داده شده است، از منوی اصلی در Google Cloud Console به Monitoring → Alerting بروید:
با این کار صفحه ای با هشدارها، خط مشی ها و موارد دیگر نمایش داده می شود. در حال حاضر، پیوندی را در بالا با عنوان EDIT NOTIFICATION CHANNELS خواهید دید. روی آن کلیک کنید.
با این کار لیستی از کانال های مختلف اعلان مطابق شکل زیر نمایش داده می شود:
قسمت Email را پیدا کرده و روی ADD NEW برای آن ردیف کلیک کنید. با این کار جزئیات پیکربندی ایمیل مطابق شکل زیر ظاهر می شود:
آدرس ایمیل و نام نمایشی خود را مطابق شکل زیر وارد کنید. بر روی SAVE کلیک کنید.
این کار ایجاد کانال اعلان ایمیل را تکمیل می کند. بیایید پیش برویم و اکنون بررسی آپتایم را پیکربندی کنیم.
ایجاد چک آپتایم
از منوی اصلی در Google Cloud Console به Monitoring → Checks Uptime بروید. در بالا پیوند CREATE UPTIME CHECK را خواهید دید. روی آن کلیک کنید.
این یک سری مراحل را نشان می دهد که باید برای پیکربندی بررسی آپتایم تکمیل کنید.
اولین گام تنظیم جزئیات Target یعنی اطلاعات مربوط به سرویس Cloud Run است که ما مستقر کرده ایم. فرم پر شده در زیر نشان داده شده است:
مقادیر مختلف را می توان به صورت زیر انتخاب کرد:
- پروتکل: HTTPS
- نوع منبع: سرویس Cloud Run را انتخاب کنید. به منابع دیگری که پشتیبانی می کند توجه کنید و همچنین می توانید بررسی های Uptime را روی آنها تنظیم کنید.
- سرویس Cloud Run: my-inventory-api یا نام خاصی را که برای سرویس Cloud Run دارید انتخاب کنید.
- مسیر / سالم است، زیرا ما یک رشته " All Izz Well" را برمی گردانیم و می خواهیم آن را بررسی کنیم.
برای رفتن به مرحله بعد، روی ادامه کلیک کنید. مرحله بعدی مرحله اعتبارسنجی پاسخ است که در زیر نشان داده شده است:
می‌بینید که ما چک را برای «تطابق محتوا» فعال می‌کنیم و سپس تنظیم می‌کنیم که پاسخی که توسط نقطه پایانی /سلامت داده می‌شود، «All Izz Well» باشد. روی ادامه کلیک کنید تا به مرحله بعدی بروید که در آن Alert را پیکربندی می‌کنیم و اگر بررسی Uptime ناموفق بود، در کدام کانال اطلاع رسانی باید هشدار دهیم.
در این مرحله یک نام برای Alert قرار دهید. من آن را به عنوان Inventory API Check Uptime Check انتخاب کرده ام، اما شما می توانید نام خود را انتخاب کنید. نکته مهم در اینجا این است که کانال اطلاع رسانی صحیح را از لیستی که قبلاً پیکربندی کرده اید انتخاب کنید.
روی REVIEW کلیک کنید تا مرحله نهایی بررسی Uptime را که پیکربندی کرده ایم بررسی کنید.
در این مرحله نهایی، یک نام برای بررسی Uptime (به عنوان مثال Inventory API Uptime Check ) بدهید و سپس می توانید بررسی کنید که آیا چک به درستی پیکربندی شده است یا خیر. برای آن روی دکمه TEST کلیک کنید.
ادامه دهید و فرآیند را کامل کنید (روی دکمه CREATE در سمت چپ کلیک کنید). Google Cloud به کاوشگرهای بررسی uptime پیکربندی شده در مناطق مختلف دستور می دهد تا URL را پینگ کنند و این پاسخ ها جمع آوری می شوند. پس از چند دقیقه به بخش مانیتورینگ → بررسی های زمان کار مراجعه کنید و در حالت ایده آل باید همه سیگنال های سبز رنگی را ببینید که نشان می دهد URL از پروب های مختلف قابل دسترسی است.
اگر هر یک از کاوشگرها برای مدتی از کار بیفتد (که قابل تنظیم است)، یک هشدار هشدار در کانال ایمیلی که ما پیکربندی کردیم دریافت خواهید کرد.
این بخش ما را در مورد تنظیم یک بررسی Uptime کامل می کند. آفرین !
6. Metrics Explorer
Cloud Monitoring هزاران معیار استاندارد را از چندین محصول Google Cloud نشان می‌دهد. این معیارها برای بررسی، پرس و جو، تبدیل به نمودارها، افزودن به داشبوردها، افزایش هشدارها و موارد دیگر در دسترس شما هستند.
هدف ما در این بخش:
- درک کنید که چگونه می توانید به معیارهای مختلف نگاه کنید و سپس ما یک معیار خاص (تأخیر) را برای سرویس API خود بررسی خواهیم کرد.
- آن معیار را به نمودار و داشبورد سفارشی تبدیل کنید که می‌توانیم از آن برای تجسم معیار در هر زمان استفاده کنیم.
متریک تأخیر برای سرویس API موجودی را کاوش کنید
از منوی اصلی در Google Cloud Console به Monitoring → Metrics Explorer بروید. این شما را به صفحه Metrics Explorer می برد. بر روی SELECT A METRIC کلیک کنید. اکنون می توانید چندین منبع فعال را که معیارهای تولید شده دارند پیمایش کنید.
از آنجایی که ما با سرویس‌های Cloud Run سروکار داریم، روی Cloud Run Revision کلیک کنید، سپس بر روی دسته و معیار خاص با عنوان Request Latency کلیک کنید.
روی Apply کلیک کنید. با این کار تاخیر درخواست در نمودار نمایش داده می شود. همانطور که در زیر نشان داده شده است، می توانید نوع ویجت را از تنظیمات نمایش در سمت راست به نمودار خطی تغییر دهید:
با این کار نمودار تاخیر مانند شکل زیر نمایش داده می شود:
نمودار و داشبورد سفارشی ایجاد کنید
اجازه دهید پیش برویم و این نمودار را ذخیره کنیم. بر روی Save Chart کلیک کنید و از جزئیات مانند شکل زیر استفاده کنید:
به خاطر داشته باشید که ما در حال ایجاد یک داشبورد جدید هستیم، به جای اینکه آن را در داشبورد موجود ذخیره کنیم. بر روی دکمه SAVE کلیک کنید. این داشبورد جدید ایجاد شده را به لیست داشبوردهای ما اضافه می کند که در زیر نشان داده شده است:
برای مشاهده جزئیات روی داشبورد خاصی که ایجاد کردیم کلیک کنید.
این بخش بررسی معیارهای مختلف از طریق Metrics Explorer و نحوه ایجاد داشبوردهای سفارشی خود را تکمیل می کند.
7. Cloud Logging
در این بخش به بررسی Cloud Logging می پردازیم. Cloud Logging با یک رابط Logs Explorer ارائه می شود که به شما کمک می کند تا در لاگ های ایجاد شده توسط سرویس های مختلف Google و برنامه های کاربردی خود پیمایش کنید و در آنها غوطه ور شوید.
در این بخش، با Logs Explorer آشنا می‌شویم و چند پیام گزارش را شبیه‌سازی می‌کنیم که سپس می‌توانیم آنها را جستجو کرده و به معیارها تبدیل کنیم، از طریق ویژگی به نام معیارهای Log-based .
لاگ کاوشگر
همانطور که در زیر نشان داده شده است، می توانید از طریق Logging →Logs Explorer از کنسول ابری اصلی Google از Logs Explorer دیدن کنید:
این یک رابط گزارش را نشان می دهد که در آن می توانید به طور خاص منابع مختلف (پروژه، منابع ابری Google، نام سرویس ها و غیره) را به همراه سطوح Log انتخاب یا لغو انتخاب کنید تا پیام های گزارش را در صورت نیاز فیلتر کنید.
در بالا لیستی از گزارش‌های مربوط به Cloud Run Revision یعنی سرویس‌های Cloud Run که ما مستقر کرده‌ایم نشان داده شده است. چندین درخواست را خواهید دید که چک های Uptime هستند که به نقطه پایانی /healthy که ما پیکربندی کرده ایم برخورد می کنند.
جستجو برای هشدارها
با ارائه شناسه های محصول که یکی از I-1، I-2 و I-3 نیستند، چند درخواست نامعتبر را به سرویس موجودی شبیه سازی کنید. به عنوان مثال یک درخواست نادرست است:
https://<SERVICE_URL>/inventory/I-999
ما اکنون تمام اخطارهایی را که توسط API ما ایجاد شده اند، هنگامی که شناسه محصول نادرستی در Query ارائه شده است، جستجو می کنیم.
در Query Box، پارامترهای query زیر را وارد کنید:
resource.type="cloud_run_revision"
textPayload =~ "درخواست موجودی برای محصول نادرست دریافت شد"
باید چیزی شبیه این باشد:
روی Run Query کلیک کنید. سپس تمام درخواست هایی که وارد شده و دارای این مشکل هستند را به شما نشان می دهد.
متریک های مبتنی بر گزارش
بیایید یک متریک ثبت سفارشی برای ردیابی این خطاها ایجاد کنیم. مایلیم بدانیم که آیا تعداد قابل توجهی از تماس‌ها با شناسه‌های محصول اشتباه صورت می‌گیرد یا خیر.
برای تبدیل موارد بالا به معیار خطا، روی دکمه Create Metric که در Logs Explorer می بینید کلیک کنید.
این فرم را برای ایجاد تعریف متریک نمایش می دهد. با یک Counter Metric بروید و جزئیات نام متریک (inventory_lookup_errors) و توضیحات را مانند شکل زیر وارد کنید و روی Create Metric کلیک کنید.
با این کار متریک شمارنده ایجاد می شود و باید پیامی را که در زیر نمایش داده شده است مشاهده کنید:
از منوی اصلی از Logging → Metrics-based Logs دیدن کنید و باید معیار سفارشی را که در لیست معیارهای تعریف شده توسط کاربر تعریف کرده ایم، مشاهده کنید:
در پایان این ورودی، سه نقطه عمودی را پیدا خواهید کرد، روی آنها کلیک کنید تا عملیاتی را که می توانید روی این معیار سفارشی انجام دهید، مشاهده کنید. لیست باید شبیه به لیستی باشد که در زیر می بینید. روی گزینه View in Metrics Explorer کلیک کنید.
این باید ما را به Metrics Explorer که در بخش قبل با آن آشنا شدیم هدایت کند، با این تفاوت که اکنون برای ما از قبل پر شده است.
بر روی Save Chart کلیک کنید. برای گزینه های ذخیره نمودار از مقادیر زیر استفاده کنید:
اکنون یک داشبورد جدید ایجاد می‌کند که می‌توانید خطاهای جستجوی موجودی را ببینید و در لیست داشبوردها موجود خواهد بود.
عالیه اکنون یک متریک سفارشی از لاگ های خود ایجاد کرده اید و آن را به نموداری تبدیل کرده اید که در داشبورد سفارشی وجود دارد. این به ما کمک می کند تعداد تماس هایی که از شناسه محصول نادرست استفاده می کنند را ردیابی کنیم.
8. سیاست های هشدار
در این بخش از متریک سفارشی که ایجاد کرده ایم استفاده می کنیم و داده های آن را برای یک آستانه نظارت می کنیم، یعنی اگر تعداد خطاها از یک آستانه خاص فراتر رفت، هشدار می دهیم. به عبارت دیگر، ما قرار است یک سیاست هشدار تنظیم کنیم.
یک خط مشی هشدار ایجاد کنید
اجازه دهید به داشبورد جستجوی موجودی برویم. این نمودار نموداری را که برای یادداشت کردن خطاهای جستجوی موجودی ایجاد کرده‌ایم، مطابق شکل زیر نشان می‌دهد:
این داده های متریک فعلی را نشان می دهد. اجازه دهید ابتدا متریک را مطابق شکل زیر ویرایش کنیم (روی دکمه ویرایش کلیک کنید):
این جزئیات متریک را نشان می دهد. می‌خواهیم نمودار را از نشان دادن نرخ خطا به مجموع یعنی تعداد خطاها تبدیل کنیم. فیلد تغییر در زیر نشان داده شده است:
روی APPLY در گوشه سمت راست بالا کلیک کنید و ما به صفحه معیارهای خود باز خواهیم گشت، اما این بار می‌توانیم تعداد کل خطاها را در دوره هم‌ترازی در مقابل میزان خطاها ببینیم.
ما می‌خواهیم یک خط‌مشی هشدار ایجاد کنیم که در صورتی که تعداد خطاها از یک آستانه فراتر رفت، به ما اطلاع دهد. بر روی 3 نقطه در گوشه سمت راست بالای نمودار کلیک کنید و از لیست گزینه ها، مانند تصویر بالا، بر روی Convert to alert chart کلیک کنید.
شما باید صفحه ای را مانند شکل زیر ببینید:
روی Next کلیک کنید، یک مقدار Threshold ظاهر می شود که می توانیم تنظیم کنیم. آستانه نمونه ای که در اینجا در نظر گرفته ایم 5 است، اما شما می توانید بر اساس ترجیح خود انتخاب کنید.
روی NEXT کلیک کنید تا فرم Notifications ظاهر شود
ما کانال اطلاع رسانی را به عنوان کانال ایمیلی که قبلا ایجاد کرده بودیم انتخاب کرده ایم. می توانید سایر جزئیات مانند مستندات (که به عنوان بخشی از هشداری که مطرح می شود ارائه می شود) پر کنید. برای مشاهده خلاصه و تکمیل فرآیند بر روی NEXT کلیک کنید.
هنگامی که این خط مشی هشدار را ایجاد کردید، مطابق شکل زیر در لیست سیاست های هشدار قابل مشاهده خواهد بود. می توانید با رفتن به مانیتورینگ → هشدار به لیست سیاست های هشدار دسترسی پیدا کنید. برای مشاهده لیست خط مشی هایی که تاکنون پیکربندی کرده ایم، بخش سیاست ها را در صفحه اسکن کنید.
عالیه شما اکنون یک خط مشی هشدار سفارشی را پیکربندی کرده اید که در صورت افزایش نرخ خطا هنگام جستجوی Inventory API به شما اطلاع می دهد.
9. نظارت بر خدمات (اختیاری)
در این بخش، ما بر اساس اصول مهندسی قابلیت اطمینان سایت (SRE) می‌خواهیم SLI/SLO را برای خدمات خود راه‌اندازی کنیم. متوجه خواهید شد که Cloud Monitoring با کشف خودکار سرویس‌هایی که در Cloud Run به کار گرفته‌اید کار را برای شما آسان‌تر می‌کند و می‌تواند SLIهای کلیدی مانند Availability، Latency را به‌طور خودکار برای شما به همراه محاسبات بودجه خطا محاسبه کند.
بیایید پیش برویم و Latency SLO را برای سرویس API خود تنظیم کنیم.
راه اندازی SLO تأخیر برای خدمات موجودی
از منوی اصلی در Cloud Console روی Monitoring → Services کلیک کنید. با این کار لیست سرویس هایی که برای مانیتورینگ سرویس پیکربندی شده اند ظاهر می شود.
در حال حاضر، ما هیچ سرویسی نداریم که برای نظارت بر SLI/SLO تنظیم شده باشد، بنابراین لیست خالی است. روی پیوند DEFINE SERVICE در بالا کلیک کنید تا ابتدا یک سرویس را تعریف یا شناسایی کنید.
این به طور خودکار خدماتی را که کاندیدای نظارت بر SLO هستند کشف می کند. می‌تواند سرویس‌های Cloud Run را کشف کند و از این رو سرویس Inventory API ما که در Cloud Run مستقر شده است در لیست قابل مشاهده خواهد بود.
نام نمایشی که مشاهده می کنید ممکن است متفاوت باشد و به انتخاب شما در زمان استقرار سرویس در Cloud Run بستگی دارد. بر روی دکمه SUBMIT کلیک کنید. با این کار صفحه نمایش داده شده در زیر ظاهر می شود:
می توانید روی CREATE SLO کلیک کنید. اکنون به شما این امکان را می دهد که از SLI هایی که به طور خودکار برای شما محاسبه می شوند، انتخاب کنید.
ما Latency SLI را به عنوان شروع انتخاب می کنیم. بر روی CONTINUE کلیک کنید. در مرحله بعد صفحه ای را مشاهده می کنید که عملکرد فعلی این سرویس و تاخیر معمولی را به شما نشان می دهد.
مقداری برای آستانه یعنی 300 میلی‌ثانیه قرار می‌دهیم، این همان چیزی است که می‌خواهیم به آن برسیم. در صورت تمایل می‌توانید مقدار متفاوتی را انتخاب کنید، اما به خاطر داشته باشید که این مقدار بر بودجه خطایی که بر اساس آن تعریف می‌کنید تأثیر می‌گذارد. روی ادامه کلیک کنید.
اکنون SLO (پنجره هدف و اندازه گیری) را مطابق شکل زیر تنظیم می کنیم:
این بدان معنی است که ما پنجره اندازه گیری را به عنوان یک پنجره از نوع Rolling انتخاب می کنیم و آن را در طول 7 روز اندازه گیری می کنیم. به طور مشابه برای هدف، ما یک هدف 90٪ را انتخاب کرده ایم. آنچه ما در اینجا می خواهیم بگوییم این است که 90٪ از درخواست ها به سرویس API باید در عرض 300 میلی ثانیه تکمیل شود و این باید در طول 7 روز اندازه گیری شود.
بر روی Continue کلیک کنید. با این کار صفحه خلاصه ظاهر می شود که می توانید با کلیک بر روی دکمه UPDATE SLO آن را تأیید کنید.
این تعریف SLO شما را ذخیره می کند و بودجه خطا به طور خودکار برای شما محاسبه می شود.
چند چیز که می توانید امتحان کنید:
- API را از طریق تماس های متعدد اعمال کنید و عملکرد سرویس و نحوه تأثیر آن بر بودجه خطای باقیمانده را مشاهده کنید.
- کد منبع را تغییر دهید تا برخی از تماس‌ها به‌طور تصادفی تأخیر اضافی (خواب) را معرفی کند. این باعث افزایش تاخیر برای تعدادی از تماس‌ها می‌شود و باید بر بودجه خطا تأثیر منفی بگذارد.
10. تبریک می گویم
تبریک می‌گوییم، شما با موفقیت یک نمونه برنامه را در Google Cloud پیاده‌سازی کردید و با استفاده از Google Cloud Operations Suite برای نظارت بر سلامت برنامه آشنا شدید!
آنچه را پوشش داده ایم
- استقرار یک سرویس در Google Cloud Run.
- راه اندازی داشبورد برای سرویس Google Cloud Run.
- بررسی های آپتایم
- تنظیم معیارهای ثبت سفارشی و داشبورد/نمودار بر اساس آن.
- کاوش Metrics Explorer و راه‌اندازی داشبورد/نمودار.
- تنظیم سیاست های هشدار
- راه اندازی SLI/SLO برای نظارت بر خدمات در Google Cloud.
توجه: اگر کد لبه را با استفاده از حساب کاربری خود و پروژه Google Cloud اجرا کرده‌اید، ممکن است منابع تخصیص‌یافته همچنان شامل هزینه صورتحساب شوند. بنابراین پس از اتمام کار با آزمایشگاه، پروژه و منابع را حذف کنید.
بعدش چی؟
برای کسب اطلاعات بیشتر در مورد Google Cloud Operations Suite، این Cloud Skills Boost Quest را بررسی کنید.