Raccogliere i log dai workflow

Questa pagina descrive la procedura per raccogliere i log dai workflow negli ambienti con air gap di Google Distributed Cloud (GDC) per facilitare la registrazione e l'osservabilità dei dati.

I log registrano condizioni e azioni durante la gestione delle operazioni in GDC. Puoi estrarre i log prodotti dai tuoi componenti per registrare eventi e attività. La piattaforma di logging offre un'API personalizzata per raccogliere i log a livello di progetto generati dai tuoi flussi di lavoro tramite le destinazioni di logging.

Per iniziare a raccogliere i dati di log, implementa una risorsa personalizzata LoggingTarget nello spazio dei nomi del progetto nel server dell'API Management. Dopo che il raccoglitore di log estrae i dati dai tuoi flussi di lavoro, la piattaforma di logging aggrega i log di tutte le origini di log, aggiunge indici e associa i log alle etichette in base alla configurazione della risorsa personalizzata LoggingTarget.

Accedi ai log raccolti utilizzando l'interfaccia utente di Grafana o l'API Log Query, come descritto in Eseguire query e visualizzare i log.

Per le best practice sull'implementazione della registrazione per l'osservabilità dei dati, consulta le linee guida della community Kubernetes:

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Prima di iniziare

Per ottenere le autorizzazioni necessarie per gestire le risorse personalizzate LoggingTarget, chiedi all'amministratore IAM dell'organizzazione o all'amministratore IAM del progetto di concederti uno dei ruoli LoggingTarget associati.

A seconda del livello di accesso e delle autorizzazioni di cui hai bisogno, potresti ottenere i ruoli di creatore, editor o visualizzatore per questa risorsa in un'organizzazione o in un progetto. Per maggiori informazioni, vedi Preparare le autorizzazioni IAM.

Configurare la risorsa personalizzata LoggingTarget

La risorsa personalizzata LoggingTarget indica alla pipeline di logging di raccogliere i log all'interno del tuo progetto GDC. Puoi specificare i target per cui raccogli i log, un parser dei log, i livelli di accesso e qualsiasi impostazione aggiuntiva.

Questa risorsa definisce le seguenti configurazioni:

  • Target: i criteri per selezionare i pod e i container da cui vuoi raccogliere i log. Puoi specificare i nomi dei cluster, i prefissi dei nomi dei pod e i prefissi dei nomi dei container.
  • Strumento di analisi log: un parser predefinito per interpretare le voci di log, mappare gli output di log alle etichette ed estrarre i campi pertinenti.
  • Identificazione del servizio: il nome del servizio applicato come etichetta alle voci di log per una più facile identificazione e filtraggio.

  • Autorizzazione: il livello di accesso per le voci di log, che controlla chi può visualizzare i log raccolti.

Configurando questi parametri all'interno della risorsa personalizzata LoggingTarget, puoi controllare con precisione la raccolta e l'organizzazione dei log.

Per raccogliere i log operativi:

  1. Determina il progetto GDC da cui vuoi raccogliere i log.

  2. Nella configurazione LoggingTarget, specifica i pod per la raccolta dei log operativi, lo spazio dei nomi del progetto e qualsiasi altra impostazione aggiuntiva.

    Il seguente file YAML mostra un esempio di configurazione LoggingTarget in my-project-namespace, dove il prefisso del nome del pod da cui raccogliere i log è my-pod-prefix, il livello di accesso alle voci di log è concesso agli operatori dell'applicazione (ao), il nome del servizio è my-service-name e il formato dei log è 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

    Per ulteriori campi e opzioni, consulta la specifica LoggingTarget completa e la documentazione di riferimento dell'API.

  3. Applica la configurazione LoggingTarget al server API Management all'interno dello stesso spazio dei nomi dei pod di destinazione:

    kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml

    Sostituisci quanto segue:

    • KUBECONFIG_PATH: il percorso del file kubeconfig per il server dell'API di gestione.
    • LOGGING_TARGET_NAME: il nome del file di definizione LoggingTarget, ad esempio my-logging-target.

    La pipeline di logging inizia a raccogliere i log dai componenti aggiuntivi del tuo progetto.

Puoi eseguire query sui log raccolti utilizzando l'interfaccia utente di Grafana o l'API Log Query. Per maggiori informazioni, vedi Esecuzione di query e visualizzazione dei log.

Se utilizzi Grafana per eseguire query sui log, puoi utilizzare la funzionalità di codifica a colori integrata per i diversi livelli di log. Per ulteriori informazioni sull'impostazione dei valori del livello di log, consulta https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Specifiche LoggingTarget complete

Il seguente file YAML mostra un esempio per la specifica completa della risorsa personalizzata LoggingTarget. Per ulteriori informazioni e una descrizione completa dei campi, consulta la documentazione di riferimento dell'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

Sostituisci quanto segue:

  • PROJECT_NAMESPACE: lo spazio dei nomi del progetto.
  • LOGGING_TARGET_NAME: il nome del file di definizione LoggingTarget.