Collecter les journaux opérationnels de votre projet AO

Cette section explique comment collecter les journaux opérationnels d'un service dans une appliance Google Distributed Cloud (GDC) isolée pour la journalisation système et l'observabilité des données.

La plate-forme de journalisation fournit une API Kubernetes personnalisée pour collecter les journaux au niveau du projet que vos services génèrent via des cibles de journalisation système. Vous devez déployer une ressource personnalisée LoggingTarget dans l'espace de noms de votre projet dans le cluster d'administrateur de l'organisation. À partir de cette ressource, la plate-forme Logging commence à collecter les données de journalisation de votre système. Accédez à ces journaux à l'aide de l'interface utilisateur (UI) de l'outil de surveillance du systèmeou de l'API GDC Logging, en suivant les étapes de Interroger et afficher les journaux.

Pour en savoir plus sur les bonnes pratiques à suivre pour implémenter la journalisation des composants de Kubernetes, consultez https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Avant de commencer

Pour obtenir les autorisations nécessaires pour collecter ou afficher les journaux opérationnels collectés, demandez à votre administrateur IAM de projet de vous accorder l'un des rôles suivants dans l'espace de noms de votre projet :

  • Logging Target Creator : crée des ressources personnalisées LoggingTarget. Demandez le rôle de créateur de cibles de journaux (loggingtarget-creator).
  • Éditeur de cibles de journalisation : permet de modifier les ressources personnalisées LoggingTarget. Demandez le rôle Éditeur de cibles de journaux (loggingtarget-editor).
  • Visionneuse de cibles de journalisation : affiche les ressources personnalisées LoggingTarget. Demandez le rôle Lecteur de cibles de journaux (loggingtarget-viewer).

Configurer la collecte des journaux opérationnels d'un service

Les journaux opérationnels enregistrent les conditions, les modifications et les actions lorsque vous gérez les opérations en cours dans les applications et les services sur GDC. Déployez la ressource personnalisée LoggingTarget sur le cluster d'administrateur de l'organisation pour configurer le pipeline de journalisation système afin de collecter les journaux opérationnels de services spécifiques au niveau du projet.

Pour collecter les journaux opérationnels d'un service, procédez comme suit :

  1. Configurez le CR LoggingTarget en spécifiant les pods sélectionnés pour collecter vos journaux opérationnels, l'espace de noms du projet et tous les paramètres supplémentaires. Pour en savoir plus, consultez Configurer la ressource personnalisée LoggingTarget.
  2. Déployez le CR LoggingTarget dans l'espace de noms de votre projet dans le cluster d'administrateur de l'organisation. Le pipeline commence à collecter les journaux des composants supplémentaires de votre projet.
  3. Interrogez vos journaux à partir de l'instanceinstance de surveillance du système de votre projet. Pour en savoir plus, consultez Interroger et afficher les journaux.

Utilisez la fonctionnalité de code couleur intégrée pour les différents niveaux de journaux du service. Pour en savoir plus sur la définition des valeurs de niveau de journalisation, consultez https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Configurer la ressource personnalisée LoggingTarget

La ressource personnalisée LoggingTarget indique au pipeline de journalisation du système de collecter les journaux de services spécifiques de votre projet et de fournir l'observabilité des données. Vous devez déployer cette ressource dans l'espace de noms à partir duquel vous souhaitez collecter des journaux.

Le fichier YAML suivant montre un exemple de configuration 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

Remplacez les éléments suivants :

  • PROJECT_NAMESPACE : espace de noms de votre projet
  • CLUSTER_NAME : nom du cluster
  • POD_NAME : préfixe du nom du pod
  • CONTAINER_NAME : préfixe du nom du conteneur
  • SERVICE_NAME : nom du service.

Les champs parser, logAccessLevel et additionalFields contiennent des exemples de valeurs que vous pouvez modifier.

Par défaut, toutes les entrées de journaux opérationnels sont enregistrées pour l'ID de locataire de l'espace de noms du projet. Pour remplacer ce comportement, indiquez une valeur logAccessLevel dans la ressource personnalisée LoggingTarget.