פתרון בעיות בלוחות בקרה למעקב

אם אתם לא רואים את לוחות הבקרה למעקב אחרי Google Kubernetes Engine‏ (GKE) ב-Cloud Monitoring, או אם נראה שחסרים בהם נתונים, יכול להיות שלא תוכלו לראות בעיות באשכולות ובעומסי העבודה שלכם ולהגיב להן.

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

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

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

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

אין משאבים ב-Kubernetes בלוח הבקרה שלי

אם לא מוצגים משאבי Kubernetes במרכז הבקרה של GKE, כדאי לבדוק את הדברים הבאים:

הפרויקט שנבחר: Google Cloud

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

פעילות באשכולות

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

טווח תאריכים

יכול להיות שטווח התאריכים שבחרתם צר מדי. אפשר להשתמש בתפריט Time בסרגל הכלים של לוח הבקרה כדי לבחור טווחי תאריכים אחרים או להגדיר טווח Custom.

הרשאות לצפייה בלוח הבקרה

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

  • You do not have sufficient permissions to view this page
  • You don't have permissions to perform the action on the selected resources

פרטים נוספים זמינים במאמר בנושא תפקידים מוגדרים מראש.

הרשאות של חשבון שירות של אשכול וצומת לכתיבת נתונים ל-Monitoring ול-Logging

אם רואים שיעורי שגיאות גבוהים בדף Enabled APIs and services במסוף Google Cloud , יכול להיות שחשבון השירות לא כולל את התפקידים הבאים:

  • ‫roles/logging.logWriter: במסוף Google Cloud , התפקיד הזה נקרא Logs Writer. מידע נוסף על תפקידים ב-Logging אפשר למצוא במדריך בקרת הגישה ל-Logging.

  • ‫roles/monitoring.metricWriter: במסוף Google Cloud , התפקיד הזה נקרא Monitoring Metric Writer. מידע נוסף על תפקידים ב-Monitoring זמין במדריך בקרת הגישה ב-Monitoring.

  • ‫roles/stackdriver.resourceMetadata.writer: במסוף Google Cloud , התפקיד הזה נקרא Stackdriver Resource Metadata Writer. התפקיד הזה מאפשר גישת כתיבה בלבד למטא-נתונים של משאבים, והוא מספק בדיוק את ההרשאות שסוכנים צריכים כדי לשלוח מטא-נתונים. מידע נוסף על תפקידי ניטור זמין במדריך בקרת הגישה לניטור.

כדי לראות רשימה של חשבונות השירות, במסוף Google Cloud עוברים אל IAM ואדמין ובוחרים באפשרות חשבונות שירות.

לא ניתן לראות את היומנים

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

הסוכן פועל ותקין

בגרסה 1.17 של GKE ואילך, המערכת משתמשת ב-Fluent Bit כדי לתעד יומנים. ‫Fluent Bit הוא סוכן Logging שפועל בצומתי Kubernetes. כדי לבדוק אם הסוכן פועל בצורה תקינה, פועלים לפי השלבים הבאים:

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

    kubectl get pods -l k8s-app=fluentbit-gke -n kube-system

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

    NAME                  READY   STATUS    RESTARTS   AGE
fluentbit-gke-6zr6g   2/2     Running   0          44d
fluentbit-gke-dzh9l   2/2     Running   0          44d

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

    JSONPATH='{range .items[*]};{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status},{end}{end};'  \
 && kubectl get pods -l k8s-app=fluentbit-gke -n kube-system -o jsonpath="$JSONPATH" | tr ";" "\n"

    אם הפריסה תקינה, הפלט ייראה כך:

    fluentbit-gke-nj4qs:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,
fluentbit-gke-xtcvt:Initialized=True,Ready=True,ContainersReady=True,PodScheduled=True,

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

    kubectl get daemonset -l k8s-app=fluentbit-gke -n kube-system

    אם הפריסה תקינה, הפלט ייראה כך:

    NAME            DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR            AGE
fluentbit-gke   2         2         2       2            2           kubernetes.io/os=linux   5d19h

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

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

הסוכן עמוס מדי ומשמיט יומנים

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

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

  • בודקים את המדד kubernetes.io/container/cpu/core_usage_time עם המסנן container_name=fluentbit-gke כדי לראות אם השימוש במעבד (CPU) של סוכן Logging קרוב ל-100% או הגיע ל-100%.

  • כדי לבדוק אם צומת כלשהו מגיע ל-100KiB לשנייה, אפשר להציג את המדד logging.googleapis.com/byte_count מקובץ לפי metadata.system_labels.node_name.

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

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

האירוע לא משויך למשאב GKE?

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

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

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

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

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

המאמרים הבאים