בדף הזה מתואר התהליך של איסוף יומנים מתהליכי העבודה בסביבות מבודדות (air-gapped) של Google Distributed Cloud (GDC), כדי לאפשר רישום ביומן ומעקב אחרי נתונים.
היומנים מתעדים את התנאים והפעולות כשמנהלים פעולות ב-GDC. אתם יכולים לגרד יומנים שהרכיבים שלכם יוצרים כדי לתעד אירועים ופעילויות. פלטפורמת הרישום ביומן מציעה API בהתאמה אישית לאיסוף יומנים ברמת הפרויקט שנוצרים בתהליכי העבודה שלכם באמצעות יעדי רישום ביומן.
כדי להתחיל לאסוף נתוני יומן, צריך לפרוס LoggingTarget משאב בהתאמה אישית למרחב השמות של הפרויקט בשרת Management API. אחרי שכלי איסוף היומנים שולף נתונים מתהליכי העבודה, פלטפורמת הרישום ביומן צוברת יומנים מכל מקורות היומנים, מוסיפה אינדקסים ומשייכת יומנים לתוויות בהתאם להגדרה מLoggingTarget המשאב המותאם אישית.
אפשר לגשת ליומנים שנאספו באמצעות ממשק המשתמש של Grafana או Log Query API, כמו שמתואר במאמר שאילתה והצגה של יומנים.
שיטות מומלצות להטמעת רישום ביומן לצורך ניראות נתונים מפורטות בהנחיות הקהילה של Kubernetes:
לפני שמתחילים
כדי לקבל את ההרשאות שדרושות לניהול משאבים מותאמים אישית של LoggingTarget, צריך לבקש מאדמין IAM בארגון או מאדמין IAM בפרויקט להקצות לכם אחד מהתפקידים המשויכים של LoggingTarget.
בהתאם לרמת הגישה וההרשאות שאתם צריכים, יכול להיות שתקבלו תפקידי יוצר, עורך או צופה במשאב הזה בארגון או בפרויקט. למידע נוסף, אפשר לעיין במאמר הכנת הרשאות IAM.
הגדרת המשאב המותאם אישית LoggingTarget
המשאב המותאם אישית LoggingTarget מורה לצינור הנתונים של הרישום ביומן לאסוף יומנים בפרויקט GDC. אפשר לציין את יעדי האיסוף של היומנים, מנתח יומנים, רמות גישה והגדרות נוספות.
במשאב הזה מוגדרות ההגדרות הבאות:
- יעדים: הקריטריונים לבחירת הפודים והקונטיינרים שמהם רוצים לאסוף יומנים. אפשר לציין שמות של אשכולות, קידומות של שמות של pods וקידומות של שמות של containers.
- כלי לניתוח יומנים: כלי מנתח מוגדר מראש שמפרש רשומות יומן, ממפה פלט יומן לתוויות ומחלץ שדות רלוונטיים.
- זיהוי השירות: שם השירות שמוחל כתווית על רשומות היומן כדי להקל על הזיהוי והסינון.
הרשאה: רמת הגישה לרשומות ביומן, שקובעת מי יכול לצפות ביומנים שנאספו.
הגדרת הפרמטרים האלה במשאב המותאם אישית LoggingTarget מאפשרת לכם לשלוט באופן מדויק באיסוף של היומנים ובארגון שלהם.
כדי לאסוף יומני פעילות:
- מזהים את פרויקט GDC שממנו רוצים לאסוף יומנים.
בהגדרות של
LoggingTarget, מציינים את ה-pods לאיסוף יומני הפעילות, את מרחב השמות של הפרויקט והגדרות נוספות.קובץ ה-YAML הבא מציג דוגמה להגדרה של
LoggingTargetב-my-project-namespace, שבה קידומת השם של ה-Pod שממנו נאספים היומנים היאmy-pod-prefix, רמת הגישה לרשומות ביומן ניתנת למפעילים של אפליקציות (ao), שם השירות הואmy-service-nameופורמט היומן הוא JSON:# Configures a log scraping job apiVersion: logging.gdc.goog/v1 kind: LoggingTarget metadata: # Choose a namespace that matches the namespace of the workload pods. namespace: my-project-namespace name: my-logging-target spec: selector: matchPodNames: - my-pod-prefix parser: json logAccessLevel: ao serviceName: my-service-nameמידע על שדות ואפשרויות נוספים מופיע במפרט
LoggingTargetהמלא ובמאמרי העזרה בנושא API.מחילים את ההגדרה
LoggingTargetעל שרת Management API באותו מרחב שמות כמו הפודים של היעד:kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yamlמחליפים את מה שכתוב בשדות הבאים:
-
KUBECONFIG_PATH: הנתיב לקובץ kubeconfig של שרת Management API. -
LOGGING_TARGET_NAME: השם של קובץ ההגדרהLoggingTarget, למשלmy-logging-target.
צינור הנתונים של הרישום מתחיל לאסוף יומנים מהרכיבים הנוספים של הפרויקט.
-
אפשר לשלוח שאילתות ליומנים שנאספו באמצעות ממשק המשתמש של Grafana או Log Query API. למידע נוסף, ראו שליחת שאילתות וצפייה ביומנים.
אם אתם משתמשים ב-Grafana כדי לשלוח שאילתות ליומנים, אתם יכולים להשתמש בתכונה המובנית של קידוד צבעים לרמות שונות של יומנים. מידע נוסף על הגדרת ערכים של רמת יומן זמין בכתובת https://grafana.com/docs/grafana/latest/explore/logs-integration/.
המפרט המלא של LoggingTarget
בקובץ ה-YAML הבא מוצגת דוגמה למפרט המלא של LoggingTarget המשאב בהתאמה אישית. מידע נוסף ותיאור מלא של השדות מופיעים במאמרי העזרה של ה-API.
# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
# Choose a namespace that matches the namespace of the workload pods.
namespace: PROJECT_NAMESPACE
name: LOGGING_TARGET_NAME
spec:
# Choose a matching pattern that identifies the pods for this job.
# Optional.
# Relationship between different selectors: 'AND'
selector:
# The clusters to collect logs from.
# The default configuration is to collect logs from all clusters.
# The relationship between different clusters is an 'OR' relationship.
# Optional
matchClusters:
- my-cluster
- another-cluster
# The pod name prefixes to collect logs from.
# The logging platform scrapes all pods with names
# that start with the specified prefixes.
# The values must contain '[a-z0-9-]' characters only.
# The relationship between different list elements is an 'OR' relationship.
# Optional.
matchPodNames:
- my-pod-prefix
- another-pod-prefix
# The container name prefixes to collect logs from.
# The logging platform scrapes all containers with names
# that start with the specified prefixes.
# The values must contain '[a-z0-9-]' characters only.
# The relationship between different list elements is an 'OR' relationship.
# Optional.
matchContainerNames:
- my-container-prefix
- another-container-prefix
# Choose the predefined parser for log entries.
# Use parsers to map the log output to labels and extract fields.
# Specify the log format.
# Optional.
# Options: klog_text, klog_json, klogr, gdch_json, json
parser: klog_text
# Specify an access level for log entries.
# The default value is 'ao'.
# Optional.
# Options: ao, pa, io
logAccessLevel: ao
# Specify a service name to be applied as a label.
# For user workloads consider this field as a workload name.
# Required.
serviceName: my-service-name
# The additional static fields to apply to log entries.
# The field is a key-value pair, where the field name is the key and
# the field value is the value.
# Optional.
additionalFields:
app: workload2
key: value
מחליפים את מה שכתוב בשדות הבאים:
-
PROJECT_NAMESPACE: מרחב השמות של הפרויקט. -
LOGGING_TARGET_NAME: השם של קובץ ההגדרהLoggingTarget.