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

Absence de signal de maintien de connexion (heartbeat) après la réutilisation d'un groupe de sécurité existant par un cluster ACK

Lorsqu'un cluster ACK utilise un groupe de sécurité existant, LoongCollector ou Logtail peut échouer à signaler le signal de maintien de connexion (heartbeat) d'un groupe de machines. Cela se produit lorsque le groupe de sécurité ECS n'autorise pas le trafic entrant depuis le CIDR des Pods. LoongCollector ne peut alors pas accéder à CoreDNS pour résoudre l'endpoint Simple Log Service.

Résolvez le problème comme suit :

1. Connectez-vous à la console ECS et localisez le groupe de sécurité utilisé par le cluster ACK.

2. Ajoutez une règle entrante qui autorise tous les protocoles et ports depuis le CIDR des Pods. Par exemple, utilisez 10.229.0.0/16 si cette valeur correspond au CIDR des Pods du cluster.

3. Confirmez que les Pods peuvent accéder à CoreDNS et résoudre l'endpoint Simple Log Service.

4. Redémarrez le DaemonSet loongcollector-ds dans le namespace kube-system :

   kubectl rollout restart daemonset/loongcollector-ds -n kube-system

5. Vérifiez à nouveau le signal de maintien de connexion (heartbeat) des Machine Groups et confirmez que la collecte des journaux reprend.

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

Si LoongCollector ou Logtail n'affiche aucun signal de maintien de connexion (heartbeat) ou échoue à 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 l'état 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 correspondante. 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 est possible que Simple Log Service ne collecte pas vos journaux de conteneurs. Vérifiez l'état du conteneur, puis effectuez les contrôles suivants.

Dépannage des journaux sidecar Istio manquants

Un journal sidecar Istio peut ne pas être collecté lorsque le fichier journal du conteneur correspondant n'existe plus. La collecte peut également échouer si ContainerFilters ne correspond pas exactement au conteneur sidecar Istio.

Effectuez les vérifications suivantes dans l'ordre :

1. Vérifiez le Deployment ou StatefulSet du Pod et assurez-vous qu'il contient la variable d'environnement correcte pour la configuration Logtail. Par exemple :

   aliyun_logs_reconfig-zltx-test-stdout: "stdout"

2. Confirmez que le composant Logtail est installé et en cours d'exécution. Vérifiez que son ConfigMap contient la configuration attendue.

3. Dans la configuration de collecte, utilisez ContainerFilters pour configurer une correspondance exacte avec le conteneur sidecar Istio. Vérifiez que le filtre identifie le sidecar plutôt que uniquement le conteneur d'application.

4. Appliquez la charge de travail ou la configuration de collecte corrigée, générez une nouvelle entrée de journal sidecar et vérifiez si Simple Log Service la reçoit.

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 des 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 les 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 aux Machine Groups dans la console SLS.

FAQ : Pourquoi ne puis-je pas trouver le Pod dans l'aperçu 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 l'aperçu des métadonnées du conteneur Preview.

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 dans 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, modifiez le montage du volume de journaux de emptyDir vers un hostPath ou un 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 pointer 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 fichier 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 généralement 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 le champ K8s Namespace Regex et les autres champs de format 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 plugin d'analyse JSON et que la configuration Logtail ne peut pas être enregistrée ?

Symptôme : après avoir ajouté un plugin d'analyse JSON à une configuration Logtail, un point d'exclamation rouge apparaît à côté de l'icône du plugin 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 plugin 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 plugin d'analyse JSON ajouté par défaut.

2. Ajoutez manuellement à nouveau un plugin 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 cela 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 caractère générique, par exemple /logtail_host/var/log/pods/*/*.log, et activez la découverte automatique des 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 des 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 si des erreurs résiduelles subsistent dans le pod Logtail. Si les méthodes précédentes ne fonctionnent pas, essayez la configuration K8s-Stdout-New et activez l'aperçu des métadonnées du conteneur pour collecter les journaux via le chemin stdout au lieu du chemin de fichier.

Dépannage complémentaire pour ACK

Dans un cluster ACK, si la collecte des journaux ne renvoie toujours aucune donnée après les vérifications précédentes, examinez les deux points suivants :

1. Vérifiez la configuration de collecte CRD d'ACK : exécutez la commande suivante pour afficher les configurations de collecte CRD du cluster ACK :

   kubectl get ClusterAliyunPipelineConfig -A

   Vérifiez que le LogStore et les règles de collecte dans la sortie correspondent à vos attentes.

2. Vérifiez la déclaration de volume de l'image du conteneur : exécutez la commande docker inspect sur l'image du conteneur et vérifiez le champ Config.Volumes :

   docker inspect <image-name> | grep -A5 Volumes

   Si Config.Volumes n'est pas vide, l'image déclare un VOLUME qui peut écraser le chemin du fichier journal. Supprimez la déclaration VOLUME ou montez le volume sur emptyDir.

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 de l'état des composants Kubernetes

Exécutez la commande suivante pour afficher l'état et les informations du déploiement Simple Log Service.

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

La sortie suivante est renvoyée :

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

Exécutez la commande suivante pour afficher les informations d'état de la ressource DaemonSet.

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

La sortie suivante est renvoyée :

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

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

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 des journaux pour un Pod dans un cluster ACK est anormale, vous pouvez utiliser les étapes suivantes pour obtenir les informations de base nécessaires à l'auto-dépannage 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 ni ne consomme 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 votre projet, LogStore et informations de cluster réels, 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.

FAQ : Un Pod qui n'est pas en état Running affecte-t-il la collecte de journaux de fichiers ?

Conclusion : oui. LoongCollector et Logtail collectent les fichiers depuis l'intérieur du conteneur. Si le service ne parvient pas à démarrer et que le Pod n'est pas en état Running, le conteneur peut ne pas créer le fichier journal ou son répertoire. Le collecteur ne peut pas lire ni collecter un fichier depuis un chemin qui n'existe pas.

Pour vérifier la collecte de journaux de fichiers, définissez temporairement la commande de démarrage du service pour maintenir le conteneur en cours d'exécution. Par exemple :

sleep 3600

Une fois que le Pod est en état Running, écrivez manuellement une entrée de journal de test dans le chemin de fichier configuré. Vérifiez ensuite si LoongCollector ou Logtail collecte la nouvelle entrée. Restaurez la commande de démarrage d'origine après le test.

FAQ : Pourquoi ne puis-je pas interroger les journaux stdout des conteneurs par nom de méthode ou par un autre champ métier ?

Simple Log Service peut interroger des champs uniquement s'ils existent dans le journal collecté et si un index a été créé pour eux. Si le stdout du conteneur ou le journal de l'application ne contient pas de nom de méthode, d'informations sur l'appelant ou un autre champ métier, vous ne pouvez pas interroger ce champ directement dans Simple Log Service.

Vérifiez la configuration de journalisation dans votre application ou passerelle, telle que NGINX ou Spring Cloud Gateway. Assurez-vous que chaque champ métier requis est écrit dans stdout ou dans le fichier journal collecté.

Pour ajouter du contexte Kubernetes, ouvrez Input Configurations dans la configuration de collecte et activez Enrich Log Tags. Cette fonctionnalité peut attacher des variables d'environnement ou des libellés de Pod Kubernetes en tant que tags, y compris des métadonnées telles que le nom du Pod, le namespace et les libellés.

Un champ de contenu de journal fait partie du texte émis par l'application ou la passerelle. Un tag de métadonnées est attaché lors de la collecte pour enrichir le contexte du journal. L'enrichissement des tags ne crée pas de nom de méthode ou de champ d'appelant manquant dans le contenu original du journal.