פתרון בעיות בשירות מנוהל ל-Prometheus

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

הגדרתם את השירות המנוהל ל-Prometheus, אבל לא רואים נתוני מדדים ב-Grafana או בממשק המשתמש של Prometheus. באופן כללי, יכול להיות שהסיבה היא אחת מהאפשרויות הבאות:

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

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

כדי לקבוע אם הבעיה היא בצד של ההטמעה או בצד של השאילתה, נסו לשלוח שאילתה לנתונים באמצעות הכרטיסייה PromQL של Metrics Explorer במסוף Google Cloud . אין בעיות בדף הזה שקשורות להרשאות קריאה או להגדרות של Grafana.

כדי להציג את הדף הזה:

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

  2. נכנסים לדף  Metrics explorer במסוף Google Cloud :

    כניסה אל Metrics Explorer

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

  3. בסרגל הכלים של החלונית ליצירת שאילתות, לוחצים על הלחצן ששמו  PromQL.

  4. מזינים את השאילתה הבאה בעורך ולוחצים על Run query:

    up

אם מבצעים שאילתה על המדד up ורואים תוצאות, הבעיה היא בצד השאילתה. מידע על פתרון הבעיות האלה מופיע במאמר בנושא בעיות בצד השאילתה.

אם מבצעים שאילתה על המדד up ולא רואים תוצאות, הבעיה היא בצד של ההטמעה. מידע על פתרון הבעיות האלה מופיע במאמר בנושא בעיות בצד ההטמעה.

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

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

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

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

כדי להציג את הדף ניהול מדדים:

  1. נכנסים לדף  Metrics management במסוף Google Cloud :

    נכנסים אל ניהול מדדים.

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

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

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

בעיות בצד השאילתה

הסיבה לרוב הבעיות בצד השאילתה היא אחת מהסיבות הבאות:

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

  • צריך לבדוק היטב את ההגדרה בהשוואה להוראות ההגדרה של שאילתות.

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

    1. נכנסים לדף IAM במסוף Google Cloud :

      כניסה לדף IAM

      אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.

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

    3. בוחרים בשדה Role, לוחצים על Currently used ומחפשים את התפקיד Monitoring Viewer. אם לחשבון השירות אין את התפקיד הזה, צריך להוסיף אותו עכשיו.

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

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

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

  • אחת מהשגיאות האלה מסוג 'אסור' ב-Grafana או בממשק המשתמש של Prometheus:

    • ‫Warning: Unexpected response status when fetching server time: Forbidden
    • ‫"Warning: Error fetching metrics list: Unexpected response status when fetching metric names: Forbidden"

  • הודעה כזו ביומני הרישום:
    "cannot read credentials file: open /gmp/key.json: no such file or directory"

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

  1. מוודאים שבחרתם את נקודת קצה ל-API הנכונה של Grafana, את ה-UID של מקור הנתונים של Grafana ואת טוקן Grafana API. אפשר לבדוק את המשתנים ב-CronJob על ידי הרצת הפקודה kubectl describe cronjob datasource-syncer.

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

  3. מוודאים שלחשבון השירות שלכם ב-Grafana יש תפקיד 'אדמין' ושהתוקף של אסימון ה-API לא פג.

  4. מוודאים שלחשבון השירות יש את התפקיד Monitoring Viewer (צפייה בנתוני ניטור) עבור מזהה הפרויקט שנבחר.

  5. כדי לוודא שאין שגיאות ביומנים של משימת סנכרון מקור הנתונים, מריצים את הפקודה kubectl logs job.batch/datasource-syncer-init. צריך להריץ את הפקודה הזו מיד אחרי שמחילים את קובץ datasource-syncer.yaml.

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

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

  1. מוודאים שמזהה הפרויקט של ממשק המשתמש בקצה הקדמי מוגדר לאותו היקף המדדים בפרויקט או פרויקט שלחשבון השירות יש אישורים לגביו.

  2. בודקים את מזהה הפרויקט שציינתם עבור כל הדגלים של --query.project-id.

  3. מוודאים שלחשבון השירות יש את התפקיד Monitoring Viewer (צפייה בנתוני ניטור) עבור מזהה הפרויקט שנבחר.

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

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

  6. אם אתם יוצרים סוד משלכם, ודאו שהוא קיים:

    kubectl get secret gmp-test-sa -o json | jq '.data | keys'

  7. מוודאים שהסוד מוטמע בצורה נכונה:

    kubectl get deploy frontend -o json | jq .spec.template.spec.volumes

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts

  8. מוודאים שהסוד מועבר בצורה נכונה למאגר התגים: 

    kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args

שיטת HTTP שגויה עבור Grafana

אם אתם רואים את שגיאת ה-API הבאה מ-Grafana, סימן ש-Grafana מוגדר לשלוח בקשת POST במקום בקשת GET:

  • ‪"{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

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

פסק זמן בשאילתות גדולות או בשאילתות שפועלות במשך זמן רב

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

  • ‪"Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

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

שגיאות באימות התווית

אם אחת מהשגיאות הבאות מופיעה ב-Grafana, יכול להיות שאתם משתמשים בנקודת קצה שלא נתמכת:

  • ‫"Validation: labels other than name are not supported yet"
  • ‫"Templating [job]: Error updating options: labels other than name are not supported yet."

השירות המנוהל ל-Prometheus תומך בנקודת הקצה /api/v1/$label/values רק עבור התווית __name__. בגלל המגבלה הזו, שאילתות שמשתמשות במשתנה label_values($label) ב-Grafana נכשלות.

במקום זאת, צריך להשתמש בטופס label_values($metric, $label). השאילתה הזו מומלצת כי היא מגבילה את ערכי התווית שמוחזרים לפי מדד, וכך מונעת אחזור של ערכים שלא קשורים לתוכן של לוח הבקרה. השאילתה הזו קוראת לנקודת קצה נתמכת של Prometheus.

למידע נוסף על נקודות קצה נתמכות, ראו תאימות ל-API.

חריגה מהמכסה

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

  • ‫"429: RESOURCE_EXHAUSTED: חריגה מהמכסה של מדד המכסה 'שאילתות של סדרות זמן ' והמגבלה 'שאילתות של סדרות זמן בדקה' של השירות 'monitoring.googleapis.com' עבור הצרכן 'project_number:...'."

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

מדדים מכמה פרויקטים

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

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

לא צוין סוג משאב במעקב

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

  • ‫מדד מוגדר לשימוש עם יותר מסוג אחד של משאב במעקב; בורר סדרות חייב לציין התאמת תוויות בשם המשאב במעקב

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

ערכים גולמיים של מדדים מסוג Counter,‏ histogram ו-summary לא תואמים בין ממשק המשתמש של הכלי לאיסוף נתונים לבין Google Cloud המסוף

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

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

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

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

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

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

נתונים חסרים של מונה או היסטוגרמות פגומות

הסימן הכי נפוץ לבעיה הזו הוא שלא רואים נתונים או שרואים פערים בנתונים כשמריצים שאילתה על מדד של מונה פשוט (לדוגמה, שאילתת PromQL של metric_name_foo). אפשר לוודא זאת אם הנתונים מופיעים אחרי שמוסיפים פונקציה rateלשאילתה (לדוגמה, rate(metric_name_foo[5m])).

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

יכול להיות שתשימו לב גם שפעולות היסטוגרמה, כמו הפונקציה quantile(), לא פועלות כמו שצריך.

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

היוריסטיקה הזו בדרך כלל עובדת טוב מאוד, אבל היא עלולה לגרום לבעיות כמו תוצאות מוזרות כשמפעילים שאילתה על מדד גולמי מסוג unknown:counter. בנוסף, היסטוגרמות הן אובייקטים עם סוג ספציפי ב-Monarch, ולכן אם תטמיעו את שלושת מדדי ההיסטוגרמה הנדרשים כמדדי מונה נפרדים, פונקציות ההיסטוגרמה לא יפעלו. מכיוון שמדדים מסוג 'לא ידוע' מוזנים פעמיים, אם לא מגדירים TYPE, כמות הדגימות שמוזנות מוכפלת.

סיבות נפוצות לכך שהמאפיין TYPE לא מוגדר:

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

כדי לפתור את הבעיה:

  • הפסקת השימוש באיחוד עם שירות מנוהל ל-Prometheus. אם רוצים לצמצם את הקרדינליות ואת העלות על ידי צבירת נתונים לפני שליחתם אל Monarch, אפשר לעיין במאמר בנושא הגדרת צבירה מקומית.
  • מפסיקים להשתמש ב-Prometheus Remote Write בנתיב האיסוף.
  • כדי לוודא שהשדה # TYPE קיים בכל מדד, נכנסים לנקודת הקצה /metrics.
  • מוחקים כל כלל לשינוי התווית שמשנה את השם של מדד.
  • כדי למחוק מדדים שמתנגשים עם הסיומת unknown או unknown:counter, צריך להתקשר אל DeleteMetricDescriptor.
  • לחלופין, אפשר תמיד לשלוח שאילתות לגבי מוניטורים באמצעות rate או פונקציה אחרת לעיבוד מוניטורים.

אפשר גם ליצור כלל להחרגת מדדים בכלי לניהול מדדים כדי למנוע את ההטמעה של מדדים שמסתיימים ב-unknown באמצעות הביטוי הרגולרי prometheus.googleapis.com/.+/unknown.*. אם לא תתקנו את הבעיה הבסיסית לפני שתתקינו את הכלל הזה, יכול להיות שתמנעו את ההטמעה של נתוני מדדים רצויים.

נתוני Grafana לא נשמרים אחרי הפעלה מחדש של ה-pod

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

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

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

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

התנהגות כזו עשויה לקרות לעיתים קרובות יותר אם מתקיים אחד מהתנאים הבאים:

  • אתם מריצים באופן עקבי הרבה שאילתות דומות מאוד במקביל, אולי באמצעות כללים. יכול להיות שההבדל בין השאילתות האלה הוא רק במאפיין אחד. לדוגמה, יכול להיות שאתם מפעילים 50 כללי הקלטה ששונים רק ב-VALUE של המסנן {foo="VALUE"}, או ששונים רק בערכים שונים של [duration] בפונקציה rate.
  • אתם מריצים שאילתות בזמן=עכשיו ללא מאגר זמני.
  • אתם מריצים שאילתות מיידיות כמו התראות או כללי הקלטה. אם אתם משתמשים בכלל הקלטה, יכול להיות שתבחינו בעלייה החדה בפלט השמור, אבל לא תמצאו אותה כשמריצים שאילתה על הנתונים הגולמיים.
  • אתם שולחים שאילתה לגבי שני מדדים כדי ליצור יחס. הזינוקים בגרף בולטים יותר כשמספר סדרות הזמן נמוך בשאילתת המונה או המכנה.
  • נתוני המדדים שלכם נמצאים באזורים גדולים יותר Google Cloud , כמו us-central1 או us-east4.

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

  • (הסיבה הנפוצה ביותר) כל השאילתות הדומות והמקבילות שלכם מבקשות נתונים מאותה קבוצה של צמתי Monarch, וצורכות כמות גדולה של זיכרון בכל צומת במצטבר. השאילתות שלכם יפעלו אם למערכת Monarch יהיו מספיק משאבים זמינים באזור Cloud. כש-Monarch נמצא בלחץ משאבים באזור בענן, כל צומת מגביל את השאילתות, ומעדיף להגביל את המשתמשים שצורכים הכי הרבה זיכרון בכל צומת. כשיהיו שוב מספיק משאבים ל-Monarch, השאילתות שלכם יפעלו שוב. יכול להיות שהשאילתות האלה הן SLI שנוצרו באופן אוטומטי על ידי כלים כמו Sloth.
  • הנתונים מגיעים באיחור, והשאילתות לא יכולות להתמודד עם זה. הזמן שנדרש כדי שאפשר יהיה לשלוח שאילתות לגבי נתונים חדשים שנכתבו הוא בערך 3-7 שניות, לא כולל זמן האחזור ברשת וכל עיכוב שנגרם בגלל עומס על המשאבים בסביבה שלכם. אם השאילתה לא כוללת השהיה או היסט כדי להביא בחשבון נתונים שמתקבלים באיחור, יכול להיות שתשאלו שאילתה על תקופה שבה יש לכם רק נתונים חלקיים. אחרי שהנתונים מגיעים, תוצאות השאילתה נראות רגילות.
  • יכול להיות שיהיה הבדל קל בין הנתונים שיישלחו ל-Monarch לבין הנתונים שיישלחו למערכות אחרות. מנוע השאילתות מנסה לבחור את העותק המשוכפל באיכות הכי גבוהה, אבל אם שאילתות שונות בוחרות עותקים משוכפלים שונים עם קבוצות נתונים שונות במקצת, יכול להיות שהתוצאות שלכם יהיו שונות מעט בין השאילתות. זו התנהגות צפויה של המערכת, וההתראות שלכם צריכות להיות סובלניות להבדלים הקטנים האלה.
  • יכול להיות שאזור שלם ב-Monarch לא יהיה זמין באופן זמני. אם אי אפשר להגיע לאזור מסוים, מנוע השאילתות מתייחס לאזור כאילו הוא לא היה קיים מעולם. אחרי שהאזור יהיה זמין, תוצאות השאילתות ימשיכו להחזיר את הנתונים של האזור הזה.

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

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

    לדוגמה, אם יש לכם תווית foo עם הערכים bar,‏ baz ו-qux, במקום להגדיר כלל נפרד לכל ערך של תווית (כלל אחד עם השאילתה sum(metric{foo="bar"}), כלל אחד עם השאילתה sum(metric{foo="baz"}) וכלל אחד עם השאילתה sum(metric{foo="qux"})), כדאי להגדיר כלל אחד שמצטבר על פני התווית הזו ומסנן באופן אופציונלי לערכי התווית שחשובים לכם (כמו sum by (foo) metric{foo=~"bar|baz|qux"}).

    אם למדד יש 2 תוויות, לכל תווית יש 50 ערכים, יש לכם כלל נפרד לכל שילוב של ערכי תוויות, והשאילתות של הכללים הן יחס, אז בכל תקופה מופעלות 50 x 50 x 2 = 5,000 שאילתות מקבילות של Monarch, וכל אחת מהן פונה לאותו סט של צמתי Monarch. במצטבר, 5,000 שאילתות מקבילות כאלה צורכות כמות גדולה של זיכרון בכל צומת של Monarch, מה שמגדיל את הסיכון להגבלת קצב הבקשות כשבאזור של Monarch יש עומס על המשאבים.

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

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

    כדאי להריץ שאילתות כאלה פעם בשעה במקום פעם בדקה. אם מריצים שאילתה למשך יום שלם כל דקה, מקבלים שינוי של 1/1440 = 0.07% בתוצאה בכל תקופה, וזה שינוי זניח. אם מריצים שאילתה למשך יום שלם כל שעה, מקבלים שינוי של 60/1440 = 4% בתוצאה בכל תקופה, שזה גודל אות רלוונטי יותר. אם אתם רוצים לקבל התראה אם יש שינויים בנתונים האחרונים, אתם יכולים להפעיל כלל אחר עם חלון מבט לאחור קצר יותר (למשל, 5 דקות) פעם בדקה.

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

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

  • אפשר להשתמש במגדיר offset ב-PromQL כדי לעכב את הערכת השאילתה, כך שהיא לא תפעל על הנתונים מהתקופה האחרונה. בודקים את מרווח הדגימה ואת מרווח הערכת הכללים ומזהים את הארוך מביניהם. מומלץ שההיסט של השאילתה יהיה לפחות כפול מאורך המרווח הארוך יותר. לדוגמה, אם אתם שולחים נתונים כל 15 שניות ומריצים כללים כל 30 שניות, כדאי להוסיף להיסט של השאילתות לפחות דקה. הזחה של דקה אחת גורמת לכללים להשתמש בחותמת זמן של סיום שהיא לפחות בת 60 שניות, וכך נוצר מאגר זמני לנתונים שמתקבלים באיחור לפני הפעלת הכלל.

    זו שיטה מומלצת גם ב-Cloud Monitoring (לכל ההתראות המנוהלות של PromQL יש היסט של דקה אחת לפחות) וגם ב-Prometheus.

  • כדי לבודד בעיות פוטנציאליות של אזורים לא זמינים, כדאי לקבץ את התוצאות לפי התווית location. יכול להיות שהתווית עם האזור Google Cloud תיקרא zone או region בחלק מהמדדים של המערכת.

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

  • אם היחס הוא יחס הצלחה (למשל, תגובות 2xx חלקי סך התגובות), כדאי להפוך אותו ליחס שגיאה (למשל, תגובות 4xx+5xx חלקי סך התגובות). יחסי השגיאות סלחניים יותר לגבי נתונים לא עקביים, כי ירידה זמנית בנתונים גורמת לכך שתוצאת השאילתה נמוכה מהסף שהגדרתם, ולכן ההתראה לא מופעלת.

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

    • אם Monarch מגביל את השאילתה של המונה אבל לא את השאילתה של המכנה, יכול להיות שתראו תוצאות נמוכות באופן לא צפוי. אם Monarch מגביל את השאילתה של המכנה אבל לא את השאילתה של המונה, יכול להיות שתראו תוצאות גבוהות באופן לא צפוי.
    • אם אתם שולחים שאילתות על תקופות זמן מהזמן האחרון ויש לכם נתונים שמגיעים באיחור, יכול להיות ששאילתה אחת ביחס תופעל לפני שהנתונים יגיעו ושאילתה אחרת ביחס תופעל אחרי שהנתונים יגיעו.
    • אם אחד מהצדדים של היחס מורכב ממספר קטן יחסית של סדרות זמן, כל שגיאה תוגדל. אם גם המונה וגם המכנה כוללים 100 סדרות עיתיות, ו-Monarch לא מחזירה סדרה עיתית אחת בשאילתת המונה, סביר להניח שתבחינו בהבדל של 1%. אם למונה ולמכנה יש כל אחד מיליון סדרות זמן, ו-Monarch לא מחזירה סדרת זמן אחת בשאילתת המונה, סביר להניח שלא תבחינו בהבדל של 0.0001%.

  • אם הנתונים שלכם דלילים, כדאי להשתמש במשך זמן ארוך יותר בשאילתה. אם הנתונים מגיעים כל 10 דקות והשאילתה משתמשת ב-rate(metric[1m]), השאילתה מחפשת נתונים רק בדקה האחרונה, ולפעמים התוצאות ריקות. ככלל, מומלץ להגדיר את [duration] כך שיהיה לפחות פי 4 ממרווח הזמן של החיפוש.

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

ההמלצות האלה רלוונטיות בעיקר אם אתם רואים תוצאות שאילתות לא עקביות כשאתם שולחים שאילתות לגבי נתונים מהזמן האחרון. אם הבעיה הזו מתרחשת כשמבצעים שאילתה על נתונים בני יותר מ-25 שעות, יכול להיות שיש בעיה טכנית ב-Monarch. במקרה כזה, צריך לפנות ל-Cloud Customer Care כדי שנוכל לבדוק את הנושא.

ייבוא מרכזי בקרה של Grafana

מידע על שימוש בכלי לייבוא לוחות בקרה ופתרון בעיות שקשורות אליו זמין במאמר ייבוא לוחות בקרה של Grafana ל-Cloud Monitoring.

מידע על בעיות בהמרת התוכן של לוח הבקרה מופיע בקובץ README של הכלי לייבוא.

בעיות בצד הקליטה

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

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

באשכולות GKE Autopilot, אפשר להריץ את הפקודות הבאות:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

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

סטטוס נקודת הקצה חסר או ישן מדי

אם הפעלתם את התכונה 'סטטוס יעד', אבל באחד או יותר מהמשאבים של PodMonitoring או ClusterPodMonitoring חסר השדה Status.Endpoint Statuses או הערך שלו, יכול להיות שנתקלתם באחת מהבעיות הבאות:

  • שירות מנוהל ל-Prometheus לא הצליח להגיע לאוסף באותו צומת כמו אחת מנקודות הקצה שלכם.
  • אחת או יותר מההגדרות של PodMonitoring או ClusterPodMonitoring לא הניבו יעדים תקינים.

בעיות דומות יכולות גם לגרום לכך שהערך בשדה Status.Endpoint Statuses.Last Update Time יהיה ישן יותר מכמה דקות בתוספת מרווח הזמן בין הסריקות.

כדי לפתור את הבעיה, קודם צריך לוודא שה-pods של Kubernetes שמשויכים לנקודת הקצה של הגירוד פועלים. אם הפודים של Kubernetes פועלים, סלקטורי התוויות תואמים ואפשר לגשת ידנית לנקודות הקצה (endpoint) של הגירוד (בדרך כלל על ידי כניסה לנקודת הקצה /metrics), צריך לבדוק אם ה-Collectors של שירות מנוהל ל-Prometheus פועלים.

השבר של האספן קטן מ-1

אם הפעלתם את התכונה 'סטטוס היעדים', תקבלו מידע על סטטוס הנכסים. הערך Status.Endpoint Statuses.Collectors Fraction של משאבי PodMonitoring או ClusterPodMonitoring מייצג את החלק היחסי של האוספים, שמוצג מ-0 עד 1, שאפשר להגיע אליהם. לדוגמה, ערך של 0.5 מציין שאפשר להגיע ל-50% מהמשתמשים שאוספים, וערך של 1 מציין שאפשר להגיע ל-100% מהמשתמשים שאוספים.

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

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

באשכולות GKE Autopilot, הפקודה הזו נראית קצת אחרת:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

כדי לבדוק פודים ספציפיים של איסוף נתונים (לדוגמה, פוד של איסוף נתונים בשם collector-12345), משתמשים בפקודה הבאה:

kubectl -n gmp-system describe pods/collector-12345

באשכולות GKE Autopilot, מריצים את הפקודה הבאה:

kubectl -n gke-gmp-system describe pods/collector-12345

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

אם המאספים תקינים, צריך לבדוק את יומני האופרטור. כדי לבדוק את היומנים של האופרטור, קודם מריצים את הפקודה הבאה כדי למצוא את שם ה-pod של האופרטור:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

באשכולות GKE Autopilot, מריצים את הפקודה הבאה:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

לאחר מכן, בודקים את היומנים של האופרטור (לדוגמה, פוד של אופרטור בשם gmp-operator-12345) באמצעות הפקודה הבאה:

kubectl -n gmp-system logs pods/gmp-operator-12345

באשכולות GKE Autopilot, מריצים את הפקודה הבאה:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

יעדים לא תקינים

אם הפעלתם את התכונה 'סטטוס היעד', אבל אחד או יותר מהמשאבים של PodMonitoring או ClusterPodMonitoring כוללים את השדה Status.Endpoint Statuses.Unhealthy Targets עם ערך שאינו 0, המשמעות היא שהאוסף לא יכול לבצע גירוד של אחד או יותר מהיעדים.

צופים בשדה Sample Groups, שבו הקבוצות ממוקדות לפי הודעת השגיאה, ומחפשים את השדה Last Error. השדה Last Error מגיע מ-Prometheus ומציין למה לא הייתה אפשרות לבצע סקראפינג של היעד. כדי לפתור את הבעיה, צריך להשתמש ביעדים לדוגמה כהפניה ולבדוק אם נקודות הקצה של הגירוד פועלות.

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

אם אתם רואים אחת מהשגיאות הבאות ויעד הגירוד שלכם דורש הרשאה, סימן שאמצעי האיסוף לא מוגדר לשימוש בסוג ההרשאה הנכון או שהוא משתמש במטען ייעודי (payload) שגוי של הרשאה:

  • server returned HTTP status 401 Unauthorized
  • x509: certificate signed by unknown authority

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

חריגה מהמכסה

אם הודעת השגיאה הבאה מופיעה, סימן שחרגתם ממכסת ההטמעה של Cloud Monitoring API:

  • ‫"429: חריגה מהמכסה של מדד המכסה 'בקשות להוספת נתוני סדרות זמן' והמגבלה 'בקשות להוספת נתוני סדרות זמן בדקה' של השירות 'monitoring.googleapis.com' עבור הצרכן 'project_number:PROJECT_NUMBER'., rateLimitExceeded"

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

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

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

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

  • ‫"execute query: Error querying Prometheus: client_error: client error: 403"
  • ‫"Readiness probe failed: HTTP probe failed with statuscode: 503"
  • ‫"Error querying Prometheus instance" (שגיאה בשאילתת נתונים במופע Prometheus)

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

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

  • מזהים את שם הצומת הבסיסי של Compute Engine, ואז מריצים את הפקודה הבאה:

    gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts

    מחפשים את המחרוזת https://www.googleapis.com/auth/monitoring. אם צריך, מוסיפים את Monitoring כמו שמתואר במאמר בנושא חשבון שירות עם הגדרה שגויה.

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

    1. נכנסים לדף Kubernetes clusters במסוף Google Cloud .

      כניסה אל Kubernetes clusters

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

    2. בוחרים באפשרות צמתים ואז לוחצים על שם הצומת בטבלה צמתים.

    3. לוחצים על פרטים.

    4. לוחצים על הקישור VM Instance.

    5. מחפשים את החלונית API וניהול זהויות ולוחצים על הצגת פרטים.

    6. מחפשים את Stackdriver Monitoring API עם גישה מלאה.

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

חשבון שירות שההגדרה שלו שגויה

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

  • ‫"code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (or the resource may not exist)"
  • ‫"google: could not find default credentials. מידע נוסף זמין בכתובת https://developers.google.com/accounts/docs/application-default-credentials."

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

  1. נכנסים לדף IAM במסוף Google Cloud :

    כניסה לדף IAM

    אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים בתוצאה שמופיע בה הכותרת המשנית IAM & Admin.

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

  3. בוחרים בשדה תפקיד, לוחצים על בשימוש כרגע ומחפשים את התפקיד Monitoring Metric Writer או Monitoring Editor. אם לחשבון השירות לא הוקצה אחד מהתפקידים האלה, צריך להקצות לו את התפקיד כותב מדדים של Monitoring ‏ (roles/monitoring.metricWriter).

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

חשבונות שירות מוגבלים בדרך כלל לפרויקט אחד. Google Cloud שימוש בחשבון שירות אחד כדי לכתוב נתוני מדדים למספר פרויקטים – לדוגמה, כשמעריך כללים מנוהל שולח שאילתה להיקף מדדים של כמה פרויקטים – עלול לגרום לשגיאת ההרשאה הזו. אם אתם משתמשים בחשבון השירות שמוגדר כברירת מחדל, כדאי להגדיר חשבון שירות ייעודי כדי שתוכלו להוסיף את ההרשאה monitoring.timeSeries.create לכמה פרויקטים בצורה בטוחה. אם אין לכם אפשרות להעניק את ההרשאה הזו, תוכלו להשתמש בשינוי שם של מדד כדי לשנות את השם של התווית project_id. מזהה הפרויקט יוגדר כברירת מחדל לפרויקט שבו פועל שרת Prometheus או כלי להערכת כללים. Google Cloud

הגדרת הגירוד לא תקינה

אם מופיעה השגיאה הבאה, המשמעות היא שהפורמט של PodMonitoring או ClusterPodMonitoring לא תקין:

  • "אירעה שגיאה פנימית: הקריאה ל-webhook נכשלה "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

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

לא מתבצעת סקירה של נתיבי מדדים עם פרמטרים של שאילתת HTTP

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

    path: /metrics/detailed?family=queue_metrics&family=queue_consumer_count

הסיבה לכך שהמדד לא נסרק היא ש-Prometheus מקודד את כתובת ה-URL של סימן השאלה (?) כ-%3F, ולכן הנתונים נשלחים לכתובת /metrics/detailed%3Ffamily=queue_metrics&family=queue_consumer_count במקום.

כדי לפתור את הבעיה, צריך להשתמש בשדה params. לדוגמה, אם המדד הוא /metrics/detailed?family=queue_metrics&family=queue_consumer_count, מגדירים את תצורת הגירוד באופן הבא:

    path: /metrics/detailed
    params:
      family: ['queue_metrics', 'queue_consumer_count']

ה-webhook של הגישה לא הצליח לנתח את ההגדרה של לקוח ה-HTTP או שההגדרה לא תקינה

בגרסאות של שירות מנוהל ל-Prometheus מגרסה 0.12 ומטה, יכול להיות שתופיע שגיאה דומה לזו שבהמשך, שקשורה להחדרת סוד במרחב השמות שאינו ברירת המחדל:

  • ‪"admission webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" denied the request: invalid definition for endpoint with index 0: unable to parse or invalid Prometheus HTTP client config: must use namespace "my-custom-namespace", got: "default""

כדי לפתור את הבעיה, צריך לשדרג לגרסה 0.12 ואילך.

בעיות במרווחי גירוד ובפסק זמן

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

kubectl -n gmp-system logs ds/collector prometheus

באשכולות GKE Autopilot, מריצים את הפקודה הבאה:

kubectl -n gke-gmp-system logs ds/collector prometheus

מחפשים את ההודעה הזו:

  • "scrape timeout greater than scrape interval for scrape config with job name "PodMonitoring/gmp-system/example-app/go-metrics""

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

חסר TYPE במדד

אם השגיאה הבאה מופיעה, סימן שחסר מידע על סוג המדד:

  • ‫"no metadata found for metric name "{metric_name}""

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

# TYPE {metric_name} <type>

ספריות מסוימות, כמו אלה מ-VictoriaMetrics בגרסה ישנה יותר מ-1.28.0, משמיטות את פרטי הסוג בכוונה. הספריות האלה לא נתמכות על ידי השירות המנוהל ל-Prometheus.

התנגשויות בסדרות זמן

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

  • ‫"One or more TimeSeries could not be written: One or more points were written more frequently than the maximum sampling period configured for the metric."
  • ‫"One or more TimeSeries could not be written: Points must be written in order. אחת או יותר מהנקודות שצוינו כללו שעת סיום מוקדמת יותר מהנקודה האחרונה."

הסיבות הנפוצות ביותר והפתרונות:

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

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

  • שימוש בכללי תיוג מחדש, במיוחד כללים שפועלים על משימות או על מופעים. שירות מנוהל ל-Prometheus מזהה באופן חלקי סדרת זמן ייחודית באמצעות השילוב של התוויות {project_id, location, cluster, namespace, job, instance}. שימוש בכלל לשינוי תוויות כדי להסיר את התוויות האלה, במיוחד התוויות job ו-instance, עלול לגרום לעיתים קרובות להתנגשויות. לא מומלץ לשכתב את התוויות האלה.

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

סיבה פחות נפוצה להתנגשויות בסדרות זמן היא שימוש במרווח גירוד קצר מ-5 שניות. מרווח הגירוד המינימלי שנתמך בשירות המנוהל ל-Prometheus הוא 5 שניות.

חריגה מהמגבלה על מספר התוויות

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

  • ‫"One or more TimeSeries could not be written: The new labels would cause the metric prometheus.googleapis.com/METRIC_NAME to have over PER_PROJECT_LIMIT labels".

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

יש שלושה שלבים לפתרון הבעיה:

  1. לזהות למה למדד מסוים יש יותר מדי תוויות או למה התוויות משתנות לעיתים קרובות.

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

  3. מוחקים את תיאור המדד של המדד הזה (מה שגורם לאובדן נתונים), כדי שאפשר יהיה ליצור אותו מחדש עם קבוצה קטנה ויציבה יותר של תוויות. אפשר להשתמש ב-metricDescriptors.delete method כדי לעשות זאת.

הסיבות הנפוצות ביותר לבעיה הן:

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

    כדי לפתור את הבעיה, אפשר להשתמש בקטע metricRelabeling ב-PodMonitoring כדי לשמור או להסיר תוויות. חלק מהאפליקציות והכלי לייצוא מאפשרים גם הגדרה שמשנה את המדדים שמיוצאים. לדוגמה, ל-cAdvisor יש מספר הגדרות מתקדמות של זמן ריצה שיכולות להוסיף תוויות באופן דינמי. כשמשתמשים באיסוף מנוהל, מומלץ להשתמש באיסוף kubelet אוטומטי המובנה.

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

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

מגבלות קצב על יצירה ועדכון של מדדים ותוויות

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

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

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

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

מגבלות על מספר תיאורי המדדים

אם מופיעה השגיאה הבאה, סימן שהגעתם למכסת מספר תיאורי המדדים בפרויקטGoogle Cloud :

  • "מיצית את המיכסה של תיאורי המדדים".

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

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

‫Cloud Monitoring וגם השירות המנוהל ל-Prometheus לא תומכים במדדים לא ממדיים, כמו אלה שמפורמטים ל-StatsD או ל-Graphite. למרות שרוב כלי הייצוא של Prometheus מוגדרים בצורה נכונה כברירת מחדל, יש כלי ייצוא מסוימים, כמו כלי הייצוא StatsD, כלי הייצוא Vault או Envoy Proxy שמגיע עם Istio, שצריך להגדיר אותם באופן מפורש לשימוש בתוויות במקום להטמיע מידע בשם המדד. דוגמאות לשמות מדדים לא תקינים:

  • request_path_____path_to_a_resource____istio_request_duration_milliseconds
  • envoy_cluster_grpc_method_name_failure
  • envoy_cluster_clustername_upstream_cx_connect_ms_bucket
  • vault_rollback_attempt_path_name_1700683024
  • service__________________________________________latency_bucket

כדי לוודא שזו הבעיה:

  1. במסוף Google Cloud , בוחרים את הפרויקט Google Cloud שמקושר לשגיאה.

  2. נכנסים לדף  Metrics management במסוף Google Cloud :

    נכנסים אל ניהול מדדים.

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

  3. מוודאים שסכום המדדים 'פעיל' ו'לא פעיל' גדול מ-25,000. ברוב המקרים, אמור להופיע מספר גדול של מדדים לא פעילים.
  4. בוחרים באפשרות 'לא פעיל' בחלונית 'מסננים מהירים', עוברים בין הדפים ברשימה ומחפשים דפוסים.
  5. בחלונית 'מסננים מהירים', בוחרים באפשרות 'פעיל', ממיינים את הרשימה לפי נפח דגימות לחיוב בסדר יורד, עוברים בין הדפים ומחפשים דפוסים.
  6. ממיינים לפי Samples נפח ניתן לחיוב בסדר עולה, עוברים בין הדפים ברשימה ומחפשים דפוסים.

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

  1. במסוף Google Cloud , בוחרים את הפרויקט Google Cloud שמקושר לשגיאה.

  2. נכנסים לדף  Metrics explorer במסוף Google Cloud :

    כניסה אל Metrics Explorer

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

  3. בכלי ליצירת שאילתות, לוחצים על 'בחירת מדד' ואז מבטלים את הסימון של התיבה 'פעיל'.
  4. מקלידים 'prometheus' בסרגל החיפוש.
  5. מחפשים דפוסים בשמות של מדדים.

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

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

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

חלק מהמדדים חסרים ביעדים שפועלים לזמן קצר

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

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

  1. מאתרים את קובץ ה-yaml של פריסת משימת ה-cron ואת הסטטוס, שמופיע בסוף הקובץ. הסטטוס בדוגמה הזו מראה שהעבודה רצה במשך דקה אחת:

      status:
    lastScheduleTime: "2024-04-03T16:20:00Z"
    lastSuccessfulTime: "2024-04-03T16:21:07Z"

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

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

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

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

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

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

בעיות בגבייה מיצואנים

אם המדדים שלכם מתוך כלי לייצוא לא נקלטים, כדאי לבדוק את הדברים הבאים:

  • כדי לוודא שהכלי לייצוא פועל ומייצא מדדים, משתמשים בפקודה kubectl port-forward.

    לדוגמה, כדי לבדוק שפודים עם הבורר app.kubernetes.io/name=redis במרחב השמות test שולחים מדדים בנקודת הקצה /metrics ביציאה 9121, אפשר להפנות את היציאה באופן הבא:

    kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" -n test 9121

    כדי לוודא שהמדדים נחשפים על ידי הכלי לייצוא לצורך גירוד, ניגשים לנקודת הקצה localhost:9121/metrics באמצעות הדפדפן או curl בסשן מסוף אחר.

  • בודקים אם אפשר לשלוח שאילתה למדדים ב Google Cloud מסוף, אבל לא ב-Grafana. אם כן, הבעיה היא ב-Grafana ולא באיסוף המדדים.

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

    1. מזהים את האוסף המנוהל שפועל באותו צומת שבו פועל האקספורטר. לדוגמה, אם תהליך הייצוא פועל ב-pods במרחב השמות test וה-pods מסומנים בתווית app.kubernetes.io/name=redis, הפקודה הבאה מזהה את האוסף המנוהל שפועל באותו הצומת:

      kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'

    2. מגדירים העברה ליציאה אחרת מיציאה 19090 של המאסף המנוהל:

      kubectl port-forward POD_NAME -n gmp-system 19090

    3. עוברים לכתובת ה-URL localhost:19090/targets כדי לגשת לממשק האינטרנט. אם רכיב הייצוא מופיע כאחד מהיעדים, המשמעות היא שהאוסף המנוהל מבצע גירוד של רכיב הייצוא בהצלחה.

שגיאות Collector Out Of Memory ‏ (OOM)

אם אתם משתמשים באיסוף מנוהל ונתקלים בשגיאות Out Of Memory (OOM) במאספים, כדאי להפעיל את התכונה 'שינוי גודל אוטומטי של פודים אנכיים'.

שגיאות Operator Out Of Memory ‏ (OOM)

אם אתם משתמשים באוסף מנוהל ונתקלים בשגיאות Out Of Memory (OOM) באופרטור, כדאי להשבית את התכונה 'סטטוס היעד'. התכונה 'סטטוס היעד' עלולה לגרום לבעיות בביצועים של האופרטור באשכולות גדולים יותר.

יותר מדי סדרות עיתיות או עלייה במספר התגובות מסוג 503 והשגיאות מסוג 'חריגה מהזמן הקצוב להקשר', במיוחד בזמן עומס שיא

יכול להיות שאתם נתקלים בבעיה הזו אם מופיעה הודעת השגיאה הבאה:

  • ‫"Monitored resource (abcdefg) has too many time series (prometheus metrics)‎" (למשאב שבמעקב (abcdefg) יש יותר מדי סדרות זמן (מדדי Prometheus))

השגיאה 'חריגה מהזמן הקצוב לתגובה בהקשר' היא שגיאת 503 כללית שמוחזרת מ-Monarch לכל בעיה בצד הקליטה שאין לה סיבה ספציפית. בשימוש רגיל במערכת, צפוי מספר קטן מאוד של שגיאות מסוג 'חריגה מהזמן הקצוב לתגובה בהקשר'.

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

  • שגיאות מסוג Context deadline exceeded (חריגה מהזמן הקצוב להקשר) מופיעות בדפוס מחזורי, והן גדלות בזמנים של עומס גבוה אצלכם או בזמנים של עומס גבוה באזור Google Cloud שצוין בתווית location.
  • ככל שמוסיפים יותר נפח של מדדים לשירות, רואים יותר שגיאות.
  • אתם משתמשים ב-statsd_exporter ל-Prometheus, ב-Envoy ל-Istio, ב-SNMP exporter, ב-Prometheus Pushgateway, ב-kube-state-metrics, או שיש לכם exporter דומה אחר שמתווך ומדווח על מדדים בשם משאבים אחרים שפועלים בסביבה שלכם. הבעיה מתרחשת רק במדדים שמופקים על ידי סוג כלי הייצוא הזה.
  • שמתם לב שבדרך כלל במדדים המושפעים מופיעה המחרוזת localhost בערך של התווית instance, או שיש מעט מאוד ערכים לתווית instance.
  • אם יש לכם גישה לממשק המשתמש של שאילתת האוסף של Prometheus בתוך האשכול, תוכלו לראות שהמדדים נאספים בהצלחה.

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

‫Monarch מתרחב על ידי אחסון נתונים קשורים יחד ביעד. יעד בשירות המנוהל ל-Prometheus מוגדר לפי סוג המשאב prometheus_target והתוויות project_id, location, cluster, namespace, job ו-instance. מידע נוסף על התוויות האלה ועל התנהגות ברירת המחדל זמין במאמר תוויות שמורות באוסף מנוהל או במאמר תוויות שמורות באוסף בהטמעה עצמית.

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

עם זאת, יכול להיות שהלוגיקה שמוגדרת כברירת מחדל תיכשל כשמריצים כלי לייצוא שמדווח על מדדים בשם משאבים אחרים באשכול, כמו statsd_exporter. במקום להגדיר את הערך של instance לכתובת ה-IP:port של המשאב שפולט את המדד, הערך של instance מוגדר לכתובת ה-IP:port של statsd_exporter עצמו. הבעיה יכולה להיות חמורה יותר אם משתמשים בתווית job, כי במקום להתייחס לחבילת המדדים או לשירות, היא גם לא מגוונת כי היא מוגדרת כ-statsd-exporter.

במקרה כזה, כל המדדים שמגיעים מהכלי הזה לייצוא בתוך אשכול ומרחב שמות נתון נכתבים לאותו יעד ב-Monarch. ככל שהיעד הזה גדל, פעולות הכתיבה מתחילות להיכשל ומוצגות יותר שגיאות 503 מסוג Context deadline exceeded.

כדי לוודא שזה קורה לכם, אפשר לפנות ל-Cloud Customer Care ולבקש מהם לבדוק את 'יומני האשפוז של Monarch Quarantiner'. צריך לכלול בכרטיס את כל הערכים הידועים של שש התוויות השמורות. חשוב לדווח על Google Cloud הפרויקט ששולח את הנתונים, ולא על Google Cloud הפרויקט של היקף המדדים.

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

  • במקום להפעיל כלי ייצוא מרכזי שמדווח על מדדים בשם כל המכונות הווירטואליות או הצמתים, מפעילים כלי ייצוא נפרד לכל מכונה וירטואלית כסוכן צומת או על ידי פריסת כלי הייצוא כ-Daemonset של Kubernetes. כדי למנוע הגדרה של התווית instance לערך localhost, אל תפעילו את הכלי לייצוא באותו צומת שבו פועל האוסף.
    • אם אחרי חלוקת הנתונים של כלי הייצוא עדיין צריך יותר מטרות מגוונות, מריצים כמה כלי ייצוא בכל מכונה וירטואלית ומקצים באופן לוגי קבוצות שונות של מדדים לכל כלי ייצוא. במקום לגלות את העבודה באמצעות השם הסטטי statsd-exporter, צריך להשתמש בשם עבודה אחר לכל קבוצה לוגית של מדדים. מופעים עם ערכים שונים של job מוקצים ליעדים שונים ב-Monarch.
    • אם אתם משתמשים ב-kube-state-metrics, כדאי להשתמש בחלוקה אופקית מובנית כדי ליצור מגוון רחב יותר של יעדים. יכול להיות שלכלי ייצוא אחרים יש יכולות דומות.
  • אם אתם משתמשים ב-OpenTelemetry או באיסוף שמוגדר עצמאית, אתם יכולים להשתמש בכלל של תיוג מחדש כדי לשנות את הערך של instance מכתובת ה-IP:היציאה או מהשם של רכיב ה-exporter לכתובת ה-IP:היציאה או לשם הייחודי של המשאב שמייצר את המדדים. סביר מאוד שכבר מתבצעת אצלכם שמירה של כתובת ה-IP:היציאה או של השם של משאב המקור כתווית מדדים. בנוסף, צריך להגדיר את השדה honor_labels לערך true בהגדרות של Prometheus או OpenTelemetry.
  • אם אתם משתמשים ב-OpenTelemetry או באיסוף שמוגדר עצמאית, אתם יכולים להשתמש בכלל של שינוי תוויות עם פונקציית hashmod כדי להפעיל כמה משימות גירוד מול אותו רכיב exporter, ולוודא שתווית מופע שונה נבחרת לכל הגדרת גירוד.

קטגוריות כפולות בנקודה בהיסטוגרמה

יכול להיות שאתם נתקלים בבעיה הזו אם מופיעה הודעת השגיאה הבאה:

  • ‫"Field points[0].distributionValue had an invalid value: Distribution |explicit_buckets.bounds| entry 1 has a value of 1 which is less than the value of entry 0 which is 1"

הסיבה לכך היא שיש שני נקודות בהיסטוגרמה בכלי הייצוא עם אותו סט תוויות בדיוק. יכולות להיות לכך כמה סיבות:

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

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

אם יש היסטוגרמות עם תוויות כפולות בנקודת קצה אחת של /metrics, ההיסטוגרמה הממוזגת שמתקבלת כוללת שני buckets עם אותו ערך le. השגיאה הזו מוחזרת על ידי ה-API כי הערכים של bucket le צריכים להיות ייחודיים ולסודרים בסדר עולה.

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

אין שגיאות ואין מדדים

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

כדי לזהות אם זו הסיבה, מנסים לפרוס את האפליקציה לדוגמה ואת משאב PodMonitoring לדוגמה. אם עכשיו מופיע הערך up (יכול להיות שיעברו כמה דקות עד שהוא יופיע), הבעיה היא בהגדרות או בכלי לייצוא.

יכולות להיות לכך כמה סיבות. מומלץ לבדוק את הדברים הבאים:

  • ההפניה של PodMonitoring היא ליציאה תקפה.

  • היציאות ב-Deployment spec של הכלי לייצוא קיבלו שמות נכונים.

  • הסלקטורים (בדרך כלל app) תואמים למשאבי הפריסה ולמשאבי PodMonitoring.

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

  • התקנתם את משאב PodMonitoring באותו מרחב שמות כמו האפליקציה שאתם רוצים לבצע לה גירוד. אל תתקינו משאבים או אפליקציות בהתאמה אישית במרחב השמות gmp-system או gke-gmp-system.

  • השמות של המדדים והתוויות תואמים לביטוי הרגולרי התקף של Prometheus. שירות מנוהל ל-Prometheus לא תומך בשמות של תוויות שמתחילים בתו _.

  • אתם לא משתמשים בקבוצת מסננים שגורמת לסינון של כל הנתונים. חשוב להיזהר שלא יהיו מסננים סותרים כשמשתמשים במסנן collection במשאב OperatorConfig.

  • אם הפעולה מתבצעת מחוץ ל- Google Cloud, צריך להגדיר את project או project-id לפרויקט Google Cloud תקף ואת location לאזור Google Cloud תקף. אי אפשר להשתמש בערך global בשדה location.

  • המדד הוא אחד מארבעת סוגי המדדים של Prometheus. ספריות מסוימות, כמו Kube State Metrics, חושפות סוגי מדדים של OpenMetrics כמו Info,‏ Stateset ו-GaugeHistogram, אבל סוגי המדדים האלה לא נתמכים על ידי Managed Service for Prometheus ומוסרים ללא הודעה.

חומות אש

חומת אש יכולה לגרום לבעיות בהטמעה ובשאילתות. צריך להגדיר את חומת האש כך שתאפשר בקשות POST ו-GET לשירות Monitoring API, ‏ monitoring.googleapis.com, כדי לאפשר קליטה ושאילתות.

שגיאה לגבי עריכות בו-זמניות

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

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

שאילתות שנחסמו ובוטלו על ידי Monarch

אם מופיעה השגיאה הבאה, הגעתם למגבלה הפנימית של מספר השאילתות שניתן להריץ בו-זמנית עבור פרויקט נתון:

  • "internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500."

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

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

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

כדי לפתור את הבעיה, צריך להגדיל את מרווח ההערכה של כללי החיפוש לאחור כדי שהם לא יפעלו כל דקה. אין צורך להריץ שאילתה לגבי שיעור של 4 שבועות כל דקה. יש 40,320 דקות ב-4 שבועות, כך שכל דקה לא מספקת כמעט שום אות נוסף (הנתונים משתנים לכל היותר ב-1/40,320). שימוש במרווח הערכה של שעה אחת אמור להספיק לשאילתה שמבקשת שיעור של 4 שבועות.

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

סוגי ערכים לא תואמים

אם השגיאה הבאה מופיעה במהלך ההטמעה או השאילתה, סימן שיש אי התאמה בסוג הערך של המדדים:

  • ‫"Value type for metric prometheus.googleapis.com/metric_name/gauge must be INT64, but is DOUBLE"
  • ‫"Value type for metric prometheus.googleapis.com/metric_name/gauge must be DOUBLE, but is INT64"
  • ‫"One or more TimeSeries could not be written: Value type for metric prometheus.googleapis.com/target_info/gauge conflicts with the existing value type (INT64)"

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

השגיאה הזו מתרחשת רק כשמשתמשים ב-OpenTelemetry collectors כדי לדווח על נתונים, והיא סביר שתתרחש אם משתמשים גם ב-OpenTelemetry (באמצעות googlemanagedprometheus exporter) וגם ב-Prometheus כדי לדווח על נתונים של אותו מדד, כמו שקורה בדרך כלל במדד target_info.

הסיבה לכך היא כנראה אחת מהסיבות הבאות:

  • אתם אוספים מדדי OTLP, וספריית מדדי OTLP שינתה את סוג הערך שלה מ-DOUBLE ל-INT64, כמו שקרה עם מדדי Java של OpenTelemetry. הגרסה החדשה של ספריית המדדים לא תואמת יותר לסוג ערך המדד שנוצר על ידי הגרסה הישנה של ספריית המדדים.
  • אתם אוספים את המדד target_info באמצעות Prometheus ו-OpenTelemetry. ‫Prometheus אוסף את המדד הזה כ-DOUBLE, ואילו OpenTelemetry אוסף את המדד הזה כ-INT64. האיסוף שלכם כותב עכשיו שני סוגי ערכים לאותו מדד באותו פרויקט, ורק האיסוף שיצר את תיאור המדד בהתחלה מצליח.
  • אתם אוספים את target_info באמצעות OpenTelemetry כ-INT64 בפרויקט אחד, ואתם אוספים את target_info באמצעות Prometheus כ-DOUBLE בפרויקט אחר. אם מוסיפים את שני המדדים לאותו היקף המדדים בפרויקט, ואז שולחים שאילתה לגבי המדד הזה דרך היקף המדדים בפרויקט, מתקבל איחוד לא תקין בין סוגים לא תואמים של ערכי מדדים.

כדי לפתור את הבעיה הזו, צריך להגדיר את כל סוגי הערכים של המדדים כ-DOUBLE. לשם כך:

  1. מגדירים מחדש את OpenTelemetry Collectors כך שכל המדדים יהיו מסוג DOUBLE. לשם כך, מפעילים את הדגל feature-gate exporter.googlemanagedprometheus.intToDouble.
  2. מחיקת כל תיאורי המדדים מסוג INT64 ומתן אפשרות ליצירה מחדש שלהם כמדדים מסוג DOUBLE. אפשר להשתמש בסקריפט delete_metric_descriptors.go כדי לבצע את הפעולה הזו באופן אוטומטי.

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