‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

פתרון בעיות שקשורות לניראות

במאמר הזה מוסבר איך לזהות כשלים בפריסה ואירועים תפעוליים שאתם עשויים להיתקל בהם במכשיר Google Distributed Cloud ‏ (GDC) עם בידוד פיזי. בנוסף, מופיעים בו תיאורים של כל ההתראות שמוצגות במערכת, כדי לעזור לכם לפתור בעיות נפוצות ברכיבי הרישום ביומן והמעקב.

זיהוי רכיבי Observability

פלטפורמת ה-Observability פורסת את הרכיבים שלה במרחב השמות obs-system באשכול התשתית הארגונית.

מופע Grafana של Infrastructure Operator ‏ (IO) מספק גישה למדדים ברמת הארגון כדי לעקוב אחרי רכיבי תשתית כמו ניצול ה-CPU וצריכת האחסון. היא מספקת גם גישה ליומנים תפעוליים ויומני ביקורת. בנוסף, היא מאפשרת גישה להתראות, ליומנים ולמדדים מהרכיבים התפעוליים של GDC.

סטאק הרישום והמעקב של GDC משתמש בפתרונות קוד פתוח כחלק מפלטפורמת ה-Observability. הרכיבים האלה אוספים יומנים ומדדים מ-Pods של Kubernetes, ממכונות Bare Metal, ממתגי רשת, מאחסון וממשירות מנוהלים.

בטבלה הבאה מפורטים כל הרכיבים שמשולבים בפלטפורמת Observability:

רכיב	תיאור
`Prometheus`	‫Prometheus הוא מסד נתונים של סדרות זמן לאיסוף ולאחסון של מדדים ולהערכה של התראות. ‫Prometheus מאחסן מדדים במופע Cortex של אשכול התשתית של הארגון לאחסון לטווח ארוך. ‫Prometheus מוסיף תוויות כצמדי מפתח/ערך ואוסף מדדים מצמתים, מ-pods, ממכונות bare metal, ממפסקי רשת וממכשירי אחסון של Kubernetes.
`Alertmanager`	‫Alertmanager היא מערכת ניהול שמוגדרת על ידי המשתמש ושולחת התראות כשיומנים או מדדים מצביעים על כך שרכיבי המערכת נכשלו או לא פועלים כרגיל. הוא מנהל את הניתוב, ההשתקה והצבירה של התראות Prometheus.
`Loki`	‫Loki הוא מסד נתונים של סדרות זמן שמאחסן ומצטבר יומנים ממקורות שונים. הוא יוצר אינדקס של יומנים כדי לאפשר שליחת שאילתות יעילה.
`Grafana`	‫Grafana מספק ממשק משתמש (UI) לצפייה במדדים שנאספים על ידי Prometheus ולשאילתות של יומני ביקורת ויומנים תפעוליים ממופעי Loki המתאימים. בממשק המשתמש אפשר לראות תצוגה חזותית של לוחות בקרה עם מדדים והתראות.
`Fluent Bit`	‫Fluent Bit הוא מעבד ששולף יומנים מרכיבים או ממיקומים שונים ושולח אותם אל Loki. הוא פועל בכל צומת של כל האשכולות.

זיהוי כשלים בפריסה

אם הפריסה פועלת ותקינה, הרכיבים פועלים במצב READY.

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

מאשרים את המצב הנוכחי של רכיב:
```
kubectl get -n obs-system TYPE/COMPONENT
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫TYPE: סוג הרכיב
- ‫COMPONENT: שם הרכיב
הפלט אמור להיראות כך:
```
NAME       READY  AGE
COMPONENT  1/1    23h
```
אם הרכיב תקין, בעמודה READY של הפלט מוצג הערך N/N. אם לא מוצג ערך בעמודה READY, זה לא בהכרח אומר שהפעולה נכשלה. יכול להיות שהשירות צריך עוד זמן לעיבוד.
בודקים את ה-pods בכל רכיב:
```
kubectl get pods -n obs-system | awk 'NR==1 | /COMPONENT/'
```
מחליפים את COMPONENT בשם הרכיב.

הפלט אמור להיראות כך:
```
NAME       READY  STATUS   RESTARTS  AGE
COMPONENT  1/1    Running  0         23h
```
מוודאים שהערך שמוצג בעמודה READY הוא N/N, שהערך שמוצג בעמודה STATUS הוא Running, ושמספר הערכים RESTARTS לא עולה על 2.

מספר גבוה של הפעלות מחדש מצביע על התסמינים הבאים:
- הפודים נכשלים ו-Kubernetes מפעיל אותם מחדש.
- בעמודה STATUS מוצג הערך CrashLoopBackoff.
כדי לפתור את הבעיה שגורמת לסטטוס 'נכשל', צריך לעיין ביומני הרישום של ה-pods.

אם הפוד נמצא במצב PENDING, המצב הזה מצביע על אחד או יותר מהסימפטומים הבאים:
- ה-Pod ממתין לגישה לרשת כדי להוריד את הקונטיינר הדרוש.
- בעיה בהגדרות מונעת את הפעלת ה-Pod. לדוגמה, חסר ערך Secret שה-pod דורש.
- לא נשארו משאבים באשכול Kubernetes לתזמון הפוד, וזה קורה אם הרבה אפליקציות פועלות באשכול.
איך מזהים את הגורם למצב PENDING:
```
kubectl describe -n obs-system pod/POD_NAME
```
מחליפים את POD_NAME בשם הפוד שמוצג בו הסטטוס PENDING.

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

הפלט הבא מציג קטע Events לדוגמה של אובייקט StatefulSet ב-Grafana:
```
Events:
  Type    Reason            Age                From                    Message
  ----    ------            ----               ----                    -------
  Normal  SuccessfulCreate  13s (x3 over 12d)  statefulset-controller  create Pod grafana-0 in StatefulSet grafana successful
```
אם לא מתרחשים אירועים בתא או במשאב אחר במשך זמן רב, תקבלו את הפלט הבא:
```
  Events:         <none>
```

בדיקה אם חבילת הרישום של Observability פועלת

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

מוודאים שכל מופעי Loki או הפודים כוללים את ה-sidecar של Istio. מוודאים ש-Istio sidecar מוזרק לכל הפודים של Fluent Bit שנקראים anthos-audit-logs-forwarder-SUFFIX ו-anthos-log-forwarder-SUFFIX.
בודקים שכל המופעים של Loki פועלים ללא שגיאות באשכול התשתית של הארגון.
בודקים את הסטטוס של אובייקטים anthos-audit-logs-forwarder ו-anthos-log-forwarder DaemonSet כדי לוודא שכל המופעים פועלים בכל הצמתים ללא שגיאות.
מוודאים שאתם מקבלים את יומני הפעילות ממאגרי kube-apiserver-SUFFIX ואת יומני הביקורת משרת Kubernetes API בחמש הדקות האחרונות בכל האשכולות. כדי לעשות זאת, מריצים את השאילתות הבאות במופע Grafana:
- יומני פעילות: sum (count_over_time({service_name="apiserver"} [5m])) by (cluster, fluentbit_pod)
- יומני ביקורת: sum (count_over_time({cluster=~".+"} [5m])) by (cluster, node)
צריך לקבל ערכים שונים מאפס עבור כל הצמתים של מישור הבקרה באשכול התשתית של הארגון.

בודקים שחבילת הניטור של Observability פועלת

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

בודקים שמופעלים מופעי Grafana באשכול התשתית של הארגון. ה-pods של grafana-0 צריכים לפעול ללא שגיאות במרחבי השמות הבאים:
- obs-system
- infra-obs-obs-system
- platform-obs-obs-system
הערה: יכול להיות שמרחבי שמות אחרים של PROJECT_NAMESPACE-obs-system יפעילו מופעים של Grafana. המופעים משתנים בהתאם לאשכול.

מוודאים שכל רכיבי המעקב נמצאים ב-Istio Service Mesh. פועלים לפי השלבים שבקטע זיהוי כשלים בהטמעה. בכל אחד מהפודים הבאים, בעמודה READY צריך להופיע שהסטטוס של כל הקונטיינרים הוא 'מוכן'. לדוגמה, ערך של 3/3 מציין ששלושה מתוך שלושה מכולות מוכנות. בנוסף, ל-Pods צריך להיות מאגר istio-proxy. אם הפודים לא עומדים בתנאים האלה, מפעילים מחדש את הפוד:

שם ה-Pod	מספר הקונטיינרים שמוכנים
`cortex-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-proxy-server-`	`2/2`
`cortex-tenant-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-`	`2/2`
`meta-prometheus-0`	`4/4`
`cortex-alertmanager-`	`2/2`
`cortex-compactor-`	`2/2`
`cortex-distributor-`	`2/2`
`cortex-etcd-0`	`2/2`
`cortex-ingester-`	`2/2`
`cortex-querier-`	`2/2`
`cortex-query-frontend-`	`2/2`
`cortex-query-scheduler-`	`2/2`
`cortex-ruler-`	`2/2`
`cortex-store-gateway-`	`2/2`
`cortex-tenant-`	`2/2`
`grafana-proxy-server-`	`2/2`
`meta-blackbox-exporter-`	`2/2`
`meta-grafana-0`	`3/3`
`meta-grafana-proxy-server-*`	`2/2`
`meta-prometheus-0`	`4/4`

מוודאים ש-Cortex פועל ללא שגיאות.

אחזור יומנים של Observability

בטבלה הבאה מפורטות הפקודות שצריך להריץ כדי לאחזר את היומנים של כל אחד מהרכיבים שפלטפורמת Observability פורסת.

רכיב	פקודה לאחזור יומן
`grafana`	`kubectl logs -n obs-system statefulset/grafana`
`anthos-prometheus-k8s`	`kubectl logs -n obs-system statefulset/anthos-prometheus-k8s`
`alertmanager`	`kubectl logs -n obs-system statefulset/alertmanager`
`ops-logs-loki-io`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io`
`ops-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-io-read`
`ops-logs-loki-all`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all`
`ops-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/ops-logs-loki-all-read`
`audit-logs-loki-io`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io`
`audit-logs-loki-io-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-io-read`
`audit-logs-loki-pa`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa`
`audit-logs-loki-pa-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-pa-read`
`audit-logs-loki-all`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all`
`audit-logs-loki-all-read`	`kubectl logs -n obs-system statefulset/audit-logs-loki-all-read`
`anthos-log-forwarder`	`kubectl logs -n obs-system daemonset/anthos-log-forwarder`
`anthos-audit-logs-forwarder`	`kubectl logs -n obs-system daemonset/anthos-audit-logs-forwarder`
`oplogs-forwarder`	`kubectl logs -n obs-system daemonset/oplogs-forwarder`
`logmon-operator`	`kubectl logs -n obs-system deployment/logmon-operator`

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

צפייה בהגדרה

חבילת הכלים Observability משתמשת במשאבים מותאמים אישית של Kubernetes API כדי להגדיר צינורות של בקרה ורישום.

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

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

צפייה בהגדרות הנוכחיות של פריסת צינור עיבוד הנתונים שלכם לרישום ביומן:
```
kubectl get loggingpipeline -n obs-system default -o yaml
```
שינוי ההגדרות של הפריסה של צינור עיבוד הנתונים לרישום ביומן:
```
kubectl edit loggingpipeline -n obs-system default
```

‫GDC משתמש באופרטור רישום וניטור בשם logmon-operator כדי לנהל את הפריסה של רכיבי Observability כמו Prometheus ו-Fluent Bit. ה-API לרכיב logmon-operator הוא הגדרת המשאב המותאם אישית logmon. הגדרת המשאב המותאם אישית logmon מנחה את logmon-operator איך להגדיר את יכולת התצפית לפריסה. הגדרת המשאב המותאם אישית הזו כוללת את המאפיינים של אמצעי אחסון לאחסון המדדים, כללי התראות ל-Alertmanager, הגדרות Prometheus לאיסוף מדדים והגדרות Grafana למרכזי בקרה.

הפקודות הבאות מציגות את הפעולות הזמינות שאפשר לבצע בהגדרה של משאב בהתאמה אישית logmon:

כדי לראות את ההגדרה הנוכחית של פריסת Observability:
```
kubectl get logmon -n obs-system logmon-default -o yaml
```

שינוי התצורה של פריסת Observability:

kubectl edit logmon -n obs-system logmon-default

הפלט של הפעלת אחת מהפקודות עשוי להפנות לכמה אובייקטים של Kubernetes ConfigMap לצורך הגדרה נוספת. לדוגמה, אפשר להגדיר כללי Alertmanager באובייקט ConfigMap נפרד, שמופנה בהגדרת המשאב המותאם אישית logmon לפי שם. אפשר לשנות את ההגדרות של Alertmanager ולראות אותן דרך logmon הגדרת משאב מותאם אישית בשם gpc-alertmanager-config.

כדי להציג את ההגדרה של Alertmanager, מריצים את הפקודה:

kubectl get configmap -n obs-system gpc-alertmanager-config -o yaml

בעיות נפוצות

בקטע הזה מפורטות בעיות נפוצות שאפשר להיתקל בהן כשפורסים את פלטפורמת ה-Observability.

אין לך גישה ל-Grafana

כברירת מחדל, Grafana לא חשוף למכונות חיצוניות לאשכול Kubernetes. כדי לגשת באופן זמני לממשק Grafana מחוץ לאשכול התשתית של הארגון, אפשר להפנות את היציאה Service אל localhost. כדי להעביר את היציאה Service, מריצים את הפקודה:

kubectl port-forward -n gpc-system service/grafana 33000\:3000

בדפדפן האינטרנט, עוברים אל http://localhost:33000 כדי לראות את לוח הבקרה של Grafana עבור הפריסה. כדי לסיים את התהליך, לוחצים על המקשים Control+C.

‫Grafana פועל לאט

אם Grafana פועל לאט, יכול להיות ש:

שאילתות אל Prometheus או אל Loki מחזירות נתונים בכמות מוגזמת.
השאילתות מחזירות יותר נתונים מכמות סבירה להצגה בתרשים יחיד.

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

בלוח הבקרה של Grafana לא מוצגים מדדים או יומנים

יכולות להיות כמה סיבות לכך שלא מוצגים מדדים או יומנים ב-Grafana:

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

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

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

שם	ארגון	כתובת URL
`Audit Logs`	`All`	`http://audit-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Root`	`http://ops-logs-loki-io-read.obs-system.svc:3100`
`Operational Logs`	`Org`	`http://ops-logs-loki-all-read.obs-system.svc:3100`
`prometheus`		`http://anthos-prometheus-k8s.obs-system.svc:9090`

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

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

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

כל ה-pods של אובייקטים מסוג Service מקבלים את ההערה 'monitoring.gke.io/scrape: "true"'.

הערה: אם השירות שלכם הוא פריסה או אובייקט StatefulSet, מוסיפים את ההערה לשירות כדי ש-Kubernetes יפיץ אותה לקבוצות ה-Pod.
פורמט המדדים של Prometheus חושף את מדדי ה-Pod דרך HTTP. כברירת מחדל, Prometheus מחפש את המדדים האלה בנקודת הקצה http://POD_NAME:80/metrics. במקרה הצורך, אפשר לבטל את הניוד, את נקודת הקצה ואת הסכימה באמצעות הערות.

‫Fluent Bit אוסף יומנים ומיועד להפעלה בכל צומת של אשכולות Kubernetes. ‫Fluent Bit שולח את היומנים ל-Loki לאחסון לטווח ארוך.

אם אין יומנים ב-Grafana, אפשר לנסות את הפתרונות הבאים:

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

התראות לא נפתחות ב-Alertmanager

אם Alertmanager לא מצליח לפתוח התראות, אפשר לבצע את הפעולות הבאות:

באובייקט configMap במרחב השמות gpc-system, מוודאים שהתווית logmon: system_metrics קיימת.
מוודאים שבקטע הנתונים configMap יש מפתח בשם alertmanager.yml. הערך של המפתח alertmanager.yml צריך להיות כללי ההתראה שמופיעים בקובץ ההגדרות התקין של Alertmanager.
מוודאים שהגדרת המשאב המותאם אישית logmon בשם logmon-default במרחב השמות gpc-system מכילה הפניה לאובייקט configMap. הגדרת המשאב המותאם אישית logmon-default חייבת לכלול את השם של האובייקט configMap, כמו בדוגמה הבאה:
```
apiVersion: addons.gke.io/v1
kind: Logmon
spec:
  system_metrics:
    outputs:
      default_prometheus:
        deployment:
          components:
            alertmanager:
              alertmanagerConfigurationConfigmaps:
                - alerts-config
```
הערך alerts-config בדוגמה הוא השם של אובייקט configMap.

‫Alertmanager לא שולח התראות לערוצי ההתראות שהוגדרו

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

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

בודקים שהערכים בקובץ התצורה של Alertmanager הם בפורמט הנכון. כש-Alertmanager מפעיל התראה, הוא שולח שאילתה ל-webhook בתוכנה החיצונית.
מוודאים שכתובות ה-URL של ה-webhook שמקושרות לתוכנה החיצונית נכונות. אם כתובות ה-URL נכונות, צריך לוודא שהתוכנה מוגדרת לקבלת תגובות לפעולות מאתר אחר (webhook). יכול להיות שתצטרכו ליצור מפתח API כדי לגשת ל-API של השירות החיצוני, או שמפתח ה-API הנוכחי שלכם פג תוקף ותצטרכו לרענן אותו.
אם השירות החיצוני נמצא מחוץ לפריסת מכשיר GDC עם בידוד פיזי, צריך לוודא שכללי היציאה של אשכול התשתית של הארגון מוגדרים. ההגדרה הזו מאפשרת ל-Alertmanager לשלוח בקשות לשירות מחוץ לרשת הפנימית של Kubernetes. אם לא תאמתו את כללי תעבורת הנתונים היוצאת (egress), יכול להיות ש-Alertmanager לא יוכל למצוא את התוכנה החיצונית.

אי אפשר לראות מדדים של עומס העבודה בהיקף הפרויקט

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

מוודאים שלמשאב המותאם אישית MonitoringTarget יש סטטוס Ready.
כדי לבצע סקריפט של עומס העבודה, צריך להצהיר על כל פרטי היעד שצוינו ב-MonitoringTarget במפרט של פוד עומסי העבודה. לדוגמה, אם מצהירים שהמדדים זמינים ביציאה 8080, קבוצת ה-Pod של עומס העבודה צריכה להצהיר ל-Kubernetes שיציאה 8080 פתוחה. אחרת, Prometheus מתעלם מעומס העבודה.
‫Prometheus מפעיל כמה רסיסים, כלומר לא כל ה-pods של Prometheus צפויים לבצע גירוד של ה-pod שלכם. אפשר לזהות את מספר הרסיס בשם של כל פוד של Prometheus. לדוגמה, primary-prometheus-shard0-replica0-0 הוא חלק מהרסיס 0. בודקים את הפוד שרוצים לבצע ממנו גירוד מכל רסיס של Prometheus:
1. מבצעים העברת פורטים (port forwarding) של ה-pod‏ primary-prometheus-shardSHARD_NUMBER-replica0-0 של Prometheus במרחב השמות obs-system כדי לקבל גישה לממשק המשתמש של Prometheus. מחליפים את SHARD_NUMBER בשם של ה-pod במספרים עולים בכל פעם שבודקים רסיס חדש.
2. נכנסים לממשק המשתמש של Prometheus בדפדפן האינטרנט ופועלים לפי השלבים הבאים:
  1. לוחצים על סטטוס > יעדים.
  2. מוודאים שה-pod שרוצים לגרד נמצא ברשימה. אם לא, בודקים את הרסיס הבא. אם אין עוד רסיסים לבדיקה, צריך לאמת מחדש של-Prometheus יש מספיק מידע כדי לגלות אותו.
3. בודקים אם יש שגיאות ב-primary-prometheus-shardSHARD_NUMBER-replica0-0 pod של יומני Prometheus במרחב השמות obs-system.
בודקים אם יש שגיאות ביומני ה-pod של cortex-tenant במרחב השמות obs-system.

לא נוצר מרכז שליטה

כדי להבין למה מרכז הבקרה לא נוצר, אפשר לנסות את הפתרון הבא:

בודקים את הסטטוס של המשאב המותאם אישית Dashboard כדי לראות אם יש שגיאות. למשאב המותאם אישית צריך להיות סטטוס Ready.
מוודאים שבודקים את מופע Grafana הנכון. לדוגמה, אם פרסתם את לוח הבקרה במרחב השמות של הפרויקט שנקרא my-namespace, לוח הבקרה צריך להיות במופע Grafana בנקודת הקצה https://GDCH_URL/my-namespace/grafana.
בודקים את היומנים של fleet-admin-controller במרחב השמות gpc-system. כדי לחפש שגיאות שקשורות ללוח הבקרה, מחפשים את השם של לוח הבקרה ביומנים. אם נמצאו שגיאות, פורמט קובץ ה-JSON באובייקט configMap שגוי, ועליכם לתקן אותו.
בודקים את היומנים של Grafana במרחב השמות PROJECT_NAME-obs-system כדי לחפש שגיאות. לוחות הבקרה שולחים שאילתות ל-Grafana API בארכיטקטורת REST, ולכן כדי ליצור לוח בקרה, Grafana צריכה לפעול.

ההתראה לא נפתחת

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

מוודאים ש-Cortex ו-Loki נמצאים במצב אחסון בדלי. הכללים לא פועלים אלא אם יש גיבוי של הקצה העורפי באמצעות אחסון בדלי.
מוודאים שהסטטוס של המשאבים המותאמים MonitoringRule ו-LoggingRule הוא Ready.
בודקים את תנאי ההתראה הבאים:
- ביטויים של PromQL ו-LogQL: משווים את כל הפונקציות שבהן אתם משתמשים לתיעוד של יצירת כללי התראה כדי לוודא שהכללים מוגדרים כמו שאתם רוצים. חשוב לוודא שהביטויים מחזירים ערך true או false.
- משך זמן: השדה for של המשאב המותאם אישית מגדיר כמה זמן תנאי צריך להתקיים. בשדה interval מוגדרת התדירות שבה התנאי ייבדק. בודקים את הערכים של השדות האלה אחד מול השני ומוודאים שהתנאים הגיוניים.
בודקים בממשק המשתמש של Grafana אם ההתראה פתוחה באמצעות הדף Alerts.
אם ב-Grafana מוצג שההתראה פתוחה, צריך לבדוק את ערוצי ההתראות ולוודא ש-Alertmanager יכול ליצור איתם קשר כדי להפיק את ההתראה.

היומנים הצפויים לא זמינים

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

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

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

אם הרכיב כותב יומנים לקובץ, צריך לוודא שהקובץ באמת קיים במערכת הקבצים של הצומת בנתיב /var/log/audit/SERVICE_NAME/NAMESPACE/ACCESS_LEVEL/audit.log.
מוודאים שאין שגיאות ב-pod‏ anthos-audit-logs-forwarder-SUFFIX באותו צומת.
אם הרכיב משתמש בנקודת קצה של syslog כדי לקבל יומנים, צריך לוודא שפריט המשאב המותאם אישית AuditLoggingTarget נפרס עם מפרט תקין ועם סטטוס Ready.

זיהוי כללים מוגדרים מראש להתראות

בקטע הזה מוסבר על כללי ההתראה המוגדרים מראש שקיימים ברכיבי Observability כדי להודיע לכם על כשלים במערכת.

כללי התראה מוגדרים מראש ב-Loki

בטבלה הבאה מפורטים כללי ההתראה שמותקנים מראש ב-Loki לגבי כשלים ביומני ביקורת:

כללי התראות שהותקנו מראש ב-Loki לגבי כשלים ברישום ביומן הביקורת
שם	סוג	תיאור
`FluentBitAuditLoggingWriteFailure`	קריטית	העברת יומני הביקורת באמצעות Fluent Bit נכשלה בחמש הדקות האחרונות.
`LokiAuditLoggingWriteFailure`	קריטית	ל-Loki לא הייתה אפשרות לכתוב יומני ביקורת באחסון העורפי.

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

כללי התראה מוגדרים מראש ב-Prometheus

בטבלה הבאה מפורטים כללי ההתראות שמותקנים מראש ב-Prometheus עבור רכיבי Kubernetes:

כללי התראה שהותקנו מראש ב-Prometheus
שם	סוג	תיאור
`KubeAPIDown`	קריטית	ממשק ה-API של Kube נעלם מגילוי היעד של Prometheus למשך 15 דקות.
`KubeClientErrors`	אזהרה	יחס השגיאות מלקוח שרת Kubernetes API היה גדול מ-0.01 למשך 15 דקות.
`KubeClientErrors`	קריטית	יחס השגיאות מלקוח שרת Kubernetes API היה גדול מ-0.1 במשך 15 דקות.
`KubePodCrashLooping`	אזהרה	ה-Pod נמצא במצב של לולאת קריסה במשך יותר מ-15 דקות.
`KubePodNotReady`	אזהרה	ה-Pod נמצא במצב לא מוכן יותר מ-15 דקות.
`KubePersistentVolumeFillingUp`	קריטית	מספר הבייטים הפנויים באובייקט `PersistentVolume` שנוסף קטן מ-0.03.
`KubePersistentVolumeFillingUp`	אזהרה	מספר הבייטים הפנויים באובייקט `PersistentVolume` שנוסף לחשבון קטן מ-0.15.
`KubePersistentVolumeErrors`	קריטית	הנפח המתמשך נמצא בשלב `Failed` או `Pending` במשך חמש דקות.
`KubeNodeNotReady`	אזהרה	הצומת לא היה מוכן במשך יותר מ-15 דקות.
`KubeNodeCPUUsageHigh`	קריטית	השימוש במעבד (CPU) של הצומת גבוה מ-80%.
`KubeNodeMemoryUsageHigh`	קריטית	השימוש בזיכרון של הצומת גדול מ-80%.
`NodeFilesystemSpaceFillingUp`	אזהרה	השימוש במערכת הקבצים של הצומת גדול מ-60%.
`NodeFilesystemSpaceFillingUp`	קריטית	השימוש במערכת הקבצים של הצומת גדול מ-85%.
`CertManagerCertExpirySoon`	אזהרה	תוקף האישור יפוג בעוד 21 ימים.
`CertManagerCertNotReady`	קריטית	האישור לא מוכן להצגת תנועה אחרי 10 דקות.
`CertManagerHittingRateLimits`	קריטית	הגעתם למגבלת הקצב כשניסיתם ליצור או לחדש אישורים במשך חמש דקות.
`DeploymentNotReady`	קריטית	פריסה באשכול של תשתית הארגון נמצאת במצב לא מוכן במשך יותר מ-15 דקות.
`StatefulSetNotReady`	קריטית	אובייקט `StatefulSet` באשכול התשתית של הארגון נמצא במצב לא מוכן במשך יותר מ-15 דקות.
`AuditLogsForwarderDown`	קריטית	ה-DaemonSet‏ `anthos-audit-logs-forwarder` לא פעיל כבר יותר מ-15 דקות.
`AuditLogsLokiDown`	קריטית	‫`audit-logs-loki` StatefulSet נמצא במצב לא מוכן במשך יותר מ-15 דקות.