Cette page a été traduite par l'API Cloud Translation.

Collecter des journaux à partir de vos workflows

Cette page décrit le processus de collecte des journaux de vos workflows dans les environnements d'appliance Google Distributed Cloud (GDC) isolés pour faciliter la journalisation et l'observabilité des données.

Les journaux enregistrent les conditions et les actions lorsque vous gérez les opérations de vos services dans GDC. Vous pouvez extraire les journaux générés par vos composants pour enregistrer les événements et les activités. La plate-forme de journalisation propose une API personnalisée pour collecter les journaux au niveau du projet générés par vos workflows via des cibles de journalisation.

Pour commencer à collecter des données de journaux, déployez une ressource personnalisée LoggingTarget dans l'espace de noms de votre projet sur le serveur de l'API Management. Une fois que le collecteur de journaux extrait les données de vos workflows, la plate-forme de journalisation agrège les journaux de toutes les sources de journaux, ajoute des index et associe les journaux à des libellés en fonction de la configuration de la ressource personnalisée LoggingTarget.

Accédez aux journaux collectés à l'aide de l'interface utilisateur Grafana, comme indiqué dans Interroger et afficher les journaux.

Pour connaître les bonnes pratiques d'implémentation de la journalisation pour l'observabilité des données, consultez les consignes de la communauté Kubernetes :

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

Avant de commencer

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

Selon le niveau d'accès et les autorisations dont vous avez besoin, vous pouvez obtenir des 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.

Opérateurs d'application : pour obtenir les autorisations nécessaires pour gérer les ressources personnalisées LoggingTarget dans un projet sur le serveur de l'API Management, demandez à votre administrateur IAM de projet de vous accorder l'un des rôles suivants dans l'espace de noms de votre projet :
- LoggingTarget Creator : crée des ressources personnalisées LoggingTarget. Demandez le rôle Créateur de LoggingTarget (loggingtarget-creator).
- Éditeur LoggingTarget : permet de modifier les ressources personnalisées LoggingTarget. Demandez le rôle Éditeur LoggingTarget (loggingtarget-editor).
- Lecteur LoggingTarget : affiche les ressources personnalisées LoggingTarget. Demandez le rôle Lecteur de LoggingTarget (loggingtarget-viewer).
Administrateurs de plate-forme : pour obtenir les autorisations nécessaires pour gérer les ressources personnalisées LoggingTarget dans l'espace de noms platform-obs du serveur de l'API Management, demandez à votre administrateur IAM de l'organisation de vous accorder l'un des rôles de cluster suivants dans l'espace de noms platform-obs :
- LoggingTarget PA Creator : crée des ressources personnalisées LoggingTarget. Demandez le rôle de cluster LoggingTarget PA Creator (loggingtarget-pa-creator).
- Éditeur PA LoggingTarget : modifie les ressources personnalisées LoggingTarget. Demandez le rôle de cluster Éditeur PA LoggingTarget (loggingtarget-pa-editor).
- Lecteur PA LoggingTarget : affiche les ressources personnalisées LoggingTarget. Demandez le rôle de cluster Lecteur de PA LoggingTarget (loggingtarget-pa-viewer).

Collecter les journaux opérationnels

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 serveur de l'API Management pour configurer le pipeline de journalisation du 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 :

Configurez la ressource personnalisée LoggingTarget dans le serveur de l'API Management, 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 savoir à quoi doit ressembler le LoggingTarget, consultez Configurer la ressource personnalisée LoggingTarget.
Déployez la ressource personnalisée LoggingTarget dans l'espace de noms de votre projet sur le serveur de l'API Management :
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME
```
Remplacez les éléments suivants :
- MANAGEMENT_API_SERVER : chemin d'accès au fichier kubeconfig du serveur de l'API Management zonale.
- LOGGING_TARGET_NAME : nom de la ressource personnalisée LoggingTarget, par exemple my-service-logging-target.yaml.
Le pipeline commence à collecter les journaux des composants supplémentaires de votre projet.
Interrogez vos journaux à partir de l'instance Grafana de votre projet. Pour en savoir plus, consultez Interroger et afficher les journaux.

Utilisez la fonctionnalité de code couleur intégrée de Grafana 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 de collecter les journaux de services spécifiques 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 des paramètres supplémentaires.

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 journaux, de mapper les sorties de journaux sur des libellés et d'extraire les champs pertinents.
Identification du service : nom du service appliqué en tant que libellé aux entrées de journal pour faciliter l'identification et le filtrage.
Autorisation : niveau d'accès aux entrées de journal, qui contrôle qui peut afficher les journaux collectés.

Remarque : 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.

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 de vos services.

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

Déterminez le projet GDC à partir duquel vous souhaitez collecter les journaux.
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 du 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-service-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name
```
Consultez la spécification complète de LoggingTarget et la documentation de référence de l'API pour découvrir d'autres champs et options.
Appliquez la configuration LoggingTarget au serveur de l'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 pour le serveur de l'API Management.
- LOGGING_TARGET_NAME : nom du fichier de définition LoggingTarget, tel que my-service-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 code couleur intégrée pour les différents niveaux de journalisation 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/.

Spécification complète de `LoggingTarget`

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 sur les 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 : espace de noms de votre projet.
LOGGING_TARGET_NAME : nom du fichier de définition LoggingTarget.