פתרון בעיות שקשורות לכללי מדיניות התראות

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

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

המדיניות של ניצול הדיסק יוצרת התראות לא צפויות

יצרתם מדיניות התראות כדי לעקוב אחרי הקיבולת "המשומשת" של הדיסקים במערכת. המדיניות הזו עוקבת אחרי המדד agent.googleapis.com/disk/percent_used. אתם מצפים לקבל התראה רק כשהניצול של דיסק פיזי כלשהו חורג מהסף שהגדרתם בתנאי. אבל המדיניות הזו יוצרת התראות כשניצול הדיסק של כל דיסק פיזי נמוך מהסף.

אחת מהסיבות הנפוצות להתראות לא צפויות במדיניות הזו היא שהתנאים לא מוגבלים למעקב אחרי דיסקים פיזיים. במקום זאת, כללי המדיניות האלה עוקבים אחרי כל הדיסקים, כולל דיסקים וירטואליים כמו התקני לולאה חוזרת (loopback). אם דיסק וירטואלי בנוי כך שהניצול שלו הוא 100%, תיווצר התראה לגבי המדיניות.

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

$ df
/dev/root     9983232  2337708  7629140   24%  /
devtmpfs      2524080        0  2524080    0%  /dev
tmpfs         2528080        0  2528080    0%  /dev/shm
...
/dev/sda15     106858     3934   102924    4%  /boot/efi
/dev/loop0      56704    56704        0  100%  /snap/core18/1885
/dev/loop1     129536   129536        0  100%  /snap/google-cloud-sdk/150
...

במערכת הזו, צריך להגדיר מדיניות התראה על ניצול הדיסק כדי לסנן את הסדרות העיתיות של התקני הלולאה החוזרת /dev/loop0 ו-/dev/loop1. לדוגמה, אפשר להוסיף את המסנן device !=~ ^/dev/loop.*, שמחריג את כל סדרות הזמנים שהתווית device שלהן לא תואמת לביטוי הרגולרי ^/dev/loop.*.

סיבות נפוצות להתראות חריגות

יצרתם מדיניות התראות, ונראה שהיא יוצרת התראות מוקדם מדי או באופן שגוי.

יש כמה סיבות אפשריות לכך שקיבלתם התראות שנראות שגויות:

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

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

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

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

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

    לדוגמה, אם המדד נדגם כל 60 שניות, צריך להגדיר חלון בדיקה חוזרת של לפחות 3 דקות. אם מגדירים את חלון הבדיקה החוזרת לערך most recent value, או לערך שווה ערך של 0 שניות, מדידה אחת יכולה לגרום ליצירת התראה.

  • כשעורכים את התנאי של מדיניות התראות, יכול להיות שיעברו כמה דקות עד שהשינוי יתעדכן בתשתית ההתראות. במהלך התקופה הזו, יכול להיות שתקבלו התראות שעמדו בתנאים של מדיניות ההתראות המקורית.

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

  • שינוי השם של התווית App Hub (metadata.system_labels.apphub_host_project_id) ל-metadata.system_labels.apphub_application_container עלול לגרום ליצירת התראות חדשות, וחלק מההתראות הפתוחות לא ייסגרו.

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

ההתראה לא נסגרת כשהנתונים מפסיקים להגיע

אתם מגדירים מדיניות התראות לסגירת התראות כשהנתונים מפסיקים להגיע. במקרים מסוימים, הנתונים מפסיקים להגיע אבל ההתראה נשארת פתוחה. לדוגמה, אם אתם עוקבים אחרי עומסי עבודה זמניים כמו פודים של Google Kubernetes Engine, משימות או גרסאות של Cloud Run או משימות באצווה, יכול להיות שההתראה תישאר פתוחה אחרי שעומס העבודה יסתיים ונתוני המדדים יפסיקו להגיע.

אם המשאב הבסיסי שמנוטר על ידי מדיניות התראה מכיל את התווית metadata.system_labels.state, ואם המדיניות הזו לא נכתבה באמצעות שפת השאילתות של Monitoring, אז Monitoring יכול לקבוע את מצב המשאב. אם ידוע שהמשאב מושבת, מערכת Monitoring לא סוגרת את ההתראות באופן אוטומטי כשהנתונים מפסיקים להגיע.

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

  • עורכים את מדיניות ההתראות ומבצעים את השינויים הבאים:

    1. עורכים את מדיניות ההתראות במסוף Google Cloud .

    2. בדף Configure trigger, מרחיבים את Advanced options ומגדירים את התפריט Evaluation of missing data לערך Missing data points treated as values that don't violate the policy condition. האפשרות הזו תואמת לערך ה-enum‏ EVALUATION_MISSING_DATA_INACTIVE.

    3. בדף Notifications and name, מגדירים את התפריט Alert autoclose duration ל-30 דקות.

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

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

אי אפשר לראות את פרטי ההתראה בגלל שגיאת הרשאה

נכנסים לדף ההתראות במסוף Google Cloud ובוחרים התראה כדי לצפות בה. אתם מצפים שדף הפרטים ייפתח. עם זאת, דף הפרטים לא נפתח ומוצגת ההודעה "Permission denied".

כדי לראות את כל פרטי ההתראה, חוץ מנתוני המדדים, ודאו שיש לכם את התפקידים הבאים בניהול זהויות והרשאות גישה (IAM): "צפייה באירועים במסוף Cloud" (roles/monitoring.cloudConsoleIncidentViewer) ו"צפייה בחשבונות Stackdriver" (roles/stackdriver.accounts.viewer).

כדי לראות את כל פרטי ההתראה, כולל נתוני המדדים, וכדי שתוכלו לאשר או לסגור התראות, ודאו שיש לכם את התפקידים "צפייה ב-Monitoring"‏ (roles/monitoring.viewer) ו"עריכת אירועים במסוף Cloud של Monitoring"‏ (roles/monitoring.cloudConsoleIncidentEditor) ב-IAM.

תפקידים בהתאמה אישית לא יכולים להעניק את ההרשאה שנדרשת כדי לראות את פרטי ההתראה.

לא נוצרת התראה כשהתנאי מתקיים

יצרתם מדיניות התראות עם תנאי אחד. בתרשים של מדיניות ההתראות מוצג שהנתונים המנוטרים מפרים את התנאי, אבל לא קיבלתם התראה ולא נוצרה התראה.

אם אחד מהקריטריונים הבאים מתקיים אחרי שהתנאי של מדיניות ההתראה מתקיים, אז Monitoring לא פותח את ההתראה.

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

  • מצב המשאב שמדיניות ההתראות עוקבת אחריו הוא "מושבת". בעזרת Monitoring אפשר לקבוע את מצב המשאב כשהמשאב מכיל את התווית metadata.system_labels.state וכשמדיניות ההתראה לא כתובה בשפת השאילתות של Monitoring.

בפרטי ההתראה מופיע פרויקט שגוי

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

אפשרויות הצבירה שצוינו בתנאי של מדיניות ההתראות קובעות את הפרויקט Google Cloud שאליו מפנה ההתראה:

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

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

לא ניתן לסגור התראה באופן ידני

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

Unable to close alert with active conditions.

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

השגיאה הבאה מתרחשת כשאי אפשר לסגור התראה בגלל שגיאה פנימית:

Unable to close alert. Please try again in a few minutes.

כשמופיעה הודעת השגיאה הקודמת, אפשר לנסות שוב את פעולת הסגירה או לאפשר ל-Monitoring לסגור את ההתראה באופן אוטומטי.

מידע נוסף זמין במאמר ניהול התראות.

מדיניות עם כמה תנאים יוצרת כמה התראות

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

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

לדוגמה, נניח שיש לכם מדיניות התראות עם שני תנאים, וכל תנאי עוקב אחרי 3 סדרות זמנים. המדיניות שולחת התראה רק כששני התנאים מתקיימים. כשהתנאים של המדיניות מתקיימים, אתם יכולים לקבל בין 2 התראות (סדרת זמנים אחת מתקיימת בכל תנאי) ל-6 התראות (כל סדרות הזמנים מתקיימות בכל תנאי).

אי אפשר להגדיר ב-Cloud Monitoring יצירה של התראה אחת ושליחה של התראה אחת.

מתי נשלחות התראות ונוצרות התראות ב-Monitoring

הערך של משתנה של תווית מדד הוא null

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

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

  • מוודאים שהגדרות הצבירה של מדיניות ההתראה שומרות את התווית שרוצים להציג.

    לדוגמה, נניח שיצרתם מדיניות התראות שעוקבת אחרי מספר הבייטים שנכתבו בדיסק על ידי מכונות וירטואליות. אתם רוצים שבתיעוד יופיע המכשיר שגרם להתראה, אז אתם מוסיפים לשדה התיעוד את הטקסט הבא: device: ${metric.label.device}.

    אתם צריכים גם לוודא שהגדרות הצבירה שומרות על הערך של התווית device. כדי לשמור את התווית הזו, צריך להגדיר את פונקציית הצבירה לערך none או לוודא שהבחירות של הקיבוץ כוללות את device.

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

    לדוגמה, המשתנה log.extracted_label.KEY נתמך רק במדיניות התראות שמבוססת על יומנים. המשתנה הזה תמיד מוצג בתור null כשמדיניות התראה עוקבת אחרי מדד, אפילו מדד מבוסס-יומנים.

אין נתונים חדשים אחרי שינויים בהגדרות של המדדים

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

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

יצירת מדיניות ההתראות נכשלת ב-API בגלל מדד חסר

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

Error 404: Cannot find metric(s) that match type = "METRIC_NAME".
If a metric was created recently, it could take up to 10 minutes to become
available. Please try again soon.

כדי לפתור את הבעיה, צריך להמתין לפחות עשר דקות ואז לשלוח מחדש את בקשת ה-API.

בתרשים של מדיניות ההתראות לא מוצגת חריגה מהסף

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

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

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