1. מבוא
עדכון אחרון: 28 ביולי 2023
מהי חבילת התפעול של Google Cloud?
חבילת התפעול של Google Cloud היא פלטפורמה שבה אפשר לעקוב אחרי ביצועי האפליקציות בסביבת Google Cloud, לפתור בעיות ולשפר את הביצועים. העמודים המרכזיים של חבילת התפעול של Google Cloud כוללים את Cloud Monitoring, Cloud Logging ו-Cloud Tracing.
בסרטון הזה יש סקירה כללית של Google Cloud Operations.
מה תפַתחו
ב-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 ( console.cloud.google.com) ויוצרים פרויקט חדש.
- שם הפרויקט הוא השם המוצג של המשתתפים בפרויקט הזה. זו מחרוזת תווים שלא נמצאת בשימוש ב-Google APIs. אפשר לעדכן את המיקום הזה בכל שלב.
- מזהה הפרויקט צריך להיות ייחודי לכל הפרויקטים ב-Google Cloud, והוא קבוע (אי אפשר לשנות אותו אחרי שמגדירים אותו). מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית. בדרך כלל לא צריך לדעת מה היא. ברוב ה-Codelabs, תצטרכו להפנות למזהה הפרויקט (בדרך כלל הוא מזוהה כ-PROJECT_ID). אם המזהה שנוצר לא מוצא חן בעיניכם, תוכלו ליצור מזהה אקראי אחר. אפשר גם לנסות שם משתמש משלכם ולבדוק אם הוא זמין. אי אפשר לשנות את ההגדרה הזו אחרי השלב הזה, והיא תישאר כזו למשך הפרויקט.
- לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. במאמרי העזרה מפורט מידע נוסף על שלושת הערכים האלה.
שימו לב: מזהה הפרויקט חייב להיות ייחודי גלובלית, ואף אחד אחר לא יכול להשתמש בו אחרי שבחרתם אותו. אתם המשתמשים היחידים במזהה הזה. גם אם פרויקט נמחק, אי אפשר להשתמש שוב במזהה שלו
- בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API של Cloud. העלות של התרגול הזה לא אמורה להיות גבוהה, ואולי אפילו לא תצטרכו לשלם בכלל. כדי להשבית את המשאבים ולא לחייב אתכם מעבר למדריך הזה, אתם יכולים למחוק את המשאבים שיצרתם או למחוק את כל הפרויקט. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.
הגדרה של Google Cloud Shell
אפשר להפעיל את Google Cloud ואת Google Cloud Trace מרחוק מהמחשב הנייד, אבל ב-codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.
כדי להפעיל את Cloud Shell ממסוף Cloud, פשוט לוחצים על 'הפעלת 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}
הפעולה הזו תספק רשומה אחת עם מזהה המוצר ורמת המלאי הזמין של המוצר הזה.
הנתונים שמוחזרים בתגובה הם בפורמט 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, סביבת שורת פקודה שפועלת בענן.
ב-GCP Console, לוחצים על סמל 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. לוחצים על הלחצן 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 הבאות של נקודות הקצה (endpoints) של ה-API:
- <SERVICE_URL>/inventory
- <SERVICE_URL>/inventory/I-1
- <SERVICE_URL>/inventory/I-100
הפורמט צריך להיות זהה לפורמט שצוין בקטע הקודם עם דוגמה לבקשת API ולתגובת API.
קבלת פרטי שירות מ-Cloud Run
פרסנו את שירות ה-API שלנו ב-Cloud Run, סביבת מחשוב ללא שרת. אפשר להיכנס לשירות 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 → Overview (מעקב → סקירה כללית) כמו שמוצג בהמשך:
בדף 'סקירה כללית' מוצגים כמה דברים שהגדרתם ב'מעקב', כמו מרכזי בקרה, התראות, בדיקות זמני פעילות וכו'.
בשלב הזה, לוחצים על מרכזי בקרה בתפריט הראשי הצדדי. יופיע המסך הבא:
לוחצים על ספריית דוגמאות . תוצג רשימה של לוחות בקרה מוכנים לשימוש (OOTB) שזמינים ב-Google Cloud, בכמה משאבים. גוללים ברשימה ובוחרים באפשרות Google Cloud Run כמו שמוצג למטה.
תוצג רשימה של לוחות בקרה רגילים שזמינים ל-Google Cloud Run. אנחנו מעוניינים בכך כי פרסנו את השירות שלנו ב-Cloud Run.
יוצג לוח בקרה אחד לניטור של Cloud Run. לוחצים על הקישור תצוגה מקדימה כדי לראות את רשימת התרשימים (המדדים) הסטנדרטיים שזמינים לניטור של Cloud Run. פשוט לוחצים על ייבוא לוח בקרה לדוגמה כדי לייבא את כל התרשימים האלה ללוח בקרה בהתאמה אישית. יוצג מסך מרכז בקרה עם שם שמולא מראש, כמו שמוצג בהמשך:
כדי לחזור, לוחצים על החץ ימינה, שנמצא מימין לשם מרכז הבקרה, בפינה הימנית העליונה. תועברו לרשימת מרכזי הבקרה, שבה אמור להופיע מרכז הבקרה החדש שיצרתם.
אפשר ללחוץ על הקישור למרכז הבקרה כדי לעקוב אחרי כמה מדדים שזמינים כברירת מחדל. המדדים האלה כוללים את זמן האחזור, מספר הבקשות, מדדי מאגר ועוד.
אפשר גם לסמן כל אחת מהלוחות בלוח הבקרה כמועדפת. כדי לעשות את זה, פשוט לוחצים על סמל הכוכב כמו שמוצג בהמשך:
הפעולה הזו תוסיף את מרכז הבקרה למסך הסקירה הכללית של 'ניטור', ותאפשר לכם לנווט בקלות למרכזי בקרה שבהם אתם משתמשים לעיתים קרובות.
נהדר! הרגע הוספתם מרכז בקרה מותאם אישית למעקב אחרי שירותי Cloud Run. כל הכבוד!
5. בדיקות זמני פעילות
בקטע הזה נגדיר בדיקת זמינות לשירות ה-API שפרסנו. בדיקת זמינות ציבורית יכולה לשלוח בקשות ממספר מיקומים ברחבי העולם לכתובות URL שזמינות לציבור או למשאבי Google Cloud, כדי לבדוק אם המשאב מגיב.
במקרה הזה, המשאב יהיה שירות ה-API שפרסנו ב-Cloud Run. כתובת ה-URL תהיה נקודת קצה ספציפית שהשירות API חושף כדי לציין את תקינות השירות.
בקוד לדוגמה של שירות ה-API, חשפנו נקודת קצה /healthy שמחזירה את ערך המחרוזת All Izz Well. לכן, כל מה שצריך לעשות הוא להגדיר בדיקת זמינות שפונה לכתובת כמו https://<SERVICE_URL>/healthy ולבדוק אם המחרוזת "All Izz Well" מוחזרת או לא.
יצירת ערוץ התראות
לפני שיוצרים את בדיקת הזמינות, חשוב להגדיר קודם ערוצי התראות. ערוץ התראות הוא אמצעי שבאמצעותו תקבלו התראה אם יש תקרית או בעיה באחד מהמשאבים המנוטרים שלנו. דוגמה לערוץ התראות היא אימייל, ותקבלו אימיילים אם יש התראה וכו'.
בשלב הזה, נגדיר ערוץ התראות באימייל ונקבע את כתובת האימייל שלנו, כדי שנוכל לקבל התראות במקרה של התראות שהמערכת שלנו תעלה ואנחנו נגדיר.
כדי ליצור ערוץ התראות:
בתפריט הראשי במסוף Google Cloud, עוברים אל Monitoring → Alerting, כמו שמוצג בהמשך:
יוצג דף עם התראות, כללי מדיניות ועוד. בשלב הזה, בחלק העליון של המסך יופיע קישור עם הכותרת עריכת ערוצי ההתראות. לוחצים על הפריט שמופיע.
תוצג רשימה של ערוצי התראות שונים, כמו שמוצג בהמשך:
מוצאים את הקטע Email ולוחצים על ADD NEW בשורה הזו. יוצגו פרטי הגדרת האימייל כמו בדוגמה הבאה:
מזינים את כתובת האימייל ואת השם לתצוגה כמו שמוצג בהמשך. לוחצים על שמירה.
כך מסיימים את היצירה של ערוץ התראות באימייל. קדימה, נגדיר עכשיו את בדיקת זמני הפעילות.
יצירת בדיקה של זמני פעילות
בתפריט הראשי במסוף Google Cloud, עוברים אל Monitoring → בדיקת זמני פעילות. בחלק העליון של המסך יופיע הקישור יצירת בדיקת זמינות. לוחצים על הפריט שמופיע.
יוצגו לכם סדרה של שלבים שתצטרכו לבצע כדי להגדיר את בדיקת זמני הפעילות.
השלב הראשון הוא להגדיר את פרטי היעד, כלומר מידע על שירות Cloud Run שפרסנו. דוגמה לטופס מלא:
אפשר לבחור את הערכים השונים באופן הבא:
- פרוטוקול : HTTPS
- סוג המשאב : בוחרים באפשרות Cloud Run Service. שימו לב למשאבים האחרים שהכלי תומך בהם, שאפשר להגדיר בהם גם בדיקות זמני פעילות.
- שירות Cloud Run : בוחרים באפשרות my-inventory-api או בשם הספציפי של שירות Cloud Run.
- הנתיב הוא /healthy, כי אנחנו מחזירים את המחרוזת All Izz Well ורוצים לבדוק אותה.
לוחצים על המשך כדי לעבור לשלב הבא. השלב הבא הוא אימות התגובה, כפי שמוצג בהמשך:
אפשר לראות שאנחנו מפעילים את הבדיקה של 'התאמת תוכן' ואז מגדירים שהתשובה שמוחזרת על ידי נקודת הקצה /healthy תהיה 'All Izz Well'. לוחצים על המשך כדי לעבור לשלב הבא, שבו נגדיר את ההתראה ואת ערוץ ההתראות שדרכו נקבל התראה אם בדיקת הזמינות תיכשל.
בשלב הזה, נותנים שם להתראה. בחרתי בשם Inventory API Uptime Check failure, אבל אתם יכולים לבחור שם אחר. הדבר החשוב כאן הוא לבחור את ערוץ ההתראות הנכון מתוך הרשימה שהגדרתם קודם.
בשלב האחרון, לוחצים על בדיקה כדי לבדוק את בדיקת הזמינות שהגדרנו.
בשלב האחרון, נותנים שם לבדיקת זמני הפעילות (למשל, Inventory API Uptime Check) ואז אפשר גם לבדוק אם הבדיקה מוגדרת בצורה נכונה. לוחצים על הלחצן בדיקה.
ממשיכים בתהליך (לוחצים על הלחצן CREATE בצד ימין). Google Cloud תורה לבדיקות הזמינות שהוגדרו באזורים שונים לשלוח פינג לכתובת ה-URL, והתגובות האלה ייאספו. אחרי כמה דקות, נכנסים לקטע מעקב ← בדיקת זמני פעילות. באופן אידיאלי, אמורים להופיע כל האותות הירוקים שמציינים שאפשר להגיע לכתובת ה-URL מהבקשות לבדיקת תקינות השונות.
אם אחת הבדיקות נכשלת למשך תקופה מסוימת (שאפשר להגדיר), תקבלו התראה בערוץ האימייל שהגדרנו.
בזה מסתיים החלק שלנו בנושא הגדרת בדיקה של זמני פעילות. כל הכבוד!
6. Metrics Explorer
ב-Cloud Monitoring מוצגים אלפי מדדים סטנדרטיים מכמה מוצרי Google Cloud. אתם יכולים לבדוק את המדדים האלה, להריץ עליהם שאילתות, להמיר אותם לתרשימים, להוסיף אותם ללוחות בקרה, להגדיר עליהם התראות ועוד.
המטרה שלנו בקטע הזה היא:
- בהמשך נסביר איך אפשר לבחון מדדים שונים, ואז נבדוק מדד ספציפי (זמן האחזור) בשירות ה-API שלנו.
- להמיר את המדד הזה לתרשים וללוח בקרה בהתאמה אישית, שבהם נוכל להשתמש כדי להציג את המדד בכל שלב.
עיון במדד זמן האחזור של שירות Inventory API
בתפריט הראשי במסוף Google Cloud, עוברים אל Monitoring → Metrics Explorer. הפעולה הזו תעביר אתכם למסך Metrics Explorer. לוחצים על בחירת מדד. עכשיו אפשר לנווט בין כמה מקורות פעילים שנוצרו להם מדדים.
מכיוון שאנחנו עוסקים בשירותי Cloud Run, לוחצים על Cloud Run Revision (גרסת Cloud Run), ואז על הקטגוריה והמדד הספציפי שנקרא Request Latency (זמן האחזור של הבקשה), כמו שמוצג בהמשך:
לוחצים על אישור. הנתון 'זמן האחזור של הבקשה' יוצג בתרשים. אפשר לשנות את סוג הווידג'ט לתרשים קו דרך הגדרות התצוגה בצד שמאל, כמו שמוצג בהמשך:
יוצג תרשים השהייה כמו שמופיע בהמשך:
יצירת תרשים ולוח בקרה בהתאמה אישית
נשמור את התרשים הזה. לוחצים על שמירת התרשים ומשתמשים בפרטים שמוצגים בהמשך:
חשוב לזכור שאנחנו יוצרים מרכז בקרה חדש , ולא שומרים אותו במרכז בקרה קיים. לוחצים על הלחצן שמירה. מרכז הבקרה החדש יתווסף לרשימת מרכזי הבקרה, כמו שמוצג בהמשך:
כדי לראות את הפרטים, לוחצים על לוח הבקרה הספציפי שיצרנו.
בזה מסתיים הקטע על בדיקת מדדים שונים באמצעות Metrics Explorer ועל יצירת לוחות בקרה מותאמים אישית.
7. Cloud Logging
בקטע הזה נסביר על Cloud Logging. ל-Cloud Logging יש ממשק Logs Explorer שעוזר לכם לנווט ביומנים שנוצרו על ידי שירותי Google שונים ועל ידי האפליקציות שלכם, ולעיין בהם.
בקטע הזה נלמד על Logs Explorer ונדגים כמה הודעות יומן שנוכל לחפש ולהמיר למדדים באמצעות התכונה מדדים מבוססי-יומן.
Logs Explorer
אפשר להיכנס ל-Logs Explorer דרך Logging →Logs Explorer ממסוף Google Cloud הראשי, כמו שמוצג בהמשך:
יוצג ממשק יומן שבו תוכלו לבחור או לבטל את הבחירה של משאבים שונים (פרויקט, משאב Google Cloud, שמות שירותים וכו') ורמות יומן כדי לסנן את הודעות היומן לפי הצורך.
למעלה מוצגת רשימת היומנים של Cloud Run Revision, כלומר שירותי Cloud Run שפרסנו. יוצגו לכם כמה בקשות שהן בדיקות זמני פעילות שמגיעות לנקודת הקצה /healthy שהגדרנו.
חיפוש אזהרות
מדמים כמה בקשות לא חוקיות לשירות המלאי על ידי ציון מזהי מוצרים שלא מופיעים ברשימה I-1, I-2 ו-I-3. לדוגמה, בקשה שגויה היא:
https://<SERVICE_URL>/inventory/I-999
עכשיו נחפש את כל האזהרות שנוצרו על ידי ה-API שלנו, כשמזהה מוצר שגוי מסופק בשאילתה.
בתיבת השאילתה, מוסיפים את הפרמטרים הבאים של השאילתה:
resource.type="cloud_run_revision"
textPayload =~ "Received inventory request for incorrect productid"
הוא אמור להיראות כך:
לוחצים על Run Query (הרצת שאילתה). לאחר מכן יוצגו כל הבקשות שהתקבלו ויופיעו אלה שבהן יש בעיה.
מדדים מבוססי-יומנים
ניצור מדד מותאם אישית של יומן כדי לעקוב אחרי השגיאות האלה. אנחנו רוצים להבין אם יש מספר משמעותי של שיחות שמתבצעות עם מזהי מוצרים שגויים.
כדי להמיר את השאילתה שלמעלה למדד שגיאות, לוחצים על הלחצן יצירת מדד שמופיע ב-Logs Explorer.
יוצג טופס ליצירת הגדרת המדד. בוחרים באפשרות Counter Metric (מדד של מונה), מזינים את הפרטים של Metric Name (שם המדד) (inventory_lookup_errors) ושל Description (תיאור) כמו שמוצג בהמשך ולוחצים על Create Metric (יצירת מדד).
כך ייצור מדד הדלפק, ותופיע הודעה כמו זו שמוצגת למטה:
בתפריט הראשי, עוברים אל Logging → Logs-based Metrics (רישום ביומן → מדדים שמבוססים על יומנים). ברשימת המדדים שהוגדרו על ידי המשתמש, אמור להופיע המדד המותאם אישית שהגדרנו, כמו שמוצג בהמשך:
בסוף הרשומה הזו מופיע סמל האפשרויות הנוספות (3 נקודות אנכיות). לוחצים עליו כדי לראות את הפעולות שאפשר לבצע במדד המותאם אישית הזה. הרשימה אמורה להיות דומה לזו שמוצגת בהמשך. לוחצים על האפשרות View in Metrics Explorer (תצוגה ב-Metrics Explorer).
הפעולה הזו תוביל אותנו אל הכלי 'Metrics Explorer' שתיארנו בקטע הקודם, אבל הפעם הוא יאוכלס מראש.
לוחצים על שמירת התרשים. משתמשים בערכים הבאים לאפשרויות של שמירת התרשים:
עכשיו ייווצר מרכז בקרה חדש שבו תוכלו לראות את השגיאות בחיפוש מלאי שטחי הפרסום, והוא יהיה זמין ברשימת מרכזי הבקרה.
מעולה! יצרתם עכשיו מדד מותאם אישית מהיומנים, והמרתם אותו לתרשים שמופיע בלוח בקרה מותאם אישית. הנתונים האלה יעזרו לנו לעקוב אחרי מספר השיחות שבהן נעשה שימוש במזהי מוצר שגויים.
8. מדיניות התראות
בקטע הזה נשתמש במדד המותאם אישית שיצרנו ונעקוב אחרי הנתונים שלו כדי לזהות חריגה מסף מסוים. כלומר, אם מספר השגיאות יעבור סף מסוים, נציג התראה. במילים אחרות, אנחנו הולכים להגדיר מדיניות התראות.
יצירת מדיניות התראות
נעבור למרכז הבקרה של חיפוש מלאי שטחי הפרסום. יוצג התרשים שיצרנו לרישום שגיאות בדיקת המלאי, כמו שמוצג בהמשך:
יוצגו נתוני המדדים הנוכחיים. קודם צריך לערוך את המדד כמו שמוצג למטה (לוחצים על הלחצן 'עריכה'):
יוצגו פרטי המדד. אנחנו הולכים להמיר את התרשים מהצגת שיעור השגיאות לסכום, כלומר מספר השגיאות. השדה שצריך לשנות מוצג בהמשך:
לוחצים על APPLY (החלה) בפינה השמאלית העליונה. נחזור למסך Metrics (מדדים), אבל הפעם נוכל לראות את המספר הכולל של השגיאות בתקופת ההתאמה לעומת שיעור השגיאות.
אנחנו ניצור מדיניות התראות שתאפשר לנו לקבל התראה אם מספר השגיאות יעבור את הסף. לוחצים על סמל האפשרויות הנוספות (3 נקודות) בפינה השמאלית העליונה של התרשים, ומהרשימה שמופיעה, כמו שמוצג למעלה, לוחצים על המרת התרשים לתרשים התראות.
יוצג מסך כמו שמוצג בהמשך:
לוחצים על הבא. יוצג ערך הסף שאפשר להגדיר. סף הדגימה שבחרנו כאן הוא 5 , אבל אתם יכולים לבחור את הסף שמתאים לכם.
לוחצים על הבא כדי להציג את טופס ההתראות.
בחרנו בערוץ ההתראות כערוץ האימייל שיצרנו קודם. אפשר למלא את הפרטים האחרים כמו מסמכים (שיישלחו כחלק מההתראה שנוצרת). לוחצים על הבא כדי לראות את הסיכום ולהשלים את התהליך.
אחרי שיוצרים את מדיניות ההתראות, היא מופיעה ברשימת מדיניות ההתראות כמו שמוצג למטה. כדי להגיע לרשימת מדיניות ההתראות, עוברים אל Monitoring → Alerting (מעקב → התראות). סורקים את הדף כדי למצוא את הקטע Policies (כללי מדיניות) ולראות את רשימת כללי המדיניות שהגדרנו עד עכשיו.
מעולה! הגדרתם עכשיו מדיניות התראות מותאמת אישית שתשלח לכם התראה במקרה של עלייה בשיעור השגיאות בזמן חיפוש ב-Inventory API.
9. ניטור שירותים (אופציונלי)
בקטע הזה נגדיר SLI/SLO לשירותים שלנו בהתאם לעקרונות של Site Reliability Engineering (SRE). תראו ש-Cloud Monitoring מקל עליכם את העבודה בכך שהוא מזהה באופן אוטומטי את השירותים שפרסתם ב-Cloud Run, ויכול לחשב באופן אוטומטי מדדי SLI מרכזיים כמו זמינות וחביון, יחד עם חישובים של תקציב השגיאות.
נמשיך ונגדיר את יעד רמת השירות (SLO) של זמן האחזור עבור שירות ה-API שלנו.
הגדרת יעד רמת שירות (SLO) של זמן אחזור עבור שירות המלאי
בתפריט הראשי ב-Cloud Console, לוחצים על Monitoring → Services. תוצג רשימת השירותים שהוגדרו לניטור שירותים.
בשלב הזה אין לנו שירותים שהוגדרו למעקב אחר SLI/SLO, ולכן הרשימה ריקה. כדי להגדיר או לזהות שירות, לוחצים על הקישור הגדרת שירות בחלק העליון.
המערכת תזהה באופן אוטומטי שירותים שמתאימים למעקב אחר יעדי זמינות (SLO). הוא יכול לגלות שירותי Cloud Run, ולכן שירות Inventory API שפרסנו ב-Cloud Run יופיע ברשימה.
השם המוצג שאתם רואים עשוי להיות שונה, והוא תלוי במה שבחרתם בזמן פריסת השירות ב-Cloud Run. לוחצים על הלחצן שליחה. יופיע המסך שמוצג למטה:
אפשר ללחוץ על CREATE SLO. עכשיו תוכלו לבחור מתוך מדדי רמת השירות (SLI) שמחושבים אוטומטית בשבילכם.
נתחיל עם מדד SLI של זמן האחזור. לוחצים על המשך. במסך הבא מוצגים הביצועים הנוכחיים של השירות והחביון האופייני.
הזנו ערך לסף, כלומר 300ms, שזה מה שאנחנו רוצים להשיג. אתם יכולים לבחור ערך אחר אם אתם רוצים, אבל קחו בחשבון שהוא ישפיע על תקציב השגיאות שתגדירו בהתאם. לוחצים על המשך.
עכשיו מגדירים את ה-SLO (יעד וחלון מדידה) כמו שמוצג בהמשך:
המשמעות היא שאנחנו בוחרים את חלון המדידה כחלון מסוג Rolling ומודדים אותו במשך 7 ימים. באופן דומה, בחרנו יעד של 90% לשיעור ההמרות. הכוונה היא ש-90% מהבקשות לשירות ה-API צריכות להסתיים תוך 300 אלפיות השנייה, והמדידה צריכה להתבצע במשך 7 ימים.
לוחצים על המשך. יוצג מסך הסיכום, שאפשר לאשר אותו בלחיצה על הלחצן UPDATE SLO (עדכון SLO).
הגדרת ה-SLO נשמרת ותקציב השגיאות מחושב באופן אוטומטי.
כמה דברים שאפשר לנסות:
- מבצעים קריאות ל-API כמה פעמים ורואים את הביצועים של השירות ואת ההשפעה שלהם על תקציב השגיאות שנותר.
- משנים את קוד המקור כדי להוסיף השהיה (sleep) אקראית לשיחות מסוימות. הפעולה הזו תגרום לעלייה בחביון של מספר שיחות, והיא צפויה להשפיע לרעה על תקציב השגיאות.
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.