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

۱. مقدمه

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

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

Google Cloud Operations Suite is a platform where you can monitor, troubleshoot, and improve application performance on your Google Cloud environment. Key Pillars of Cloud Operations Suite include Cloud Monitoring, Cloud Logging and Cloud Tracing.

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

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

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

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

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

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

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

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

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

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

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

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

Note: If you're using a Gmail account, you can leave the default location set to No organization. If you're using a Google Workspace account, then choose a location that makes sense for your organization.

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

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

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

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

If you've never started Cloud Shell before, you're presented with an intermediate screen (below the fold) describing what it is. If that's the case, click Continue (and you won't ever see it again). Here's what that one-time screen looks like:

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

This virtual machine is loaded with all the development tools you need. It offers a persistent 5GB home directory and runs in Google Cloud, greatly enhancing network performance and authentication. Much, if not all, of your work in this codelab can be done with simply a browser or your Chromebook.

پس از اتصال به 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 هستند.

Note: This API application is for demo purposes only and does not represent a secure and robust API implementation. It is meant to have a quick application available to us, to explore the key purpose of the lab ie Google Cloud Operations.

داده‌های نمونه و درخواست/پاسخ 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 در نوار ابزار بالا سمت راست کلیک کنید:

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

This virtual machine is loaded with all the development tools you'll need. It offers a persistent 5GB home directory, and runs on Google Cloud, greatly enhancing network performance and authentication. All of your work in this lab can be done with simply a browser.

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

در 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. In the terminal, provide the following command (At the time of writing, Cloud Shell comes with Python 3.9.x installed and we will use the default version. If you plan to run it locally on your laptop, you can go with Python 3.8+) :

$ 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 .

This will ask you multiple questions (if asked to authorize, please go ahead) and some of the points are mentioned below. You may or may not get all the questions, depending on the configuration and if you have already enabled specific APIs in your Google Cloud project.

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) اجازه فراخوانی‌های احراز هویت نشده داده می‌شود؟ بله

Eventually, this will kick-off the process to take your source code, containerize it, push it to the Artifact Registry and then deploy the Cloud Run service + revision. You should be patient through this process (can take 3-4 minutes) and you should see the process getting completed with the Service URL shown to you.

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

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

اکنون که برنامه را در 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 دسترسی داشته باشیم.

From the main menu, navigate to Cloud Run. This will display the list of services that you have running in Cloud Run. You should see the service that you just deployed. Depending on the name that you selected, you should see something like this:

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

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

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

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

One of the convenient features that Cloud Monitoring provides is Out-of-the-Box (OOTB) dashboards across multiple resources in Google Cloud. This makes the initial setup of Dashboards with standard metrics, a quick and convenient process.

بیایید نگاهی به نحوه انجام این کار برای سرویس API که به تازگی در Cloud Run مستقر کرده‌ایم، بیندازیم.

داشبورد سفارشی برای خدمات ما

از آنجایی که سرویس API خود را در Cloud Run مستقر کرده‌ایم، بیایید نحوه تنظیم داشبوردهایی را بررسی کنیم که می‌توانند به تجسم معیارهای مختلف، از جمله تأخیر سرویس، کمک کنند.

ابتدا، از کنسول، مطابق شکل زیر به بخش Monitoring → Overview مراجعه کنید:

نمای کلی چندین مورد را که شما در بخش مانیتورینگ پیکربندی می‌کردید، مانند داشبوردها، هشدارها، بررسی‌های آپتایم و غیره، نشان می‌دهد.

فعلاً، بیایید از منوی اصلی کناری روی داشبوردها کلیک کنیم. این ما را به صفحه زیر می‌برد:

Click on SAMPLE LIBRARY . This will display the list of Out-Of-The-Box (OOTB) Dashboards that are available in Google Cloud, across multiple resources. Specifically, scroll down the list and select Google Cloud Run as shown below.

این لیستی از داشبوردهای استاندارد موجود برای Google Cloud Run را نمایش می‌دهد. ما به این موضوع علاقه‌مندیم زیرا سرویس خود را روی Cloud Run مستقر کرده‌ایم.

You will see one Dashboard for Cloud Run Monitoring. Click on PREVIEW link to view the list of standard charts (metrics)that are available for Cloud Run Monitoring. Simply click on IMPORT SAMPLE DASHBOARD to import all these charts into a custom dashboard. This will present a Dashboard screen with a prefilled name for the same as shown below:

You can navigate back by clicking on the Left Arrow , which is to the left of the Dashboard name, right on the top left. This will lead to the list of Dashboards, out of which you should be able to see the new Dashboard that you just created.

روی لینک داشبورد کلیک کنید تا بتوانید معیارهای متعددی را که به صورت پیش‌فرض در دسترس هستند، رصد کنید. این معیارها شامل تأخیر، تعداد درخواست‌ها، معیارهای کانتینر و موارد دیگر می‌شود.

همچنین می‌توانید با انتخاب آیکون ستاره، همانطور که در زیر نشان داده شده است، هر یک از داشبوردها را به عنوان مورد علاقه علامت‌گذاری کنید:

این کار داشبورد را به صفحه مرور کلی مانیتورینگ اضافه می‌کند و به روشی آسان برای پیمایش به داشبوردهای پرکاربرد تبدیل می‌شود.

فوق‌العاده‌ست! شما همین الان یک داشبورد سفارشی برای نظارت بر سرویس‌های Cloud Run خود اضافه کردید. آفرین!

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

In this section, we are going to set up an uptime check for our API Service that we have deployed. A public uptime check can issue requests from multiple locations throughout the world to publicly available URLs or Google Cloud resources to see whether the resource responds.

The resource in this case is going to be the API Service that we have deployed to Cloud Run. The URL will be a specific endpoint that the API Service exposes to indicate the health of the service.

In the sample API service code, we have exposed an endpoint /healthy that returns a string value " All Izz Well ". So all we need to do is define an uptime check that hits something like https://<SERVICE_URL>/healthy and checks if the string "All Izz Well" is returned or not.

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

Before we create the uptime check, it is important to first configure notification channels. A notification channel is a medium over which you will be alerted if there is an incident/issue with any of our monitored resources. An example of a notification channel is Email and you will receive emails in case there is an Alert, etc.

For now, we are going to configure an Email Notification Channel and configure it with our email address, so that we can get notified in case of any alerts which our system will raise and which we will configure.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You can see that we are enabling the check for "Content Matching" and then setting up that the response returned by the /healthy endpoint will be "All Izz Well". Click on CONTINUE to move to the next step where we will configure the Alert and which notification channel we should be alerted on, if the Uptime check fails.

In this step, give a name to the Alert. I have chosen it as Inventory API Uptime Check failure , but you can choose your name. The important thing here is to select the correct notification channel from the list that you configured earlier.

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

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

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

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

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

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

Cloud Monitoring exposes thousands of standard metrics from multiple Google Cloud products. These metrics are available for you to investigate, query, convert to Charts, add to Dashboards, raise Alerts on and more.

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

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

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

Go to Monitoring → Metrics Explorer from the main menu in Google Cloud Console. This will take you to the Metrics Explorer screen. Click on SELECT A METRIC. You can now navigate several active resources that have metrics generated.

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

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

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

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

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

Keep in mind that we are creating a new dashboard , instead of saving it in an existing dashboard. Click on the SAVE button. This will add the newly created dashboard to our list of dashboards as shown below:

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

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

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

In this section, we are going to explore Cloud Logging. Cloud Logging comes with a Logs Explorer interface that helps you navigate and dive into logs generated by various Google Services and your own applications.

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

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

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

This will display a log interface where you can specifically select/deselect various Resources (Project, Google cloud Resource, service names, etc) along with Log levels to filter the log messages as needed.

Shown above is the list of logs for the Cloud Run Revision ie Cloud Run services that we have deployed. You will see several requests that are Uptime checks hitting the /healthy endpoint that we have configured.

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

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

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

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

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

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

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

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

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

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

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

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

This will bring up the form to create the metric definition. Go with a Counter Metric and enter the details for the Metric Name (inventory_lookup_errors) and Description as shown below and click on Create Metric .

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

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

At the end of this entry, you will find three vertical dots , click on them to see the operations that you can perform on this custom metric. The list should be similar to the one that you are seeing below. Click on the View in Metrics Explorer option.

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

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

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

Great ! You have now created a custom metric from your logs, converted that into a chart that is there in a custom dashboard. This will help us track the number of calls that are using incorrect product Ids.

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

In this section, we will use the custom metric that we created and monitor its data for a threshold ie if the number of errors goes beyond a certain threshold, we will raise an alert. In other words, we are going to set up an alert policy.

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

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

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

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

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

We are going to create an Alert Policy that can notify us in case the number of errors are going beyond a threshold. Click on the 3 dots at the top right corner of the chart and from the list of options, as shown above, click on Convert to alert chart.

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

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

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

We have selected the Notification Channel as the Email channel that we created earlier. You may fill up the other details like Documentation (which will be provided as part of the Alert that gets raised). Click on NEXT to see the summary and complete the process.

Once you create this Alert Policy, it will be visible in the list of Alert Policies as shown below. You can get to the list of Alert Policies, by going to Monitoring → Alerting . Scan for the Policies section in the page to see the list of policies that we have configured so far.

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

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

In this section, we are going to set up SLI/SLOs for our services as per Site Reliability Engineering (SRE) principles. You will notice that Cloud Monitoring makes it easier for you by auto-discovering services that you have deployed in Cloud Run and can compute key SLIs like Availability, Latency automatically for you along with Error Budget calculations.

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

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

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

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

This will auto discover services that are a candidate for SLO Monitoring. It is able to discover Cloud Run services and hence our Inventory API service deployed to Cloud Run will be visible in the list.

The display name that you see might be different and will depend on what you chose at the time of deploying the service to Cloud Run. Click on the SUBMIT button. This will bring up the screen shown below:

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

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

We put in a value for the Threshold ie 300ms , which is what we want to achieve. You can choose a different value if you want but keep in mind that it will affect the error budget that you define accordingly. Click on CONTINUE .

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

This means that we are selecting the Measurement window as a Rolling type window and measuring it across 7 days. Similarly for the target, we have chosen a goal of 90%. What we are trying to say here is that 90% of the requests to the API service should complete within 300ms and this should be measured across 7 days.

روی ادامه کلیک کنید. این صفحه خلاصه را نمایش می‌دهد که می‌توانید با کلیک روی دکمه 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.

Note: If you have executed the codelab using your own account and Google Cloud project, the resources allocated may continue to incur a billing charge. So delete the Project and resources once you are done with the lab.

بعدش چی؟

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

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

مطالعه بیشتر

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