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

פתרון בעיות במדדים מבוססי-יומנים

כדי לאבחן ולפתור בעיות במדדים מבוססי-היומנים ב-Cloud Logging, כמו נתונים חסרים, ספירות שמתעכבות או התראות חיוביות מוטעות, אתם יכולים להיעזר בהנחיות לפתרון בעיות שמופיעות בדף הזה.

התוכן בדף הזה רלוונטי רק לנתוני המדדים שנגזרים מהיומנים שלכם. היא לא חלה על נתוני מדדים שנכתבו ישירות על ידי שירותי Google Cloud או האפליקציות שלכם.

אי אפשר לראות או ליצור מדדים

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

כדי ליצור מדדים מבוססי-יומנים, צריך את ההרשאות המתאימות לניהול זהויות והרשאות גישה (IAM). לפרטים נוספים, קראו את המאמר בקרת גישה באמצעות IAM: מדדים מבוססי-יומנים.

במדד חסרים נתוני יומנים

הרשומה הזו רלוונטית רק לנתוני מדדים ש-Google Cloud Observability מפיק מנתוני היומנים (מדדים מבוססי-יומנים). היא לא חלה על נתוני מדדים שנכתבים על ידי Google Cloud שירותים או האפליקציות שלכם.

יכולות להיות כמה סיבות לכך שחסרים נתונים במדדים מבוססי-יומנים:

יכול להיות שרשומות חדשות ביומן לא יתאימו למסנן של המדד. מדד מבוסס-יומנים מקבל נתונים מרשומות יומן תואמות שמתקבלות אחרי שהמדד נוצר. הכלי Logging לא ממלא את המדד מרשומות קודמות ביומן.
יכול להיות שרשומות חדשות ביומן לא יכילו את השדה הנכון, או שהנתונים לא יהיו בפורמט הנכון לחילוץ על ידי מדד ההתפלגות. חשוב לוודא ששמות השדות והביטויים הרגולריים נכונים.
יכול להיות שיהיה עיכוב בספירת המדדים. למרות שרשומות יומן שנספרות מופיעות ב-Logs Explorer, יכול להיות שיעברו עד 10 דקות עד שהמדדים מבוססי-יומנים יתעדכנו ב-Cloud Monitoring.
יכול להיות שרשומות היומן שמוצגות ייספרו באיחור או לא ייספרו בכלל, כי חותמת הזמן שלהן היא בעבר הרחוק או בעתיד הרחוק. אם רשומת יומן מתקבלת ב-Cloud Logging יותר מ-24 שעות בעבר או 10 דקות בעתיד, רשומת היומן לא תיספר במדד מבוסס-היומנים.

מספר הרשומות שהגיעו באיחור מתועד במדד מבוסס-היומנים logging.googleapis.com/logs_based_metrics_error_count.

דוגמה: רשומה ביומן שתואמת למדד מבוסס-יומנים מגיעה באיחור. הערך של timestamp הוא 2:30 PM ב-20 בפברואר 2020, והערך של receivedTimestamp הוא 2:45 PM ב-21 בפברואר 2020. הרשומה הזו לא תיספר במדד מבוסס-היומנים.
המדד מבוסס-היומנים נוצר אחרי שהתקבלו רשומות ביומן שהמדד יכול לספור. מדדים מבוססי-יומנים מעריכים רשומות ביומן כשהן מאוחסנות בקטגוריות של יומנים. המדדים האלה לא מעריכים רשומות ביומן שמאוחסנות ב-Logging.
במדד מבוסס-היומנים יש פערים בנתונים. יכול להיות שיהיו פערים מסוימים בנתונים, כי המערכות שמעבדות את נתוני המדדים מבוססי-היומנים לא מבטיחות שכל נקודה על הגרף של מדד תישמר. אם יש פערים, הם בדרך כלל נדירים וקצרים. עם זאת, אם יש לכם מדיניות התראות שעוקבת אחרי מדד מבוסס-יומנים, פערים בנתונים עלולים לגרום להתראה שגויה. ההגדרות שבהן אתם משתמשים במדיניות ההתראות יכולות לצמצם את האפשרות הזו.

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

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

סוג המשאב הוא undefined ב-Cloud Monitoring

חלק מסוגי המשאבים במעקב ב-Cloud Logging לא ממופים ישירות לסוגי המשאבים במעקב ב-Cloud Monitoring. לדוגמה, כשיוצרים בפעם הראשונה מדיניות התראות או תרשים ממדד מבוסס-יומנים, יכול להיות שסוג המשאב יופיע כ-undefined.

סוג המשאב לא מוגדר.

סוג המשאב במעקב ממופה ל-global או לסוג אחר של משאב במעקב ב-Cloud Monitoring. כדי לקבוע איזה סוג של משאב במעקב צריך לבחור, עיינו במאמר מיפויים למשאבים של Logging בלבד.

תוויות בהתראה לא נפתרו

יוצרים מדד מבוסס-יומנים, ואז יוצרים מדיניות התראות כדי לעקוב אחרי המדד הזה. בשדה התיעוד של מדיניות ההתראה, אתם מפנים לתוויות שחולצו באמצעות משתנה בפורמט ${log.extracted_label.KEY}, כאשר KEY הוא השם שנתתם לתווית שחולצה. התווית לא נפתרת בהתראה.

כדי לפתור את הבעיה, אתם יכולים לבצע אחת מהפעולות הבאות:

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

התראות לא נוצרות או שהן תוצאות חיוביות כוזבות

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

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

התראות חיוביות כוזבות יכולות להתרחש כי רשומות ביומן יכולות להישלח ל-Logging באיחור. לדוגמה, במקרים מסוימים יכול להיות הבדל של כמה דקות בין השדות timestamp ו-receiveTimestamp ביומן. בנוסף, כש-Logging מאחסן יומנים בקטגוריות של יומנים, יש עיכוב מובנה בין הזמן שבו נוצרות הרשומות ביומן לבין הזמן שבו Logging מקבל אותן. כלומר, יכול להיות שבכלי הרישום ביומן לא יופיע המספר הכולל של רשומות יומן מסוימות עד לנקודת זמן מסוימת לאחר יצירת רשומות היומן. לכן, מדיניות התראה שמשתמשת בלוגיקה של פחות מ- או שמבוססת על תנאי של אחוזון למדד התפלגות, יכולה ליצור התראה חיובית מוטעית: לא כל רשומות היומן נלקחו בחשבון עדיין.

עם זאת, מדדים מבוססי-יומנים הם עקביים בסופו של דבר, כי אפשר לשלוח ל-Logging רשומת יומן שתואמת למדד מבוסס-יומנים עם timestamp ישן או חדש יותר באופן משמעותי מה-receiveTimestamp של היומן.

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

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

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

אם אתם משתמשים במסוף Google Cloud , השתמשו בתפריט חלון זמן דינמי כדי להגדיר את תקופת ההתאמה.
אם אתם משתמשים ב-API, השתמשו בשדה aggregations.alignmentPeriod של התנאי כדי להגדיר את תקופת ההתאמה.

במדד מבוסס-היומנים יש יותר מדי סדרות זמנים

מספר הסדרות של נתונים כרונולוגיים במדד תלוי במספר השילובים השונים של ערכי התוויות. מספר סדרות הזמנים נקרא העוצמה (cardinality) של המדד. המספר המקסימלי של סדרות הזמן למדד הוא 30,000.

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

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

בגלל המגבלה של מיליון סדרות זמנים פעילות לכל משאב במעקב, המערכת עשויה לווסת את נתוני המדדים גם אם יש פחות מ-30,000 סדרות זמנים פעילות. במדדים מבוססי-יומנים ברמת הפרויקט, המשאב מוגדר על ידי המשאב ברשומת היומן. במדדים מבוססי-יומנים ברמת הקטגוריה, המשאב הוא logging_bucket.

כדי למנוע יצירה של מדדים בעלי עוצמה גבוהה:

מוודאים ששדות התוויות והביטויים הרגולריים של החילוץ תואמים לערכים עם עוצמה מוגבלת.

לדוגמה, אל תאחסנו גדלים, ספירות או משכי זמן בתוויות. בנוסף, אל תאחסנו שדות כמו כתובות URL, כתובות IP או מזהים ייחודיים, כי כולם יכולים לגרום למספר גדול של סדרות זמן.
אל תחלצו הודעות טקסט שיכולות להשתנות ללא הגבלה כערכי תוויות.
אל תחלצו ערכים מספריים עם עוצמה (cardinality) בלתי מוגבלת.
לחלץ ערכים רק מתוויות עם עוצמה ידועה, למשל קודי סטטוס עם קבוצה של ערכים ידועים.

המדדים האלה, שמבוססים על יומני המערכת, יכולים לעזור לכם למדוד את ההשפעה של הוספה או הסרה של תוויות על העוצמה של המדד:

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

שם המדד לא תקין

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

האורך המקסימלי של מחרוזות של שמות מדדים הוא 100 תווים, והן יכולות לכלול רק את התווים הבאים:

A-Z
a-z
0-9
התווים המיוחדים _-.,+!*',()%\/.

התו קו נטוי / מציין היררכיה של חלקים בתוך שם המדד, והוא לא יכול להיות התו הראשון בשם.

ערכי המדדים מבוססי-היומנים שגויים

שמתם לב שהערכים שמדווחים במדד מבוסס-יומנים שונים לפעמים ממספר הרשומות ביומן שמדווחות ב-Logs Explorer.

כדי לצמצם את הפער בנתונים, מבצעים את הפעולות הבאות:

מוודאים שהאפליקציות לא שולחות רשומות כפולות ביומן. רשומות ביומן נחשבות לכפילויות אם יש להן את אותם timestamp ו-insertId. ב-Logs Explorer, רשומות כפולות ביומן נמחקות באופן אוטומטי. עם זאת, במדדים מבוססי-יומנים נספרת כל רשומת יומן שתואמת למסנן של המדד.
חשוב לוודא שרשומת היומן נשלחת ל-Cloud Logging כשחותמת הזמן היא פחות מ-24 שעות בעבר או פחות מ-10 דקות בעתיד. רשומות ביומן שחותמות הזמן שלהן לא נמצאות בטווח הזה לא נספרות על ידי מדדים מבוססי-יומנים.

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

ערכי התוויות נחתכים

הערכים של תוויות שמוגדרות על ידי המשתמשים לא יכולים להיות גדולים מ-1,024 בייטים.

אי אפשר למחוק מדד מבוסס-יומנים בהתאמה אישית

אתם מנסים למחוק מדד מבוסס-יומנים מותאם אישית באמצעות מסוף Google Cloud . בקשת המחיקה נכשלת, ובתיבת הדו-שיח של המחיקה מוצגת הודעת השגיאה There is an unknown error while executing this operation.

כדי לפתור את הבעיה, נסו את הפתרונות הבאים:

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