איסוף יומנים מתהליכי העבודה של Kubernetes

איסוף יומנים ב-Google Distributed Cloud (GDC)‎ עם air gap מאפשר לכם לצבור אירועים תפעוליים מתהליכי העבודה של Kubernetes לצורך מעקב ופתרון בעיות. פורסים משאב בהתאמה אישית של LoggingTarget בשרת ה-API לניהול כדי לאחזר, להוסיף לאינדקס ולהוסיף תוויות ליומני הפרויקט ממכונות וירטואליות (VM) של צומת עובד ב-Kubernetes. הצינור הזה לא תומך באיסוף יומנים ממכונות וירטואליות עצמאיות של משתמשים.

אחרי שמגדירים את איסוף היומנים, אפשר לשאול ולהציג יומנים ב-Grafana או באמצעות Log Query API. המלצות למכשור מופיעות בהנחיות לרישום ביומן של Kubernetes.

לפני שמתחילים

כדי לקבל את ההרשאות שדרושות לניהול משאבים בהתאמה אישית של LoggingTarget, בקשו ממנהל החשבון הארגוני או ממנהל הפרויקט ב-IAM להקצות לכם את אחד מהתפקידים המשויכים של LoggingTarget.

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

הגדרת המשאב בהתאמה אישית LoggingTarget

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

המשאב הזה מגדיר את ההגדרות הבאות:

  • ‫Targets: הקריטריונים לבחירת ה-pods והקונטיינרים שמהם רוצים לאסוף את היומנים. אפשר לציין שמות של אשכולות, קידומות של שמות Pods וקידומות של שמות קונטיינרים.
  • מנתח יומנים: מנתח מוגדר מראש שמפרש רשומות ביומן, ממפה פלטים של יומנים לתוויות ומחלץ שדות רלוונטיים.
  • זיהוי השירות: שם השירות שמופיע כתווית ברשומות ביומן, כדי שיהיה קל יותר לזהות ולסנן אותן.

  • הרשאה: רמת הגישה לרשומות ביומן, שקובעת מי יכול לראות את היומנים שנאספו.

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

כדי לאסוף יומני פעילות:

  1. בוחרים את הפרויקט ב-GDC שממנו רוצים לאסוף את היומנים.

  2. בהגדרות של 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.

  3. מחילים את ההגדרה 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.