1. מבוא
העדכון האחרון: 28 ביולי 2023
מהי חבילת התפעול של Google Cloud?
Google Cloud Operations Suite היא פלטפורמה שבה אפשר לעקוב אחרי ביצועי האפליקציות בסביבת Google Cloud, לפתור בעיות ולשפר אותם. העמודות העיקריות של Cloud Operations Suite כוללות את Cloud Monitoring, Cloud Logging ו-Cloud Tracing.
בסרטון הזה מופיעה סקירה כללית על Google Cloud Operations.
מה תפַתחו
בסדנת הקוד הזו פורסים ממשק API לדוגמה ב-Google Cloud. לאחר מכן תבדקו ותגדירו מספר תכונות ב-Cloud Monitoring לעומת ה-API.
מה תלמדו
- שימוש ב-Cloud Shell של Google Cloud כדי לפרוס אפליקציה לדוגמה ב-Cloud Run.
- שימוש בתכונות של Google Cloud Monitoring כמו לוחות בקרה, התראות, בדיקות זמני פעילות, מעקב SLI/SLO ועוד.
מה צריך להכין
- גרסה עדכנית של Chrome (גרסה 74 ואילך)
- חשבון Google Cloud ופרויקט ב-Google Cloud
2. הגדרה ודרישות
הגדרת סביבה בקצב עצמאי
אם עדיין אין לכם חשבון Google (Gmail או Google Apps), עליכם ליצור חשבון. נכנסים למסוף Google Cloud Platform ( console.cloud.google.com) ויוצרים פרויקט חדש.
- שם הפרויקט הוא השם המוצג של המשתתפים בפרויקט. זוהי מחרוזת תווים שלא משמשת את Google APIs. אפשר לעדכן את המיקום הזה בכל שלב.
- מזהה הפרויקט חייב להיות ייחודי בכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו (אי אפשר לשנות אותו אחרי שמגדירים אותו). מסוף Cloud יוצר מחרוזת ייחודית באופן אוטומטי, ובדרך כלל לא משנה מה המחרוזת הזו. ברוב ה-codelabs תצטרכו להפנות למזהה הפרויקט (בדרך כלל הוא מזוהה בתור PROJECT_ID). אם המזהה שנוצר לא מוצא חן בעיניכם, תוכלו ליצור מזהה אקראי אחר. לחלופין, אפשר לנסות שם משלכם ולבדוק אם הוא זמין. לא ניתן לשנות את השם אחרי השלב הזה, והוא יישאר למשך כל תקופת הפרויקט.
- לידיעתך, יש ערך שלישי, מספר פרויקט, שמשתמשים בו בחלק מממשקי ה-API. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי העזרה.
חשוב לדעת: מזהה הפרויקט חייב להיות ייחודי גלובלי, ואף אחד אחר לא יוכל להשתמש בו אחרי שתבחרו בו. אתם היחידים שמשתמשים במזהה הזה. גם אם פרויקט נמחק, לא ניתן להשתמש במזהה שלו שוב
- בשלב הבא, כדי להשתמש במשאבים או ב-API של Cloud, תצטרכו להפעיל את החיוב במסוף Cloud. השלמת הקודלאב הזה לא אמורה לעלות הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים אחרי סיום המדריך, אפשר למחוק את המשאבים שיצרתם או למחוק את הפרויקט כולו. משתמשים חדשים ב-Google Cloud זכאים להשתתף בתוכנית תקופת ניסיון בחינם בסך 300$.
הגדרת Google Cloud Shell
אפשר להפעיל את Google Cloud ו-Google Cloud Trace מרחוק מהמחשב הנייד, אבל בסדנת הקוד הזו נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת ב-Cloud.
כדי להפעיל את Cloud Shell במסוף Cloud, פשוט לוחצים על Activate Cloud Shell (הקצאת המשאבים וההתחברות לסביבה אמורים להימשך רק כמה רגעים).
אם זו הפעם הראשונה שאתם מפעילים את Cloud Shell, יוצג מסך ביניים (מתחת לקצה המסך) עם תיאור של Cloud Shell. במקרה כזה, לוחצים על 'המשך' (והמסך הזה לא יוצג שוב). כך נראה המסך החד-פעמי:
תהליך ההקצאה וההתחברות ל-Cloud Shell אמור להימשך רק כמה רגעים.
המכונה הווירטואלית הזו כוללת את כל הכלים הדרושים לפיתוח. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר משמעותית את ביצועי הרשת והאימות. אפשר לבצע חלק גדול מהעבודה בקודלאב הזה, אם לא את כולה, באמצעות דפדפן או Chromebook.
אחרי ההתחברות ל-Cloud Shell, אתם אמורים לראות שכבר בוצע אימות ושהפרויקט כבר מוגדר למזהה הפרויקט שלכם.
מריצים את הפקודה הבאה ב-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. המאגר מכיל כמה אפליקציות לדוגמה, ואפשר להשתמש בכל אחת מהן בתרגול הזה.
קישור למאגר Git: https://github.com/rominirani/cloud-code-sample-repository
3. פריסת אפליקציית ה-API
מהו הנושא של האפליקציה או ה-API לדוגמה?
האפליקציה שלנו היא אפליקציה פשוטה של Inventory API שחשפה נקודת קצה של API ל-REST עם כמה פעולות להצגת רשימת הפריטים במלאי ולקבלת מספר פריטים ספציפיים במלאי.
אחרי שפורסים את ה-API, בהנחה שהוא מתארח בכתובת https://<somehost>, אפשר לגשת לנקודות הקצה של ה-API באופן הבא:
- https://<somehost>/inventory
ברשימה יופיעו כל הפריטים של המוצרים עם רמות המלאי הקיימות.
- https://<somehost>/inventory/{productid}
תהיה לכם רשומה אחת עם מאפיין מזהה המוצר (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} |
שכפול המאגר
אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל בסדנת הקוד הזו נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת ב-Cloud.
במסוף GCP, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:
תהליך ההקצאה והחיבור לסביבת העבודה אמור להימשך רק כמה רגעים. בסיום, אמור להופיע משהו כזה:
המכונה הווירטואלית הזו כוללת את כל הכלים הדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, משפרת מאוד את ביצועי הרשת ואת האימות. כל העבודה בשיעור ה-Lab הזה יכולה להתבצע באמצעות דפדפן בלבד.
הגדרת gcloud
ב-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
כדי להריץ את האפליקציה באופן מקומי, פועלים לפי השלבים הבאים:
- בטרמינל, עוברים לגרסת Python של ה-API באמצעות הפקודה הבאה:
$ cd cloud-code-sample-repository
$ cd python-flask-api
- בטרמינל, מזינים את הפקודה הבאה (בזמן כתיבת המאמר, ב-Cloud Shell מותקנת גרסת Python 3.9.x, ואנחנו נשתמש בגרסה שמוגדרת כברירת מחדל. אם אתם מתכננים להריץ אותו באופן מקומי במחשב הנייד, אתם יכולים להשתמש ב-Python 3.8 ואילך:
$ python app.py
- אפשר להריץ את הפקודה הבאה כדי להפעיל את שרת Python באופן מקומי.
- הפקודה הזו תפעיל שרת ביציאה 8080, ותוכלו לבדוק אותו באופן מקומי באמצעות התכונה 'תצוגה מקדימה באינטרנט' ב-Cloud Shell. לוחצים על הלחצן Web Preview (תצוגה מקדימה באינטרנט) כפי שמוצג בהמשך:
לוחצים על 'תצוגה מקדימה' ביציאה 8080.
- ייפתח חלון בדפדפן. תופיע שגיאה 404, וזה בסדר. משנים את כתובת ה-URL כך שתכלול רק את החלק /inventory אחרי שם המארח.
לדוגמה, במכונה שלי זה נראה כך:
https://8080-cs-557561579860-default.cs-asia-southeast1-yelo.cloudshell.dev/inventory
תוצג רשימת פריטי המלאי כפי שמוסבר למעלה:
- עכשיו אפשר להפסיק את השרת. עוברים ל-Terminal ומקישים על Ctrl-C.
פריסה של האפליקציה
עכשיו נפרוס את אפליקציית ה-API הזו ל-Cloud Run. התהליך כלל שימוש בלקוח שורת הפקודה של gcloud כדי להריץ את הפקודה לפריסה של הקוד ב-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
- כדי לפרוס מקוד מקור, צריך מאגר Docker ב-Artifact Registry לאחסון קונטיינרים שנוצרו. ייווצר מאגר בשם [cloud-run-source-deploy] באזור [us-west1].
רוצה להמשיך (Y/n)? Y
- לאפשר הפעלות לא מאומתות ל-[my-inventory-api] (y/N)? Y
בסופו של דבר, התהליך הזה יאפשר לקחת את קוד המקור, ליצור אותו בקונטיינרים, לדחוף אותו ל-Artifact Registry ואז לפרוס את השירות Cloud Run ואת הגרסה הקודמת. תודה על הסבלנות במהלך התהליך (התהליך עשוי להימשך 3-4 דקות), והתהליך אמור להסתיים בכתובת ה-URL של השירות.
בהמשך מוצגת דוגמה להרצה:
בדיקת האפליקציה
עכשיו, אחרי שפרוסנו את האפליקציה ב-Cloud Run, אפשר לגשת לאפליקציית ה-API באופן הבא:
- צריך לרשום את כתובת ה-URL של השירות מהשלב הקודם. לדוגמה, בהגדרה שלי הוא מוצג כ-
https://my-inventory-api-bt2r5243dq-uw.a.run.app. נקרא לו <SERVICE_URL>. - פותחים דפדפן ונכנסים ל-3 כתובות ה-URL הבאות של נקודות הקצה של ה-API:
- <SERVICE_URL>/מלאי
- <SERVICE_URL>/מלאי/I-1
- <SERVICE_URL>/מלאי/I-100
היא צריכה להיות בהתאם למפרטים שציינו בקטע הקודם, עם בקשת API ותגובה לדוגמה.
איך מקבלים את פרטי השירות מ-Cloud Run
פרסנו את שירות ה-API שלנו ב-Cloud Run, סביבה מחשובית ללא שרת (serverless). אנחנו יכולים להיכנס לשירות Cloud Run דרך מסוף Google Cloud בכל שלב.
בתפריט הראשי, עוברים אל Cloud Run. תוצג רשימת השירותים שפועלים ב-Cloud Run. השירות שפרסמתם אמור להופיע. בהתאם לשם שבחרתם, אמור להופיע משהו כזה:
לוחצים על שם השירות כדי להציג את הפרטים. הפרטים לדוגמה מוצגים בהמשך:
שימו לב לכתובת ה-URL, שהיא לא יותר מכתובת השירות שאפשר להזין בדפדפן כדי לגשת ל-Inventory API שפרוסנו עכשיו. אפשר לעיין במדדים ובפרטים אחרים.
קדימה, מתחילים עם חבילת התפעול של Google Cloud.
4. הגדרת מרכז בקרה
אחת מהתכונות הנוחות של Cloud Monitoring היא לוחות בקרה מוכנים מראש (OOTB) במספר משאבים ב-Google Cloud. כך תהליך ההגדרה הראשונית של מרכזי בקרה עם מדדים סטנדרטיים הוא מהיר ונוח.
בואו נראה איך לעשות זאת עבור שירות ה-API שפרסנו עכשיו ב-Cloud Run.
מרכז בקרה בהתאמה אישית לשירות שלנו
מכיוון שפרסנו את שירות ה-API שלנו ל-Cloud Run, בואו נראה איך להגדיר מרכזי בקרה כדי להציג מדדים שונים באופן חזותי, שחלקם כוללים את זמן האחזור של השירות.
קודם כול, במסוף, עוברים אל Monitoring (מעקב) → Overview (סקירה כללית) כפי שמוצג בהמשך:
בסקירה הכללית מוצגים כמה דברים שהגדרתם ב-Monitoring, כמו מרכזי בקרה, התראות, בדיקות זמן פעולה תקינה וכו'.
בינתיים, אפשר ללחוץ על מרכזי בקרה בתפריט הראשי שבצד. נגיע למסך הבא:
לוחצים על ספריית דוגמאות . תוצג רשימת לוחות הבקרה מוכנים לשימוש (OOTB) שזמינים ב-Google Cloud במספר משאבים. באופן ספציפי, גוללים למטה ברשימה ובוחרים באפשרות Google Cloud Run כפי שמוצג בהמשך.
תוצג רשימה של לוחות בקרה רגילים שזמינים ל-Google Cloud Run. אנחנו מעוניינים בכך כי פרסנו את השירות שלנו ב-Cloud Run.
יופיע לוח בקרה אחד ל-Cloud Run Monitoring. לוחצים על הקישור תצוגה מקדימה כדי להציג את רשימת התרשימים הסטנדרטיים (המדדים) שזמינים לניטור ב-Cloud Run. פשוט לוחצים על ייבוא לוח בקרה לדוגמה כדי לייבא את כל התרשימים האלה ללוח בקרה מותאם אישית. הפעולה הזו תציג מסך מרכז בקרה עם שם שהוזן מראש, אותו השם שמוצג בהמשך:
כדי לנווט חזרה, לוחצים על החץ שמאלה, שנמצא מימין לשם מרכז הבקרה, מימין למעלה מימין. פעולה זו תוביל לרשימה של מרכזי בקרה, שממנה תוכלו לראות את מרכז הבקרה החדש שיצרתם.
לוחצים על הקישור למרכז הבקרה כדי לעקוב אחרי מדדים רבים שזמינים ללא הגבלה. המדדים האלה כוללים זמן אחזור, ספירת בקשות, מדדי מאגר תגים ועוד.
אפשר גם לסמן כל אחד מהמדדים במרכז השליטה בתור מועדף. לשם כך, פשוט לוחצים על סמל הכוכב כפי שמוצג בהמשך:
הפעולה הזו תוסיף את מרכז הבקרה למסך הסקירה הכללית של 'מעקב', ותהיה דרך קלה לנווט למרכזי בקרה שבהם אתם משתמשים לעיתים קרובות.
מעולה! הוספת מרכז בקרה מותאם אישית למעקב אחרי שירותי Cloud Run. כל הכבוד!
5. בדיקות של זמן פעולה תקינה
בקטע הזה נגדיר בדיקת זמני פעילות לשירות ה-API שפרסנו. בדיקת זמן פעולה תקינה ציבורית יכולה לשלוח בקשות מכמה מיקומים ברחבי העולם לכתובות URL או למשאבים של Google Cloud שזמינים לכולם, כדי לבדוק אם המשאב מגיב.
המשאב במקרה הזה יהיה שירות ה-API שפרוסנו ב-Cloud Run. כתובת ה-URL תהיה נקודת קצה ספציפית ששירות ה-API חושף כדי לציין את סטטוס התקינות של השירות.
בקוד השירות לדוגמה של ה-API, חשפנו נקודת קצה (endpoint) /healthy שמחזירה את ערך המחרוזת All Izz Well". כל מה שצריך לעשות הוא להגדיר בדיקת זמן פעולה תקינה שמגיעה לכתובת כמו https://<SERVICE_URL>/healthy ובודקת אם מוחזר המחרוזת "All Izz Well" או לא.
יצירת ערוץ התראות
לפני שיוצרים את בדיקת זמן הפעולה, חשוב קודם להגדיר את ערוצי ההתראות. ערוץ התראות הוא אמצעי שבו תקבלו התראות אם תהיה תקרית או בעיה באחד מהמשאבים שבמעקב שלנו. דוגמה לערוץ התראות היא אימייל, ותקבלו אימיילים במקרה של התראה וכו'.
נכון לעכשיו, נגדיר ערוץ התראות באימייל ונגדיר אותו באמצעות כתובת האימייל שלנו, כדי שנוכל לקבל התראות במקרה של התראות שהמערכת שלנו תעלה ואילו נגדיר.
כדי ליצור ערוץ התראות:
עוברים אל Monitoring → Alerting בתפריט הראשי של מסוף Google Cloud, כפי שמוצג בהמשך:
יוצג דף עם התראות, כללי מדיניות ועוד. בשלב הזה יופיע קישור בחלק העליון עם הכיתוב עריכת ערוצי ההתראות. לוחצים עליו.
תוצג רשימה של ערוצים שונים להתראות, כפי שמתואר בהמשך:
מאתרים את הקטע אימייל ולוחצים על הוספת חדש בשורה הזו. יוצגו פרטי ההגדרה של האימייל, כפי שמוצג בהמשך:
מזינים את כתובת האימייל ואת השם לתצוגה כפי שמתואר בהמשך. לוחצים על שמירה.
זהו, ערוץ ההתראות באימייל נוצר. עכשיו נגדיר את בדיקת זמן הפעולה.
יצירת בדיקה של זמני פעילות
בתפריט הראשי במסוף Google Cloud, עוברים אל Monitoring → Uptime checks. בחלק העליון יופיע הקישור יצירת בדיקת זמן פעולה תקינה. לוחצים על הקישור.
יוצגו לכם סדרה של שלבים שצריך להשלים כדי להגדיר את בדיקת זמני הפעילות.
השלב הראשון הוא להגדיר את פרטי היעד, כלומר את המידע על שירות Cloud Run שפרוסנו. טופס מלא מוצג בהמשך:
ניתן לבחור את הערכים השונים כך:
- פרוטוקול : HTTPS
- Resource Type (סוג המשאב): בוחרים באפשרות Cloud Run Service. שימו לב למשאבים האחרים שהתכונה הזו תומכת בהם, ושאתם יכולים להגדיר גם בהם בדיקות של זמני פעילות.
- שירות Cloud Run : בוחרים את my-inventory-api או את השם הספציפי של שירות Cloud Run.
- הנתיב הוא /healthy, כי אנחנו מחזירים מחרוזת "All Izz Well" ואנחנו רוצים לבדוק את זה.
לוחצים על המשך כדי לעבור לשלב הבא. השלב הבא הוא השלב אימות תגובה כפי שמוצג בהמשך:
אפשר לראות שאנחנו מפעילים את הבדיקה של 'התאמת תוכן', ולאחר מכן מגדירים שהתגובה שתוחזר על ידי נקודת הקצה /healthy תהיה 'All Izz Well'. לוחצים על CONTINUE (המשך) כדי לעבור לשלב הבא, שבו נגדיר את ההתראה ואת ערוץ ההתראות שבו נקבל התראה אם בדיקת זמן הפעולה נכשל.
בשלב הזה, נותנים שם להתראה. בחרתי בשם Inventory API Uptime Check failure, אבל אפשר לבחור שם אחר. חשוב לבחור את ערוץ ההתראות הנכון מהרשימה שהגדרתם קודם.
כדי לעבור לשלב האחרון, לוחצים על בדיקה כדי לבדוק את בדיקת זמני הפעילות שהגדרנו.
בשלב האחרון, נותנים שם לבדיקת זמן הפעולה (למשל בדיקת זמן הפעולה של Inventory API), ואז אפשר גם לבדוק אם הבדיקה מוגדרת בצורה נכונה. כדי לעשות זאת, לוחצים על הלחצן TEST.
ממשיכים בתהליך (לוחצים על הלחצן CREATE בצד ימין). מערכת Google Cloud תורה לגששים לבדיקת זמן פעולה תקינה שהוגדרו באזורים שונים לשלוח פינג לכתובת ה-URL, והתגובות האלה ייאספו. אחרי כמה דקות, תוכלו לעבור לקטע Monitoring ← Uptime checks. במצב אידיאלי, אמורים להופיע כל האותות הירוקים שמעידים על כך שניתן להגיע לכתובת ה-URL מבקשות הבדיקה השונות.
אם אחת מהבדיקות תיכשל למשך פרק זמן מסוים (ניתן להגדרה), תקבלו התראה בערוץ האימייל שהגדרנו.
סיימנו את הקטע בנושא הגדרת בדיקה של זמני פעילות. נהדר!
6. Metrics Explorer
Cloud Monitoring חושף אלפי מדדים סטנדרטיים מכמה מוצרי Google Cloud. המדדים האלה זמינים לבדיקה, לשליחת שאילתות, להמרה לתרשימים, להוספה ללוחות בקרה, להגדרת התראות ועוד.
המטרה שלנו בקטע הזה היא:
- נלמד איך אפשר לבחון מדדים שונים, ולאחר מכן נבדוק מדד ספציפי (זמן אחזור) של שירות ה-API שלנו.
- להמיר את המדד הזה לתרשים וללוח בקרה בהתאמה אישית, שבעזרתם נוכל להציג את המדד באופן חזותי בכל שלב.
הסבר על מדד זמן האחזור בשירות Inventory API
עוברים אל Monitoring → Metrics Explorer בתפריט הראשי של מסוף Google Cloud. תועברו למסך Metrics Explorer. לוחצים על בחירת מדד. עכשיו אפשר לנווט בין כמה משאבים פעילים שנוצרו להם מדדים.
מכיוון שאנחנו מטפלים בשירותי Cloud Run, לוחצים על Cloud Run Revision, ואז על הקטגוריה והמדד הספציפי שנקרא Request Latency (זמן אחזור של בקשה), כפי שמוצג בהמשך:
לוחצים על החלה. הזמן שחלף מהבקשה יוצג בתרשים. אפשר לשנות את סוג הווידג'ט לתרשים קו בהגדרות התצוגה שבצד שמאל, כפי שמוצג בהמשך:
יוצג תרשים זמן האחזור כפי שמוצג בהמשך:
יצירת תרשים ולוח בקרה בהתאמה אישית
עכשיו נשמור את התרשים הזה. לוחצים על Save Chart ומזינים את הפרטים כפי שמתואר בהמשך:
חשוב לזכור שאנחנו יוצרים מרכז בקרה חדש , במקום לשמור אותו במרכז בקרה קיים. לוחצים על הלחצן שמירה. הפעולה הזו תוסיף את מרכז הבקרה החדש לרשימה של מרכזי הבקרה, כפי שמוצג בהמשך:
לוחצים על מרכז הבקרה הספציפי שיצרנו כדי להציג את הפרטים.
נסיים את הסעיף בנושא חקירת מדדים שונים באמצעות Metrics Explorer והאופן שבו נוכל ליצור מרכזי בקרה מותאמים אישית.
7. Cloud Logging
בקטע הזה נסביר על Cloud Logging. Cloud Logging מגיע עם ממשק Logs Explorer שעוזר לכם לנווט ולחקור יומנים שנוצרו על ידי שירותים שונים של Google ואפליקציות משלכם.
בקטע הזה נסביר על Logs Explorer ונסנכרן כמה הודעות ביומן, שבאמצעותן נוכל לחפש מדדים ולהמיר אותם למדדים, באמצעות התכונה מדדים שמבוססים על יומנים.
Logs Explorer
אתם יכולים להיכנס ל-Logging Explorer דרך Logging ←Logs Explorer ממסוף Google Cloud הראשי, באופן הבא:
יוצג ממשק של יומן שבו תוכלו לבחור או לבטל את הבחירה במשאבים שונים (פרויקט, משאב Google Cloud, שמות שירותים וכו') יחד עם רמות יומן, כדי לסנן את ההודעות ביומן לפי הצורך.
למעלה מוצגת רשימת היומנים של גרסה של Cloud Run, כלומר שירותי Cloud Run שפרוסנו. יוצגו כמה בקשות שהן בדיקות זמן פעולה תקינה שפוגעות בנקודת הקצה /healthy שהגדרתם.
חיפוש אזהרות
כדי לדמות כמה בקשות לא חוקיות לשירות המלאי, מספקים מזהי מוצרים שאינם I-1, I-2 ו-I-3. לדוגמה, בקשה שגויה היא:
https://<SERVICE_URL>/inventory/I-999
עכשיו נבצע חיפוש של כל האזהרות שנוצרו על ידי ה-API שלנו, כשמזהה המוצר שצוין בשאילתה שגוי.
בתיבת השאילתה, מזינים את הפרמטרים הבאים של השאילתה:
resource.type="cloud_run_revision"
textPayload =~ "התקבלה בקשת מלאי עבור מזהה מוצר שגוי"
הוא אמור להיראות כך:
לוחצים על Run Query. לאחר מכן יוצגו כל הבקשות שהתקבלו וכוללות את הבעיה הזו.
מדדים מבוססי יומן
בואו ניצור מדד יומן מותאם אישית כדי לעקוב אחרי השגיאות האלה. אנחנו רוצים לבדוק אם יש מספר משמעותי של קריאות עם מזהי מוצרים שגויים.
כדי להמיר את הנתונים שלמעלה למדד שגיאות, לוחצים על הלחצן Create Metric (יצירת מדד) שמופיע ב-Logs Explorer.
הטופס ליצירת הגדרת המדד יופיע. בוחרים באפשרות 'מדד מונה' ומזינים את הפרטים של שם המדד (inventory_lookup_errors) והתיאור, כפי שמוצג בהמשך, ולוחצים על Create Metric (יצירת מדד).
הפעולה הזו תיצור את מדד המונה, ואמורה להופיע הודעה כמו זו שבהמשך:
בתפריט הראשי, עוברים אל רישום ביומן → מדדים שמבוססים על יומנים. המדד המותאם אישית שהגדרנו אמור להופיע ברשימה של המדדים המוגדרים על ידי משתמשים, כפי שמופיע בהמשך:
בסוף הרשומה הזו מופיעות שלוש נקודות אנכיות. לוחצים עליהן כדי לראות את הפעולות שאפשר לבצע על המדד המותאם אישית הזה. הרשימה אמורה להיות דומה לרשימה שמוצגת בהמשך. לוחצים על האפשרות הצגה ב-Metrics Explorer.
הפעולה הזו אמורה להוביל אותנו אל Metrics Explorer, שסיפרנו עליו בקטע הקודם, אלא שהפעם הוא מאוכלס מראש.
לוחצים על Save Chart. משתמשים בערכים הבאים לאפשרויות של שמירת התרשים:
הפעולה הזו תיצור מרכז בקרה חדש שבו יוצגו השגיאות בחיפוש מלאי שטחי הפרסום, והוא יהיה זמין ברשימת מרכזי הבקרה.
מצוין! עכשיו יצרתם מדד מותאם אישית מהיומנים, והפכתם אותו לתרשים שמופיע בלוח בקרה מותאם אישית. כך נוכל לעקוב אחרי מספר השיחות שבהן נעשה שימוש במזהי מוצרים שגויים.
8. כללי מדיניות התראות
בקטע הזה נשתמש במדד המותאם אישית שיצרנו ונפקח על הנתונים שלו כדי לזהות ערך סף. כלומר, אם מספר השגיאות יחרוג מערך סף מסוים, נשלח התראה. במילים אחרות, אנחנו הולכים להגדיר מדיניות התראות.
יצירת מדיניות התראות
נעבור למרכז הבקרה של חיפוש מלאי שטחי הפרסום. יוצג התרשים שיצרנו כדי לציין את שגיאות החיפוש במלאי, כפי שמוצג בהמשך:
יוצגו נתוני המדד הנוכחיים. קודם נערוך את המדד כפי שמתואר בהמשך (לוחצים על הלחצן 'עריכה'):
הפרטים של המדד יוצגו. אנחנו עומדים להמיר את התרשים כך שיציג לנו את סה"כ השגיאות במקום את שיעור השגיאות. השדה שרוצים לשנות מוצג בהמשך:
לוחצים על אישור בפינה השמאלית העליונה, ונחזור למסך המדדים, אבל הפעם נוכל לראות את המספר הכולל של השגיאות בתקופת ההתאמה לעומת שיעור השגיאות.
אנחנו ניצור מדיניות התראות שתוכל להודיע לנו אם מספר השגיאות חורג מסף מסוים. לוחצים על 3 הנקודות בפינה השמאלית העליונה של התרשים, ומתוך רשימת האפשרויות, כפי שמוצג למעלה, לוחצים על המרת התרשים לתרשים התראות.
אמור להופיע מסך כמו זה שבהמשך:
לוחצים על הבא , וכך מוצג ערך הסף שאפשר להגדיר. סף הדוגמה שקבענו כאן הוא 5 , אבל אתם יכולים לבחור אותו לפי העדפתכם.
לוחצים על הבא כדי להציג את טופס ההתראות.
בחרנו ב'ערוץ ההתראות' כערוץ האימייל שיצרנו קודם. אפשר למלא את הפרטים האחרים, כמו מסמכים (שיוצגו כחלק מההתראה שתישלח). לוחצים על הבא כדי לראות את הסיכום ולהשלים את התהליך.
אחרי היצירה של מדיניות ההתראות, היא תוצג ברשימה של כללי מדיניות ההתראות, כפי שמתואר בהמשך. כדי להגיע לרשימת כללי מדיניות ההתראות, עוברים אל Monitoring (ניטור) → Alerting (התראות). מחפשים את הקטע Policies בדף כדי לראות את רשימת כללי המדיניות שהגדרתם עד כה.
מצוין! עכשיו הגדרתם מדיניות התראות מותאמת אישית שתודיע לכם במקרה של עלייה בשיעור השגיאות במהלך החיפוש של Inventory API.
9. ניטור שירותים (אופציונלי)
בקטע הזה נגדיר SLI/SLOs לשירותים שלנו בהתאם לעקרונות של Site Reliability Engineering (SRE). תוכלו לראות ש-Cloud Monitoring מקל עליכם על ידי זיהוי אוטומטי של שירותים שפרסמתם ב-Cloud Run, ויכול לחשב עבורכם מדדי SLI מרכזיים כמו זמינות וזמן אחזור, יחד עם חישובים של תקציב שגיאות.
נמשיך ונגדיר את יעד ה-SLO של זמן האחזור לשירות ה-API שלנו.
הגדרת יעד זמן אחזור (SLO) לשירות מלאי שטחי הפרסום
לוחצים על Monitoring → Services בתפריט הראשי של מסוף Cloud. תוצג רשימת השירותים שהוגדרו למעקב אחר שירותים.
נכון לעכשיו, אין לנו שירותים שהוגדרו לניטור SLI/SLO, ולכן הרשימה ריקה. קודם צריך ללחוץ על הקישור DEFINE SERVICE (הגדרת שירות) בחלק העליון כדי להגדיר או לזהות שירות.
הפעולה הזו תאתר באופן אוטומטי שירותים שעומדים בדרישות למעקב SLO. הוא יכול לזהות שירותי Cloud Run, ולכן שירות Inventory API שלנו שנפרס ב-Cloud Run יופיע ברשימה.
השם המוצג עשוי להיות שונה, והוא תלוי במה שבחרתם כשפרסתם את השירות ב-Cloud Run. לוחצים על הלחצן שליחה. יוצג המסך הבא:
אפשר ללחוץ על CREATE SLO. עכשיו תוכלו לבחור מתוך מדדי ה-SLI שמחושבים באופן אוטומטי.
בתור התחלה, בוחרים באפשרות Latency SLI. לוחצים על המשך. לאחר מכן יוצג מסך שבו מוצגים הביצועים הנוכחיים של השירות הזה וזמן האחזור האופייני.
אנחנו מזינים ערך לסף, למשל 300ms, שהוא הערך שאנחנו רוצים להשיג. אפשר לבחור ערך אחר אם רוצים, אבל חשוב לזכור שהדבר ישפיע על תקציב השגיאות שתגדירו בהתאם. לוחצים על המשך.
עכשיו מגדירים את יעד ה-SLO (חלון היעד והמדידה) כפי שמתואר בהמשך:
כלומר, אנחנו בוחרים את חלון המדידה כחלון מסוג 'מתגלגל' וממדדים אותו במשך 7 ימים. באופן דומה, בחרנו ביעד של 90%. כלומר, 90% מהבקשות לשירות ה-API צריכות להתבצע תוך 300 אלפיות השנייה, והמדידה צריכה להתבצע במשך 7 ימים.
לוחצים על המשך. ייפתח מסך הסיכום, שאותו תוכלו לאשר בלחיצה על הלחצן Update SLO (עדכון יעד).
פעולה זו שומרת את הגדרת ה-SLO שלכם, ותקציב השגיאות מחושב עבורכם באופן אוטומטי.
כמה דברים שאפשר לנסות:
- אפשר להפעיל את ה-API באמצעות מספר קריאות ולראות את הביצועים של השירות ואת ההשפעה שלו על יתרת תקציב השגיאות.
- משנים את קוד המקור כדי להפעיל עיכוב נוסף (שינה) באופן אקראי בחלק מהשיחות. הפעולה הזו תגדיל את זמן האחזור של מספר שיחות, ותשפיע לרעה על תקציב השגיאות.
10. מזל טוב
מזל טוב, פרסתם בהצלחה אפליקציה לדוגמה ב-Google Cloud ולימדתם איך להשתמש ב-Google Cloud Operations Suite כדי לעקוב אחרי תקינות האפליקציה.
מה עסקנו בו
- פריסת שירות ב-Google Cloud Run.
- הגדרת לוח בקרה לשירות Google Cloud Run.
- בדיקות זמני פעילות.
- הגדרת מדדי יומן מותאמים אישית ולוח בקרה/תרשים על סמך הנתונים האלה.
- סקירה כללית על Metrics Explorer והגדרת מרכז בקרה או תרשים.
- הגדרת כללי מדיניות התראות.
- הגדרת SLI/SLO למעקב אחר שירותים ב-Google Cloud.
הערה: אם ביצעתם את ה-Codelab באמצעות החשבון שלכם ופרויקט ב-Google Cloud, יכול להיות שתחויבו על המשאבים שהוקצו לכם. לכן, בסיום שיעור ה-Lab, מוחקים את הפרויקט ואת המשאבים.
מה השלב הבא?
מומלץ לעיין במשימות של Cloud Skills Boost כדי לקבל מידע נוסף על Google Cloud Operations Suite.