1. מבוא
עדכון אחרון: 28.07.2023
מהי חבילת התפעול של Google Cloud?
Google Cloud Operations Suite היא פלטפורמה שבה תוכלו לעקוב אחרי ביצועי אפליקציות בסביבת Google Cloud, לפתור בעיות בהם ולשפר אותם. עמודי התווך העיקריים של חבילת התפעול של Cloud כוללים את Cloud Monitoring, Cloud Logging ו-Cloud Tracing.
בסרטון הזה מוצגת סקירה כללית ברמה גבוהה על התפעול של Google Cloud.
מה תפַתחו
ב-Codelab הזה, אתם עומדים לפרוס 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 משתמשים בו. מידע נוסף על כל שלושת הערכים האלה זמין במסמכי התיעוד.
זהירות: מזהה הפרויקט חייב להיות ייחודי בכל העולם, ואף אחד אחר לא יכול להשתמש בו אחרי שבוחרים אותו. אתם המשתמשים היחידים במזהה הזה. גם אם הפרויקט נמחק, לא ניתן להשתמש יותר במזהה
- בשלב הבא צריך להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבים או בממשקי API של Cloud. מעבר ב-Codelab הזה לא אמור לעלות הרבה, אם בכלל. כדי להשבית את המשאבים ולא לצבור חיובים מעבר למדריך הזה, אתם יכולים למחוק את המשאבים שיצרתם או למחוק את הפרויקט כולו. משתמשים חדשים ב-Google Cloud זכאים להצטרף לתוכנית תקופת ניסיון בחינם בשווי 1,200 ש"ח.
הגדרת Google Cloud Shell
אומנם אפשר להפעיל את Google Cloud ואת Google Cloud Trace מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת הפקודה שפועלת ב-Cloud.
כדי להפעיל את Cloud Shell ממסוף Cloud, פשוט לוחצים על Activate Cloud Shell (ההקצאה וההתחברות של הסביבה אמורות להימשך כמה דקות).
אם לא הפעלתם את Cloud Shell בעבר, יוצג לכם מסך ביניים (בחלק הנגלל) שמתאר מהו. במקרה כזה, לוחצים על 'המשך' (והוא לא יוצג שוב אף פעם). כך נראה המסך החד-פעמי:
ההקצאה וההתחברות ל-Cloud Shell נמשכת כמה דקות.
במכונה הווירטואלית הזו משולבת כל כלי הפיתוח שדרושים לכם. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר משמעותית את ביצועי הרשת והאימות. אם לא את כולן, ניתן לבצע חלק גדול מהעבודה ב-Codelab הזה באמצעות דפדפן או 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 מרחוק מהמחשב הנייד, אבל ב-Codelab הזה משתמשים ב-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 ותוכלו לבדוק אותו באופן מקומי באמצעות תכונת Web Preview של Cloud Shell. לוחצים על הלחצן תצוגה מקדימה של אתר כפי שמוצג בהמשך:
לוחצים על Preview ביציאה 8080.
- פעולה זו תפתח חלון דפדפן. תופיע שגיאה 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
- פריסה מקוד המקור דורשת מאגר 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>/inventory
- <SERVICE_URL>/מלאי/I-1
- <SERVICE_URL>/מלאי/I-100
הן צריכות להתאים למפרט שציינו בסעיף קודם עם דוגמת בקשה ותגובה של API.
קבלת פרטי שירות מ-Cloud Run
פרסנו את שירות ה-API שלנו ב-Cloud Run, סביבת מחשוב ללא שרת (serverless). אנחנו יכולים להיכנס לשירות Cloud Run דרך מסוף Google Cloud בכל שלב.
מהתפריט הראשי, עוברים אל Cloud Run. פעולה זו תציג את רשימת השירותים שאתם מפעילים ב-Cloud Run. אתם אמורים לראות את השירות שפרסתם עכשיו. בהתאם לשם שבחרתם, אתם אמורים לראות משהו כזה:
לוחצים על שם השירות כדי להציג את הפרטים. פרטי הדוגמה מוצגים בהמשך:
שימו לב לכתובת ה-URL, שהיא רק כתובת ה-URL של השירות שניתן להזין לדפדפן ולגשת ל-Inventory API שפרסנו כרגע. אפשר לעיין במדדים ובפרטים אחרים.
קדימה, מתחילים עם חבילת התפעול של Google Cloud.
4. הגדרת מרכז בקרה
אחת התכונות הנוחות שיש ב-Cloud Monitoring היא מרכזי בקרה מחוץ לתיבה (OOTB) בכמה משאבים ב-Google Cloud. כך תהליך ההגדרה הראשוני של מרכזי בקרה עם מדדים סטנדרטיים הוא תהליך מהיר ונוח.
בואו נראה איך לעשות זאת עבור שירות ה-API שפרסנו עכשיו ב-Cloud Run.
מרכז בקרה מותאם אישית לשירות שלנו
מכיוון שפרסנו את שירות ה-API שלנו ל-Cloud Run, בואו נראה איך להגדיר מרכזי בקרה כדי להציג מדדים שונים באופן חזותי, שחלקם כוללים את זמן האחזור של השירות.
קודם כל, נכנסים למסוף דרך Monitoring ← סקירה כללית:
הסקירה הכללית מציגה מספר דברים שהייתם מגדירים ב-Monitoring, כמו 'לוחות בקרה', 'התראות', 'בדיקת זמני פעילות' וכו'.
בינתיים, אפשר ללחוץ על מרכזי בקרה בתפריט הראשי שבצד. הפעולה הזו תעביר אותנו למסך הבא:
לוחצים על ספרייה לדוגמה . פעולה זו תציג רשימה של מרכזי בקרה מחוץ לתיבה (OOTB) שזמינים ב-Google Cloud במשאבים מרובים. באופן ספציפי, גללו למטה ברשימה ובחרו באפשרות Google Cloud Run כפי שמוצג בהמשך.
תוצג רשימה של מרכזי בקרה סטנדרטיים שזמינים ל-Google Cloud Run. אנחנו מעוניינים בכך כי פרסנו את השירות שלנו ב-Cloud Run.
יופיע לוח בקרה אחד ל-Cloud Run Monitoring. לוחצים על הקישור תצוגה מקדימה כדי להציג את רשימת התרשימים (מדדים) הסטנדרטיים שזמינים ל-Cloud Run Monitoring. כדי לייבא את כל התרשימים למרכז בקרה מותאם אישית, אפשר ללחוץ על ייבוא של מרכז בקרה לדוגמה. הפעולה הזו תציג מסך מרכז בקרה עם שם שהוזן מראש, אותו השם שמוצג בהמשך:
כדי לנווט חזרה, לוחצים על החץ שמאלה, שנמצא מימין לשם מרכז הבקרה, מימין למעלה מימין. פעולה זו תוביל לרשימה של מרכזי בקרה, שממנה תוכלו לראות את מרכז הבקרה החדש שיצרתם.
אפשר ללחוץ על הקישור לאותו מרכז שליטה כדי לעקוב אחרי מדדים רבים שזמינים ללא הגבלה. המדדים האלה כוללים את זמן האחזור, ספירת הבקשות, מדדי מאגר התגים ועוד.
אפשר גם לסמן כל מרכז בקרה כמועדף, פשוט בוחרים בסמל הכוכב כמו שמוצג בהמשך:
הפעולה הזו תוסיף את מרכז הבקרה למסך הסקירה הכללית של Monitoring, ותהיה דרך קלה לנווט למרכזי בקרה שמשתמשים בהם לעיתים קרובות.
מעולה! הוספתם עכשיו לוח בקרה בהתאמה אישית למעקב אחרי שירותי Cloud Run. נהדר!
5. בדיקות זמני פעילות
בקטע הזה נגדיר בדיקת זמני פעילות לשירות ה-API שפרסנו. בדיקת זמני פעילות ציבורית יכולה לשלוח בקשות ממספר מיקומים ברחבי העולם לכתובות URL שזמינות באופן ציבורי או למשאבים של Google Cloud כדי לראות אם המשאב מגיב.
המשאב במקרה הזה יהיה שירות ה-API שפרסנו ב-Cloud Run. כתובת ה-URL תהיה נקודת קצה ספציפית ששירות ה-API חושף כדי לציין את תקינות השירות.
בקוד השירות לדוגמה של ממשק ה-API, חשפנו נקודת קצה (endpoint) /healthy שמחזירה את ערך המחרוזת All Izz Well". לכן, כל מה שאנחנו צריכים לעשות הוא להגדיר בדיקת זמני פעילות שמופנית לערך כמו https://<SERVICE_URL>/healthy, ולבדוק אם המחרוזת https://<SERVICE_URL>/healthy מוחזרת או לא.
יצירת ערוץ התראות
לפני שניצור את בדיקת זמני הפעילות, חשוב להגדיר קודם את ערוצי ההתראות. ערוץ התראות הוא אמצעי ההגעה לאתר שדרכו תקבלו התראות במקרה של אירוע או בעיה שקשורה לאחד מהמשאבים שנמצאים במעקב שלנו. דוגמה לערוץ התראות היא 'אימייל' ותקבלו אימיילים במקרה שתהיה התראה וכו'.
נכון לעכשיו, נגדיר ערוץ התראות באימייל ונגדיר אותו באמצעות כתובת האימייל שלנו, כדי שנוכל לקבל התראות במקרה של התראות שהמערכת שלנו תעלה ואילו נגדיר.
כדי ליצור ערוץ התראות, מבצעים את השלבים הבאים:
נכנסים אל Monitoring ← Alerting מהתפריט הראשי ב-Google Cloud Console, כפי שמוצג בהמשך:
יוצג דף עם התראות, מדיניות ועוד. בינתיים, יופיע בחלק העליון קישור עריכת ערוצי התראות. לוחצים על הקישור.
תוצג רשימה של ערוצי ההתראות השונים, כפי שמוצג בהמשך:
מאתרים את הקטע אימייל ולוחצים על הוספת חדש בשורה הזו. יוצגו הפרטים של תצורת האימייל, כפי שמוצג בהמשך:
מזינים את כתובת האימייל ושם המוצג כפי שמוצג בהמשך. לוחצים על שמירה.
פעולה זו הושלמה ליצירת ערוץ ההתראות באימייל. עכשיו נגדיר את בדיקת זמני הפעילות.
יצירת בדיקה של זמני פעילות
בתפריט הראשי במסוף Google Cloud, עוברים אל Monitoring → Uptime checks. בחלק העליון יופיע הקישור CREATE UPTIME CHECK. לוחצים על הקישור.
כאן תופיע סדרה של שלבים שתצטרכו לבצע כדי להגדיר את בדיקת זמני הפעילות.
השלב הראשון הוא להגדיר את פרטי היעד, כלומר מידע על שירות Cloud Run שפרסנו. למטה מוצג טופס שמולאו:
ניתן לבחור את הערכים השונים כך:
- פרוטוקול : HTTPS
- סוג משאב : בוחרים שירות Cloud Run. שימו לב למשאבים האחרים שהתכונה הזו תומכת בהם, ושאתם יכולים להגדיר גם בהם בדיקות של זמני פעילות.
- Cloud Run Service : בוחרים את my-inventory-api או את השם הספציפי שלכם לשירות Cloud Run.
- הנתיב הוא /healthy, מכיוון שאנחנו מחזירים את המחרוזת All Izz Well ואנחנו רוצים לבדוק את זה.
לוחצים על המשך כדי לעבור לשלב הבא. השלב הבא הוא השלב אימות תגובה כפי שמוצג בהמשך:
אפשר לראות שאנחנו מפעילים את הבדיקה של 'התאמת תוכן' ולאחר מכן מגדירים שהתשובה שתוחזר על ידי נקודת הקצה /healthy תהיה 'All Izz Well'. לוחצים על המשך כדי לעבור לשלב הבא שבו נגדיר את ההתראה ובאיזה ערוץ התראות עלינו לקבל התראה, אם בדיקת זמני הפעילות נכשלה.
בשלב זה, נותנים שם להתראה. בחרתי באפשרות הזו ככשל בבדיקת זמן הפעולה התקינה של Inventory API, אבל אפשר לבחור את השם שלך. הדבר החשוב כאן הוא לבחור את ערוץ ההתראות הנכון מהרשימה שהגדרתם קודם לכן.
בשלב האחרון, לוחצים על בדיקה כדי לבדוק את בדיקת זמני הפעילות שהגדרנו.
בשלב האחרון הזה, נותנים שם לבדיקת זמני הפעילות (לדוגמה, בדיקת זמני פעילות ב-Inventory API) ואז אפשר גם לבדוק אם הבדיקה מוגדרת נכון. לשם כך, לוחצים על הלחצן TEST.
משלימים את התהליך (לוחצים על הלחצן יצירה בצד ימין). מערכת 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 זמן אחזור , באופן הבא:
לוחצים על החלה. הפעולה הזו תציג את זמן האחזור של הבקשה בתרשים. אפשר לשנות את סוג הווידג'ט לתרשים קו בתרשים קו דרך הגדרות התצוגה משמאל, כפי שמוצג למטה:
פעולה זו תציג את תרשים זמן האחזור באופן הבא:
יצירת תרשים ומרכז בקרה מותאם אישית
בואו נשמור את התרשים. לוחצים על שמירת התרשים ומשתמשים בפרטים הבאים:
חשוב לזכור שאנחנו יוצרים מרכז בקרה חדש במקום לשמור אותו במרכז בקרה קיים. לוחצים על הלחצן שמירה. הפעולה הזו תוסיף את מרכז הבקרה החדש שיצרתם לרשימת מרכזי הבקרה שלנו, כפי שמוצג בהמשך:
כדי לראות את הפרטים, לוחצים על מרכז הבקרה הספציפי שיצרנו.
נסיים את הסעיף בנושא חקירת מדדים שונים באמצעות 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 =~ "התקבלה בקשת מלאי עבור מזהה מוצר שגוי"
הוא אמור להיראות כך:
לוחצים על 'הרצת שאילתה'. כך יוצגו כל הבקשות שהתקבלו ובאילו בעיות זוהתה הבעיה.
מדדים מבוססי יומן
בואו ניצור מדד יומן מותאם אישית כדי לעקוב אחרי השגיאות האלה. נרצה לדעת אם יש מספר רב של שיחות עם מזהי מוצרים שגויים.
כדי להמיר את הערכים שלמעלה למדד שגיאה, לוחצים על הלחצן יצירת מדד שמופיע ב-Logs Explorer.
הפעולה הזו תפתח את הטופס ליצירת הגדרת המדד. עוברים עם מדד ספירה ומזינים את הפרטים של שם המדד (inventory_lookup_errors) והתיאור של התיאור כפי שמוצג למטה, ולוחצים על Create Metric.
הפעולה הזו תיצור את המדד המונה ותוצג לכם הודעה שמוצגת בהמשך:
בתפריט הראשי, נכנסים אל Logging ← מדדים מבוססי-יומנים. המדד המותאם אישית שהגדרנו אמור להופיע ברשימת המדדים בהגדרת המשתמש, כפי שמתואר בהמשך:
בסוף הרשומה הזו יוצגו שלוש נקודות אנכיות. אפשר ללחוץ עליהן כדי לראות את הפעולות שאפשר לבצע במדד המותאם אישית. הרשימה אמורה להיות דומה לרשימה שמוצגת בהמשך. לוחצים על האפשרות הצגה ב-Metrics Explorer.
זה יוביל אותנו אל הכלי Metrics Explorer שלמדנו עליו בקטע הקודם, אבל עכשיו הוא מאוכלס מראש.
לוחצים על שמירת התרשים. משתמשים בערכים הבאים לאפשרויות של שמירת התרשים:
עכשיו ייווצר מרכז שליטה חדש, שבו ניתן יהיה לראות את השגיאות בחיפוש מלאי, והוא יהיה זמין ברשימת מרכזי הבקרה.
נהדר! יצרתם עכשיו מדד מותאם אישית מהיומנים שלכם, והמרתם אותו לתרשים שמופיע במרכז בקרה מותאם אישית. כך נוכל לעקוב אחר מספר השיחות שבהן נעשה שימוש במזהי מוצרים שגויים.
8. מדיניות התראות
בקטע הזה נשתמש במדד המותאם אישית שיצרנו ונעקוב אחרי הנתונים שלו כדי לאתר סף מסוים. כלומר אם מספר השגיאות חורג מסף מסוים, נודיע לכם על כך. במילים אחרות, נגדיר מדיניות התראות.
יצירת מדיניות התראות
בואו נעבור ללוח הבקרה של חיפוש מלאי. פעולה זו תפתח את התרשים שיצרנו, כדי לשים לב לשגיאות בחיפוש מלאי, כפי שמוצג בהמשך:
יוצגו נתוני המדד הנוכחיים. קודם כול אנחנו עורכים את המדד כמו שמוצג למטה (צריך ללחוץ על הלחצן 'עריכה'):
יוצגו פרטי המדד. אנחנו הולכים להמיר את התרשים כך שלא יציג את שיעור השגיאות לסכום כלומר מספר השגיאות. השדה לשינוי מוצג למטה:
לוחצים על אישור בפינה השמאלית העליונה וחוזרים למסך 'מדדים', אבל הפעם נוכל לראות את המספר הכולל של השגיאות בתקופת ההתאמה לעומת שיעור השגיאות.
אנחנו עומדים ליצור מדיניות התראות שיכולה להודיע לנו במקרה שמספר השגיאות חורג מהסף. לוחצים על סמל האפשרויות הנוספות (3 נקודות) בפינה השמאלית העליונה של התרשים, ומתוך רשימת האפשרויות, כפי שמתואר למעלה, לוחצים על המרה לתרשים התראה.
אתם אמורים לראות את המסך הבא:
לוחצים על Next (הבא). פעולה זו תציג את ערך הסף שנוכל להגדיר. סף הדוגמה שקבענו כאן הוא 5 , אבל אתם יכולים לבחור אותו לפי העדפתכם.
לוחצים על הבא כדי להציג את טופס ההתראות
בחרנו ב'ערוץ ההתראות' כערוץ האימייל שיצרנו קודם. אפשר למלא את הפרטים האחרים, כמו מסמכים (שיסופקו כחלק מההתראה שמוצגת). לוחצים על הבא כדי לראות את הסיכום ולהשלים את התהליך.
אחרי היצירה של מדיניות ההתראות, היא תוצג ברשימה של כללי מדיניות ההתראות, כפי שמתואר בהמשך. תוכלו להיכנס לרשימה של כללי מדיניות ההתראות בקטע Monitoring ← Alerting. ניתן לסרוק את הקטע כללי מדיניות בדף כדי להציג את הרשימה של כללי המדיניות שהגדרנו עד עכשיו.
נהדר! הגדרת עכשיו מדיניות התראות מותאמת אישית, שתיידע אותך במקרה של עלייה בשיעור השגיאות בזמן חיפוש של Inventory API.
9. Service Monitoring (אופציונלי)
בקטע הזה, נגדיר יעדי SLI/SLO לשירותים שלנו בהתאם לעקרונות Site Reliability Engineering (SRE). תוכלו לראות ש-Cloud Monitoring מקל עליכם על ידי איתור אוטומטי של שירותים שפרסתם ב-Cloud Run, ושיכול לחשב בשבילכם שגיאות SLI עיקריות כמו זמינות, זמן אחזור וחישובי 'תקציב שגיאות' באופן אוטומטי.
עכשיו נגדיר את ה-SLO של זמן האחזור לשירות ה-API שלנו.
הגדרת SLO של זמן אחזור לשירות מלאי
בתפריט הראשי ב-Cloud Console, לוחצים על Monitoring ← Services. תוצג רשימת השירותים שהוגדרו ל-Service Monitoring.
נכון לעכשיו, אין לנו שירותים שהוגדרו לניטור SLI/SLO, ולכן הרשימה ריקה. לוחצים על הקישור הגדרת שירות בחלק העליון כדי להגדיר או לזהות שירות קודם.
הפעולה הזו תאתר באופן אוטומטי שירותים שעומדים בדרישות למעקב SLO. היא יכולה לאתר את שירותי Cloud Run, ולכן שירות Inventory API שנפרס ב-Cloud Run יופיע ברשימה.
השם המוצג עשוי להיות שונה, והוא תלוי במה שבחרתם כשפרסתם את השירות ב-Cloud Run. לוחצים על הלחצן SUBMIT. הפעולה הזו תפתח את המסך הבא:
אפשר ללחוץ על CREATE SLO. עכשיו תוכלו לבחור מבין יעדי ה-SLI שמחושבים בשבילכם באופן אוטומטי.
בתור התחלה, בוחרים באפשרות Latency SLI. לוחצים על המשך. בשלב הבא יוצג מסך שמציג את הביצועים הנוכחיים של שירות זה ואת זמן האחזור הטיפוסי.
אנחנו מזינים ערך לסף, כלומר 300ms , וזה מה שאנחנו רוצים להשיג. אם תרצו, תוכלו לבחור ערך אחר, אבל חשוב לזכור שהוא ישפיע על תקציב השגיאות שתגדירו בהתאם. לוחצים על המשך.
עכשיו מגדירים את ה-SLO (חלון יעד ומדידה) באופן הבא:
פירוש הדבר הוא שאנחנו בוחרים את חלון המדידה כחלון מסוג 'גלילה רציפה' ומודדים אותו על פני 7 ימים. באופן דומה, בחרנו ביעד של 90%. המטרה שלנו היא ש-90% מהבקשות לשירות ה-API אמורות להסתיים תוך 300 אלפיות השנייה, וצריך למדוד את התהליך הזה על פני 7 ימים.
לוחצים על המשך. ייפתח מסך הסיכום, שאותו אפשר לאשר בלחיצה על הלחצן Update SLO (עדכון יעד).
פעולה זו שומרת את הגדרת ה-SLO שלכם, ותקציב השגיאות מחושב עבורכם באופן אוטומטי.
אפשר לנסות את הפעולות הבאות:
- אפשר להפעיל את ה-API באמצעות מספר קריאות ולראות את ביצועי השירות ואיך הוא משפיע על תקציב השגיאות שנותר.
- משנים את קוד המקור כדי להוסיף עיכוב נוסף (שינה) באופן אקראי בחלק מהשיחות. המצב הזה מאריך את זמן האחזור של מספר שיחות, וזה עלול להשפיע לרעה על תקציב השגיאות.
10. מזל טוב
כל הכבוד, פרסתם בהצלחה אפליקציה לדוגמה ב-Google Cloud ולמדתם איך להשתמש בחבילת התפעול של Google Cloud כדי לעקוב אחר תקינות האפליקציה!
אילו נושאים דיברנו?
- פריסת שירות ב-Google Cloud Run.
- הגדרת מרכז בקרה לשירות Google Cloud Run.
- בדיקות זמני פעילות.
- הגדרת מדדי יומן מותאמים אישית ולוח בקרה/תרשים על סמך הנתונים האלה.
- התנסות ב-Metrics Explorer והגדרת מרכז בקרה/תרשים.
- הגדרת מדיניות התראות.
- הגדרה של SLI/SLO למעקב אחר שירות ב-Google Cloud.
הערה: אם ביצעתם את ה-Codelab באמצעות החשבון שלכם ופרויקט ב-Google Cloud, יכול להיות שתחויבו על המשאבים שהוקצו לכם. לכן, בסיום שיעור ה-Lab, מוחקים את הפרויקט ואת המשאבים.
מה השלב הבא?
לקבלת מידע נוסף על חבילת התפעול של Google Cloud, מומלץ לצפות ביחידת ה-Quest בנושא Cloud Skills Boost.