Collecter les journaux de vos workflows Kubernetes

La collecte de journaux dans Google Distributed Cloud (GDC) avec isolation physique vous permet d'agréger les événements opérationnels de vos workflows Kubernetes à des fins de surveillance et de dépannage. Déployez une ressource personnalisée LoggingTarget sur le serveur d'API de gestion pour extraire, indexer et étiqueter les journaux de projet des machines virtuelles (VM) des nœuds de calcul Kubernetes. Ce pipeline n'est pas compatible avec la collecte de journaux à partir de VM utilisateur autonomes.

Après avoir configuré la collecte des journaux, vous pouvez interroger et afficher les journaux dans Grafana ou via l'API Log Query. Pour obtenir des recommandations d'instrumentation, consultez les consignes de journalisation Kubernetes.

Avant de commencer

Pour obtenir les autorisations nécessaires pour gérer les ressources personnalisées LoggingTarget, demandez à votre administrateur d'organisation IAM ou à votre administrateur de projet IAM de vous accorder l'un des rôles LoggingTarget associés.

En fonction du niveau d'accès et des autorisations dont vous avez besoin, vous pouvez obtenir les rôles de créateur, d'éditeur ou de lecteur pour cette ressource dans une organisation ou un projet. Pour en savoir plus, consultez Préparer les autorisations IAM.

Configurer la ressource personnalisée LoggingTarget

La ressource personnalisée LoggingTarget indique au pipeline de journalisation de collecter les journaux dans votre projet GDC. Vous pouvez spécifier les cibles pour lesquelles vous collectez des journaux, un analyseur de journaux, des niveaux d'accès et d'autres paramètres.

Cette ressource définit les configurations suivantes :

  • Cibles : critères de sélection des pods et des conteneurs à partir desquels vous souhaitez collecter des journaux. Vous pouvez spécifier des noms de cluster, des préfixes de nom de pod et des préfixes de nom de conteneur.
  • Analyseur de journaux : analyseur prédéfini permettant d'interpréter les entrées de journal, de mapper les sorties de journal aux étiquettes et d'extraire les champs pertinents.
  • Identification du service : nom du service appliqué en tant qu'étiquette aux entrées de journal pour faciliter l'identification et le filtrage.

  • Autorisation : niveau d'accès des entrées de journal, qui contrôle qui peut afficher les journaux collectés.

En configurant ces paramètres dans la ressource personnalisée LoggingTarget, vous pouvez contrôler précisément la collecte et l'organisation des journaux.

Pour collecter les journaux opérationnels, procédez comme suit :

  1. Déterminez le projet GDC à partir duquel vous souhaitez collecter les journaux.

  2. Dans votre configuration LoggingTarget, spécifiez les pods pour collecter vos journaux opérationnels, l'espace de noms du projet et tous les paramètres supplémentaires.

    Le fichier YAML suivant montre un exemple de configuration LoggingTarget dans my-project-namespace, où le préfixe du nom du pod à partir duquel collecter les journaux est my-pod-prefix, le niveau d'accès aux entrées de journal est accordé aux opérateurs d'application (ao), le nom du service est my-service-name et le format de journal est 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

    Pour en savoir plus sur les champs et options supplémentaires, consultez la spécification LoggingTarget complète et la documentation de référence de l'API.

  3. Appliquez la configuration LoggingTarget au serveur d'API Management dans le même espace de noms que vos pods cibles :

    kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml

    Remplacez les éléments suivants :

    • KUBECONFIG_PATH : chemin d'accès au fichier kubeconfig du serveur d'API Management.
    • LOGGING_TARGET_NAME : nom du fichier de définition LoggingTarget, tel que my-logging-target.

    Le pipeline de journalisation commence à collecter les journaux des composants supplémentaires de votre projet.

Vous pouvez interroger les journaux collectés à l'aide de l'interface utilisateur Grafana ou de l'API Log Query. Pour en savoir plus, consultez Interroger et afficher les journaux.

Si vous utilisez Grafana pour interroger vos journaux, vous pouvez utiliser la fonctionnalité de codage couleur intégrée pour différents niveaux de journaux. Pour en savoir plus sur la définition des valeurs de niveau de journal, consultez https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Spécification LoggingTarget complète

Le fichier YAML suivant montre un exemple de spécification complète de la ressource personnalisée LoggingTarget. Pour en savoir plus et obtenir une description complète des champs, consultez la documentation de référence de l'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

Remplacez les éléments suivants :

  • PROJECT_NAMESPACE : l'espace de noms de votre projet.
  • LOGGING_TARGET_NAME : nom du fichier de définition LoggingTarget.