Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

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

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

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

לא נוצרים אירועים או שנוצרים אירועים שהם תוצאות חיוביות שגויות

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

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

יכול להיות שיהיו אירועים חיוביים כוזבים כי רשומות ביומן יכולות להישלח ל-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.

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