Simple Log Service:Dépannage des problèmes de collecte de journaux de conteneurs

FAQ : Pourquoi n'y a-t-il pas de signal de maintien de connexion (heartbeat) après le déploiement de Docker/LoongCollector ?

Si LoongCollector ou Logtail n'envoie pas de signal de maintien de connexion (heartbeat) ou ne parvient pas à s'enregistrer auprès du groupe de machines après le déploiement Docker, la cause racine est généralement une configuration manquante de l'identifiant utilisateur (AliUID).

Solution :

1. Sur la machine hôte, créez le répertoire /etc/ilogtail/users/.

   mkdir -p /etc/ilogtail/users/

2. Dans le répertoire /etc/ilogtail/users/, créez un fichier vide nommé avec votre ID de compte Alibaba Cloud.

   touch /etc/ilogtail/users/<your-alibaba-cloud-account-id>

3. Lors du démarrage du conteneur LoongCollector ou Logtail, montez le répertoire en lecture seule en ajoutant l'indicateur suivant :

   -v /etc/ilogtail/users:/etc/ilogtail/users:ro

4. Redémarrez le conteneur LoongCollector ou Logtail.

Vérification : connectez-vous à la console SLS, accédez à Resources > Machine Groups et trouvez le groupe de machines cible. Cliquez sur Check Status dans la colonne Actions. Dans la boîte de dialogue View Machine Group Status, confirmez que le statut du signal de maintien de connexion (heartbeat) du groupe de machines est passé à OK.

FAQ : Pourquoi le groupe de machines n'affiche-t-il qu'un seul serveur lorsque plusieurs serveurs Docker Swarm signalent la même adresse IP ?

Cause : dans un cluster Docker Swarm, plusieurs serveurs peuvent signaler la même adresse IP interne via le réseau de conteneurs. Si ces serveurs partagent également la même valeur de variable d'environnement ALIYUN_LOGTAIL_USER_DEFINED_ID, le système ne peut pas les distinguer et la section Machine Groups n'affiche qu'une seule entrée.

Solution 1 : définissez une variable d'environnement ALIYUN_LOGTAIL_USER_DEFINED_ID unique pour le conteneur Logtail sur chaque serveur.

Définissez une valeur différente sur chaque serveur et assurez-vous que la valeur correspond à la configuration du Machine Groups correspondant. Par exemple :

-e ALIYUN_LOGTAIL_USER_DEFINED_ID=<unique-id-for-this-server>

Solution 2 : définissez la variable d'environnement ALIYUN_LOGTAIL_WORKING_IP pour spécifier manuellement une adresse IP unique pour chaque serveur.

Utilisez une valeur qui identifie de manière unique chaque hôte, telle que l'adresse IP publique de l'hôte ou une adresse IP de réseau interne unique sur tous les serveurs :

-e ALIYUN_LOGTAIL_WORKING_IP=<unique-ip-for-this-server>

Si vous ne trouvez aucun journal sur la page Preview ou sur la page de requête du Logstore dans la console Simple Log Service, il se peut que Simple Log Service ne collecte pas vos journaux de conteneurs. Vérifiez l'état du conteneur, puis effectuez les vérifications suivantes.

Le groupe de machines ne couvre pas tous les nœuds de conteneurs

Symptôme : le signal de maintien de connexion (heartbeat) du groupe de machines est normal, mais la collecte de journaux depuis certains conteneurs s'est arrêtée.

Ce problème peut survenir lorsque les conteneurs s'exécutent sur des serveurs qui ne sont pas inclus dans le Machine Groups.

Étapes de dépannage :

1. Sur tous les serveurs concernés, exécutez la commande suivante pour identifier les nœuds sur lesquels les conteneurs s'exécutent réellement :

   docker ps -a | grep <container-name>

2. Si un conteneur s'exécute sur un serveur qui n'a pas été ajouté au groupe de machines, ajoutez l'adresse IP de ce serveur au Machine Groups dans la console SLS.

FAQ : Pourquoi ne puis-je pas trouver le Pod dans la prévisualisation des métadonnées du conteneur, ou pourquoi les journaux ne peuvent-ils pas être collectés depuis emptyDir ?

Cause : Logtail, exécuté en mode DaemonSet, ne peut pas accéder directement au stockage temporaire emptyDir à l'intérieur d'un conteneur. Cela empêche Logtail de lire les fichiers journaux et d'extraire les métadonnées du conteneur, de sorte que le Pod ne peut pas être trouvé dans la section Preview des métadonnées du conteneur.

Solution 1 (recommandée) : redirigez la sortie des journaux de l'application vers la sortie standard (stdout/stderr).

1. Modifiez votre application pour qu'elle écrive les journaux sur stdout ou stderr au lieu de fichiers.

2. Dans la console SLS, configurez le chemin de collecte pour utiliser le chemin de journal Kubernetes standard :

   /logtail_host/var/log/pods/<namespace>_<pod-name>-<uid>/<container-name>/*.log

Solution 2 : si votre application doit écrire les journaux dans des fichiers, changez le montage du volume de journalisation de emptyDir vers hostPath ou PVC.

1. Dans la spécification de votre Pod, remplacez le volume emptyDir par une définition hostPath ou PVC afin que les journaux soient persistés sur un chemin accessible depuis l'hôte.

2. Ajustez le chemin de collecte SLS pour qu'il pointe vers le chemin de montage réel sur l'hôte, par exemple :

   /logtail_host/var/log/your-app/*.log

FAQ : Comment gérer les échecs de création de fichiers ou les erreurs d'autorisation lors de la collecte de journaux de conteneurs ?

Symptôme : un message d'erreur indique que Logtail doit créer un fichier vide spécifique à l'intérieur du conteneur, mais la création du fichier échoue ou une erreur d'autorisation est signalée.

Solution :

1. Créez manuellement le fichier vide spécifié dans le message d'erreur à l'intérieur du conteneur.

2. Définissez les autorisations du fichier sur -rw-r--r-- (644) :

   chmod 644 <file-path>

3. Redémarrez le conteneur.

Alternative : si le problème persiste après les étapes ci-dessus, montez le répertoire des journaux du conteneur sur la machine hôte et configurez SLS pour collecter les journaux depuis le chemin hôte correspondant. Cette approche est plus stable que la collecte de fichiers à l'intérieur du conteneur.

FAQ : Comment gérer l'erreur « parse cri docker line error: invalid CRI log, timestamp not found » ?

Cause : l'analyse des journaux échoue. Cette erreur est couramment causée par une configuration incorrecte des journaux multilignes.

Solution :

1. Vérifiez et ajustez l'expression régulière de début de ligne, ou désactivez le mode multiligne :

   • Dans la configuration YAML : commentez la section de configuration multiline.

   • Dans la console SLS : ouvrez la configuration Logtail et désactivez le mode multiligne.

2. Vérifiez que les champs de format, tels que K8s Namespace Regex, sont corrects. Si vous devez spécifier plusieurs namespaces, assurez-vous qu'ils sont séparés par le délimiteur approprié.

3. Après avoir modifié la configuration YAML, réappliquez-la pour prendre en compte les changements :

   kubectl apply -f <your-config-file>.yaml

FAQ : Que faire si un point d'exclamation rouge apparaît à côté du plug-in d'analyse JSON et que la configuration Logtail ne peut pas être enregistrée ?

Symptôme : après avoir ajouté un plug-in d'analyse JSON à une configuration Logtail, un point d'exclamation rouge apparaît à côté de l'icône du plug-in et la configuration ne peut pas être enregistrée dans la boîte de dialogue.

Cause : le point d'exclamation rouge indique généralement que le plug-in n'est pas configuré ou que la configuration a été modifiée mais non appliquée.

Solution :

1. Sur la page de modification de la configuration Logtail, supprimez le plug-in d'analyse JSON ajouté par défaut.

2. Ajoutez manuellement à nouveau un plug-in d'analyse JSON et renseignez tous les champs requis, tels que l'exemple de journal et les règles d'analyse.

3. Une fois la configuration terminée, le point d'exclamation rouge disparaît et vous pouvez enregistrer la configuration Logtail.

FAQ : Que faire si aucune donnée n'est collectée car plusieurs configurations Logtail correspondent au même fichier (MULTI CONFIG MATCH ALARM) ?

Symptôme : l'alerte MULTI CONFIG MATCH ALARM apparaît dans les journaux opérationnels de Logtail et aucune donnée n'est collectée depuis le fichier cible.

Cause : par défaut, un fichier journal ne peut correspondre qu'à une seule configuration Logtail. Lorsque plusieurs configurations Logtail correspondent au même fichier, une seule d'entre elles prend effet. Les autres configurations ne peuvent pas collecter de données et déclenchent l'alerte MULTI CONFIG MATCH ALARM.

Solution :

1. Supprimez les configurations Logtail redondantes : dans la console Simple Log Service, vérifiez toutes les configurations Logtail liées aux Machine Groups. Supprimez les configurations dupliquées ou inutilisées afin que chaque fichier ne corresponde qu'à une seule configuration.

2. Séparez la correspondance par nom de pod : si vous avez besoin de plusieurs configurations pour le même fichier, par exemple pour séparer la collecte par nom de pod, modifiez les configurations comme décrit dans la documentation officielle. Assurez-vous que chaque configuration Logtail ne correspond qu'à son propre fichier cible grâce à un chemin ou un filtre de libellé plus précis, et évitez les chevauchements de chemins.

3. Après la modification, vérifiez les journaux opérationnels de Logtail et confirmez que l'alerte MULTI CONFIG MATCH ALARM a disparu et que les données sont collectées comme prévu.

FAQ : Comment gérer l'erreur Logtail no such file or directory lors de la collecte de journaux de conteneurs ?

Symptôme : les journaux opérationnels de Logtail contiennent l'erreur no such file or directory et les journaux du conteneur cible ne peuvent pas être collectés. Assurez-vous qu'un index est créé pour le LogStore afin que les journaux puissent être interrogés et analysés après la collecte.

Cause : le chemin de collecte cible n'existe pas sur le nœud. Ce problème est généralement lié au cycle de vie des pods Kubernetes ou au mécanisme de rotation des journaux.

Solution :

1. Vérifiez si le pod existe toujours : si le pod a été supprimé, le chemin de journal correspondant n'existe plus et vous pouvez ignorer l'erreur. Si le pod est toujours en cours d'exécution, connectez-vous au serveur (nœud) et vérifiez si le chemin de journal réel existe.

2. Utilisez la collecte stdout du conteneur lorsque c'est possible : lors de la création d'une configuration de collecte de journaux dans la console ACK, sélectionnez le type Container Stdout et faites correspondre le conteneur cible par libellé de conteneur ou nom de conteneur, au lieu de vous fier au chemin de fichier interne au conteneur.

3. Suggestions de configuration lorsque la collecte de fichiers est requise : utilisez un chemin avec joker, par exemple /logtail_host/var/log/pods/*/*.log, et activez la découverte automatique de nouveaux fichiers dans la configuration Logtail afin que Logtail puisse suivre les nouveaux chemins après la rotation des journaux ou la recréation des pods.

4. Vérifiez que la configuration Logtail est appliquée au groupe de machines : assurez-vous que la configuration Logtail est liée aux Machine Groups qui contiennent le pod cible.

5. Vérifiez les journaux opérationnels de Logtail : si un grand nombre d'erreurs sont concentrées sur des pods déjà détruits, vous pouvez les ignorer. Si les erreurs persistent et que le pod est toujours en cours d'exécution, corrigez le chemin de collecte ou vérifiez le montage du nœud.

FAQ : Comment gérer l'interruption de la collecte causée par Logtail ignorant les fichiers en raison de logfiletoobig ?

Symptôme : l'alerte logfiletoobig apparaît dans les journaux opérationnels de Logtail, le fichier cible est ignoré et la collecte de journaux est interrompue.

Cause : la taille du fichier journal cible dépasse la limite par défaut de Logtail. Logtail ignore le fichier pour protéger sa stabilité.

Solution :

1. Ajustez les paramètres de collecte de Logtail : dans la configuration Logtail ou dans les paramètres globaux des Machine Groups, apportez les modifications suivantes :

   • Augmentez MaxLogFileSize, par exemple à 1GB, pour éviter que les fichiers volumineux ne soient ignorés.

   • Augmentez MaxLogFileInodeCacheSize, par exemple à 2000, pour améliorer le suivi des fichiers après rotation.

   • Définissez EnableContainerDiscovery sur true afin que Logtail puisse découvrir automatiquement les chemins de journaux des conteneurs et créer automatiquement des entrées de suivi pour les nouveaux pods.

2. Déclenchez une nouvelle analyse : dans le cluster ACK, exécutez la commande suivante pour supprimer le pod loongcollector-ds (ou Logtail-ds). Le DaemonSet recrée automatiquement le pod et réanalyse tous les chemins de journaux des conteneurs :

   kubectl delete pod -n kube-system -l k8s-app=loongcollector-ds

3. Vérifiez le résultat ou utilisez une alternative : vérifiez l'état de réception des journaux dans la console Simple Log Service et examinez s'il reste des erreurs résiduelles dans le pod Logtail. Si les méthodes précédentes ne fonctionnent pas, essayez la configuration K8s-Stdout-New et activez la prévisualisation des métadonnées du conteneur pour collecter les journaux via le chemin stdout au lieu du chemin de fichier.

Connexion à un conteneur Logtail

• Docker standard

  1. Sur l'hôte, exécutez la commande suivante pour trouver le conteneur Logtail.

     docker ps | grep logtail

     Le résultat ressemble à ce qui suit :

     223****6e        registry.cn-hangzhou.aliyuncs.com/log-service/logtail                             "/usr/local/ilogta..."   8 days ago          Up 8 days                               logtail-iba

  2. Exécutez la commande suivante pour démarrer un shell bash dans le conteneur Logtail.

     docker exec -it 223****6e  bash

     Remplacez 223****6e par l'ID réel du conteneur.

• Kubernetes

  1. Exécutez la commande suivante pour trouver le pod Logtail.

     kubectl get po -n kube-system | grep logtail

     Le résultat ressemble à ce qui suit :

     logtail-ds-****d                                             1/1       Running    0          8d
     logtail-ds-****8                                             1/1       Running    0          8d

  2. Exécutez la commande suivante pour vous connecter au pod.

     kubectl exec -it -n kube-system logtail-ds-****d -- bash

     Remplacez logtail-ds-****d par l'ID réel du pod.

Affichage des journaux d'exécution de Logtail

Logtail stocke ses journaux dans le répertoire /usr/local/ilogtail/ du conteneur Logtail. Les fichiers journaux sont ilogtail.LOG et logtail_plugin.LOG.

1. Connectez-vous au conteneur Logtail. Pour plus d'informations, reportez-vous à la rubrique Connexion à un conteneur Logtail.

2. Accédez au répertoire /usr/local/ilogtail/.

   cd /usr/local/ilogtail

3. Consultez les fichiers ilogtail.LOG et logtail_plugin.LOG.

   cat ilogtail.LOG
   cat logtail_plugin.LOG

Sortie standard (stdout) du conteneur Logtail

La sortie standard d'un conteneur Logtail ne fournit pas d'informations utiles pour le dépannage. Vous pouvez ignorer le contenu suivant.

start umount useless mount points, /shm$|/merged$|/mqueue$
umount: /logtail_host/var/lib/docker/overlay2/3fd0043af174cb0273c3c7869500fbe2bdb95d13b1e110172ef57fe840c82155/merged: must be superuser to unmount
umount: /logtail_host/var/lib/docker/overlay2/d5b10aa19399992755de1f85d25009528daa749c1bf8c16edff44beab6e69718/merged: must be superuser to unmount
umount: /logtail_host/var/lib/docker/overlay2/5c3125daddacedec29df72ad0c52fac800cd56c6e880dc4e8a640b1e16c22dbe/merged: must be superuser to unmount
......
xargs: umount: exited with status 255; aborting
umount done
start logtail
ilogtail is running
logtail status:
ilogtail is running

Vérification du statut des composants Kubernetes

Exécutez la commande suivante pour afficher le statut et les informations du déploiement Simple Log Service.

kubectl get deploy -n kube-system | grep -E 'alibaba-log-controller|loongcollector-operator'

Le résultat suivant est renvoyé :

NAME                     READY   UP-TO-DATE   AVAILABLE   AGE
alibaba-log-controller   1/1     1            1           11d

Exécutez la commande suivante pour afficher les informations de statut de la ressource DaemonSet.

kubectl get ds  -n kube-system | grep -E 'logtail-ds|loongcollector-ds'

Le résultat suivant est renvoyé :

NAME         DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR  AGE
logtail-ds   2         2         2       2            2           **ux           11d

Version, adresse IP et heure de démarrage de Logtail

1. Sur l'hôte, exécutez la commande suivante pour afficher la version, l'adresse IP et l'heure de démarrage de Logtail.

   Les informations sont stockées dans le fichier /usr/local/ilogtail/app_info.json du conteneur Logtail.

   kubectl exec logtail-ds-****k -n kube-system cat /usr/local/ilogtail/app_info.json

   Le résultat ressemble à ce qui suit :

   {
      "UUID" : "",
      "hostname" : "logtail-****k",
      "instance_id" : "0EB****_172.20.4.2_1517810940",
      "ip" : "172.20.4.2",
      "logtail_version" : "0.16.2",
      "os" : "Linux; 3.10.0-693.2.2.el7.x86_64; #1 SMP Tue Sep 12 22:26:13 UTC 2017; x86_64",
      "update_time" : "2018-02-05 06:09:01"
   }

Obtention d'informations de dépannage pour les journaux de Pod dans un cluster ACK

Si la collecte de journaux pour un Pod dans un cluster ACK est anormale, vous pouvez utiliser les étapes suivantes pour obtenir les informations de base nécessaires au dépannage autonome ou pour les fournir au support technique.

Étape 1 : trouvez le nom du pod Logtail ou LoongCollector.

kubectl get pods -n kube-system | grep loongcollector

Étape 2 : obtenez l'adresse IP de l'instance Logtail ou LoongCollector à partir du fichier app_info.json.

kubectl exec <pod-name> -n kube-system cat /usr/local/ilogtail/app_info.json

Le champ ip dans la sortie JSON renvoyée correspond à l'adresse IP de l'instance Logtail.

Lorsque vous sollicitez le support, fournissez les informations suivantes pour faciliter le dépannage :

• Nom du projet SLS

• Nom de la configuration de collecte Logtail

• Nom du Pod cible

• Nom du conteneur cible

Gestion des Logstores CRD supprimés accidentellement

Si vous supprimez un Logstore créé automatiquement par une Custom Resource Definition (CRD), les données collectées sont irrécupérables et la configuration CRD pour le Logstore devient invalide. Pour éviter des problèmes de collecte de journaux, choisissez l'une des solutions suivantes :

• Dans la configuration CRD, utilisez un Logstore différent de celui que vous avez supprimé.

• Redémarrez le pod alibaba-log-controller.

  Exécutez la commande suivante pour trouver le pod.

  kubectl get po -n kube-system | grep alibaba-log-controller

FAQ : L'exécution de docker pull pour télécharger l'image LoongCollector ou Logtail affecte-t-elle les autres services sur l'hôte ?

Conclusion : l'exécution de la seule commande docker pull pour télécharger l'image LoongCollector ou Logtail n'affecte pas les autres services exécutés sur l'hôte. Cela s'applique aux instances ECS Alibaba Cloud ainsi qu'aux serveurs sur site. La commande docker pull télécharge uniquement les couches d'image dans le référentiel d'images local. Elle ne démarre pas de conteneur et ne consomme pas de ressources CPU ou mémoire supplémentaires.

Précautions :

• Lorsque vous exécutez ultérieurement docker run pour démarrer un conteneur, assurez-vous que l'hôte dispose de suffisamment de ressources CPU et mémoire afin que le nouveau conteneur n'entre pas en concurrence avec les charges de travail existantes.

• Vérifiez si le mappage de port du conteneur entre en conflit avec les ports déjà utilisés par les services existants sur l'hôte.

• Si vous souhaitez exécuter le composant de collecte de journaux dans Kubernetes sur le long terme, installez LoongCollector en mode DaemonSet via Component Management dans la console ACK (recommandé). Cela permet au cluster de planifier les ressources de manière unifiée.

FAQ : Que faire si l'option K8s-Stdout-New est absente de la page d'accès aux journaux du cluster ACK dans la console Simple Log Service ?

Symptôme : l'entrée K8s-Stdout-New est absente de la page d'accès aux journaux du cluster ACK dans la console Simple Log Service.

Cause : l'entrée peut être temporairement indisponible car la fonctionnalité backend est retirée pour réparation.

Solutions / Alternatives :

1. Utilisez temporairement la méthode d'accès héritée : dans la console, sélectionnez l'entrée héritée K8s-Stdout pour terminer l'accès. La version héritée a atteint sa fin de maintenance et ne doit être utilisée que comme solution de contournement temporaire.

2. Utilisez une CRD au lieu de l'entrée de la console (recommandé) : utilisez kubectl dans le cluster pour créer une CRD AliyunPipelineConfig afin de configurer la collecte stdout de la nouvelle version, sans dépendre de l'entrée de la console. Reportez-vous à l'exemple YAML dans la section Container Stdout - New Version de ce document, remplacez les paramètres par vos informations réelles de projet, LogStore et cluster, puis exécutez la commande suivante :

   kubectl apply -f aliyun-pipeline-config.yaml

   Cette méthode équivaut à la configuration créée via la console et est plus facile à gérer selon une approche GitOps.