مقدمه ای بر مجموعه عملیات ابری

۱. مقدمه

آخرین به‌روزرسانی: 2023-07-28

مجموعه عملیات ابری گوگل چیست؟

Google Cloud Operations Suite پلتفرمی است که در آن می‌توانید عملکرد برنامه‌های کاربردی را در محیط Google Cloud خود نظارت، عیب‌یابی و بهبود بخشید. ارکان اصلی Cloud Operations Suite شامل نظارت بر ابر، ثبت وقایع در ابر و ردیابی ابر است.

برای آشنایی بیشتر با فعالیت‌های گوگل در حوزه ابری، این ویدیو را تماشا کنید.

آنچه خواهید ساخت

در این آزمایشگاه کد، شما یک API نمونه را روی Google Cloud مستقر خواهید کرد. سپس چندین ویژگی در Cloud Monitoring را در رابطه با API بررسی و پیکربندی خواهید کرد.

آنچه یاد خواهید گرفت

• استفاده از Cloud Shell گوگل کلود برای استقرار یک برنامه نمونه در Cloud Run.
• استفاده از ویژگی‌های مانیتورینگ ابری گوگل مانند داشبوردها، هشدارها، بررسی‌های آپتایم، مانیتورینگ SLI/SLO و موارد دیگر.

آنچه نیاز دارید

• نسخه جدید کروم (۷۴ یا بالاتر)
• یک حساب کاربری گوگل کلود و پروژه گوگل کلود

۲. تنظیمات و الزامات

تنظیم محیط خودتنظیم

اگر از قبل حساب گوگل (جیمیل یا برنامه‌های گوگل) ندارید، باید یکی ایجاد کنید . وارد کنسول پلتفرم ابری گوگل ( console.cloud.google.com ) شوید و یک پروژه جدید ایجاد کنید.

• نام پروژه، نام نمایشی برای شرکت‌کنندگان این پروژه است. این یک رشته کاراکتری است که توسط APIهای گوگل استفاده نمی‌شود. می‌توانید آن را در هر زمانی به‌روزرسانی کنید.
• شناسه پروژه باید در تمام پروژه‌های گوگل کلود منحصر به فرد باشد و تغییرناپذیر است (پس از تنظیم، قابل تغییر نیست). کنسول کلود به طور خودکار یک رشته منحصر به فرد تولید می‌کند؛ معمولاً برای شما مهم نیست که چه باشد. در اکثر آزمایشگاه‌های کد، باید شناسه پروژه را ارجاع دهید (که معمولاً با عنوان PROJECT_ID شناخته می‌شود). اگر شناسه تولید شده را دوست ندارید، می‌توانید یک شناسه تصادفی دیگر ایجاد کنید. به عنوان یک جایگزین، می‌توانید شناسه خودتان را امتحان کنید و ببینید که آیا در دسترس است یا خیر. پس از این مرحله قابل تغییر نیست و در طول پروژه باقی خواهد ماند.
• برای اطلاع شما، یک مقدار سوم هم وجود دارد، شماره پروژه که برخی از APIها از آن استفاده می‌کنند. برای کسب اطلاعات بیشتر در مورد هر سه این مقادیر، به مستندات مراجعه کنید.

احتیاط: شناسه پروژه باید به صورت سراسری منحصر به فرد باشد و پس از انتخاب آن توسط شما، شخص دیگری نمی‌تواند از آن استفاده کند. شما تنها کاربر آن شناسه هستید. حتی اگر پروژه‌ای حذف شود، شناسه دیگر هرگز قابل استفاده نخواهد بود.

توجه: اگر از حساب Gmail استفاده می‌کنید، می‌توانید مکان پیش‌فرض را روی «بدون سازمان» تنظیم کنید. اگر از حساب Google Workspace استفاده می‌کنید، مکانی را انتخاب کنید که برای سازمان شما منطقی باشد.

2. در مرحله بعد، برای استفاده از منابع/API های ابری، باید پرداخت صورتحساب را در کنسول ابری فعال کنید . اجرای این آزمایشگاه کد، اگر اصلاً هزینه‌ای نداشته باشد، هزینه زیادی نخواهد داشت. برای خاموش کردن منابع به طوری که پس از این آموزش متحمل پرداخت صورتحساب نشوید، می‌توانید منابعی را که ایجاد کرده‌اید یا کل پروژه را حذف کنید. کاربران جدید Google Cloud واجد شرایط برنامه آزمایشی رایگان ۳۰۰ دلاری هستند.

راه‌اندازی پوسته ابری گوگل

اگرچه می‌توان از راه دور و از طریق لپ‌تاپ، Google Cloud و Google Cloud Trace را مدیریت کرد، اما در این آزمایشگاه کد، از Google Cloud Shell ، یک محیط خط فرمان که در فضای ابری اجرا می‌شود، استفاده خواهیم کرد.

برای فعال کردن Cloud Shell از کنسول Cloud، کافیست روی Activate Cloud Shell کلیک کنید (تأمین و اتصال به محیط فقط چند لحظه طول می‌کشد).

اگر قبلاً Cloud Shell را شروع نکرده‌اید، یک صفحه میانی (در پایین صفحه) به شما نمایش داده می‌شود که توضیح می‌دهد چیست. در این صورت، روی ادامه کلیک کنید (و دیگر هرگز آن را نخواهید دید). آن صفحه یکبار مصرف به این شکل است:

آماده‌سازی و اتصال به Cloud Shell فقط چند لحظه طول می‌کشد.

این ماشین مجازی با تمام ابزارهای توسعه مورد نیاز شما پر شده است. این ماشین یک دایرکتوری خانگی ۵ گیگابایتی دائمی ارائه می‌دهد و در فضای ابری گوگل اجرا می‌شود که عملکرد شبکه و احراز هویت را تا حد زیادی بهبود می‌بخشد. بخش عمده‌ای از کار شما در این آزمایشگاه کد، اگر نگوییم همه، را می‌توان به سادگی با یک مرورگر یا کروم‌بوک انجام داد.

پس از اتصال به Cloud Shell، باید ببینید که از قبل احراز هویت شده‌اید و پروژه از قبل روی شناسه پروژه شما تنظیم شده است.

برای تأیید احراز هویت، دستور زیر را در Cloud Shell اجرا کنید:

پس از اتصال به Cloud Shell، باید ببینید که از قبل احراز هویت شده‌اید و پروژه از قبل روی PROJECT_ID شما تنظیم شده است.

gcloud auth list

خروجی دستور

Credentialed accounts:
 - <myaccount>@<mydomain>.com (active)

توجه : ابزار خط فرمان gcloud به صورت پیش‌فرض در Cloud Shell نصب شده است و مطمئناً از پشتیبانی آن برای تکمیل تب لذت خواهید برد. برای اطلاعات بیشتر، به نمای کلی ابزار خط فرمان gcloud مراجعه کنید.

gcloud config list project

خروجی دستور

[core]
project = <PROJECT_ID>

اگر به هر دلیلی پروژه تنظیم نشده باشد، کافیست دستور زیر را اجرا کنید:

gcloud config set project <PROJECT_ID>

Cloud Shell همچنین برخی از متغیرهای محیطی را به طور پیش‌فرض تنظیم می‌کند که ممکن است هنگام اجرای دستورات بعدی مفید باشند.

echo $GOOGLE_CLOUD_PROJECT

خروجی دستور

<PROJECT_ID>

کاربردهای نمونه

ما هر آنچه را که برای این پروژه نیاز دارید در یک مخزن گیت قرار داده‌ایم. این مخزن شامل چند برنامه نمونه است و می‌توانید از هر یک از آنها برای این تمرین استفاده کنید.

لینک مخزن گیت: https://github.com/rominirani/cloud-code-sample-repository

۳. برنامه API را مستقر کنید

برنامه یا API نمونه در مورد چیست؟

برنامه ما یک برنامه API موجودی ساده است که یک نقطه پایانی API REST را با چند عملیات برای فهرست کردن اقلام موجودی و دریافت تعداد موجودی هر کالا ارائه می‌دهد.

زمانی که API را مستقر کردیم و فرض کردیم که در آدرس https://<somehost> میزبانی می‌شود، می‌توانیم به نقاط انتهایی API به صورت زیر دسترسی پیدا کنیم:

• https://<somehost>/inventory

این لیست تمام اقلام محصول را با سطوح موجودی موجود نشان می‌دهد.

• https://<somehost>/inventory/{productid}

این یک رکورد واحد با شناسه محصول و سطح موجودی در دسترس برای آن محصول ارائه می‌دهد.

داده‌های پاسخ برگشتی در قالب JSON هستند.

توجه: این برنامه API فقط برای اهداف آزمایشی است و یک پیاده‌سازی API امن و قوی را نشان نمی‌دهد. هدف از این برنامه، دسترسی سریع به یک برنامه کاربردی برای بررسی هدف اصلی آزمایشگاه، یعنی عملیات ابری گوگل، است.

داده‌های نمونه و درخواست/پاسخ API

این برنامه برای ساده نگه داشتن امور، در قسمت بک‌اند به پایگاه داده وابسته نیست. این برنامه شامل ۳ شناسه محصول نمونه و سطح موجودی آنها است.

شناسه محصول	سطح موجودی در دسترس
۱-۱	۱۰
آی-۲	۲۰
آی-۳	۳۰

نمونه درخواست و پاسخ API در زیر نشان داده شده است:

درخواست API	پاسخ API
https://<somehost>/inventory	[ { "I-1": 10، "I-2": 20، "I-3": 30 }]
https://<somehost>/inventory/I-1	{"شناسه محصول": "I-1", "تعداد": 10}
https://<somehost>/inventory/I-2	{"شناسه محصول": "I-2", "تعداد": 20}
https://<somehost>/inventory/I-200	{"شناسه محصول": I-200، "تعداد": -1}

مخزن را کلون کنید

اگرچه می‌توان از راه دور و از طریق لپ‌تاپ، گوگل کلود را مدیریت کرد، اما در این آزمایشگاه کد، از گوگل کلود شل ، یک محیط خط فرمان که در فضای ابری اجرا می‌شود، استفاده خواهید کرد.

از کنسول GCP روی آیکون Cloud Shell در نوار ابزار بالا سمت راست کلیک کنید:

آماده‌سازی و اتصال به محیط فقط چند لحظه طول می‌کشد. وقتی تمام شد، باید چیزی شبیه به این را ببینید:

این ماشین مجازی مجهز به تمام ابزارهای توسعه مورد نیاز شماست. این ماشین یک دایرکتوری خانگی دائمی ۵ گیگابایتی ارائه می‌دهد و روی فضای ابری گوگل اجرا می‌شود که عملکرد شبکه و احراز هویت را تا حد زیادی بهبود می‌بخشد. تمام کارهای شما در این آزمایشگاه را می‌توان به سادگی با یک مرورگر انجام داد.

راه اندازی جی کلود

در Cloud Shell، شناسه پروژه خود را تنظیم کرده و آن را به عنوان متغیر 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 اجرا کنید

شما می‌توانید با دنبال کردن مراحل زیر، برنامه را به صورت محلی اجرا کنید:

1. از طریق ترمینال، با استفاده از دستور زیر به نسخه پایتون API بروید:

$ cd cloud-code-sample-repository
$ cd python-flask-api

2. در ترمینال، دستور زیر را وارد کنید (در زمان نوشتن این مطلب، Cloud Shell با پایتون ۳.۹.x نصب شده ارائه می‌شود و ما از نسخه پیش‌فرض استفاده خواهیم کرد. اگر قصد دارید آن را به صورت محلی روی لپ‌تاپ خود اجرا کنید، می‌توانید از پایتون ۳.۸+ استفاده کنید):

$ python app.py

3. برای شروع سرور پایتون به صورت محلی می‌توانید دستور زیر را اجرا کنید.

4. این کار یک سرور را روی پورت ۸۰۸۰ راه‌اندازی می‌کند و می‌توانید آن را به صورت محلی از طریق ویژگی پیش‌نمایش وب Cloud Shell آزمایش کنید. مطابق شکل زیر، روی دکمه پیش‌نمایش وب کلیک کنید:

روی پورت ۸۰۸۰ روی پیش‌نمایش کلیک کنید.

5. این یک پنجره مرورگر باز می‌کند. شما یک خطای ۴۰۴ خواهید دید و مشکلی نیست. URL را اصلاح کنید و آن را به /inventory بعد از نام میزبان تغییر دهید.

مثلاً روی دستگاه من، به این شکل است:

https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory

این لیست اقلام موجودی را همانطور که قبلاً توضیح داده شد نمایش می‌دهد:

6. اکنون می‌توانید با رفتن به ترمینال و فشردن کلیدهای Ctrl-C، سرور را متوقف کنید.

برنامه را مستقر کنید

اکنون این برنامه API را در Cloud Run مستقر خواهیم کرد. این فرآیند شامل استفاده از کلاینت خط فرمان glcoud برای اجرای دستور جهت استقرار کد در Cloud Run است .

از ترمینال، دستور gcloud زیر را اجرا کنید:

$ gcloud run deploy --source .

این از شما چندین سوال می‌پرسد (در صورت درخواست مجوز، لطفاً ادامه دهید) و برخی از نکات در زیر ذکر شده است. بسته به پیکربندی و اینکه آیا قبلاً API های خاصی را در پروژه Google Cloud خود فعال کرده‌اید یا خیر، ممکن است همه سوالات را دریافت کنید یا نکنید.

1. نام سرویس (python-flask-api): یا با این پیش‌فرض پیش بروید یا چیزی شبیه به my-inventory-api انتخاب کنید.
2. API [run.googleapis.com] در پروژه [project-number] فعال نشده است. آیا می‌خواهید آن را فعال کرده و دوباره امتحان کنید (این کار چند دقیقه طول می‌کشد)؟ (y/N)؟ بله
3. لطفاً یک منطقه را مشخص کنید: با دادن یک شماره، منطقه مورد نظر خود را انتخاب کنید.
4. API [artifactregistry.googleapis.com] در پروژه [project-number] فعال نشده است. آیا می‌خواهید آن را فعال کرده و دوباره امتحان کنید (این کار چند دقیقه طول می‌کشد)؟ (y/N)؟ بله
5. استقرار از منبع به یک مخزن Docker در رجیستری Artifact برای ذخیره کانتینرهای ساخته شده نیاز دارد. یک مخزن با نام [cloud-run-source-deploy] در منطقه [us-west1] ایجاد خواهد شد.

آیا می‌خواهید ادامه دهید (بله/خیر)؟ بله

6. آیا به [my-inventory-api] (y/N) اجازه فراخوانی‌های احراز هویت نشده داده می‌شود؟ بله

در نهایت، این فرآیند شروع می‌شود تا کد منبع شما گرفته شود، آن را کانتینرایز (containerize) کنید، به Artifact Registry منتقل کنید و سپس سرویس Cloud Run + revision را مستقر کنید. شما باید در طول این فرآیند صبور باشید (ممکن است ۳-۴ دقیقه طول بکشد) و باید ببینید که فرآیند با نمایش URL سرویس به شما تکمیل می‌شود.

یک نمونه اجرا در زیر نشان داده شده است:

اپلیکیشن را تست کنید

اکنون که برنامه را در Cloud Run مستقر کرده‌ایم، می‌توانید به صورت زیر به برنامه API دسترسی پیدا کنید:

1. آدرس اینترنتی سرویس (Service URL) را از مرحله قبل یادداشت کنید. برای مثال، در تنظیمات من، به صورت https://my-inventory-api-bt2r5243dq-uw.a.run.app نمایش داده می‌شود. بیایید آن را <SERVICE_URL> بنامیم.
2. یک مرورگر باز کنید و به ۳ آدرس اینترنتی زیر برای نقاط پایانی API دسترسی پیدا کنید:
3. <SERVICE_URL>/موجودی
4. <SERVICE_URL>/موجودی/I-1
5. <SERVICE_URL>/موجودی/I-100

باید مطابق با مشخصاتی باشد که در بخش قبلی با نمونه درخواست و پاسخ API ارائه داده بودیم.

جزئیات خدمات را از Cloud Run دریافت کنید

ما سرویس API خود را در Cloud Run، یک محیط محاسباتی بدون سرور، مستقر کردیم. می‌توانیم در هر زمانی از طریق کنسول Google Cloud به سرویس Cloud Run دسترسی داشته باشیم.

از منوی اصلی، به Cloud Run بروید. این کار لیست سرویس‌هایی را که در Cloud Run اجرا کرده‌اید نمایش می‌دهد. باید سرویسی را که اخیراً مستقر کرده‌اید، ببینید. بسته به نامی که انتخاب کرده‌اید، باید چیزی شبیه به این را ببینید:

برای مشاهده جزئیات، روی نام سرویس کلیک کنید. نمونه جزئیات در زیر نشان داده شده است:

به URL توجه کنید، که چیزی جز URL سرویس نیست که می‌توانید آن را در مرورگر تایپ کنید و به API موجودی که ما مستقر کرده‌ایم دسترسی پیدا کنید. می‌توانید به Metrics و سایر جزئیات نگاهی بیندازید.

بیایید شروع کنیم و همین حالا با Google Cloud Operations Suite شروع کنیم.

۴. یک داشبورد راه‌اندازی کنید

یکی از ویژگی‌های کاربردی که 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 خود اضافه کردید. آفرین!

۵. بررسی‌های آپتایم

در این بخش، ما قصد داریم یک بررسی آپتایم برای سرویس API خود که مستقر کرده‌ایم، تنظیم کنیم. یک بررسی آپتایم عمومی می‌تواند درخواست‌هایی را از مکان‌های مختلف در سراسر جهان به URL های عمومی یا منابع Google Cloud ارسال کند تا ببیند آیا منبع پاسخ می‌دهد یا خیر.

منبع در این مورد، سرویس API خواهد بود که ما در Cloud Run مستقر کرده‌ایم. URL یک نقطه پایانی خاص خواهد بود که سرویس API برای نشان دادن سلامت سرویس در معرض آن قرار می‌دهد.

در کد سرویس API نمونه، ما یک نقطه پایانی /healthy را نمایش داده‌ایم که مقدار رشته‌ای " All Izz Well " را برمی‌گرداند. بنابراین تنها کاری که باید انجام دهیم این است که یک بررسی زمان فعال بودن را تعریف کنیم که به چیزی مانند https://<SERVICE_URL>/healthy برخورد کند و بررسی کند که آیا رشته "All Izz Well" برگردانده می‌شود یا خیر.

ایجاد کانال اعلان

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

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

برای ایجاد کانال اعلان، مراحل زیر را دنبال کنید:

همانطور که در زیر نشان داده شده است، از منوی اصلی در کنسول ابری گوگل به مسیر Monitoring → Alerting بروید:

این کار صفحه‌ای حاوی هشدارها، سیاست‌ها و موارد دیگر را نمایش می‌دهد. فعلاً، در بالای صفحه لینکی با عنوان «ویرایش کانال‌های اعلان» خواهید دید. روی آن کلیک کنید.

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

بخش ایمیل را پیدا کنید و روی افزودن جدید برای آن ردیف کلیک کنید. این کار جزئیات پیکربندی ایمیل را مطابق شکل زیر نمایش می‌دهد:

آدرس ایمیل و نام نمایشی خود را مطابق شکل زیر وارد کنید. روی ذخیره کلیک کنید.

این کار ایجاد کانال اعلان ایمیل را تکمیل می‌کند. بیایید ادامه دهیم و بررسی زمان روشن بودن سرور را پیکربندی کنیم.

ایجاد بررسی آپتایم

از منوی اصلی در کنسول گوگل کلود به مسیر Monitoring → Uptime checks بروید. در بالای صفحه، لینک CREATE UPTIME CHECK را مشاهده خواهید کرد. روی آن کلیک کنید.

این یک سری مراحل را نشان می‌دهد که برای پیکربندی بررسی آپتایم باید آنها را انجام دهید.

اولین قدم، تنظیم جزئیات هدف، یعنی اطلاعات مربوط به سرویس Cloud Run که مستقر کرده‌ایم، است. فرم تکمیل‌شده در زیر نشان داده شده است:

مقادیر مختلف را می‌توان به صورت زیر انتخاب کرد:

• پروتکل: HTTPS
• نوع منبع: سرویس Cloud Run را انتخاب کنید. به منابع دیگری که پشتیبانی می‌کند و اینکه می‌توانید بررسی‌های Uptime را روی آنها نیز تنظیم کنید، توجه کنید.
• سرویس اجرای ابری: my-inventory-api یا نام خاصی که برای سرویس اجرای ابری در نظر دارید را انتخاب کنید.
• مسیر /healthy است، زیرا ما یک رشته " All Izz Well" را برمی‌گردانیم و می‌خواهیم این را بررسی کنیم.

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

می‌توانید ببینید که ما بررسی «تطبیق محتوا» را فعال می‌کنیم و سپس تنظیم می‌کنیم که پاسخ برگردانده شده توسط نقطه پایانی /healthy «همه خوب هستند» باشد. برای رفتن به مرحله بعدی که در آن هشدار را پیکربندی می‌کنیم و اینکه در صورت عدم موفقیت بررسی زمان فعال بودن سرور، از کدام کانال اعلان باید هشدار دریافت کنیم، روی «ادامه» کلیک کنید.

در این مرحله، برای هشدار یک نام انتخاب کنید. من آن را Inventory API Uptime Check failure انتخاب کرده‌ام، اما شما می‌توانید نام دلخواه خود را انتخاب کنید. نکته مهم در اینجا انتخاب کانال اعلان صحیح از لیستی است که قبلاً پیکربندی کرده‌اید.

برای مرحله آخر، روی REVIEW کلیک کنید تا بررسی Uptime که پیکربندی کرده‌ایم را بررسی کنید.

در این مرحله آخر، یک نام برای بررسی آپتایم (Uptime check) انتخاب کنید (مثلاً Inventory API Uptime Check ) و سپس می‌توانید بررسی کنید که آیا بررسی به درستی پیکربندی شده است یا خیر. برای این کار روی دکمه TEST کلیک کنید.

ادامه دهید و فرآیند را تکمیل کنید (روی دکمه CREATE در سمت چپ کلیک کنید). Google Cloud به کاوشگرهای بررسی آپتایم پیکربندی شده در مناطق مختلف دستور می‌دهد تا URL را پینگ کنند و این پاسخ‌ها جمع‌آوری می‌شوند. پس از چند دقیقه به بخش Monitoring → Uptime checks مراجعه کنید و در حالت ایده‌آل باید تمام سیگنال‌های سبز را که نشان می‌دهند URL از کاوشگرهای مختلف قابل دسترسی بوده است، مشاهده کنید.

اگر هر یک از کاوشگرها برای مدت زمانی (که قابل تنظیم است) از کار بیفتند، یک اعلان هشدار در کانال ایمیلی که پیکربندی کرده‌ایم دریافت خواهید کرد.

این بخش ما در مورد تنظیم بررسی آپتایم را کامل می‌کند. آفرین!

۶. کاوشگر معیارها

مانیتورینگ ابری هزاران معیار استاندارد را از چندین محصول ابری گوگل در معرض نمایش قرار می‌دهد. این معیارها برای بررسی، پرس‌وجو، تبدیل به نمودار، افزودن به داشبورد، ایجاد هشدار و موارد دیگر در دسترس شما هستند.

هدف ما در این بخش:

1. بفهمید که چگونه می‌توانید معیارهای مختلف را بررسی کنید و سپس ما یک معیار خاص (تاخیر) را برای سرویس API خود بررسی خواهیم کرد.
2. آن معیار را به یک نمودار و داشبورد سفارشی تبدیل کنید که بتوانیم از آن برای تجسم معیار در هر زمان استفاده کنیم.

بررسی معیار تأخیر برای سرویس API موجودی

از منوی اصلی در کنسول گوگل کلود به مسیر Monitoring → Metrics Explorer بروید. این کار شما را به صفحه Metrics Explorer می‌برد. روی SELECT A METRIC کلیک کنید. اکنون می‌توانید چندین منبع فعال که معیارهای تولید شده دارند را پیمایش کنید.

از آنجایی که ما با سرویس‌های Cloud Run سروکار داریم، روی Cloud Run Revision کلیک کنید، سپس دسته‌بندی و معیار خاص با عنوان Request Latency را مطابق شکل زیر انتخاب کنید:

روی اعمال کلیک کنید. این کار تأخیر درخواست را در یک نمودار نمایش می‌دهد. می‌توانید نوع ابزارک را از تنظیمات نمایش در سمت راست، همانطور که در زیر نشان داده شده است، به نمودار خطی تغییر دهید:

این نمودار تأخیر را مطابق شکل زیر نمایش می‌دهد:

ایجاد نمودار و داشبورد سفارشی

بیایید ادامه دهیم و این نمودار را ذخیره کنیم. روی ذخیره نمودار کلیک کنید و از جزئیات مانند تصویر زیر استفاده کنید:

به خاطر داشته باشید که ما در حال ایجاد یک داشبورد جدید هستیم، نه ذخیره آن در یک داشبورد موجود. روی دکمه ذخیره کلیک کنید. این کار داشبورد تازه ایجاد شده را به لیست داشبوردهای ما اضافه می‌کند، همانطور که در زیر نشان داده شده است:

برای مشاهده جزئیات، روی داشبورد خاصی که ایجاد کرده‌ایم کلیک کنید.

این بخش مربوط به بررسی معیارهای مختلف از طریق Metrics Explorer و نحوه ایجاد داشبوردهای سفارشی ما را تکمیل می‌کند.

۷. ثبت وقایع در فضای ابری

در این بخش، قصد داریم Cloud Logging را بررسی کنیم. Cloud Logging با یک رابط کاربری Logs Explorer ارائه می‌شود که به شما کمک می‌کند تا در لاگ‌های تولید شده توسط سرویس‌های مختلف گوگل و برنامه‌های خودتان پیمایش کرده و به آنها دسترسی پیدا کنید.

در این بخش، با Logs Explorer آشنا می‌شویم و چند پیام لاگ را شبیه‌سازی می‌کنیم که می‌توانیم از طریق ویژگی‌ای به نام Log-based metrics آنها را جستجو و به معیارها تبدیل کنیم.

کاوشگر گزارش‌ها

شما می‌توانید از طریق مسیر Logging →Logs Explorer در کنسول اصلی گوگل کلود، مطابق شکل زیر، به Logs Explorer دسترسی پیدا کنید:

این یک رابط گزارش نمایش می‌دهد که در آن می‌توانید منابع مختلف (پروژه، منبع ابری گوگل، نام سرویس‌ها و غیره) را به طور خاص انتخاب/لغو انتخاب کنید و همچنین سطوح گزارش را برای فیلتر کردن پیام‌های گزارش در صورت نیاز تنظیم کنید.

در بالا لیست لاگ‌های مربوط به Cloud Run Revision، یعنی سرویس‌های Cloud Run که ما پیاده‌سازی کرده‌ایم، نشان داده شده است. چندین درخواست مشاهده خواهید کرد که مربوط به بررسی‌های Uptime هستند و به نقطه پایانی /healthy که ما پیکربندی کرده‌ایم، می‌رسند.

جستجو برای هشدارها

با ارائه شناسه‌های محصولی که جزو I-1، I-2 و I-3 نیستند، چند درخواست نامعتبر به سرویس موجودی را شبیه‌سازی کنید. برای مثال، یک درخواست نادرست عبارت است از:

https://<SERVICE_URL>/inventory/I-999

اکنون تمام هشدارهایی را که توسط API ما ایجاد شده‌اند، هنگامی که یک شناسه محصول نادرست در پرس و جو ارائه شده است، جستجو خواهیم کرد.

در کادر جستجو، پارامترهای جستجوی زیر را وارد کنید:

منبع.نوع="cloud_run_revision"

textPayload =~ "درخواست موجودی برای شناسه محصول نادرست دریافت شد"

باید چیزی شبیه به این باشد:

روی اجرای پرس‌وجو کلیک کنید. سپس تمام درخواست‌هایی که دریافت شده‌اند و این مشکل را دارند، به شما نشان داده می‌شود.

معیارهای مبتنی بر لاگ

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

برای تبدیل موارد فوق به یک معیار خطا، روی دکمه Create Metric که در Logs Explorer مشاهده می‌کنید، کلیک کنید.

این کار فرم ایجاد تعریف معیار را نمایش می‌دهد. با یک شمارنده معیار شروع کنید و جزئیات نام معیار (inventory_lookup_errors) و توضیحات را مطابق شکل زیر وارد کنید و روی ایجاد معیار کلیک کنید.

این کار متریک شمارنده را ایجاد می‌کند و باید پیامی مانند تصویر زیر مشاهده کنید:

از منوی اصلی به مسیر Logging → Logs-based Metrics بروید. در آنجا باید معیار سفارشی که در لیست معیارهای تعریف‌شده توسط کاربر تعریف کرده‌ایم را به صورت زیر ببینید:

در انتهای این مطلب، سه نقطه عمودی خواهید دید، روی آنها کلیک کنید تا عملیاتی را که می‌توانید روی این معیار سفارشی انجام دهید، مشاهده کنید. لیست باید مشابه لیستی باشد که در زیر می‌بینید. روی گزینه View in Metrics Explorer کلیک کنید.

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

روی ذخیره نمودار کلیک کنید. از مقادیر زیر برای گزینه‌های ذخیره نمودار استفاده کنید:

اکنون یک داشبورد جدید ایجاد می‌شود که می‌توانید خطاهای جستجوی موجودی را در آن مشاهده کنید و در لیست داشبوردها در دسترس خواهد بود.

عالی! شما اکنون یک معیار سفارشی از گزارش‌های خود ایجاد کرده‌اید و آن را به نموداری تبدیل کرده‌اید که در داشبورد سفارشی وجود دارد. این به ما کمک می‌کند تا تعداد تماس‌هایی را که از شناسه‌های محصول نادرست استفاده می‌کنند، ردیابی کنیم.

۸. سیاست‌های هشدار

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

ایجاد یک سیاست هشدار

بیایید به داشبورد جستجوی موجودی برویم. این کار نموداری را که برای ثبت خطاهای جستجوی موجودی ایجاد کرده‌ایم، مطابق شکل زیر نمایش می‌دهد:

این کار داده‌های معیار فعلی را نمایش می‌دهد. ابتدا معیار را مطابق شکل زیر ویرایش می‌کنیم (روی دکمه ویرایش کلیک کنید):

این کار جزئیات معیار را نمایش می‌دهد. ما قصد داریم نمودار را از نمایش نرخ خطاها به مجموع، یعنی تعداد خطاها، تبدیل کنیم. فیلدی که باید تغییر کند در زیر نشان داده شده است:

روی گزینه‌ی «اعمال» در گوشه‌ی بالا سمت راست کلیک کنید تا به صفحه‌ی «معیارها» برگردیم، اما این بار می‌توانیم تعداد کل خطاها در دوره‌ی هم‌ترازی را نسبت به نرخ خطاها مشاهده کنیم.

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

شما باید صفحه‌ای مطابق شکل زیر ببینید:

روی Next کلیک کنید، این یک مقدار آستانه (Threshold) را نمایش می‌دهد که می‌توانیم تنظیم کنیم. آستانه نمونه‌ای که ما در اینجا در نظر گرفته‌ایم ۵ است، اما شما می‌توانید طبق ترجیح خود آن را انتخاب کنید.

برای نمایش فرم اعلان‌ها، روی «بعدی» کلیک کنید.

ما کانال اعلان را به عنوان کانال ایمیل که قبلاً ایجاد کردیم انتخاب کرده‌ایم. شما می‌توانید جزئیات دیگری مانند مستندات (که به عنوان بخشی از هشداری که ایجاد می‌شود ارائه می‌شود) را پر کنید. برای مشاهده خلاصه و تکمیل فرآیند، روی «بعدی» کلیک کنید.

پس از ایجاد این سیاست هشدار، همانطور که در زیر نشان داده شده است، در لیست سیاست‌های هشدار قابل مشاهده خواهد بود. می‌توانید با رفتن به مسیر Monitoring → Alerting به لیست سیاست‌های هشدار دسترسی پیدا کنید. برای مشاهده لیست سیاست‌هایی که تاکنون پیکربندی کرده‌ایم، بخش Policyها را در صفحه جستجو کنید.

عالی! شما اکنون یک سیاست هشدار سفارشی پیکربندی کرده‌اید که در صورت افزایش نرخ خطاها هنگام جستجوی API موجودی، به شما اطلاع می‌دهد.

۹. نظارت بر سرویس (اختیاری)

در این بخش، ما قصد داریم SLI/SLOها را برای سرویس‌های خود طبق اصول مهندسی قابلیت اطمینان سایت (SRE) راه‌اندازی کنیم. متوجه خواهید شد که Cloud Monitoring با کشف خودکار سرویس‌هایی که در Cloud Run مستقر کرده‌اید، کار را برای شما آسان‌تر می‌کند و می‌تواند SLIهای کلیدی مانند Availability و Latency را به همراه محاسبات Error Budget به طور خودکار برای شما محاسبه کند.

بیایید ادامه دهیم و Latency SLO را برای سرویس API خود تنظیم کنیم.

تنظیم SLO تأخیر برای سرویس موجودی

از منوی اصلی در Cloud Console روی Monitoring → Services کلیک کنید. این کار لیستی از سرویس‌هایی را که برای Service Monitoring پیکربندی شده‌اند، نمایش می‌دهد.

در حال حاضر، ما هیچ سرویسی برای مانیتورینگ SLI/SLO راه‌اندازی نکرده‌ایم، بنابراین لیست خالی است. برای تعریف/شناسایی یک سرویس، ابتدا روی لینک DEFINE SERVICE در بالا کلیک کنید.

این به طور خودکار سرویس‌هایی را که کاندید نظارت بر SLO هستند، کشف می‌کند. این ابزار قادر به کشف سرویس‌های Cloud Run است و از این رو سرویس Inventory API ما که در Cloud Run مستقر شده است، در لیست قابل مشاهده خواهد بود.

نام نمایشی که می‌بینید ممکن است متفاوت باشد و به آنچه در زمان استقرار سرویس در Cloud Run انتخاب کرده‌اید بستگی دارد. روی دکمه SUBMIT کلیک کنید. این کار صفحه‌ای را که در زیر نشان داده شده است، نمایش می‌دهد:

می‌توانید روی CREATE SLO کلیک کنید. این کار به شما امکان می‌دهد از بین SLIهایی که به طور خودکار برای شما محاسبه می‌شوند، انتخاب کنید.

ما Latency SLI را به عنوان شروع انتخاب می‌کنیم. روی ادامه کلیک کنید. در مرحله بعد، صفحه‌ای را مشاهده خواهید کرد که عملکرد فعلی این سرویس و میزان تأخیر معمول آن را نشان می‌دهد.

ما مقداری برای آستانه (Threshold) یعنی ۳۰۰ میلی‌ثانیه قرار می‌دهیم، که همان مقداری است که می‌خواهیم به آن برسیم. در صورت تمایل می‌توانید مقدار دیگری را انتخاب کنید، اما به خاطر داشته باشید که این مقدار بر بودجه خطایی که متناسب با آن تعریف می‌کنید، تأثیر خواهد گذاشت. روی ادامه (CONTINUE) کلیک کنید.

اکنون SLO (پنجره هدف و اندازه‌گیری) را مطابق شکل زیر تنظیم می‌کنیم:

این یعنی ما پنجره اندازه‌گیری را از نوع غلتان انتخاب می‌کنیم و آن را در طول ۷ روز اندازه‌گیری می‌کنیم. به طور مشابه برای هدف، هدف ۹۰٪ را انتخاب کرده‌ایم. چیزی که ما در اینجا سعی داریم بگوییم این است که ۹۰٪ درخواست‌ها به سرویس API باید ظرف ۳۰۰ میلی‌ثانیه تکمیل شوند و این باید در طول ۷ روز اندازه‌گیری شود.

روی ادامه کلیک کنید. این صفحه خلاصه را نمایش می‌دهد که می‌توانید با کلیک روی دکمه UPDATE SLO آن را تأیید کنید.

این تعریف SLO شما را ذخیره می‌کند و بودجه خطا به طور خودکار برای شما محاسبه می‌شود.

چند نکته که می‌توانید امتحان کنید:

1. API را از طریق چندین فراخوانی اجرا کنید و عملکرد سرویس و نحوه تأثیر آن بر بودجه خطای باقیمانده را مشاهده کنید.
2. کد منبع را طوری تغییر دهید که در برخی از فراخوانی‌ها، تأخیر اضافی (حالت خواب) به صورت تصادفی اعمال شود. این کار باعث افزایش تأخیر برای تعدادی از فراخوانی‌ها می‌شود و باید تأثیر منفی بر بودجه خطا (Error Budget) داشته باشد.

۱۰. تبریک

تبریک می‌گوییم، شما با موفقیت یک برنامه نمونه را در Google Cloud مستقر کردید و نحوه استفاده از Google Cloud Operations Suite را برای نظارت بر سلامت برنامه آموختید!

آنچه ما پوشش داده‌ایم

• استقرار یک سرویس در Google Cloud Run.
• راه‌اندازی داشبورد برای سرویس Google Cloud Run
• بررسی‌های آپتایم.
• تنظیم معیارهای گزارش سفارشی و داشبورد/نمودار بر اساس آن.
• بررسی ابزار اندازه‌گیری (Metrics Explorer) و تنظیم داشبورد/نمودار.
• تنظیم سیاست‌های هشدار
• راه‌اندازی SLI/SLO برای نظارت بر سرویس در Google Cloud.

توجه: اگر codelab را با استفاده از حساب کاربری خود و پروژه Google Cloud اجرا کرده‌اید، منابع اختصاص داده شده ممکن است همچنان شامل هزینه شوند. بنابراین، پس از اتمام کار با آزمایشگاه، پروژه و منابع را حذف کنید.

بعدش چی؟

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

• مجموعه عملیات ابری گوگل

مطالعه بیشتر

• صفحه اصلی محصول عملیات ابری
• مستندات عملیات ابری