הגדרת אפליקציה לניטור אפליקציות

במאמר הזה מוסבר איך להגדיר אפליקציה ב-App Hub כך שהמדדים ונתוני המעקב שהאפליקציה יוצרת יכללו תוויות ספציפיות לאפליקציה. בנוסף, מוסבר איך להגדיר את האפליקציה כך שתייצא מדד שמשמש את Application Monitoring לדיווח על רמת התנועה, שיעור שגיאות השרת או זמן האחזור של עומסי עבודה של בקשות HTTP שפועלים ב-Google Kubernetes Engine.

מידע על תוויות ספציפיות לאפליקציות

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

בקטע הזה, צריך לפרש את a.b.{x,y} כ-a.b.x ואת a.b.y.

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

• metric.labels.apphub_application_{container,id,location}
• metric.labels.apphub_workload_{criticality_type,environment_type,id}

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

• gcp.apphub.application.{container,id,location}
• gcp.apphub.{workload,service}.{criticality_type,environment_type,id}

מידע על מדדים של שרת HTTP ב-OpenTelemetry

אין מדדים של המערכת לעומסי עבודה שפועלים ב-Google Kubernetes Engine, שיכולים לדווח על רמת התנועה, על שיעור שגיאות השרת או על זמן האחזור של בקשות HTTP. עם זאת, אפשר לגזור את הערכים של האותות האלה מ-http.server.request.duration, שהוא מדד שנאסף באופן אוטומטי על ידי ספריית לקוח ה-HTTP של OpenTelemetry.

ה-exporter‏ googlemanagedprometheus ממיר את מדד OpenTelemetry‏ http.server.request.duration למדד Prometheus עם המאפיינים הבאים:

• שם: prometheus/http_server_request_duration_seconds/histogram
• מדד: prometheus.googleapis.com/http_server_request_duration_seconds/histogram
• סוגי משאבים: prometheus_target
• יחידה: s
• סוג: CUMULATIVE
• סוג הערך: DISTRIBUTION

אם הפרויקט שלכם Google Cloud מכיל את המדד http_server_request_duration_seconds metric, לוחות הבקרה של Application Monitoring יציגו את רמת התנועה, את שיעור השגיאות בחיבור לשרת ואת זמן האחזור של בקשות HTTP.

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

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

‫Google Cloud Observability מנסה לזהות את המקור של מדדי Prometheus על ידי השוואה בין המאפיינים שמצורפים למדדי Prometheus שנשלחים לפרויקט לבין הנתונים שמוחזרים מ-App Hub API. בהמשך הקטע מפורטות ההגדרות שמאפשרות ל-Google Cloud Observability לזהות את האפליקציה App Hub.

שימוש ב-OpenTelemetry ב-Kubernetes

כדי ש-Google Cloud Observability יצרף תוויות של אפליקציות לנתוני מדדים שנוצרו על ידי עומסי העבודה של האפליקציה שפועלים ב-Google Kubernetes Engine, צריך לבצע את הפעולות הבאות:

1. מגדירים את האפליקציה באמצעות OpenTelemetry.

   • מידע כללי זמין במאמר אינסטרומנטציה וניראות.
   • במאמר סקירה כללית של דוגמאות לאינסטרומנטציה מופיעים קישורים לדוגמאות של Go,‏ Java,‏ Node.js ו-Python, וגם מידע על הדוגמאות האלה.

2. פורסים את Collector מבית Google או את OpenTelemetry Collector, ומגדירים את Collector באופן הבא:

   • ייצוא נתוני מדדים באמצעות הכלי googlemanagedprometheus.
   • מגדירים את מעבד k8sattributes לחילוץ מטא-נתונים, כמו namespace, מהסביבה.
   • מגדירים את מעבד transform/collision כדי להגדיר את המאפיינים project_id, location, cluster ו-namespace.
   • מגדירים את מעבד transform/aco-gke כדי לאכלס את התוויות top_level_controller_name ו-top_level_controller_type.

   לדוגמה, אפשר לעיין בotlp-k8s-ingest/config/collector.yaml, שהוא קובץ התצורה של הכלי לאיסוף נתונים שנוצר על ידי Google. למידע נוסף על כלי האיסוף הזה, אפשר לעיין במאמר פריסת OpenTelemetry Collector מבית Google ב-GKE.

3. רושמים את עומסי העבודה של האפליקציה ב-App Hub.

שימוש בשירות המנוהל של Google Cloud ל-Prometheus ב-GKE

כדי שמערכת Google Cloud Observability תצרף תוויות של אפליקציות לנתוני מדדים שנוצרו על ידי עומסי העבודה של האפליקציה שפועלת באשכולות Google Kubernetes Engine, צריך לבצע את הפעולות הבאות:

1. שימוש בשירות המנוהל של Google Cloud ל-Prometheus עם איסוף מנוהל.

2. פריסת עומסי העבודה באשכול Google Kubernetes Engine שהגרסה שלו היא לפחות 1.32.1-gke.1439000.

3. רושמים את עומסי העבודה של האפליקציה ב-App Hub.

השירות המנוהל של Google Cloud ל-Prometheus מאתר את הערכים של תוויות האפליקציה באמצעות מטא-נתונים של זיהוי שירותים, ואז מוסיף את התוויות top_level_controller_{name,type} אל targetLabels.metadata. במהלך הטמעת המדדים, Google Cloud Observability משתמש בtop_level_controller_{name,type}תוויות וב-App Hub API כדי לזהות את האפליקציה שלכם ב-App Hub ולהוסיף את התוויות המתאימות לנתוני המדדים.

שימוש ב-Cloud Run

כדי ש-Google Cloud Observability יצרף תוויות של אפליקציות לנתונים של מדדים שנוצרו על ידי עומסי העבודה שלכם ב-Cloud Run, צריך לבצע את הפעולות הבאות:

1. מגדירים את האפליקציה באמצעות OpenTelemetry או באמצעות שירות מנוהל ל-Prometheus sidecar ל-Cloud Run. מידע על הגישות האלה זמין במסמכים הבאים:

   • פריסת Google-Built OpenTelemetry Collector ב-Cloud Run
   • שימוש ב-Prometheus sidecar ל-Cloud Run

2. רושמים את עומסי העבודה של האפליקציה ב-App Hub.

אימות תוויות של מדדים

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

1. מוודאים שהאפליקציה שולחת מדדים של Prometheus לפרויקט:

   1. במסוף Google Cloud , עוברים לדף leaderboard Metrics explorer:

      כניסה אל Metrics Explorer

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

   2. בסרגל הכלים של מסוף Google Cloud , בוחרים את Google Cloud הפרויקט. בהגדרות של App Hub, בוחרים את פרויקט המארח של App Hub או את פרויקט הניהול של התיקייה לניהול אפליקציות.
   3. ברכיב Metric, מרחיבים את התפריט Select a metric, כותבים Prometheus Target בשורת הסינון ומשתמשים בתפריטי המשנה כדי לבחור סוג ספציפי של משאב ומדד:
      1. בתפריט Active resources בוחרים באפשרות Prometheus Target.
      2. כדי לבחור מדד, משתמשים בתפריטים Active metric categories ו-Active metrics.
      3. לוחצים על אישור.

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

   5. מגדירים את אופן התצוגה של הנתונים.
      

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

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

   אם אתם לא רואים מדדים של Prometheus, כדאי לבדוק את ההגדרה.

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

1. מוודאים שרשמתם את עומס העבודה או השירות ב-App Hub.

2. צריך לבדוק את היומנים כדי לראות אם יש שגיאות.

   לדוגמה, אם אתם פורסים OpenTelemetry Collector או את ה-Collector שנוצר על ידי Google, ואתם מריצים ב-Google Kubernetes Engine, יכול להיות שתבצעו את הפעולות הבאות:

   1. במסוף Google Cloud , עוברים לדף Workloads:

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

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

   2. בוחרים את פריסת האוסף ולוחצים על הכרטיסייה Logs (יומנים).

3. אם אתם משתמשים ב-OpenTelemetry Collector או ב-Collector שנוצר על ידי Google, כדאי לבדוק את ההגדרה של ה-Collector. הכלי לאיסוף נתונים צריך לבצע את הפעולות הבאות:

   • ייצוא נתוני מדדים באמצעות הכלי googlemanagedprometheus.
   • מגדירים את מעבד k8sattributes לחילוץ מטא-נתונים, כמו namespace, מהסביבה.
   • מגדירים את מעבד transform/collision כדי להגדיר את המאפיינים project_id, location, cluster ו-namespace.
   • מגדירים את מעבד transform/aco-gke כדי לאכלס את התוויות top_level_controller_name ו-top_level_controller_type.

   לדוגמה, ראו קובץ התצורה של Collector שנוצר על ידי Google: otlp-k8s-ingest/config/collector.yaml.

הוספת מאפייני אפליקציה לטווחים של מעקב

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

כדי ש-Google Cloud Observability יצרף מאפייני משאבים ספציפיים לאפליקציה לנתוני מעקב שנוצרו על ידי השירותים ועומסי העבודה של האפליקציה, צריך לבצע את כל הפעולות הבאות:

• מטמיעים את OpenTelemetry באפליקציה ומגדירים את כלי הייצוא לשליחת נתוני מעקב לנקודת הקצה של Telemetry (OTLP) API.

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

  • פריסת OpenTelemetry Collector מבית Google ב-Google Kubernetes Engine
  • פריסת Google-Built OpenTelemetry Collector ב-Cloud Run.
  • פריסת OpenTelemetry Collector במערכת הפעלה שמותאמת לקונטיינרים

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

• פריסת השירותים ועומסי העבודה בתשתית נתמכת.

• רושמים את השירותים ועומסי העבודה ב-App Hub.

מידע נוסף על המאפיינים האלה זמין במאמר Google Cloud מוסכמות סמנטיות של App Hub.

מאפייני חובה

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

מאפיינים שמזהים את הפרויקט ואת מיקום המשאב

מגדירים את המאפיינים הבאים:

• ‫cloud.provider: מוגדר ל-"gcp".
• ‫cloud.account.id: מוגדר למזהה הפרויקט.
• ‫cloud.availability_zone או cloud.region: מוגדר לאזור או לתחום שבו נמצאים המשאבים. אפשר להגדיר את שני המאפיינים.

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

• resourcedetectionprocessor
• כניסה אל: Google Cloud resource detector
• ‫Java: ‏ opentelemetry-java-contrib/gcp-resources
• ‫Node.js: ‏ resource-detector-gcp
• ‫Python: opentelemetry-resourcedetector-gcp

מאפיינים של עומסי עבודה ב-Google Kubernetes Engine

כדי להגדיר עומס עבודה ב-Google Kubernetes Engine, צריך להגדיר את האוסף או את האינסטרומנטציה כך שיבצעו את הפעולות הבאות:

• אפשר לחלץ מהסביבה מטא-נתונים כמו namespace.
• חילוץ מטא-נתונים רלוונטיים מהמעבד k8sattributes.
• מגדירים את המאפיינים project_id,‏ location,‏ cluster ו-namespace.
• מגדירים את התוויות top_level_controller_name ו-top_level_controller_type.

דוגמה שמבוססת על כלי לאיסוף נתונים מופיעה במאמר בנושא otlp-k8s-ingest/config/collector.yaml. המעבד שבו משתמש המלקט הוא k8sattributesprocessor.

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

אם פורסים את האפליקציה במכונת VM, מכונת ה-VM הזו צריכה להיות משויכת לקבוצת מופעי מכונה מנוהלים (MIG). צריך גם לצרף את המאפיינים הבאים:

• gcp.gce.instance_group_manager.name
• gcp.gce.instance_group_manager.region או gcp.gce.instance_group_manager.zone