מעקב
אתם יכולים לעקוב אחרי Bigtable באופן חזותי, באמצעות תרשימים שזמינים ב- Google Cloud console, או לשלוח קריאה פרוגרמטית ל-Cloud Monitoring API.
במסוף Google Cloud , נתוני המעקב זמינים במקומות הבאים:
- תובנות מערכת של Bigtable
- סקירה כללית של מכונות Bigtable
- סקירה כללית של אשכול Bigtable
- סקירה כללית של טבלת Bigtable
- Cloud Monitoring
- Key Visualizer
בדפי הסקירה הכללית והתובנות לגבי המערכת מוצג מידע כללי על השימוש ב-Bigtable. אתם יכולים להשתמש ב-Key Visualizer כדי להציג פירוט של דפוסי הגישה לפי מפתח שורה, ולפתור בעיות ספציפיות בביצועים.
הסבר על השימוש במשאבים
לא משנה באילו כלים אתם משתמשים כדי לעקוב אחרי המכונה, חשוב לעקוב אחרי השימוש במעבד (CPU), בדיסק ובשכבה בזיכרון (תצוגה מקדימה) בכל אשכול במכונה. אם השימוש במעבד או בדיסק של אשכול חורג מסף מסוים, האשכול לא יפעל היטב, וייתכן שיוחזרו שגיאות כשמנסים לקרוא או לכתוב נתונים.
שימוש ב-CPU
הצמתים באשכולות משתמשים במשאבי מעבד (CPU) כדי לטפל במשימות קריאה, כתיבה וניהול. מומלץ להפעיל התאמה אוטומטית לעומס (autoscaling), שמאפשרת ל-Bigtable להוסיף ולהסיר צמתים באופן אוטומטי באשכול, בהתאם לעומס העבודה. למידע נוסף על האופן שבו מספר הצמתים משפיע על ביצועי האשכול, ראו ביצועים של עומסי עבודה אופייניים.
ב-Bigtable מדווחים המדדים הבאים לשימוש ב-CPU:
| מדד | תיאור |
|---|---|
| ניצול ממוצע של המעבד (CPU) |
ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כוללת פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופיל של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח. הערכים המקסימליים המומלצים מספקים מרווח ביטחון לעליות חדות קצרות בשימוש. |
| ניצול המעבד (CPU) של הצומת הכי חם |
ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. המדד הזה ממשיך להיות זמין כדי לשמור על המשכיות, אבל ברוב המקרים כדאי להשתמש במדד המדויק יותר High-granularity CPU utilization of hottest node. |
| ניצול המעבד (CPU) ברמת פירוט גבוהה של הצומת הפעיל ביותר |
מדידה מפורטת של ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. הצומת החם ביותר הוא לא בהכרח אותו צומת לאורך זמן, והוא יכול להשתנות במהירות, במיוחד במהלך משימות אצווה גדולות או סריקות של טבלאות. אם הצומת החם ביותר נמצא לעיתים קרובות מעל הערך המומלץ, גם כשניצול המעבד הממוצע סביר, יכול להיות שאתם ניגשים לחלק קטן מהנתונים בתדירות גבוהה בהרבה משאר הנתונים.
|
| ניצול המעבד (CPU) של סנכרון שינויים בזרמי נתונים |
ניצול המעבד (CPU) הממוצע שנגרם כתוצאה מפעילות של סנכרון שינויים בזרמי נתונים בכל הצמתים באשכול. |
| ניצול המעבד (CPU) לפי פרופיל אפליקציה, שיטה וטבלה |
ניצול המעבד (CPU) לפי פרופיל אפליקציה, שיטה וטבלה. אם אתם מבחינים בשימוש גבוה מהצפוי ב-CPU באשכול, תוכלו להשתמש במדד הזה כדי לקבוע אם השימוש ב-CPU של פרופיל אפליקציה, שיטת API או טבלה מסוימים גורם לעומס על ה-CPU. |
שימוש בדיסק
לכל אשכול במכונה, Bigtable מאחסן עותק נפרד של כל הטבלאות באותה מכונה.
Bigtable עוקב אחרי השימוש בדיסק ביחידות בינאריות, כמו ג'יגה-בייט (GB) בינארי, שבו 1GB הוא 230 בייטים. יחידת המידה הזו נקראת גם gibibyte (GiB).
ב-Bigtable מדווחים המדדים הבאים לשימוש בדיסק:
| מדד | תיאור |
|---|---|
| ניצול נפח האחסון (בייטים) |
כמות הנתונים שמאוחסנים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים שמאוחסנים בדיסק. הוא לא משקף את גודל הנתונים הלוגיים הלא דחוסים. כדי לראות את הגודל של נתוני הטבלה לפני הדחיסה, עיינו במאמר נתונים לוגיים בבייטים. הערך הזה משפיע על העלויות. בנוסף, כפי שמתואר בהמשך, יכול להיות שתצטרכו להוסיף צמתים לכל אשכול ככל שכמות הנתונים תגדל. |
| ניצול נפח האחסון (% מקסימלי) |
אחוז נפח האחסון של האשכול שנמצא בשימוש. הקיבולת מבוססת על מספר הצמתים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. באופן כללי, מומלץ לא להשתמש ביותר מ-70% מהמגבלה הקשיחה של נפח האחסון הכולל, כדי שיהיה מקום להוסיף עוד נתונים. אם אתם לא מתכננים להוסיף כמויות גדולות של נתונים למכונה, אתם יכולים להשתמש בעד 100% מהמגבלה הקשיחה. אם אתם משתמשים ביותר מהאחוז המומלץ של מגבלת האחסון, הוסיפו צמתים לאשכול. אפשר גם למחוק נתונים קיימים, אבל נתונים שנמחקו תופסים יותר מקום, לא פחות, עד שמתבצעת דחיסה. למידע נוסף על אופן החישוב של הערך הזה, ראו ניצול האחסון לכל צומת. |
| ניצול האחסון של סנכרון שינויים בזרמי נתונים (בייטים) |
נפח האחסון שמשמש לרשומות של סנכרון שינויים בזרמי נתונים בטבלאות במכונה. האחסון הזה לא נכלל בנפח האחסון הכולל בשימוש. אתם מחויבים על האחסון של סנכרון השינויים בזרמי נתונים, אבל הוא לא נכלל בחישוב של ניצול האחסון (% מקסימלי). המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם. |
| עומס בדיסק |
באשכולות HDD, אחוז רוחב הפס המקסימלי האפשרי לקריאות HDD שבו האשכול משתמש. באשכולות SSD שמופעל בהם אחסון מדורג, אחוז הניצול של האשכול מתוך קצב הנתונים המקסימלי האפשרי של רמת הגישה בתדירות נמוכה. אם הערך הזה הוא לעיתים קרובות 100%, יכול להיות שזמן האחזור יהיה ארוך יותר. מוסיפים צמתים לאשכול כדי להקטין את אחוז העומס על הדיסק. |
שימוש ברמת הזיכרון
Bigtable עוקב אחרי קצב העברת הנתונים בשכבת הזיכרון בקריאות לשנייה. קריאה אחת לשנייה שוות ערך לקריאת נקודה של 1 KiB. אם עומס העבודה דורש תפוקה גבוהה יותר מהקיבולת הבסיסית, Bigtable מבצע התאמה אוטומטית לעומס אנכית. למידע נוסף על מגבלות קצב העברת הנתונים ועל התאמה אנכית לעומס, קראו את המאמר הסבר על הביצועים. מידע נוסף על שכבת הזיכרון הפנימי זמין במאמר סקירה כללית על שכבת הזיכרון הפנימי.
ב-Bigtable מדווחים המדדים הבאים לשימוש בזיכרון:
| מדד | תיאור |
|---|---|
| יחידות בקשה מקסימליות בזיכרון |
המספר המקסימלי של קריאות לשנייה בחלון של 5 דקות. |
| מספר יחידות הבקשה בזיכרון |
השימוש בקריאות לשנייה לבקשות קריאה שמנסות להשתמש בשכבת הזיכרון. |
| מספר בקשות הקריאה בזיכרון |
מספר הבקשות לקריאה של טבלה שהועברו לשכבת הזיכרון, בחלוקה לפי הצלחת הקריאה מהזיכרון. |
| זמני אחזור של קריאה בזיכרון |
התפלגות זמני האחזור של בקשות קריאה בשרת לטבלה שניסתה להגיע לשכבת הזיכרון. |
| שיעור ההיטים בזיכרון |
היחס בין מספר בקשות הקריאה שקראו בהצלחה משכבת הזיכרון לבין כל בקשות הקריאה שעומדות בדרישות הזיכרון. |
| מספר הסיבות לאי-עמידה בדרישות בזיכרון |
מספר הבקשות שלא עמדו בדרישות של שכבת הזיכרון, בחלוקה לפי הסיבה. |
דחיסה ומכונות משוכפלות
מדדי האחסון משקפים את גודל הנתונים הדחוסים בדיסק. הדחיסה מתבצעת באופן עצמאי על בסיס מתגלגל באשכולות במהלך שבוע, ולכן מדדי נפח אחסון נדרש של אשכול מסוים עשויים לפעמים להיות שונים באופן זמני מאשכולות אחרים במכונה. נתונים חדשים שנכתבים נדחסים ומשתקפים במדדי האחסון תוך כשעתיים, אבל כדי לפנות מקום ממחיקות ומאיסוף אשפה צריך להשלים את הדחיסה. ההשפעות של זה כוללות:
באשכול חדש שנוסף לאחרונה למכונה, יכול להיות שיוצג באופן זמני נפח אחסון של 0 בייטים, למרות שכל הנתונים שוכפלו בהצלחה לאשכול החדש.
יכול להיות שהגודל של טבלה יהיה שונה בכל אשכול, גם כשהרפליקציה פועלת כמו שצריך.
מדדי השימוש באחסון עשויים להיות שונים בכל אשכול, גם אחרי שהרפליקציה הסתיימה ולא נשלחו כתיבות במשך כמה ימים. ההטמעה של האחסון הפנימי, כולל האופן שבו הנתונים מחולקים ומאוחסנים בצורה מבוזרת, יכולה להיות שונה בכל אשכול, ולכן השימוש בפועל באחסון יכול להיות שונה.
סקירה כללית של המכונה
בדף הסקירה הכללית של המכונה מוצג סיכום של התקינות והביצועים של המכונה.
מדדי מכונות
בטבלה הבאה מתוארים הערכים של מדדי המפתח של כל אשכול במכונה:
| מדד | תיאור |
|---|---|
| ניצול ממוצע של המעבד (CPU) |
ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כוללת פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופיל של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח. |
| ניצול המעבד (CPU) של הצומת הכי חם |
ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. המדד הזה ממשיך להיות זמין כדי לשמור על המשכיות, אבל ברוב המקרים כדאי להשתמש במדד המדויק יותר High-granularity CPU utilization of hottest node. |
| ניצול המעבד (CPU) ברמת פירוט גבוהה של הצומת הפעיל ביותר |
מדידה מפורטת של ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. הצומת החם ביותר הוא לא בהכרח אותו צומת לאורך זמן, והוא יכול להשתנות במהירות, במיוחד במהלך משימות אצווה גדולות או סריקות של טבלאות. חריגה מהמספר המקסימלי המומלץ של הצומת העמוס ביותר עלולה לגרום לזמן אחזור ולבעיות אחרות באשכול. |
| שורות שנקראו | מספר השורות שנקראות בשנייה. |
| שורות שנכתבו | מספר השורות שנכתבות בשנייה. |
| תפוקה בקריאה | מספר הבייטים לשנייה של נתוני התגובה שנשלחו. המדד הזה מתייחס לכמות הנתונים המלאה שמוחזרת אחרי החלת המסננים. |
| תפוקה בכתיבה | מספר הבייטים לשנייה שהתקבלו בזמן כתיבת הנתונים. |
| שיעור השגיאות במערכת | אחוז כל הבקשות שנכשלו בצד השרת של Bigtable. |
| זמן אחזור של שכפול לקלט | משך הזמן המקסימלי באחוזון ה-99, בשניות, לכתיבה לאשכול אחר שצריך לשכפל לאשכול הזה. |
| זמן אחזור של שכפול לפלט | משך הזמן המקסימלי באחוזון ה-99, בשניות, שנדרש כדי לשכפל כתיבה לאשכול הזה לאשכול אחר. |
כדי לראות סקירה כללית של המדדים העיקריים האלה:
במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.
לוחצים על המכונה שרוצים לראות את המדדים שלה. במסוף Google Cloud מוצגים המדדים הנוכחיים של האשכולות במכונה.
התראות ואזהרות
בנוסף למדדים שמופיעים בטבלה הקודמת, אם הפעלתם אחסון מדורג (גרסת טרום-השקה (Preview)) לטבלאות כלשהן במכונה, יכול להיות שיופיע באנר אזהרה שמציין שאחסון עם גישה לא תכופה משפיע על קיבולת ה-SSD באשכול אחד או יותר.
סקירה כללית של האשכול
בדף הסקירה הכללית של האשכול אפשר לראות את הסטטוס הנוכחי והקודם של אשכול מסוים.
בדף הסקירה הכללית של האשכולות מוצגים תרשימים עם המדדים הבאים לכל אשכול:
| מדד | תיאור |
|---|---|
| מספר הצמתים | מספר הצמתים שמשמשים את האשכול בזמן נתון. |
| יעד של מספר הצמתים המקסימלי | מספר הצמתים המקסימלי שאליו Bigtable יגדיל את האשכול כשההתאמה האוטומטית לעומס מופעלת. המדד הזה מוצג רק אם באשכול מופעלת התאמה אוטומטית לעומס. אפשר לשנות את הערך הזה בדף Edit cluster. |
| יעד מספר הצמתים המינימלי | מספר הצמתים המינימלי שאליו Bigtable יקטין את האשכול כשההתאמה האוטומטית לעומס מופעלת. המדד הזה מוצג רק אם באשכול מופעלת התאמה אוטומטית לעומס. אפשר לשנות את הערך הזה בדף Edit cluster. |
| מספר הצמתים המומלץ ליעד של שימוש ב-CPU | מספר הצמתים ש-Bigtable ממליץ עליהם לאשכול, על סמך היעד שהגדרתם לניצול המעבד. המדד הזה מוצג רק כשההתאמה האוטומטית לעומס מופעלת באשכול. אם המספר הזה גבוה מהיעד של מספר הצמתים המקסימלי, כדאי להגדיל את יעד ניצול המעבד (CPU) או את מספר הצמתים המקסימלי באשכול. אם המספר הזה נמוך מהמספר המינימלי של הצמתים, יכול להיות שהאשכול הוקצה יתר על המידה לשימוש שלכם, וכדאי לשקול להקטין את המינימום. |
| מספר הצמתים המומלץ ליעד האחסון | מספר הצמתים ש-Bigtable ממליץ עליהם לאשכול, על סמך יעד ניצול האחסון המובנה. המדד הזה מוצג רק כשההתאמה האוטומטית לעומס מופעלת באשכול. אם המספר הזה גבוה מהיעד המקסימלי של מספר הצמתים, כדאי להגדיל את מספר הצמתים המקסימלי באשכול. |
| ניצול המעבד (CPU) |
ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כוללת פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופיל של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח. |
| ניצול נפח האחסון |
כמות הנתונים שמאוחסנים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם. |
| מדדים של שכבת הזיכרון | רק ב-Enterprise Plus. כולל תרשימים של שיעור ההתאמה, זמן האחזור של הקריאה והשימוש ביחידות הבקשה (RU) באשכול. |
כדי להציג את דף הסקירה הכללית של אשכול:
במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.
לוחצים על המכונה שרוצים לראות את המדדים שלה.
עוברים לקטע שאחרי הקטע שבו מוצג הסטטוס הנוכחי של חלק מהמדדים של האשכול.
לוחצים על מזהה האשכול כדי לפתוח את הדף Cluster overview של האשכול.
יומנים
בתרשים Logs מוצגות רשומות של יומן אירועי המערכת של האשכול. יומני אירועים של המערכת נוצרים רק לאשכולות שמשתמשים בהתאמה אוטומטית לעומס. במאמר רישום ביומן הביקורת מוסבר על דרכים נוספות להצגת יומני הביקורת של Bigtable.
סקירה כללית של הטבלה
בדף הסקירה הכללית של הטבלה אפשר לראות את הסטטוס הנוכחי והקודם של טבלה מסוימת.
בדף הסקירה הכללית של הטבלה מוצגים תרשימים עם המדדים הבאים של הטבלה. בכל תרשים מוצג קו נפרד לכל אשכול שהטבלה נמצאת בו.
| מדד | תיאור |
|---|---|
| ניצול נפח האחסון (בייטים) |
נפח האחסון באשכול בבייטים שמשמש את הטבלה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם. בטבלאות שמופעל בהן אחסון מדורג (תצוגה מקדימה) מוצג גם פירוט של השימוש ב-SSD ובאחסון עם גישה לא תכופה לאורך זמן. למידע נוסף על אופן החישוב של הערך הזה, ראו ניצול האחסון לכל צומת. |
| ניצול המעבד (CPU) |
ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כוללת פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופיל של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח. |
| זמן אחזור של קריאה | הזמן שלוקח לבקשת קריאה להחזיר תגובה. מדידת זמן האחזור של הקריאה מתחילה כש-Bigtable מקבל את הבקשה, ומסתיימת כשנשלח הבייט האחרון של הנתונים ללקוח. בבקשות לכמויות גדולות של נתונים, זמן האחזור של הקריאה יכול להיות מושפע מהיכולת של הלקוח לצרוך את התגובה. |
| זמן אחזור של כתיבה | הזמן שלוקח לבקשת כתיבה להחזיר תשובה. |
| שורות שנקראו |
מספר השורות שנקראות בשנייה. המדד הזה מספק תצוגה שימושית יותר של קצב הנתונים הכולל של Bigtable מאשר מספר בקשות הקריאה, כי בקשה אחת יכולה לקרוא מספר גדול של שורות. |
| שורות שנכתבו |
מספר השורות שנכתבות בשנייה. המדד הזה מספק תצוגה שימושית יותר של קצב הנתונים הכולל של Bigtable מאשר מספר בקשות הכתיבה, כי בקשה אחת יכולה לכתוב מספר גדול של שורות. |
| בקשות קריאה | מספר בקשות הקריאה והסריקה האקראיות לשנייה. |
| בקשות כתיבה | מספר בקשות הכתיבה לשנייה. |
| תפוקה בקריאה | מספר הבייטים לשנייה של נתוני התגובה שנשלחו. המדד הזה מתייחס לכמות הנתונים המלאה שמוחזרת אחרי החלת המסננים. |
| תפוקה בכתיבה | מספר הבייטים לשנייה שהתקבלו בזמן כתיבת הנתונים. |
| יתירות כשל אוטומטית |
מספר הבקשות שנותבו מחדש באופן אוטומטי מאשכול אחד לאחר בגלל תרחיש של יתירות כשל, כמו הפסקה קצרה או עיכוב. ניתוב מחדש אוטומטי יכול להתרחש אם פרופיל האפליקציה משתמש בניתוב לכמה אשכולות. התרשים הזה לא כולל בקשות שנותבו מחדש באופן ידני. |
בדף הסקירה הכללית של הטבלה מוצג גם מצב הרפליקציה של הטבלה בכל אשכול במכונה. לכל אשכול, בדף מוצגים הפרטים הבאים:
- סטטוס
- מזהה אשכול
- תחום (zone)
- נפח האחסון באשכול שהטבלה תופסת
- מפתח הצפנה וסטטוס המפתח
- תאריך הגיבוי האחרון של הטבלה שנבחרה
- קישור לדף Edit cluster.
כדי להציג את דף הסקירה הכללית של טבלה:
במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.
לוחצים על המכונה שרוצים לראות את המדדים שלה.
בחלונית הימנית, לוחצים על טבלאות. במסוף Google Cloud מוצגת רשימה של כל הטבלאות במכונה.
לוחצים על מזהה טבלה כדי לפתוח את הדף Table overview של הטבלה.
מעקב אחרי הביצועים לאורך זמן
כדי להבין את הביצועים הקודמים של המכונה, אפשר להשתמש בדף System Insights של המכונה ב-Bigtable. אתם יכולים לנתח את הביצועים של כל אשכול, ולפרט את המדדים של סוגים שונים של משאבי Bigtable. התרשימים יכולים להציג תקופה שבין השעה האחרונה ל-6 השבועות האחרונים.
תרשימים של תובנות מערכת למשאבי Bigtable
בדף Bigtable system insights מוצגים תרשימים לסוגי המשאבים הבאים של Bigtable:
- מכונות
- Tables
- פרופילי אפליקציות
- רפליקציה
בתרשימים שבדף התובנות לגבי המערכת מוצגים המדדים הבאים:
| מדד | זמין עבור | תיאור |
|---|---|---|
| ניצול המעבד (CPU) | מכונות טבלאות פרופילי אפליקציות |
ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כוללת פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופיל של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח. |
| ניצול המעבד (CPU) ברמת פירוט גבוהה (הצומת הכי חם) | מכונות |
מדידה מפורטת של ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. הצומת החם ביותר הוא לא בהכרח אותו צומת לאורך זמן, והוא יכול להשתנות במהירות, במיוחד במהלך משימות אצווה גדולות או סריקות של טבלאות. חריגה מהמספר המקסימלי המומלץ של הצומת העמוס ביותר עלולה לגרום לזמן אחזור ולבעיות אחרות באשכול. |
| יחידות עיבוד ללא שרת (SPU) של Data Boost | מכונות | השימוש ב-Data Boost שניתן לחיוב, נמדד בשניות SPU. |
| זמן אחזור של קריאה |
מכונות טבלאות פרופילי אפליקציות |
הזמן שלוקח לבקשת קריאה להחזיר תגובה. מדידת זמן האחזור של הקריאה מתחילה כש-Bigtable מקבל את הבקשה, ומסתיימת כשנשלח הבייט האחרון של הנתונים ללקוח. בבקשות לכמויות גדולות של נתונים, זמן האחזור של הקריאה יכול להיות מושפע מהיכולת של הלקוח לצרוך את התגובה. |
| זמן האחזור של קריאת SQL |
מכונות פרופילים של אפליקציות |
הזמן שלוקח לבקשת קריאה של SQL להחזיר תשובה. מדידת זמן האחזור של קריאת SQL מתחילה כש-Bigtable מקבל את הבקשה ומסתיימת כשבייט הנתונים האחרון נשלח ללקוח. בבקשות לכמויות גדולות של נתונים, זמן האחזור של קריאת SQL יכול להיות מושפע מהיכולת של הלקוח לצרוך את התגובה. |
| זמן אחזור של כתיבה |
מכונות טבלאות פרופילי אפליקציות |
הזמן שלוקח לבקשת כתיבה להחזיר תשובה. |
| זמן אחזור של קריאה בצד הלקוח |
מכונות טבלאות פרופילי אפליקציות |
זמן האחזור הכולל מקצה לקצה בכל ניסיונות ה-RPC שמשויכים לפעולה ב-Bigtable. מודד את זמן הסבב של הפעולה מהלקוח ל-Bigtable ובחזרה ללקוח, וכולל את כל הניסיונות החוזרים. |
| זמן אחזור של קריאת SQL בצד הלקוח |
מכונות טבלאות פרופילי אפליקציות |
זמן האחזור הכולל מקצה לקצה בכל ניסיונות ה-RPC שמשויכים לפעולה ב-Bigtable. מודד את זמן הסבב של הפעולה מהלקוח ל-Bigtable ובחזרה ללקוח, וכולל את כל הניסיונות החוזרים. בבקשות |
| זמן אחזור של כתיבה בצד הלקוח |
מכונות טבלאות פרופילי אפליקציות |
זמן האחזור הכולל מקצה לקצה בכל ניסיונות ה-RPC שמשויכים לפעולה ב-Bigtable. מודד את זמן הסבב של הפעולה מהלקוח ל-Bigtable ובחזרה ללקוח, וכולל את כל הניסיונות החוזרים. |
| זמן האחזור של ניסיון קריאה בצד הלקוח |
מכונות טבלאות פרופילי אפליקציות |
זמני האחזור של ניסיון קריאה של RPC על ידי לקוח. בנסיבות רגילות, הערך הזה זהה לערך של |
| זמן האחזור של ניסיון קריאת SQL בצד הלקוח |
מכונות טבלאות פרופילי אפליקציות |
זמני האחזור של ניסיון RPC לקריאת SQL של לקוח. בנסיבות רגילות, הערך הזה זהה לערך של |
| זמן האחזור של ניסיון הכתיבה בצד הלקוח |
מכונות טבלאות פרופילי אפליקציות |
זמני האחזור של ניסיון כתיבה של RPC על ידי לקוח. בנסיבות רגילות, הערך הזה זהה לערך של |
| שיעור שגיאות המשתמשים | מכונות |
שיעור השגיאות שנגרמו בגלל תוכן הבקשה, בניגוד לשגיאות בצד השרת של Bigtable. שיעור שגיאות המשתמשים כולל את קודי הסטטוס הבאים:
שגיאות משתמש נגרמות בדרך כלל מבעיה בהגדרה, כמו בקשה שמציינת אשכול, טבלה או פרופיל אפליקציה שגויים. |
| שיעור השגיאות במערכת | מכונות |
אחוז כל הבקשות שנכשלו בצד השרת של Bigtable.
שיעור השגיאות במערכת כולל את קודי הסטטוס הבאים:
|
| יתירות כשל אוטומטית |
מכונות טבלאות פרופילי אפליקציות |
מספר הבקשות שנותבו מחדש באופן אוטומטי מאשכול אחד לאחר בגלל תרחיש של יתירות כשל, כמו הפסקה קצרה או עיכוב. ניתוב מחדש אוטומטי יכול להתרחש אם פרופיל האפליקציה משתמש בניתוב לכמה אשכולות. התרשים הזה לא כולל בקשות שנותבו מחדש באופן ידני. |
| יתירות כשל אוטומטית ב-SQL |
מכונות טבלאות פרופילי אפליקציות |
מספר בקשות ה-SQL שנותבו מחדש באופן אוטומטי מאשכול אחד לאחר בגלל תרחיש של יתירות כשל, כמו הפסקה קצרה או עיכוב. ניתוב מחדש אוטומטי יכול להתרחש אם פרופיל האפליקציה משתמש בניתוב לכמה אשכולות. התרשים הזה לא כולל בקשות שנותבו מחדש באופן ידני. |
| ניצול נפח האחסון (בייטים) |
מופעים טבלאות |
כמות הנתונים שמאוחסנים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם. |
| ניצול נפח האחסון (% מקסימלי) | מכונות |
אחוז נפח האחסון של האשכול שנמצא בשימוש. הקיבולת מבוססת על מספר הצמתים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. למידע נוסף על אופן החישוב של הערך הזה, ראו ניצול האחסון לכל צומת. |
| עומס בדיסק | מכונות | באשכולות HDD, אחוז רוחב הפס המקסימלי האפשרי לקריאות HDD שבו האשכול משתמש. באשכולות SSD שמופעל בהם אחסון מדורג, אחוז הניצול של האשכול מתוך קצב הנתונים המקסימלי האפשרי של רמת הגישה בתדירות נמוכה. |
| יחידות בקשה מקסימליות בשכבה בזיכרון | מכונות אשכולות |
רק ב-Enterprise Plus. המספר המקסימלי של יחידות בקשה לשנייה שנעשה בהן שימוש בחלון של 5 דקות. |
| מספר יחידות הבקשה בשכבה בזיכרון | מכונות אשכולות טבלאות פרופילים של אפליקציות |
רק ב-Enterprise Plus. השימוש ביחידות הבקשה לבקשות קריאה שמנסות להשתמש בשכבת הזיכרון. |
| מספר בקשות הקריאה ברמה בזיכרון | מכונות אשכולות טבלאות פרופילים של אפליקציות |
רק ב-Enterprise Plus. מספר הבקשות לקריאה של טבלה שהועברו לשכבת הזיכרון, בחלוקה לפי הצלחת הקריאה מהזיכרון. |
| זמן אחזור בקריאה של שכבת הזיכרון | מכונות אשכולות טבלאות פרופילים של אפליקציות |
רק ב-Enterprise Plus. התפלגות זמני האחזור של בקשות קריאה בשרת לטבלה שניסתה להגיע לשכבת הזיכרון. |
| שיעור ההיטים ברמת הזיכרון | מכונות אשכולות טבלאות פרופילים של אפליקציות |
רק ב-Enterprise Plus. היחס בין מספר בקשות הקריאה שקראו בהצלחה משכבת הזיכרון לבין כל בקשות הקריאה שעומדות בדרישות הזיכרון. |
| מספר הסיבות לכך שרמת הזיכרון לא עומדת בדרישות | מכונות אשכולות טבלאות פרופילים של אפליקציות |
רק ב-Enterprise Plus. מספר הבקשות שלא עמדו בדרישות של שכבת הזיכרון, בחלוקה לפי הסיבה. |
| שורות שנקראו |
מכונות טבלאות פרופילי אפליקציות |
מספר השורות שנקראות בשנייה. המדד הזה מספק תצוגה שימושית יותר של קצב הנתונים הכולל של Bigtable מאשר מספר בקשות הקריאה, כי בקשה אחת יכולה לקרוא מספר גדול של שורות. |
| שורות שנכתבו |
מכונות טבלאות פרופילי אפליקציות |
מספר השורות שנכתבות בשנייה. המדד הזה מספק תצוגה שימושית יותר של קצב הנתונים הכולל של Bigtable מאשר מספר בקשות הכתיבה, כי בקשה אחת יכולה לכתוב מספר גדול של שורות. |
| בקשות קריאה |
מכונות טבלאות פרופילי אפליקציות |
מספר בקשות הקריאה והסריקה האקראיות לשנייה. |
| בקשות כתיבה |
מכונות טבלאות פרופילי אפליקציות |
מספר בקשות הכתיבה לשנייה. |
| תפוקה בקריאה |
מכונות טבלאות פרופילי אפליקציות |
מספר הבייטים לשנייה של נתוני התגובה שנשלחו. המדד הזה מתייחס לכמות הנתונים המלאה שמוחזרת אחרי החלת המסננים. |
| תפוקה בכתיבה |
מכונות טבלאות פרופילי אפליקציות |
מספר הבייטים לשנייה שהתקבלו בזמן כתיבת הנתונים. |
| תפוקה בכתיבה |
מכונות טבלאות פרופילי אפליקציות |
מספר הבייטים לשנייה שהתקבלו בזמן כתיבת הנתונים. |
| מספר הצמתים | מכונות | מספר הצמתים באשכול. |
| התנועה שעומדת בדרישות של Data Boost | פרופילי אפליקציות | בקשות Bigtable נוכחיות שעומדות ולא עומדות בדרישות של Data Boost. |
| סיבות לכך שתנועה ב-Data Boost לא עומדת בדרישות | פרופילי אפליקציות | סיבות לכך שתנועת הגולשים הנוכחית לא עומדת בדרישות ל-Data Boost. |
כדי לראות את המדדים של המשאבים האלה:
במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.
לוחצים על המכונה שרוצים לראות את המדדים שלה.
בחלונית הימנית, לוחצים על תובנות מערכת. במסוף Google Cloud מוצגת סדרה של תרשימים של המכונה, וגם תצוגה בטבלה של המדדים של המכונה. כברירת מחדל, במסוף Google Cloud מוצגים מדדים מהשעה האחרונה, ומוצגים מדדים נפרדים לכל אשכול במכונה.
כדי לראות את כל התרשימים, גוללים בחלונית שבה הם מוצגים.
כדי לראות מדדים ברמת הטבלה, לוחצים על טבלאות.
כדי לראות מדדים של פרופילי אפליקציות ספציפיים, לוחצים על Application Profiles.
כדי לראות את המדדים המשולבים של המכונה כולה, בקטע קיבוץ לפי שמעל התרשימים לוחצים על Instance.
כדי לראות מדדים לתקופה ארוכה יותר, לוחצים על החץ לצד שעה אחת. בוחרים טווח תאריכים מוגדר מראש או מזינים טווח תאריכים בהתאמה אישית, ולוחצים על Apply.
תרשימים לשכפול
בדף תובנות המערכת מוצג תרשים של זמן האחזור של הרפליקציה לאורך זמן. אפשר לראות את זמן האחזור הממוצע לשכפול כתיבות באחוזונים ה-50, ה-99 וה-100.
כדי לראות את זמן האחזור של הרפליקציה לאורך זמן:
במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.
לוחצים על המכונה שרוצים לראות את המדדים שלה.
בחלונית הימנית, לוחצים על תובנות מערכת. הדף נפתח בכרטיסייה Instance.
לוחצים על הכרטיסייה Replication. במסוףGoogle Cloud מוצג זמן האחזור של הרפליקציה לאורך זמן. כברירת מחדל, במסוף Google Cloud מוצג זמן האחזור של הרפליקציה בשעה האחרונה.
כדי לעבור בין תרשימי זמן אחזור שמקובצים לפי טבלה או לפי אשכול, משתמשים בתפריט Group by.
כדי לשנות את האחוזון שמוצג, משתמשים בתפריט Percentile.
כדי לראות מדדים לתקופה ארוכה יותר, לוחצים על החץ לצד שעה אחת. בוחרים טווח תאריכים מוגדר מראש או מזינים טווח תאריכים בהתאמה אישית, ולוחצים על Apply.
התפקידים הנדרשים
כדי לקבל את ההרשאות שדרושות לצפייה או לשינוי של מרכזי הבקרה של התובנות, כולל מרכזי בקרה בהתאמה אישית, בקשו מהאדמין לתת לכם את התפקידים הבאים ב-IAM ברמת הפרויקט:
-
כדי ליצור ולערוך מרכזי בקרה בהתאמה אישית: עריכת ההגדרות של מרכז הבקרה של Monitoring (
roles/monitoring.dashboardEditor) -
כדי לפתוח תרשימים ב-Metrics Explorer ולצפות בהם:
צפייה בהגדרות של לוח הבקרה של Monitoring (
roles/monitoring.dashboardViewer) -
כדי ליצור ולערוך התראות ב-Metrics Explorer:
עריכת מעקב (
roles/monitoring.editor)
להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.
התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות כדי לצפות בלוחות הבקרה של התובנות או לשנות אותם, כולל לוחות בקרה בהתאמה אישית. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:
ההרשאות הנדרשות
כדי לצפות בלוחות הבקרה של התובנות או לשנות אותם, כולל לוחות בקרה בהתאמה אישית, נדרשות ההרשאות הבאות:
-
כדי ליצור מרכזי בקרה בהתאמה אישית:
monitoring.dashboards.create -
כדי לערוך מרכזי בקרה בהתאמה אישית:
monitoring.dashboards.update -
כדי לראות מרכזי בקרה בהתאמה אישית:
monitoring.dashboards.get, monitoring.dashboards.list
יכול להיות שתקבלו את ההרשאות האלה באמצעות תפקידים בהתאמה אישית או תפקידים מוגדרים מראש אחרים.
התאמה אישית של מרכז הבקרה "תובנות לגבי המערכת"
מרכז הבקרה של תובנות המערכת הוא מרכז בקרה מוגדר מראש שאפשר להתאים אישית כדי להציג את המידע שהכי חשוב לכם. אפשר להוסיף תרשימים חדשים, לשנות את הפריסה ולסנן את הנתונים כדי להתמקד במשאבים ספציפיים.
השינויים במרכז הבקרה של תובנות המערכת לא גורמים נזק, ואפשר לאפס אותם על ידי הגדרת בורר מרכז הבקרה לערך Predefined.
שינוי מרכז הבקרה
כדי לשנות את מרכז הבקרה, לוחצים על Customize dashboards. אלה האפשרויות שעומדות לרשותכם:
- הוספת ווידג'ט: בסרגל הכלים של מרכז הבקרה, לוחצים על Add widget, בוחרים את הווידג'ט שרוצים להוסיף ומגדירים אותו.
- עריכת ווידג'ט: מעבירים את העכבר מעל הווידג'ט כדי להציג את סרגל הכלים שלו, ואז לוחצים על עריכה. אפשר לשנות את סוג הווידג'ט ולהתאים אישית את הנתונים שמוצגים בו.
- שכפול ווידג'ט: מעבירים את העכבר מעל ווידג'ט כדי להציג את סרגל הכלים שלו, לוחצים על More chart options ואז על Clone widget.
- מחיקת ווידג'ט: מעבירים את העכבר מעל הווידג'ט כדי להציג את סרגל הכלים שלו, לוחצים על אפשרויות נוספות של התרשים ואז על מחיקת הווידג'ט.
- לשנות את הפריסה: אפשר לגרור ווידג'טים כדי לשנות את המיקום שלהם, ולגרור את הפינות שלהם כדי לשנות את הגודל שלהם.
- לתת שם לתצוגה בהתאמה אישית: אפשר להגדיר את שם התצוגה בהתאמה אישית בתיבה Custom view name.
- שמירת מרכז הבקרה: כדי לשמור את התצוגה בהתאמה אישית, לוחצים על Save. אפשר גם לצאת בלי לשמור בלחיצה על יציאה ממצב עריכה.
מעקב באמצעות Cloud Monitoring
Bigtable מייצא מדדי שימוש ל-Cloud Monitoring. אתם יכולים להשתמש במדדים האלה במגוון דרכים:
- מעקב פרוגרמטי באמצעות Cloud Monitoring API.
- מעקב חזותי ב-Metrics Explorer.
- להגדיר כללי מדיניות התראות.
- להוסיף מדדי שימוש ב-Bigtable למרכז בקרה בהתאמה אישית.
- כדי לשרטט ולנתח את מדדי השימוש של Bigtable, אפשר להשתמש בספריית תרשימים כמו Matplotlib ל-Python.
כדי לראות את מדדי השימוש ב-Metrics Explorer:
פותחים את הדף Monitoring במסוף Google Cloud .
אם מתבקשים לבחור חשבון, בוחרים את החשבון שמשמש לגישה אל Google Cloud.
לוחצים על Resources ואז על Metrics Explorer.
בקטע Find resource type and metric, מקלידים
bigtable. מופיעה רשימה של משאבים ומדדים של Bigtable.לוחצים על מדד כדי לראות את התרשים שלו.
למידע נוסף על השימוש ב-Cloud Monitoring, קראו את המסמכים של Cloud Monitoring.
יצירת התראה על ניצול נפח האחסון
אתם יכולים להגדיר התראה שתיידע אתכם כשאשכול Bigtable חורג מסף מסוים. למידע נוסף על קביעת ניצול נפח האחסון הרצוי, ראו שימוש בדיסק.
כדי ליצור מדיניות התראות שמופעלת כשניצול האחסון באשכול Bigtable חורג מסף מומלץ, כמו 70%, משתמשים בהגדרות הבאות.
| תנאי חדש שדה |
ערך |
|---|---|
| משאב ומדד | בתפריט Resources, בוחרים באפשרות Cloud Bigtable Cluster. בתפריט Metric categories בוחרים באפשרות Cluster. בתפריט Metrics, בוחרים באפשרות Storage utilization. (הערך של metric.type הוא bigtable.googleapis.com/cluster/storage_utilization).
|
| סינון | cluster = YOUR_CLUSTER_ID |
| הגדרת טריגר להתראה שדה |
ערך |
|---|---|
| סוג התנאי | Threshold |
| התנאי מופעל אם | Any time series violates |
| מיקום הסף | Above threshold |
| ערך הסף | 70 |
| חלון הבדיקה החוזרת | 10 minutes |
המאמרים הבאים
- איך פותרים בעיות ב-Key Visualizer
- מידע על מדדים בצד הלקוח
- המדריך למתחילים של Cloud Monitoring
- מידע ולמידה על יצירת התראות על סמך מדדים של Bigtable
- איך בודקים את הביצועים בעזרת AI