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

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

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

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

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

לא ניתן להציג את היומנים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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