מדדים של סנכרון תצורות

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

תמחור

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

מידע נוסף זמין במאמר בנושא תמחור של Cloud Monitoring.

איך סנכרון תצורות אוסף מדדים

‫סנכרון תצורות משתמש ב-OpenCensus כדי ליצור ולתעד מדדים, וב-OpenTelemetry כדי לייצא את המדדים שלו אל Prometheus ו-Cloud Monitoring. במדריכים הבאים מוסבר איך לייצא מדדים:

כדי להגדיר את OpenTelemetry Collector,‏ סנכרון תצורות יוצר כברירת מחדל ConfigMap בשם otel-collector. הפריסה otel-collector פועלת במרחב השמות config-management-monitoring.

יצירת ה-ConfigMap‏ otel-collector מגדירה את כלי הייצוא prometheus, שחושף נקודת קצה של מדדים לסריקה של Prometheus.

כשמריצים את סנכרון תצורות ב-GKE או בסביבת Kubernetes אחרת שהוגדרה עם פרטי כניסה של Google Cloud ,‏ סנכרון תצורות יוצר ConfigMap בשם otel-collector-google-cloud. ההגדרה otel-collector-google-cloud מבטלת את ההגדרה ב-ConfigMap otel-collector. ‫סנכרון תצורות מחזיר את כל השינויים שבוצעו ב-ConfigMaps של otel-collector או otel-collector-google-cloud.

יצירת otel-collector-google-cloud ConfigMap מוסיפה גם את cloudmonitoring exporter, שמייצא ל-Cloud Monitoring, ואת kubernetes exporter, שמייצא לשירות המדדים הפנימי של Google. הכלי לייצוא kubernetes שולח מדדים אנונימיים נבחרים ל-Google כדי לעזור לשפר את סנכרון תצורות.

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

השבתת המעקב

כברירת מחדל, סנכרון תצורות אוסף מדדים לכל האובייקטים מסוג RootSync ו-RepoSync. השבתת מדדים נתמכת רק באובייקטים מותאמים אישית מסוג RootSync או RepoSync. אם אובייקט RootSync נוצר כברירת מחדל כשהתקנתם את סנכרון תצורות באמצעות מסוף Google Cloud ,‏ Google Cloud CLI או Terraform, והשם שלו הוא root-sync, כל שינוי שנעשה בשדה spec.monitoring.enabled יבוטל באופן אוטומטי.

כדי להשבית את איסוף המדדים עבור אובייקט ספציפי מסוג RootSync או RepoSync, מגדירים את השדה spec.monitoring.enabled לערך false במשאב המותאם אישית מסוג RootSync או RepoSync:

כשמשביתים את המעקב אחרי אובייקט מסוג RootSync או RepoSync:

  • קונטיינר ה-sidecar‏ otel-agent מושמט מ-Pod של reconciler.
  • האיסוף והייצוא של נתוני טלמטריה עבור כלי ההתאמה הספציפי הזה מושבתים, מה שיכול לעזור לצמצם את צריכת המשאבים.

בדוגמה הבאה מושבת המעקב באובייקט מותאם אישית מסוג RootSync או RepoSync:

apiVersion: configsync.gke.io/v1beta1
kind: RootSync # or RepoSync
metadata:
  name: SYNC_NAME
  namespace: SYNC_NAMESPACE
spec:
  monitoring:
    enabled: false

מדדים של OpenTelemetry

‫סנכרון תצורות ו-Resource Group Controller אוספים את המדדים הבאים באמצעות OpenCensus ומפרסמים אותם דרך OpenTelemetry Collector . בעמודה Tags מפורטים תגים ספציפיים של סנכרון תצורות שרלוונטיים לכל מדד. מדדים עם תגים מייצגים כמה מדידות, אחת לכל שילוב של ערכי תגים.

מדדים של סנכרון תצורות

שם סוג תגים תיאור
api_duration_seconds הפצה פעולה, סטטוס התפלגות זמן האחזור של קריאות לשרת API.
apply_duration_seconds הפצה סטטוס התפלגות זמן האחזור של החלת משאבים שהוגדרו ממקור מידע אמין על אשכול.
apply_operations_total ספירה פעולה, סטטוס, בקר המספר הכולל של פעולות שבוצעו כדי לסנכרן משאבים ממקור האמת לאשכול.
declared_resources ערך אחרון מספר המשאבים המוצהרים שנותחו מ-Git.
internal_errors_total ספירה מקור המספר הכולל של שגיאות פנימיות שנתקל בהן סנכרון תצורות. יכול להיות שהמדד לא יופיע בתוצאות השאילתה אם לא אירעה שגיאה פנימית.
last_sync_timestamp ערך אחרון סטטוס חותמת הזמן של הסנכרון האחרון מ-Git.
parser_duration_seconds הפצה סטטוס, טריגר, מקור התפלגות זמן האחזור של שלבים שונים שקשורים לסנכרון ממקור האמת לאשכול.
pipeline_error_observed ערך אחרון name, reconciler, component הסטטוס של משאבים מותאמים אישית של RootSync ו-RepoSync. הערך 1 מציין כשל.
reconcile_duration_seconds הפצה סטטוס התפלגות זמן האחזור של אירועי התאמה שטופלו על ידי מנהל ההתאמה.
reconciler_errors ערך אחרון component, errorclass מספר השגיאות שנתקלו בהן במהלך סינכרון משאבים ממקור האמת לאשכול.
remediate_duration_seconds הפצה סטטוס התפלגות השהיות של אירועי גישור של כלי התיקון.
resource_conflicts_total ספירה המספר הכולל של התנגשויות משאבים שנובעות מחוסר התאמה בין המשאבים שבמטמון לבין משאבי האשכול. יכול להיות שהמדד לא יופיע בתוצאות השאילתה אם לא היה ניגוד משאבים.
resource_fights_total ספירה המספר הכולל של משאבים שמסונכרנים בתדירות גבוהה מדי. כל תוצאה שגבוהה מאפס מצביעה על בעיה. מידע נוסף זמין במאמר KNV2005: ResourceFightWarning. יכול להיות שהמדד לא יופיע בתוצאות השאילתה אם לא התרחש מאבק על משאבים.

מדדים של בקר קבוצת משאבים

ה-Resource Group Controller הוא רכיב ב-סנכרון תצורות שעוקב אחרי המשאבים המנוהלים ובודק אם כל משאב מוכן או מסונכרן. המדדים הבאים זמינים:

שם סוג תגים תיאור
rg_reconcile_duration_seconds הפצה stallreason התפלגות הזמן שנדרש לתיאום של ResourceGroup CR
resource_group_total ערך אחרון המספר הנוכחי של CR מסוג ResourceGroup
resource_count ערך אחרון resourcegroup המספר הכולל של משאבים שנמצאים במעקב על ידי ResourceGroup
ready_resource_count ערך אחרון resourcegroup המספר הכולל של משאבים מוכנים ב-ResourceGroup
resource_ns_count ערך אחרון resourcegroup מספר מרחבי השמות שמשמשים משאבים ב-ResourceGroup
cluster_scoped_resource_count ערך אחרון resourcegroup מספר המשאבים בהיקף אשכול ב-ResourceGroup
crd_count ערך אחרון resourcegroup מספר ה-CRD ב-ResourceGroup
kcc_resource_count ערך אחרון resourcegroup המספר הכולל של משאבי KCC ב-ResourceGroup
pipeline_error_observed ערך אחרון name, reconciler, component הסטטוס של משאבים מותאמים אישית של RootSync ו-RepoSync. הערך 1 מציין כשל.

תוויות של מדדים בסנכרון תצורות

אפשר להשתמש בתוויות של מדדים כדי לצבור נתוני מדדים ב-Cloud Monitoring וב-Prometheus. אפשר לבחור אותם מהרשימה הנפתחת 'קיבוץ לפי' במסוף המעקב.

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

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

התוויות הבאות משמשות למדדים של סנכרון תצורות ושל Resource Group Controller, שזמינים כשמבצעים מעקב באמצעות Cloud Monitoring ו-Prometheus.

שם ערכים תיאור
operation יצירה, תיקון, עדכון, מחיקה סוג הפעולה שבוצעה
status הצלחה, שגיאה סטטוס הביצוע של פעולה
reconciler rootsync, reposync הסוג של הכלי להשוואת נתונים
source מנתח, כלי להשוואה, כלי לתיקון מקור השגיאה הפנימית
trigger ניסיון חוזר, watchUpdate, ‏ managementConflict, ‏ resync, ‏ reimport הטריגר של אירוע התאמה
name שם המאחד השם של הכלי להשוואת נתונים
component ניתוח, מקור, סנכרון, רינדור, מוכנות שם הרכיב או השלב הנוכחי בתהליך ההתאמה
container ‫reconciler, ‏ git-sync שם הקונטיינר
resource מעבד (CPU), זיכרון סוג המשאב
controller applier, remediator השם של בקר ב-reconciler של שורש או מרחב שמות
type כל משאב ב-Kubernetes, למשל ClusterRole,‏ Namespace,‏ NetworkPolicy,‏ Role וכו'. סוג ה-API של Kubernetes
commit ---- הגיבוב של הקומיט האחרון שסונכרן

תוויות משאבים

למדדים של סנכרון תצורות שנשלחים אל Prometheus ו-Cloud Monitoring מוגדרות תוויות המדדים הבאות כדי לזהות את ה-Pod של המקור:

שם תיאור
k8s.node.name השם של הצומת שמארח Pod של Kubernetes
k8s.pod.namespace מרחב השמות של ה-Pod
k8s.pod.uid מזהה ה-Pod
k8s.pod.ip כתובת ה-IP של ה-Pod
k8s.deployment.name השם של הפריסה שבבעלותה נמצא ה-Pod

למדדים של סנכרון תצורות שנשלחים אל Prometheus ו-Cloud Monitoring מ-Pods של reconciler מוגדרות גם תוויות המדדים הבאות, כדי לזהות את RootSync או RepoSync ששימשו להגדרת ה-reconciler:

שם תיאור
configsync.sync.kind סוג המשאב שמגדיר את הכלי הזה להשוואה: RootSync או RepoSync
configsync.sync.name השם של RootSync או RepoSync שמגדיר את הכלי הזה להשוואת נתונים
configsync.sync.namespace מרחב השמות של RootSync או RepoSync שמגדיר את הכלי הזה להשוואת נתונים

תוויות משאבים ב-Cloud Monitoring

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

סוג המשאב k8s_container מגדיר את תוויות המשאב הבאות כדי לזהות את מאגר התגים של המקור:

שם תיאור
container_name שם הקונטיינר
pod_name שם ה-Pod
namespace_name מרחב השמות של ה-Pod
location האזור או התחום של האשכול שמארח את הצומת
cluster_name השם של האשכול שמארח את הצומת
project מזהה הפרויקט שמארח את האשכול

הגדרת סינון של מדדים מותאמים אישית

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

כדי לשנות מדדים מותאמים אישית, יוצרים ConfigMap בשם otel-collector-custom ואז עורכים אותו. השימוש ב-ConfigMap הזה מבטיח שסנכרון תצורות לא יבטל את השינויים שביצעתם. אם משנים את ה-ConfigMaps של otel-collector או otel-collector-google-cloud, ‏ סנכרון תצורות מחזיר את השינויים למצב הקודם.

דוגמאות לאופן ההתאמה של ConfigMap מופיעות במאמר Custom Metric Filtering במסמכי התיעוד של Config Sync בקוד פתוח.

הסבר על המדד pipeline_error_observed

המדד pipeline_error_observed עוזר לכם לזהות במהירות CR של RepoSync או RootSync שלא מסונכרנים או שמכילים משאבים שלא הותאמו למצב הרצוי.

  • כדי שהסנכרון באמצעות RootSync או RepoSync יצליח, המדדים עם כל הרכיבים (rendering, ‏ source, ‏ sync, ‏ readiness) צריכים להיות עם הערך 0.

    צילום מסך של המדד pipeline_error_observed עם כל הרכיבים שנצפו עם הערך 0

  • אם הקומיט האחרון נכשל בעיבוד האוטומטי, המדד עם הרכיב rendering יקבל את הערך 1.

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

  • אם לא ניתן להחיל משאב על האשכול, המדד עם הרכיב sync יקבל את הערך 1.

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

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