ב-Google Distributed Cloud (GDC) עם air gap, אתם יכולים לאסוף מדדים מעומסי העבודה לאורך זמן כדי לעקוב אחרי ביצועי האפליקציה ולשמור על ניראות הנתונים. כדי להתחיל לאסוף מדדים, פורסים MonitoringTarget משאב בהתאמה אישית במרחב השמות של הפרויקט בשרת ה-API לניהול.
המשאב בהתאמה אישית MonitoringTarget מנחה את צינור עיבוד הנתונים של המעקב לאסוף נתונים מפודים ייעודיים שחושפים נקודת קצה (endpoint) של HTTP בפורמט תצוגה של Prometheus, כמו OpenMetrics. אתם יכולים להתאים אישית את תדירות הגירוד, הגדרות נקודת הקצה, התוויות וההערות של פודי היעד. במכונה של Grafana בפרויקט מוצגים המדדים שנאספו, כדי שתוכלו לנתח את המצב התפעולי של האפליקציה.
לפני שמתחילים
כדי לנהל MonitoringRule משאבים בהתאמה אישית, צריך לבקש מהאדמין את ההרשאות הנדרשות.
התפקידים שצריך ב-IAM
כדי לבקש את התפקידים הבאים, פנו לאדמין של הפרויקט ב-IAM:
- יצירת MonitoringRule (
monitoringrule-creator): יצירת משאבים בהתאמה אישית שלMonitoringRuleבמרחב השמות של הפרויקט. - עריכת MonitoringRule (
monitoringrule-editor): עריכה או שינוי של משאבים בהתאמה אישית שלMonitoringRuleבמרחב השמות של הפרויקט. - MonitoringRule Viewer (
monitoringrule-viewer): צפייה במשאבים בהתאמה אישית שלMonitoringRuleבמרחב השמות של הפרויקט.
הגדרת המשאב בהתאמה אישית MonitoringTarget
המשאב המותאם אישית MonitoringTarget מציין לפלטפורמת המעקב מאיפה לאסוף את המדדים. אתם יכולים לציין את הפודים שאתם אוספים מהם מדדים, את נקודת הקצה של המדדים של הפודים האלה, את תדירות הגירוד והגדרות נוספות.
המשאב הזה מגדיר את ההגדרות הבאות:
- Targets: הפודים ונקודות הקצה שלהם בפרויקט שחושפים מדדים.
- Scrape interval: התדירות שבה רוצים לשלוף מדדים מנקודות הקצה שנבחרו.
- התאמות אישיות של תוויות: כללים אופציונליים עם שינויים בתוויות של מדדים.
בוחרים אחת מהשיטות הבאות כדי לציין נקודות קצה (endpoints) של מדדים במשאב המותאם אישית MonitoringTarget:
- נקודות קצה סטטיות: אתם מצהירים באופן מפורש על נקודת הקצה (יציאה, נתיב, סכימה) בהגדרות של
MonitoringTarget. הערות: המידע על נקודת הקצה של מדדי ה-Pod מאוחזר מהערות בקובץ
Deploymentשל מאגר הנתונים. השיטה הזו גמישה יותר אם לכל pod יש נקודות קצה שונות.
נקודות קצה סטטיות
כדי לחשוף מדדים מה-Pods שבחרתם בנקודת קצה (endpoint) שמוגדרת באופן סטטי:
בוחרים את הפרויקט ב-Distributed Cloud שממנו רוצים לאסוף מדדים למעקב.
במפרט של ה-Pod, מגדירים את היציאה שמספקת מדדים בשדה
containerPort. בדוגמה הבאה אפשר לראות איך להצהיר על יציאה2112במפרט של ה-Pod:# ... spec: template: spec: containers: - name: your-container-name ports: - containerPort: 2112 # ...בהגדרות של
MonitoringTarget, מציינים את פרטי נקודת הקצה (יציאה, נתיב, סכימה) בקטעpodMetricsEndpointsכך שיתאימו ליציאה שחשפתם במפרט של ה-Pod.קובץ ה-YAML הבא מציג דוגמה להגדרה של
MonitoringTarget, שבה כל pod שנבחר צריך לחשוף מדדים באותה נקודת קצה (http://your-container-name:2112/metrics):apiVersion: monitoring.gdc.goog/v1 kind: MonitoringTarget metadata: # Choose the same namespace as the workload pods. namespace: your-project-namespace name: your-container-name spec: selector: # Choose pod labels to consider for this job. # Optional: Map of key-value pairs. # Default: No filtering by label. # To consider every pod in the project namespace, remove selector fields. matchLabels: app: your-app-label podMetricsEndpoints: port: value: 2112 path: # Choose any value for your endpoint. # The /metrics value is an example. value: /metrics scheme: value: httpמחילים את ההגדרות של
MonitoringTargetעל שרת Management API באותו מרחב שמות של פודי היעד:kubectl --kubeconfig KUBECONFIG_PATH apply -f MONITORING_TARGET_NAME.yamlמחליפים את מה שכתוב בשדות הבאים:
-
KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של שרת Management API. -
MONITORING_TARGET_NAME: השם של קובץ ההגדרה שלMonitoringTarget.
-
פלטפורמת המעקב מתחילה לאסוף מדדים.
הערות
כדי לחשוף מדדים באמצעות הערות, אם לכל pod יש נקודות קצה שונות:
בוחרים את הפרויקט ב-Distributed Cloud שממנו רוצים לאסוף מדדים למעקב.
מוסיפים את ההערות הבאות לקטע
annotationsבקובץDeploymentשל הקונטיינר:prometheus.io/pathprometheus.io/portprometheus.io/scheme
בדוגמה הבאה מוצגות הערות למדדים ביציאה
2112:apiVersion: apps/v1 kind: Deployment metadata: name: your-container-name namespace: your-project-namespace labels: app: your-app-label annotations: # These annotations are not required. They demonstrate selecting # pod metric endpoints through annotations. prometheus.io/path: /metrics prometheus.io/port: \"2112\" prometheus.io/scheme: httpבהגדרות של
MonitoringTarget, מציינים את ההערות שהוספתם לקובץDeploymentשל הקונטיינר בקטעpodMetricsEndpoints. המפרט הזה מורה למשאב בהתאמה אישית לאסוף את המידע על נקודת הקצה של המדדים מההערות ב-Pod שנבחרו.קובץ ה-YAML הבא מציג דוגמה להגדרה של
MonitoringTargetבאמצעות הערות:apiVersion: monitoring.gdc.goog/v1 kind: MonitoringTarget metadata: metadata: # Choose the same namespace as the workload pods. namespace: your-project-namespace name: your-container-name spec: selector: matchLabels: app: your-app-label podMetricsEndpoints: port: annotation: prometheus.io/port path: annotation: prometheus.io/path scheme: annotation: prometheus.io/schemeמחילים את ההגדרות של
MonitoringTargetעל שרת Management API באותו מרחב שמות של פודי היעד:kubectl --kubeconfig KUBECONFIG_PATH apply -f MONITORING_TARGET_NAME.yamlמחליפים את מה שכתוב בשדות הבאים:
-
KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של שרת Management API. -
MONITORING_TARGET_NAME: השם של קובץ ההגדרה שלMonitoringTarget.
-
פלטפורמת המעקב מתחילה לאסוף מדדים.
כדי לראות שדות ואפשרויות נוספים, עיינו במפרט המלא של MonitoringTarget ובמאמרי העזרה של ה-API.
המפרט המלא של MonitoringTarget
קובץ ה-YAML הבא מציג דוגמה למפרט המלא של המשאב המותאם אישית MonitoringTarget. למידע נוסף ולתיאור מלא של השדות, קראו את מאמרי העזרה של ה-API.
apiVersion: monitoring.gdc.goog/v1
kind: MonitoringTarget
metadata:
# Choose the same namespace as the workload pods.
namespace: PROJECT_NAMESPACE
name: MONITORING_TARGET_NAME
spec:
# Choose matching pattern that identifies pods for this job.
# Optional
# Relationship between different selectors: AND
selector:
# Choose clusters to consider for this job.
# Optional: List
# Default: All clusters applicable to this project.
# Relationship between different list elements: OR
matchClusters:
- string
# Choose pod labels to consider for this job.
# Optional: Map of key-value pairs.
# Default: No filtering by label.
# Relationship between different pairs: AND
matchLabels:
key1: value1
# Choose annotations to consider for this job.
# Optional: Map of key-value pairs
# Default: No filtering by annotation
# Relationship between different pairs: AND
matchAnnotations:
key1: value1
# Configure the endpoint exposed for this job.
podMetricsEndpoints:
# Choose a port either through static value or annotation.
# Optional
# Annotation takes priority.
# Default: static port 80
port:
value: integer
annotation: string
# Choose a path either through static value or annotation.
# Optional
# Annotation takes priority
# Default: static path /metrics
path:
value: string
annotation: string
# Choose a scheme either through a static value (http or https) or annotation.
# Optional
# Annotation takes priority
# Default: static scheme http
scheme:
value: string
annotation: string
# Choose the frequency to scrape the metrics endpoint defined in podMetricsEndpoints
# Optional
# Default: 60s
scrapeInterval: string
# Dynamically rewrite the label set of a target before it gets scraped.
# https://prometheus.io/docs/prometheus/latest/configuration/configuration/#relabel_config
# Optional
# Default: No filtering by label
metricsRelabelings:
- sourceLabels:
- string
separator: string
regex: string
action: string
targetLabel: string
replacement: string
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_NAMESPACE: מרחב השמות של הפרויקט. -
MONITORING_TARGET_NAME: השם של קובץ ההגדרה שלMonitoringTarget.