Désactiver les transferts de logs et métriques d'un Dynamic Engine vers Talend Management Console

Par défaut, les logs d'exécution et les métriques des composants des Jobs sont automatiquement transféré·es vers Talend Management Console et peuvent être visualisé·es dans la page Run overview (Vue d'ensemble des exécutions). Vous pouvez désactiver ce transfert.

Mettez à jour la configuration ConfigMap nommée global-configuration de l'environnement de Dynamic Engine dans Kubernetes afin de désactiver le transfert de log de Dynamic Engine associé.

Grâce au type de déploiement Helm, il est simple de désactiver ce transfert au cours du déploiement ou de la mise à niveau du moteur. Pour plus d'informations, consultez Désactiver le transfert des logs et métriques après déploiement ou mise à niveau.

Pour plus d'informations concernant les commandes et flags kubectl, consultez kubectl Quick Reference (en anglais).

Pourquoi et quand exécuter cette tâche

Comprendre l'architecture de déploiement d'une instance de Dynamic Engine et de ses environnements de Dynamic Engine dans un cluster Kubernetes permet d'effectuer correctement les mises à jour :

Dynamic Engine et environnements de Dynamic Engine :
Chaque environnement de Dynamic Engine est attribué à un seul Dynamic Engine à la fois, mais plusieurs environnements sont autorisés par moteur.
Restriction relative au déploiement :

Seul un Dynamic Engine est autorisé dans le cluster Kubernetes mais plusieurs environnements de Dynamic Engine peuvent être déployés.
Isolation de la configuration :

Chaque environnement de Dynamic Engine a sa propre configuration global-configuration ConfigMap dédiée. Les mises à jour d'une configuration ConfigMap affectent uniquement l'environnement auquel cette configuration appartient.
Ressources personnalisées :

Les environnements de Dynamic Engine sont déployés en tant que ressource Kubernetes personnalisée de type (kind) nommée DynamicEngineEnv. Le nom de ressource d'un environnement de Dynamic Engine est également utilisé comme espace de noms. Les environnements appartiennent à la définition de ressource personnalisée dynamicengineenvs.apps.qlik.com.

Procédure

Obtenez le nom de l'espace de noms de l'environnement de Dynamic Engine à mettre à jour en exécutant cette commande :
```
kubectl get dynamicengineenvs.apps.qlik.com
```
La liste des ressources du type DynamicEngineEnv est retournée. Cela vous permet d'identifier l'environnement de Dynamic Engine pour lequel mettre à jour sa configuration ConfigMap. Par exemple, le nom de la ressource ou le nom de l'espace de noms à utiliser se présente comme suit : qlik-processing-env-66f2c0bb3e063d3518122259.
Ouvrez global-configuration ConfigMap pour mettre à jour la propriété concernant l'envoi de logs vers Talend Management Console :
```
kubectl edit cm -n qlik-processing-env-66f2c0bb3e063d3518122259 global-configuration
```
Dans cette commande, cm représente ConfigMap, -n représente l'espace de noms et qlik-processing-env-66f2c0bb3e063d3518122259 est le nom de l'espace de noms d'exemple de la ressource d'environnement de Dynamic Engine.
global-configuration ConfigMap est ouvert dans un éditeur de texte.
Passez chaque valeur true à false pour les propriétés suivantes, afin de désactiver les transferts :
- "logging":{"publishToTalendCloud":false} : cette propriété définit si les logs d'exécution sont transférés à Talend Management Console.
- "observability":{"componentMetricsFeatureEnabled": false} : cette propriété détermine si les métriques d'exécution sont transférées à Talend Management Console.
Sauvegardez le fichier.

Résultats

Après cette modification, les logs, même s'ils sont toujours créés dans le moteur, ne sont plus envoyés à Talend Management Console.

Dans cette situation, si vous avez besoin d'accéder aux logs, exécutez les commandes suivantes dans votre terminal Kubernetes :

```
kubectl logs --tail=20 -n qlik-processing-env-66f2c0bb3e063d3518122259 -l 'app.kubernetes.io/instance=di-job-controller'
```
Cette commande retourne les logs concernant le service créant les processus Kubernetes.
L'option --tail vous permet de spécifier le nombre de lignes de sortie de log à afficher.
```
kubectl logs --tail=20 -n qlik-processing-env-66f2c0bb3e063d3518122259 -l 'app.kubernetes.io/instance=di-job-deployer'
```
Cette commande retourne les logs concernant le service lisant le message de tâche depuis ActiveMQ et déclenche les processus Kubernetes.
```
kubectl logs --tail=20 -n qlik-processing-env-66f2c0bb3e063d3518122259 -l 'flowID=664c66ddb1ad64071d44b510'
```
Cette commande retourne les logs d'une tâche donnée. Le champ 'flowID=664c66ddb1ad64071d44b510' est l'ID de la tâche en question. Vous pouvez trouver cet ID sur la page dédiée de la tâche dans Talend Management Console ou en utilisant cet endpoint d'API.
```
kubectl logs --tail=20 -n qlik-processing-env-66f2c0bb3e063d3518122259 -l 'flowExecutionId=3c1d860a-e433-47c0-90bb-52a3b2b4fdfa'
```
Cette commande retourne les logs d'une exécution donnée. Le champ 'flowExecutionId=3c1d860a-e433-47c0-90bb-52a3b2b4fdfa' est l'ID d'exécution de la tâche ou du plan en question. Vous pouvez trouver cet ID à l'aide de cet endpoint d'API ou sur la page Task execution log (en anglais) dans Talend Management Console. Sur la page Task execution log, l'ID est nommé Task execution ID.

Conseil :

Vous pouvez utiliser -f pour spécifier si les logs doivent être mis en flux (stream) ou non.

Vous pouvez également utiliser kubectl logs --help pour voir toutes les commandes et options.

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.

Laissez vos commentaires ici