1. מבוא
עדכון אחרון: 28 ביולי 2023
מהי חבילת התפעול של Google Cloud?
חבילת התפעול של Google Cloud היא פלטפורמה שבה אפשר לנטר את ביצועי האפליקציות בסביבת Google Cloud, לפתור בעיות ולשפר את הביצועים. העמודים המרכזיים של חבילת התפעול של Google 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 ( 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, ותוכלו לבדוק אותו באופן מקומי באמצעות התכונה 'תצוגה מקדימה באינטרנט' של 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 (מעקב → סקירה כללית) כמו שמוצג בהמשך:
בדף Overview מוצגים כמה דברים שהגדרתם ב-Monitoring, כמו לוחות בקרה, התראות, בדיקות זמינות וכו'.
בשלב הזה, לוחצים על Dashboards (מרכזי בקרה) בתפריט הראשי הצדדי. יופיע המסך הבא:
לוחצים על ספריית דוגמאות . תוצג רשימה של לוחות בקרה מוכנים לשימוש (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, והתגובות האלה ייאספו. אחרי כמה דקות, נכנסים לקטע Monitoring → Uptime checks. באופן אידיאלי, אמורים לראות את כל האותות הירוקים שמציינים שאפשר להגיע לכתובת ה-URL מהבדיקות השונות.
אם אחת הבדיקות תיכשל למשך תקופה מסוימת (שאפשר להגדיר), תקבלו התראה בערוץ האימייל שהגדרנו.
בזה מסתיים החלק שלנו בנושא הגדרת בדיקה של זמני פעילות. כל הכבוד!
6. Metrics Explorer
Cloud Monitoring חושף אלפי מדדים סטנדרטיים מכמה מוצרי Google Cloud. אתם יכולים לבחון את המדדים האלה, להריץ עליהם שאילתות, להמיר אותם לתרשימים, להוסיף אותם ללוחות בקרה, להגדיר עליהם התראות ועוד.
המטרה שלנו בקטע הזה היא:
- בהמשך נסביר איך אפשר לבחון מדדים שונים, ואז נבדוק מדד ספציפי (זמן האחזור) בשירות ה-API שלנו.
- להמיר את המדד הזה לתרשים וללוח בקרה בהתאמה אישית, שבהם נוכל להשתמש כדי להציג את המדד בכל שלב.
עיון במדד זמן האחזור של Inventory API Service
בתפריט הראשי במסוף Google Cloud, עוברים אל Monitoring → 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) ואת התיאור כמו שמוצג למטה ולוחצים על Create Metric (יצירת מדד).
פעולה זו תיצור את מדד הדלפק, ותופיע הודעה כמו זו שמוצגת למטה:
בתפריט הראשי, עוברים אל Logging → Logs-based Metrics (רישום ביומן → מדדים שמבוססים על יומנים). ברשימת המדדים שהוגדרו על ידי המשתמש, אמור להופיע המדד המותאם אישית שהגדרנו, כמו שמוצג בהמשך:
בסוף הרשומה הזו, מופיע סמל שלוש הנקודות האנכיות. לוחצים עליו כדי לראות את הפעולות שאפשר לבצע במדד המותאם אישית הזה. הרשימה אמורה להיות דומה לזו שמופיעה למטה. לוחצים על האפשרות 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 של זמן האחזור. לוחצים על המשך. במסך הבא מוצגים הביצועים הנוכחיים של השירות הזה ומה היה זמן האחזור האופייני.
הזנו ערך לסף, כלומר 300 אלפיות השנייה, שזה מה שאנחנו רוצים להשיג. אפשר לבחור ערך אחר, אבל חשוב לזכור שהוא ישפיע על תקציב השגיאות שתגדירו בהתאם. לוחצים על המשך.
עכשיו מגדירים את ה-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.