‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

מעקב

אתם יכולים לעקוב אחרי Bigtable באופן חזותי באמצעות תרשימים שזמינים ב- Google Cloud console, או לשלוח קריאה פרוגרמטית ל-Cloud Monitoring API.

במסוף Google Cloud , נתוני המעקב זמינים במקומות הבאים:

תובנות מערכת ב-Bigtable
סקירה כללית של מכונות Bigtable
סקירה כללית של אשכול Bigtable
סקירה כללית של טבלת Bigtable
Cloud Monitoring
Key Visualizer

בדפי הסקירה הכללית והתובנות לגבי המערכת מוצג מידע כללי על השימוש ב-Bigtable. אתם יכולים להשתמש ב-Key Visualizer כדי להציג פירוט של דפוסי הגישה לפי מפתח שורה, ולפתור בעיות ספציפיות בביצועים.

הסבר על השימוש במשאבים

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

שימוש במעבד (CPU)

הצמתים באשכולות משתמשים במשאבי מעבד (CPU) כדי לטפל בקריאות, בכתיבות ובמשימות ניהוליות. מומלץ להפעיל התאמה אוטומטית לעומס (autoscaling), שמאפשרת ל-Bigtable להוסיף ולהסיר צמתים באופן אוטומטי באשכול, בהתאם לעומס העבודה. למידע נוסף על האופן שבו מספר הצמתים משפיע על הביצועים של האשכול, ראו ביצועים של עומסי עבודה אופייניים.

ב-Bigtable מדווחים המדדים הבאים לשימוש ב-CPU:

מדד	תיאור
ניצול ממוצע של המעבד (CPU)	ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כולל פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופילים של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח. הערכים המקסימליים המומלצים מספקים מרווח לשימוש מוגבר לזמן קצר.
ניצול המעבד (CPU) של הצומת החם ביותר	ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. המדד הזה ממשיך להיות זמין כדי לשמור על המשכיות, אבל ברוב המקרים כדאי להשתמש במדד המדויק יותר High-granularity CPU utilization of hottest node.
ניצול המעבד (CPU) ברמת פירוט גבוהה של הצומת הפעיל ביותר	מדידה מפורטת של ניצול המעבד (CPU) בצומת העמוס ביותר באשכול. הצומת החם ביותר הוא לא בהכרח אותו צומת לאורך זמן, והוא יכול להשתנות במהירות, במיוחד במהלך סריקות של טבלאות או משימות אצווה גדולות. אם הצומת הכי פעיל נמצא לעיתים קרובות מעל הערך המומלץ, גם כשניצול המעבד הממוצע סביר, יכול להיות שאתם ניגשים לחלק קטן מהנתונים בתדירות גבוהה בהרבה מאשר לשאר הנתונים. משתמשים בכלי Key Visualizer כדי לזהות נקודות חמות בטבלה שעלולות לגרום לעליות חדות בשימוש ב-CPU. בודקים את עיצוב הסכימה כדי לוודא שהוא תומך בחלוקה שווה של קריאות וכתיבות בכל טבלה.
ניצול המעבד (CPU) של סנכרון שינויים בזרמי נתונים	ניצול המעבד (CPU) הממוצע שנגרם כתוצאה מפעילות של סנכרון שינויים בזרמי נתונים בכל הצמתים באשכול.
ניצול ה-CPU לפי פרופיל אפליקציה, שיטה וטבלה	ניצול המעבד (CPU) לפי פרופיל אפליקציה, שיטה וטבלה. אם אתם מבחינים בשימוש גבוה מהצפוי ב-CPU באשכול, תוכלו להשתמש במדד הזה כדי לקבוע אם השימוש ב-CPU של פרופיל אפליקציה, שיטת API או טבלה מסוימים גורם לעומס על ה-CPU.

שימוש בדיסק

בכל אשכול במכונה, Bigtable מאחסן עותק נפרד של כל הטבלאות באותה מכונה.

‫Bigtable עוקב אחרי השימוש בדיסק ביחידות בינאריות, כמו ג'יגה-בייט (GB) בינארי, שבו 1GB הוא 2‎³⁰‎ בייטים. יחידת המידה הזו נקראת גם gibibyte‏ (GiB).

ב-Bigtable מדווחים המדדים הבאים לשימוש בדיסק:

מדד	תיאור
ניצול נפח האחסון (בייטים)	כמות הנתונים שמאוחסנים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים שמאוחסנים בדיסק. הוא לא משקף את גודל הנתונים הלוגיים הלא דחוסים. כדי לראות את הגודל של נתוני הטבלה לפני הדחיסה, עיינו במאמר נתונים לוגיים בבייטים. הערך הזה משפיע על העלויות. בנוסף, כמו שמתואר בהמשך, יכול להיות שתצטרכו להוסיף צמתים לכל אשכול ככל שכמות הנתונים תגדל.
ניצול נפח האחסון (% מקסימלי)	אחוז נפח האחסון של האשכול שנמצא בשימוש. הקיבולת מבוססת על מספר הצמתים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. באופן כללי, מומלץ לא להשתמש ביותר מ-70% מהמגבלה הקשיחה של נפח האחסון הכולל, כדי שיהיה מקום להוסיף עוד נתונים. אם אתם לא מתכננים להוסיף כמויות גדולות של נתונים למכונה, אתם יכולים להשתמש בעד 100% מהמגבלה הקשיחה. חשוב: אם אחד מהאשכולות במכונה חורג מהמגבלה הנוקשה של נפח האחסון לכל צומת, פעולות הכתיבה לכל האשכולות במכונה הזו ייכשלו עד שתוסיפו צמתים לכל אשכול שחורג מהמגבלה. בנוסף, אם תנסו להסיר צמתים מאשכול, והשינוי יגרום לאשכול לחרוג מהמגבלה הנוקשה על האחסון, Bigtable ידחה את הבקשה. אם אתם משתמשים ביותר מהאחוז המומלץ של מגבלת האחסון, הוסיפו צמתים לאשכול. אפשר גם למחוק נתונים קיימים, אבל נתונים שנמחקו תופסים יותר מקום, לא פחות, עד שמתבצעת דחיסה. לפרטים על אופן החישוב של הערך הזה, ראו ניצול האחסון לכל צומת.
ניצול האחסון של סנכרון שינויים בזרמי נתונים (בייטים)	נפח האחסון שמשמש לרשומות של סנכרון שינויים בזרמי נתונים בטבלאות במכונה. האחסון הזה לא נכלל בנפח האחסון הכולל. אתם מחויבים על האחסון של סנכרון שינויים בזרמי נתונים, אבל הוא לא נכלל בחישוב של ניצול האחסון (% מקסימלי). המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם.
עומס בדיסק	באשכולות 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.

סקירה כללית של הטבלה

בדף הסקירה הכללית של הטבלה אפשר לראות את הסטטוס הנוכחי והקודם של טבלה מסוימת.

בדף הסקירה הכללית של הטבלה מוצגים תרשימים עם המדדים הבאים של הטבלה. בכל תרשים מוצג קו נפרד לכל אשכול שהטבלה נמצאת בו.

מדד	תיאור
ניצול נפח האחסון (בייטים)	נפח האחסון באשכול בבייטים שמשמש את הטבלה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם. בטבלאות שבהן מופעל אחסון מדורג (גרסת טרום-השקה (Preview)), מוצג גם פירוט של השימוש ב-SSD ובאחסון עם גישה לא תכופה לאורך זמן. לפרטים על אופן החישוב של הערך הזה, ראו ניצול האחסון לכל צומת.
ניצול המעבד (CPU)	ניצול המעבד (CPU) הממוצע בכל הצמתים באשכול. כולל פעילות של סנכרון שינויים בזרמי נתונים אם סנכרון שינויים בזרמי נתונים מופעל בטבלה במכונה. בתרשימי הפרופילים של האפליקציה, <system> מציין פעילויות מערכת ברקע, כמו שכפול ודחיסה. פעילויות המערכת ברקע לא מופעלות על ידי הלקוח.
זמן אחזור של קריאה	הזמן שלוקח לבקשת קריאה להחזיר תגובה. המדידה של זמן האחזור לקריאה מתחילה כש-Bigtable מקבל את הבקשה, ומסתיימת כשנשלח הבייט האחרון של הנתונים ללקוח. בבקשות לכמויות גדולות של נתונים, זמן האחזור של הקריאה יכול להיות מושפע מהיכולת של הלקוח לצרוך את התגובה.
זמן אחזור בכתיבה	הזמן שלוקח לבקשת כתיבה להחזיר תשובה.
שורות שנקראו	מספר השורות שנקראות בשנייה. המדד הזה מספק תצוגה שימושית יותר של קצב הנתונים הכולל של Bigtable מאשר מספר בקשות הקריאה, כי בקשה אחת יכולה לקרוא מספר גדול של שורות.
שורות שנכתבו	מספר השורות שנכתבות בשנייה. המדד הזה מספק תצוגה שימושית יותר של קצב הנתונים הכולל של Bigtable מאשר מספר בקשות הכתיבה, כי בקשה אחת יכולה לכתוב מספר גדול של שורות.
בקשות קריאה	מספר בקשות הקריאה והסריקה האקראיות לשנייה.
בקשות כתיבה	מספר בקשות הכתיבה לשנייה.
קצב העברת נתונים בקריאה	מספר הבייטים לשנייה של נתוני התגובה שנשלחו. המדד הזה מתייחס לכמות הנתונים המלאה שמוחזרת אחרי החלת המסננים.
קצב העברת נתונים בכתיבה	מספר הבייטים לשנייה שהתקבלו בזמן כתיבת הנתונים.
יתירות כשל אוטומטית	מספר הבקשות שנותבו מחדש באופן אוטומטי מאשכול אחד לאחר בגלל תרחיש של יתירות כשל, כמו הפסקה קצרה או עיכוב. ניתוב מחדש אוטומטי יכול להתרחש אם פרופיל האפליקציה משתמש בניתוב לכמה אשכולות. התרשים הזה לא כולל בקשות שנותבו מחדש באופן ידני.

בדף הסקירה הכללית של הטבלה מוצג גם מצב הרפליקציה של הטבלה בכל אשכול במכונה. לכל אשכול, בדף מוצגים הפרטים הבאים:

סטטוס
מזהה אשכול
תחום (zone)
נפח האחסון באשכול שהטבלה משתמשת בו
מפתח ההצפנה והסטטוס שלו
תאריך הגיבוי האחרון של הטבלה שנבחרה
קישור לדף Edit cluster.

כדי להציג את דף הסקירה הכללית של טבלה:

במסוף Google Cloud , פותחים את רשימת המכונות של Bigtable.

פתיחת רשימת המכונות
לוחצים על המכונה שרוצים לראות את המדדים שלה.
בחלונית הימנית, לוחצים על Tables. במסוף Google Cloud מוצגת רשימה של כל הטבלאות במכונה.
לוחצים על מזהה טבלה כדי לפתוח את הדף Table overview של הטבלה.

מעקב אחרי הביצועים לאורך זמן

כדי להבין את הביצועים הקודמים של המכונה, אפשר להשתמש בדף System Insights של מכונת Bigtable. אתם יכולים לנתח את הביצועים של כל אשכול, ולפרט את המדדים לפי סוגים שונים של משאבי Bigtable. התרשימים יכולים להציג תקופה שבין השעה האחרונה ל-6 השבועות האחרונים.

תרשימים של תובנות מערכת למשאבי Bigtable

בדף System Insights של Bigtable מוצגים תרשימים לסוגי המשאבים הבאים של 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 ובחזרה ללקוח, וכולל את כל הניסיונות החוזרים. בבקשות `ExecuteQuery`, זמני האחזור של הפעולה כוללים את זמן עיבוד האפליקציה לכל הודעה שמוחזרת.
זמן אחזור של כתיבה בצד הלקוח	מכונות טבלאות פרופילים של אפליקציות	זמן האחזור הכולל מקצה לקצה בכל ניסיונות ה-RPC שמשויכים לפעולה ב-Bigtable. מודד את זמן הסבב של הפעולה מהלקוח ל-Bigtable ובחזרה ללקוח, וכולל את כל הניסיונות החוזרים.
זמן האחזור של ניסיון קריאה בצד הלקוח	מכונות טבלאות פרופילים של אפליקציות	זמני האחזור של ניסיון קריאה של RPC על ידי לקוח. בנסיבות רגילות, הערך הזה זהה לערך של `operation_latencies`. עם זאת, אם הלקוח מקבל שגיאות זמניות, הערך של `operation_latencies` הוא הסכום של כל הערכים של `attempt_latencies` וההשהיות המעריכיות.
זמן האחזור של ניסיון קריאה של SQL בצד הלקוח	מכונות טבלאות פרופילים של אפליקציות	זמני האחזור של ניסיון RPC לקריאת SQL של לקוח. בנסיבות רגילות, הערך הזה זהה לערך של `operation_latencies`. עם זאת, אם הלקוח מקבל שגיאות זמניות, הערך של `operation_latencies` הוא הסכום של כל הערכים של `attempt_latencies` וההשהיות המעריכיות.
זמן האחזור של ניסיון הכתיבה בצד הלקוח	מכונות טבלאות פרופילים של אפליקציות	זמני האחזור של ניסיון כתיבה של לקוח ב-RPC. בנסיבות רגילות, הערך הזה זהה לערך של `operation_latencies`. עם זאת, אם הלקוח מקבל שגיאות זמניות, הערך של `operation_latencies` הוא הסכום של כל הערכים של `attempt_latencies` וההשהיות המעריכיות.
שיעור שגיאות המשתמשים	מכונות	שיעור השגיאות שנגרמו בגלל תוכן הבקשה, בניגוד לשגיאות בצד השרת של Bigtable. שיעור שגיאות המשתמשים כולל את קודי הסטטוס הבאים: INVALID_ARGUMENT NOT_FOUND PERMISSION_DENIED RESOURCE_EXHAUSTED OUT_OF_RANGE שגיאות משתמש נגרמות בדרך כלל מבעיה בהגדרה, כמו בקשה שמציינת את האשכול, הטבלה או פרופיל האפליקציה הלא נכונים. הערה: כדי לראות את התרשים הזה, צריך לקבץ את נתוני התובנות לגבי המערכת לפי מכונה. ברשימה הנפתחת View metrics for, בוחרים באפשרות Instance. אחר כך, בקטע קיבוץ לפי, לוחצים על Instance.
שיעור השגיאות במערכת	מכונות	אחוז כל הבקשות שנכשלו בצד השרת של Bigtable. שיעור השגיאות במערכת כולל את קודי הסטטוס הבאים: לא ידוע הפעולה בוטלה UNIMPLEMENTED פנימי לא זמין
יתירות כשל אוטומטית	מכונות טבלאות פרופילים של אפליקציות	מספר הבקשות שנותבו מחדש באופן אוטומטי מאשכול אחד לאחר בגלל תרחיש של יתירות כשל, כמו הפסקה קצרה או עיכוב. ניתוב מחדש אוטומטי יכול להתרחש אם פרופיל האפליקציה משתמש בניתוב לכמה אשכולות. התרשים הזה לא כולל בקשות שנותבו מחדש באופן ידני.
יתירות כשל אוטומטית ב-SQL	מכונות טבלאות פרופילים של אפליקציות	מספר בקשות ה-SQL שנותבו מחדש באופן אוטומטי מאשכול אחד לאחר בגלל תרחיש של יתירות כשל, כמו הפסקה קצרה או עיכוב. ניתוב מחדש אוטומטי יכול להתרחש אם פרופיל האפליקציה משתמש בניתוב לכמה אשכולות. התרשים הזה לא כולל בקשות שנותבו מחדש באופן ידני.
ניצול נפח האחסון (בייטים)	מכונות טבלאות	כמות הנתונים שמאוחסנים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. המדד הזה משקף את הגודל הפיזי של הנתונים הדחוסים בדיסק, ולא את הגודל הלוגי הלא דחוס שלהם.
ניצול נפח האחסון (% מקסימלי)	מכונות	אחוז נפח האחסון של האשכול שנמצא בשימוש. הקיבולת מבוססת על מספר הצמתים באשכול. השימוש בסנכרון שינויים בזרמי נתונים לא נכלל במדד הזה. לפרטים על אופן החישוב של הערך הזה, ראו ניצול האחסון לכל צומת.
עומס בדיסק	מכונות	באשכולות HDD, אחוז רוחב הפס המקסימלי האפשרי לקריאות HDD שבו האשכול משתמש. באשכולות SSD שמופעל בהם אחסון מדורג, אחוז השימוש של האשכול מתוך קצב הנתונים המקסימלי האפשרי ברמת הגישה הלא תכופה.
נפח האחסון ברמת הזיכרון	מכונות אשכולות	רק ב-Enterprise Plus. קיבולת האחסון של שכבת הזיכרון בבייטים.
יחידות בקשה מקסימליות בשכבה בזיכרון	מכונות אשכולות	רק ב-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 למרכז בקרה בהתאמה אישית.
משתמשים בספריית תרשימים, כמו Matplotlib ל-Python, כדי לשרטט ולנתח את מדדי השימוש ב-Bigtable.

כדי לראות את מדדי השימוש ב-Metrics Explorer:

פותחים את הדף Monitoring במסוף Google Cloud .

פתיחת הדף Monitoring

אם מוצגת בקשה לבחור חשבון, בוחרים את החשבון שמשמש לגישה אל Google Cloud.
לוחצים על Resources ואז על Metrics Explorer.
בקטע Find resource type and metric, מקלידים bigtable. מופיעה רשימה של משאבים ומדדים של Bigtable.
לוחצים על מדד כדי לראות את התרשים שלו.

למידע נוסף על השימוש ב-Cloud Monitoring, קראו את המסמכים של Cloud Monitoring.

לרשימה המלאה של מדדי Bigtable, ראו מדדים.

יצירת התראה על ניצול נפח האחסון

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

כדי ליצור מדיניות התראות שמופעלת כשניצול האחסון באשכול Bigtable חורג מסף מומלץ, כמו 70%, משתמשים בהגדרות הבאות.

השלבים ליצירת מדיניות התראות.

כדי ליצור מדיניות התראות:

נכנסים לדף Alerting במסוף Google Cloud :
נכנסים לדף Alerting.

אם אתם משתמשים בשורת החיפוש כדי למצוא את הדף הזה, בחרו בתוצאה שכותרת המשנה שלה היא Monitoring.
אם לא יצרתם ערוצי התראות ואתם רוצים לקבל התראות, לוחצים על Edit Notification Channels ומוסיפים את ערוצי ההתראות. אחרי שמוסיפים את הערוצים, חוזרים לדף Alerting.
בדף Alerting, לוחצים על Create policy.
כדי לבחור את המשאב, המדד והמסננים, מרחיבים את התפריט Select a metric ומשתמשים בערכים שבטבלה New condition:
1. אופציונלי: כדי להגביל את התפריט לרשומות רלוונטיות, מזינים את שם המשאב או המדד בסרגל הסינון.
2. בוחרים סוג משאב. לדוגמה, בוחרים באפשרות VM instance.
3. בוחרים קטגוריית מדדים. לדוגמה, בוחרים באפשרות instance.
4. בוחרים מדד. לדוגמה, בוחרים באפשרות CPU Utilization.
5. לוחצים על אישור.
לוחצים על Next ומגדירים את הטריגר של מדיניות ההתראות. כדי למלא את השדות האלה, משתמשים בערכים שבטבלה הגדרת טריגר להתראה.
לוחצים על הבא.
אופציונלי: כדי להוסיף התראות למדיניות ההתראות, לוחצים על Notification channels. בתיבת הדו-שיח, בוחרים ערוץ התראות אחד או יותר מהתפריט ולוחצים על OK.

כדי לקבל התראות כשפותחים וסוגרים התראות, מסמנים את האפשרות Notify on alert closure. כברירת מחדל, התראות נשלחות רק כשפותחים אותן.
אופציונלי: מעדכנים את משך הזמן לסגירה אוטומטית של ההתראה. השדה הזה קובע מתי מערכת Monitoring סוגרת התראות כשאין נתוני מדדים.
אופציונלי: לוחצים על Documentation ומוסיפים את המידע שרוצים לכלול בהודעה.
לוחצים על Alert name ונותנים שם למדיניות ההתראות.
לוחצים על יצירת מדיניות.

תנאי חדש שדה	ערך
משאב ומדד	בתפריט 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`