Mengumpulkan log operasional dari project AO Anda

Bagian ini menjelaskan cara mengumpulkan log operasional dari layanan di perlengkapan air-gapped Google Distributed Cloud (GDC) untuk logging sistem dan kemampuan pengamatan data.

Platform Logging menyediakan Kubernetes API kustom untuk mengumpulkan log tingkat project yang dihasilkan layanan Anda melalui target logging sistem. Anda harus men-deploy resource kustom LoggingTarget ke namespace project di cluster admin org. Berdasarkan resource ini, platform Logging mulai mengumpulkan data logging sistem Anda. Akses log tersebut menggunakan antarmuka pengguna (UI) alat pemantauan sistem atau GDC Logging API, dengan mengikuti langkah-langkah Membuat kueri dan melihat log.

Untuk mengetahui informasi tentang praktik terbaik dalam menerapkan logging untuk komponen Kubernetes, lihat https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Sebelum memulai

Untuk mendapatkan izin yang diperlukan untuk mengumpulkan log operasional atau melihat log operasional yang dikumpulkan, minta Admin IAM Project Anda untuk memberi Anda salah satu peran berikut di namespace project Anda:

  • Logging Target Creator: membuat resource kustom LoggingTarget. Minta peran Logging Target Creator (loggingtarget-creator).
  • Editor Target Logging: mengedit atau mengubah LoggingTarget resource kustom. Minta peran Logging Target Editor (loggingtarget-editor).
  • Logging Target Viewer: melihat LoggingTarget resource kustom. Minta peran Logging Target Viewer (loggingtarget-viewer).

Mengonfigurasi pengumpulan log operasional dari layanan

Log operasional mencatat kondisi, perubahan, dan tindakan saat Anda mengelola operasi yang sedang berlangsung di aplikasi dan layanan di GDC. Deploy resource kustom LoggingTarget ke cluster admin org untuk mengonfigurasi pipeline logging sistem guna mengumpulkan log operasional dari layanan tertentu di tingkat project.

Selesaikan langkah-langkah berikut untuk mengumpulkan log operasional dari layanan:

  1. Konfigurasi CR LoggingTarget, dengan menentukan pod yang dipilih untuk mengumpulkan log operasional, namespace project, dan setelan tambahan. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi resource kustom LoggingTarget.
  2. Deploy CR LoggingTarget ke namespace project Anda di cluster admin org. Pipeline mulai mengumpulkan log dari komponen tambahan project Anda.
  3. Kueri log Anda dari instance Grafana instance pemantauan sistem project Anda. Untuk mengetahui informasi selengkapnya, lihat Mengueri dan melihat log.

Gunakan fitur kode warna bawaan untuk berbagai level log layanan. Untuk mengetahui informasi selengkapnya tentang cara menyetel nilai tingkat log, lihat https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Mengonfigurasi resource kustom LoggingTarget

Resource kustom LoggingTarget menginstruksikan pipeline logging sistem untuk mengumpulkan log dari layanan tertentu di project Anda dan memberikan kemampuan observasi data. Anda harus men-deploy resource ini ke namespace tempat Anda ingin mengumpulkan log.

File YAML berikut menunjukkan contoh konfigurasi LoggingTarget:

# 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: my-service-logging-target
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.
    # For example, the value '["admin", "system"]' indicates to consider
    # the admin cluster 'OR' the system cluster.
    # Optional
    matchClusters:
    - CLUSTER_NAME
    - CLUSTER_NAME

    # The pod name prefixes to collect logs from.
    # The Observability 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:
      - POD_NAME
      - POD_NAME

    # The container name prefixes to collect logs from.
    # The Observability 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:
      - CONTAINER_NAME
      - CONTAINER_NAME

  # 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: 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

Ganti kode berikut:

  • PROJECT_NAMESPACE: namespace project Anda
  • CLUSTER_NAME: nama cluster
  • POD_NAME: awalan nama pod
  • CONTAINER_NAME: awalan nama container
  • SERVICE_NAME: nama layanan

Kolom parser, logAccessLevel, dan additionalFields berisi contoh nilai yang dapat Anda ubah.

Secara default, semua entri log operasional disimpan untuk ID tenant namespace project. Untuk mengganti perilaku ini, berikan nilai logAccessLevel di resource kustom LoggingTarget.