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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

לא נוצרים אירועים או שהם חיוביים כוזבים

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

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

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

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

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

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

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

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

מדד מבוסס-יומנים מכיל יותר מדי סדרות זמן

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

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

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