הסבר על מעקב אחר ביצועים ב-Firestore במצב Datastore

‫Cloud Monitoring אוסף מדדים, אירועים ומטא-נתונים ממוצרי Google Cloud . בעזרת Cloud Monitoring, אפשר גם להגדיר מרכזי בקרה מותאמים אישית והתראות על שימוש.

במאמר הזה מוסבר איך להשתמש במדדים, איך להבין את לוח הבקרה של מדדים מותאמים אישית ואיך להגדיר התראות.

משאבים במעקב

משאב במעקב ב-Cloud Monitoring מייצג ישות לוגית או פיזית, כמו מכונה וירטואלית, מסד נתונים או אפליקציה. משאבים בפיקוח מכילים קבוצה ייחודית של מדדים שאפשר לבדוק, לדווח עליהם באמצעות מרכז בקרה או להשתמש בהם כדי ליצור התראות. לכל משאב יש גם קבוצה של תוויות משאבים, שהן צמדי מפתח/ערך שמכילים מידע נוסף על המשאב. תוויות משאבים זמינות לכל המדדים שמשויכים למשאב.

הביצועים של Firestore במצב Datastore מנוטרים באמצעות המשאבים הבאים דרך Cloud Monitoring API:

Resources	תיאור	מצב מסד נתונים נתמך
firestore.googleapis.com/Database (מומלץ)	סוג המשאב במעקב שמספק פירוטים של project,‏ location* ו-database_id . התווית database_id תהיה (default) למסדי נתונים שנוצרו ללא שם ספציפי.	ההגדרה חלה על שני המצבים.
datastore_request	סוג המשאב שבמעקב בפרויקטים של Datastore, ולא מספק פירוט של מסדי נתונים.

מדדים

‫Firestore זמין בשני מצבים שונים: Firestore Native ו-Firestore במצב Datastore. כאן אפשר לראות השוואה בין התכונות של שני המצבים.

רשימה מלאה של מדדים ל-Firestore במצב Datastore מופיעה במאמר מדדים של Firestore במצב Datastore.

מדדים של זמן ריצה של שירות

המדדים של serviceruntime מספקים סקירה כללית של תנועת הגולשים בפרויקט. המדדים האלה זמינים ברוב ממשקי ה-API של Google Cloud . סוג המשאב במעקב consumed_api מכיל את המדדים הנפוצים האלה. המדדים האלה נדגמים כל 30 דקות, ולכן הנתונים מוחלקים.

תווית חשובה של משאב למדדים serviceruntime היא method. התווית הזו מייצגת את שיטת ה-RPC הבסיסית שנקראת. יכול להיות שהשם של ה-method ב-SDK שאתם קוראים לה לא יהיה זהה לשם של ה-method הבסיסית של ה-RPC. הסיבה לכך היא ש-SDK מספק הפשטה של API ברמה גבוהה. עם זאת, כשמנסים להבין איך האפליקציה שלכם מתקשרת עם Firestore, חשוב להבין את המדדים על סמך השם של שיטת ה-RPC.

אם אתם רוצים לדעת מהי שיטת ה-RPC הבסיסית עבור שיטת SDK נתונה, תוכלו לעיין במאמרי העזרה של ה-API.

api/request_count

במדד הזה מוצג מספר הבקשות שהושלמו, לפי פרוטוקול(פרוטוקול הבקשה, כמו HTTP,‏ gRPC וכו'), קוד תגובה (קוד תגובת HTTP), response_code_class (סיווג קוד התגובה, כמו 2xx,‏ 4xx וכו') ו-grpc_status_code (קוד תגובת gRPC מספרי). אפשר להשתמש במדד הזה כדי לראות את בקשות ה-API הכוללות ולחשב את שיעור השגיאות.

תרשים 1. המדד api/request_count (לחצו כדי להגדיל).

באיור 1 אפשר לראות בקשות שמחזירות קוד 2xx, מקובצות לפי שירות ושיטה. קודים מסוג 2xx הם קודי סטטוס HTTP שמציינים שהבקשה הושלמה בהצלחה.

איור 2. המדד api/request_count שמחזיר קוד 2xx (לחצו כדי להגדיל).

באיור 2 אפשר לראות קומיטים שמקובצים לפי response_code. בדוגמה הזו, אנחנו רואים רק תגובות HTTP 200, מה שאומר שהמסד נתונים תקין.

אפשר להשתמש במדדי זמן הריצה של השירות הבאים כדי לעקוב אחרי מסד הנתונים.

‫api/request_count בסוג המשאב datastore_request

המדד api/request_count זמין גם בסוג המשאב datastore_request עם פירוטים של api_method ו-response_code. מומלץ להשתמש במדד הזה במקום זאת כדי ליהנות מתקופת הדגימה המדויקת יותר, שעוזרת לזהות עליות חדות.

איור 3. המדד api/request_count מתחת למשאב datastore_request (לחצו כדי להגדיל).

api/request_latencies

המדד api/request_latencies מספק את התפלגות זמני האחזור בכל הבקשות שהושלמו.

‫Firestore מתעד מדדים מהרכיב Firestore Service. מדדי זמן האחזור כוללים את הזמן שחל מרגע ש-Firestore מקבל את הבקשה ועד לרגע ש-Firestore מסיים לשלוח את התשובה, כולל אינטראקציות עם שכבת האחסון. לכן, זמן האחזור הלוך ושוב (rtt) בין הלקוח לשירות Firestore לא נכלל במדדים האלה.

איור 4. api/request_latencies כדי לחשב את התפלגות זמני האחזור.

‫api/request_sizes ו-api/response_sizes

המדדים api/request_sizes ו-api/response_sizes מספקים תובנות לגבי גדלי מטען הייעודי (בבייטים). הם יכולים לעזור להבין עומסי עבודה של כתיבה ששולחים כמויות גדולות של נתונים או שאילתות רחבות מדי, ומחזירים מטען ייעודי גדול.

איור 5. המדדים api/request_sizes ו-api/response_sizes (לחיצה להגדלה).

באיור 5 אפשר לראות מפת חום של גדלי התגובות לשיטה RunQuery. אפשר לראות שהגדלים יציבים, החציון הוא 50 בייטים והטווח הכולל הוא בין 10 בייטים ל-100 בייטים. חשוב לזכור שגודלי מטען נמדדים תמיד בבייט לא דחוס, לא כולל תקורה של בקרת שידור.

מדדי פעולות על ישויות

המדדים האלה מספקים נתונים על גודל המטען הייעודי (payload) בבייטים לקריאות (חיפושים ושאילתות) ולכתיבות במסד נתונים של Firestore. הערכים מייצגים את הגודל הכולל של המטען הייעודי (payload). לדוגמה, כל התוצאות שמוחזרות על ידי שאילתה. המדדים האלה דומים למדדים api/request_sizes ו-api/response_sizes, אבל ההבדל העיקרי הוא שהמדדים של פעולות הישות מספקים דגימה מפורטת יותר, אבל פירוטים פחות מפורטים.

לדוגמה, מדדי הפעולות של הישויות משתמשים במשאב datastore_request שבמעקב, ולכן אין פירוט של השירות או השיטה.

• ‫entity/read_sizes: התפלגות הגדלים של ישויות לקריאה, מקובצות לפי סוג.
• ‫entity/write_sizes: חלוקת הגדלים של ישויות שנכתבו, מקובצות לפי פעולות.

מדדי אינדקס

אפשר להשוות בין שיעורי הכתיבה של האינדקס לבין document/write_ops_count המדד כדי להבין את יחס הפיצול של האינדקס.

• ‫index/write_count: מספר הכתיבות לאינדקס.

איור 7. שיעור הכתיבה לאינדקס בהשוואה לשיעור הכתיבה של המסמך (אפשר ללחוץ כדי להגדיל).

באיור 7 אפשר לראות את ההבדל בין קצב הכתיבה לאינדקס לבין קצב הכתיבה של המסמך. בדוגמה הזו, לכל פעולת כתיבה של מסמך יש בערך 6 פעולות כתיבה של אינדקס, שזה שיעור פיצול קטן יחסית של האינדקס.

מדדי TTL

מדדי ה-TTL זמינים גם ל-Firestore Native וגם למסדי נתונים של Firestore במצב Datastore. אפשר להשתמש במדדים האלה כדי לעקוב אחרי ההשפעה של מדיניות ה-TTL שנאכפת.

• ‫entity/ttl_deletion_count: המספר הכולל של הישויות שנמחקו על ידי שירותי ה-TTL.

• ‫entity/ttl_expiration_to_deletion_delays: הזמן שחלף בין המועד שבו פג תוקף של ישות עם TTL לבין המועד שבו היא נמחקה בפועל.

  אם אתם רואים שהעיכובים במחיקה של TTL נמשכים יותר מ-24 שעות, פנו לתמיכה.

המאמרים הבאים

• איך משתמשים בלוח הבקרה של Cloud Monitoring כדי להציג מדדים