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

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

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

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

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

מדדים מבוססי-יומן חלים רק על פרויקט אחד Google Cloud או על קטגוריית Logging בתוך פרויקט 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 הוא השם שנתתם לתווית שחולצה. התווית לא נפתרה בהתראה.

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

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

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

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

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

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