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

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

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

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

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

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

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

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

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

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

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

במדד יש יותר מדי סדרות עיתיות

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

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

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

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