Simple Log Service:Collecter les journaux des conteneurs (sortie standard et fichiers)

Par défaut, tous les journaux sont envoyés vers le Logstore actuel avec une compression lz4. Pour distribuer les journaux provenant d'une même source vers différents Logstores, suivez les étapes ci-dessous.

Afficher les journaux collectés

1. Vérifiez que le fichier journal contient de nouveaux contenus : LoongCollector collecte uniquement les journaux incrémentiels. Exécutez tail -f /path/to/your/log/file et déclenchez des opérations métier pour vous assurer que de nouveaux journaux sont écrits.

2. Recherchez des journaux : Accédez à la page Search & Analyze du Logstore cible. Cliquez sur Search & Analyze. La plage de temps par défaut est les 15 dernières minutes. Vérifiez si de nouveaux journaux sont ingérés. Chaque journal texte de conteneur collecté inclut par défaut les champs suivants :

   Paramètre	Description
   __tag__:__hostname__	Nom de l'hôte du conteneur.
   __tag__:__path__	Chemin du fichier journal dans le conteneur.
   __tag__:_container_ip_	Adresse IP du conteneur.
   __tag__:_image_name_	Nom de l'image utilisée par le conteneur.
   __tag__:_pod_name_	Nom du Pod.
   __tag__:_namespace_	Namespace du Pod.
   __tag__:_pod_uid_	Identifiant unique (UID) du Pod.

Interroger les nœuds historiques d'un Pod

Si un Pod a migré ou redémarré, vous pouvez interroger les journaux d'événements Kubernetes de votre cluster ACK dans Simple Log Service pour identifier les nœuds sur lesquels le Pod s'exécutait précédemment.

1. Connectez-vous à la console Simple Log Service et localisez le projet k8s-log-{cluster_id} dans la liste des projets.

2. Cliquez sur le LogStore k8s-event pour accéder à la page de requête et d'analyse.

3. Dans la zone de recherche, saisissez une instruction de requête filtrant par nom de Pod, par exemple pod_name: my-pod, puis cliquez sur Search & Analyze.

4. Dans les résultats renvoyés, vérifiez la valeur du champ hostname. Cette valeur correspond au nom d'hôte du nœud sur lequel le Pod s'exécutait.

Résoudre les problèmes courants

Gérer les configurations de distribution multi-destinations

Étant donné que les configurations de distribution multi-destinations s'appliquent à plusieurs logstores, gérez-les depuis la page de gestion au niveau du Project :

1. Connectez-vous à la console Simple Log Service et cliquez sur le nom du Project cible.

2. Sur la page Project, dans le volet de navigation de gauche, cliquez sur Resource Group > Configurations.

   Remarque

   Cette page gère toutes les configurations de collecte au sein du Project, y compris les configurations des logstores qui ont été accidentellement supprimés.

Envoyer les journaux ACK vers un Project inter-comptes

Vous pouvez envoyer les journaux de conteneurs vers un Project Simple Log Service (SLS) appartenant à un autre compte Alibaba Cloud en installant manuellement le composant LoongCollector (Logtail) dans le cluster ACK et en le configurant avec l'ID de compte Alibaba Cloud du compte cible ou ses identifiants d'accès (AccessKey).

Description du scénario : Si vous devez collecter des données de journaux dans le Project SLS d'un autre compte à des fins organisationnelles, de permissions ou de surveillance, installez manuellement LoongCollector (Logtail) pour activer la collecte inter-comptes.

Procédure : Suivez ces étapes pour installer manuellement LoongCollector. Pour plus d'informations sur l'installation de Logtail, consultez la rubrique Installer et configurer Logtail.

1. Connectez-vous au cluster Kubernetes et exécutez la commande appropriée pour votre région :

   Régions Chine

   wget https://aliyun-observability-release-cn-shanghai.oss-cn-shanghai.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

   Régions hors Chine

   wget https://aliyun-observability-release-ap-southeast-1.oss-ap-southeast-1.aliyuncs.com/loongcollector/k8s-custom-pkg/3.0.12/loongcollector-custom-k8s-package.tgz; tar xvf loongcollector-custom-k8s-package.tgz; chmod 744 ./loongcollector-custom-k8s-package/k8s-custom-install.sh

2. Accédez au répertoire loongcollector-custom-k8s-package et modifiez le fichier de configuration ./loongcollector/values.yaml.

   # ===================== Required Information =====================
   # The name of the Project to which logs from this cluster are sent. Example: k8s-log-custom-sd89ehdq
   projectName: ""
   # The region where the Project is located. Example: cn-shanghai
   region: ""
   # The UID of the Alibaba Cloud account that owns the Project. Enclose the UID in quotation marks (""). Example: "123456789"
   aliUid: ""
   # The network type. Valid values: Internet and Intranet. Default value: Internet.
   net: Internet
   # The AccessKey ID and AccessKey secret of the Alibaba Cloud account or RAM user. The account or RAM user must have the AliyunLogFullAccess system policy permission.
   accessKeyID: ""
   accessKeySecret: ""
   # A custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-).
   clusterID: ""

3. Dans le répertoire loongcollector-custom-k8s-package, exécutez la commande suivante pour installer LoongCollector et ses dépendances :

   bash k8s-custom-install.sh install

4. Une fois l'installation terminée, vérifiez que les composants sont en cours d'exécution.

   Si un pod ne démarre pas, vérifiez les configurations dans le fichier values.yaml et assurez-vous que les images requises ont été extraites.

   # Check the pod status
   kubectl get po -n kube-system | grep loongcollector-ds

   Simple Log Service crée également automatiquement les ressources suivantes. Vous pouvez les consulter dans la console Simple Log Service.

   Type de ressource	Nom de la ressource	Description
   Project	La valeur de projectName que vous avez spécifiée dans le fichier values.yaml	Isole les journaux des différents services. Pour une gestion flexible des journaux, consultez la rubrique Créer un projet.
   Groupe de machines	k8s-group-${cluster_id}	Un ensemble de nœuds de collecte de journaux. Les adresses IP des nœuds Kubernetes changent dynamiquement lors de la mise à l'échelle du cluster (ajout ou suppression de nœuds), ce qui peut entraîner des échecs de heartbeat si le groupe de machines est identifié par adresse IP. Par conséquent, les groupes de machines dans les scénarios Kubernetes utilisent un identifiant personnalisé. Pour plus d'informations, consultez le Guide d'association des groupes de machines aux configurations de collecte.

   Important

   Le composant LoongCollector ne crée pas de logstore nommé config-operation-log. Si ce logstore existe déjà, LoongCollector n'y écrit pas de journaux.

Utiliser plusieurs configurations pour la même source

Par défaut, afin d'éviter la duplication des données, Simple Log Service (SLS) n'autorise qu'une seule configuration de collecte pour chaque source de journaux :

• Un fichier journal texte ne peut correspondre qu'à une seule configuration de collecte Logtail.

• Sortie standard (stdout) d'un conteneur :

  • Si vous utilisez la nouvelle version du modèle de sortie standard, stdout ne peut être collecté que par une seule configuration de collecte de sortie standard par défaut.

  • Si vous utilisez l'ancienne version du modèle de sortie standard, aucune configuration supplémentaire n'est requise et plusieurs collectes sont prises en charge par défaut.

1. Connectez-vous à la console Simple Log Service et accédez au Project cible.

2. Dans le volet de navigation de gauche, choisissez Logstores et recherchez le logstore cible.

3. Cliquez sur l'icône située à côté de son nom pour développer le logstore.

4. Cliquez sur Logtail Configuration. Dans la liste des configurations, recherchez la configuration Logtail cible et cliquez sur Manage Logtail Configuration dans la colonne Actions.

5. Sur la page de configuration Logtail, cliquez sur Edit et faites défiler jusqu'à la section Input Configurations :

   • Pour collecter les journaux de fichiers texte, activez l'option Allow File to Be Collected for Multiple Times.

   • Pour collecter la sortie standard des conteneurs, activez l'option Allow Collection by Different Logtail Configurations.

Erreur de dépendance lors de la désinstallation de loongcollector

Problème : Lorsque vous tentez de désinstaller le composant loongcollector (logtail-ds) dans Container Service for Kubernetes (ACK), vous recevez une erreur indiquant que les dépendances du composant ne sont pas satisfaites.

Dependencies of addons are not met: terway-eniip depends on logtail-ds(>0.0) whose version is v3.x.x.x-aliyun or will be v3.x.x.x-aliyun.

Cause : Le plugin réseau terway-eniip a la collecte de journaux activée, ce qui crée une dépendance envers le composant loongcollector (logtail-ds). Par conséquent, ACK ne vous permet pas de désinstaller loongcollector (logtail-ds) tant que cette dépendance n'est pas supprimée.

Solution : Suivez ces étapes pour supprimer la dépendance, puis désinstallez le composant :

1. Connectez-vous à la console ACK.

2. Dans la liste des clusters, cliquez sur le nom du cluster cible pour accéder à sa page de détails.

3. Dans le volet de navigation de gauche, cliquez sur Add-ons.

4. Dans la liste des add-ons, recherchez le composant terway-eniip et cliquez sur Disable Logging.

5. Dans la boîte de dialogue qui s'affiche, cliquez sur OK.

6. Une fois la configuration appliquée, tentez à nouveau de désinstaller le composant loongcollector (logtail-ds).

Dernière entrée de journal retardée ou tronquée

Cause : La troncature des journaux se produit généralement lorsqu'il manque un saut de ligne final dans un fichier journal, ou lorsqu'une entrée multiligne, telle qu'une pile d'exceptions, n'a pas été entièrement écrite. Comme le collecteur ne peut pas déterminer si l'entrée de journal est complète, la dernière entrée peut être divisée ou retardée. La gestion de cette situation dépend de votre version de LoongCollector (Logtail) :

• Versions antérieures à 1,8 : Si la dernière ligne d'un journal ne contient pas de saut de ligne (retour chariot) ou si un bloc de journal multiligne est incomplet, le collecteur attend la prochaine opération d'écriture pour déclencher une sortie. Cela peut retarder considérablement la dernière entrée de journal jusqu'à ce qu'un nouveau journal soit écrit.

• Version 1.8 et ultérieures : Ces versions introduisent un mécanisme de vidage avec délai d'expiration pour éviter que les journaux ne restent bloqués. Lorsqu'une ligne de journal incomplète est détectée, le système lance un minuteur. À l'expiration du délai d'attente, le contenu actuel est automatiquement soumis pour garantir que le journal est finalement collecté.

  • Délai d'expiration par défaut : 60 secondes (garantit l'intégrité des données dans la plupart des scénarios)

  • Vous pouvez ajuster cette valeur selon vos besoins. Toutefois, nous vous recommandons de ne pas la définir sur 0, car cela pourrait entraîner une troncature des journaux ou une perte partielle de données.

Solution :

Vous pouvez prolonger le temps d'attente pour vous assurer qu'une entrée de journal complète est écrite avant sa collecte :

1. Connectez-vous à la console Simple Log Service et accédez au Project cible.

2. Dans le volet de navigation de gauche, choisissez Logstores et recherchez le logstore cible.

3. Cliquez sur l'icône située à côté de son nom pour développer le logstore.

4. Cliquez sur Logtail Configuration. Dans la liste des configurations, recherchez la configuration Logtail cible et cliquez sur Manage Logtail Configuration dans la colonne Actions.

5. Sur la page de configuration Logtail, cliquez sur Edit.

   • Accédez à Input Configurations > Other Input Configurations > Advanced Parameters et ajoutez la configuration JSON suivante pour personnaliser le délai d'expiration.

     {
       "FlushTimeoutSecs": 1
     }

     • Valeur par défaut : Déterminée par le paramètre de démarrage default_reader_flush_timeout, qui est généralement de quelques secondes.

     • Unité : Secondes.

     • Valeur recommandée : ≥ 1 seconde. Nous vous recommandons de ne pas la définir sur 0, car cela pourrait entraîner une troncature des journaux ou une perte partielle de données.

6. Une fois la configuration terminée, cliquez sur OK.

Basculement et récupération du réseau LoongCollector

Si LoongCollector (Logtail) détecte un problème de connectivité au réseau interne, tel qu'une panne ou un délai d'expiration, il bascule automatiquement vers le réseau public. Ce mécanisme de basculement garantit une collecte fiable des journaux et prévient les retards ou la perte de données.

• LoongCollector : Rebascule automatiquement vers le réseau interne après la récupération du réseau.

• Logtail : Ne rebascule pas automatiquement. Vous devez le redémarrer pour rétablir la communication via le réseau interne.

Sur la page Logtail Configuration, dans la zone Processor Configurations, vous pouvez ajouter des plug-ins de traitement pour structurer les journaux bruts. Pour ajouter un plug-in de traitement à une configuration de collecte existante, procédez comme suit :

1. Dans le volet de navigation de gauche, choisissez Logstores et localisez le Logstore cible.

2. Cliquez sur à gauche de son nom pour développer le Logstore.

3. Cliquez sur Logtail Configuration. Dans la liste des configurations, repérez la configuration Logtail cible et cliquez sur Manage Logtail Configuration dans la colonne Actions.

4. Sur la page de configuration Logtail, cliquez sur Edit.

Cette section présente uniquement les plug-ins de traitement couramment utilisés qui couvrent les scénarios de traitement de journaux fréquents. Pour en savoir plus sur les autres fonctionnalités, consultez Plug-ins de traitement étendus .

Analyse par délimiteur

05/May/2025:13:30:28,10.10.*.*,"POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028 %20Jun%202013 %2006 %3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1,1",200,18204,aliyun-sdk-java

ip:10.10.*.*
request:POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=****************&Date=Fri%2C%2028 %20Jun%202013 %2006 %3A53%3A30%20GMT&Topic=raw&Signature=******************************** HTTP/1.1
size:18204
status:200
time:05/May/2025:13:30:28
user_agent:aliyun-sdk-java

Analyse JSON standard

{"url": "POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek********&Date=Fri%2C%2028%20Jun%202013%2006%3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1.1", "ip": "10.200.98.220", "user-agent": "aliyun-sdk-java", "request": {"status": "200", "latency": "18204"}, "time": "05/Jan/2025:13:30:28"}

ip: 10.200.98.220
request: {"status": "200", "latency" : "18204" }
time: 05/Jan/2025:13:30:28
url: POST /PutData?Category=YunOsAccountOpLog&AccessKeyId=U0Ujpek******&Date=Fri%2C%2028 %20Jun%202013 %2006 %3A53%3A30%20GMT&Topic=raw&Signature=pD12XYLmGxKQ%2Bmkd6x7hAgQ7b1c%3D HTTP/1,1
user-agent:aliyun-sdk-java

Analyse JSON imbriqué

{"s_key":{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}}

0_s_key_k1_k2_k3_k41:41
0_s_key_k1_k2_k3_k4_k51:51
0_s_key_k1_k2_k3_k4_k52:52

1_s_key:{"k1":{"k2":{"k3":{"k4":{"k51":"51","k52":"52"},"k41":"41"}}}}

Analyse de tableau JSON

[{"key1":"value1"},{"key2":"value2"}]

json1:{"key1":"value1"}
json2:{"key2":"value2"}

* | extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')

Analyse des journaux Apache

1 192.168.1.10 - - [08/May/2024:15:30:28 +0800] "GET /index.html HTTP/1,1" 200 1234 "https://www.example.com/referrer" "Mozilla/5,0 (Windows NT 10.0; Win64; x64) AppleWebKit/537,36 (KHTML, like Gecko) Chrome/123,0.X.X Safari/537,36"

http_referer:https://www.example.com/referrer
http_user_agent:Mozilla/5,0 (Windows NT 10.0; Win64; x64) AppleWebKit/537,36 (KHTML, like Gecko) Chrome/123,0.X.X Safari/537.36
remote_addr:192.168.1.10
remote_ident:-
remote_user:-
request_method:GET
request_protocol:HTTP/1,1
request_uri:/index.html
response_size_bytes:1234
status:200
time_local:[08/May/2024:15:30:28 +0800]

Masquage des données

Masquez les données sensibles présentes dans vos journaux.

Exemple :

[{'account':'1812213231432969','password':'04a23f38'}, {'account':'1812213685634','password':'123a'}]

[{'account':'1812213231432969','password':'********'}, {'account':'1812213685634','password':'********'}]

Procédure : Sur la page Logtail Configuration, dans la section Processor Configurations, cliquez sur Add Processor et sélectionnez Native Processor > Data Masking :

• Original Field : champ source contenant les données à masquer.

• Data Masking Method :

  • const : remplace les données sensibles par une chaîne spécifiée.

  • md5 : remplace les données sensibles par leur valeur de hachage MD5.

• Replacement String : chaîne utilisée pour le masquage. Ce paramètre est requis lorsque la Data Masking Method est définie sur const.

• Content Expression that Precedes Replaced Content : expression régulière utilisant la syntaxe RE2 pour localiser le contenu situé immédiatement avant les données sensibles.

• Content Expression to Match Replaced Content : expression régulière utilisant la syntaxe RE2 pour identifier les données sensibles à remplacer.

1. Différences de syntaxe pour les groupes nommés

Go utilise la syntaxe (?P<name>...) pour définir un groupe nommé et ne prend pas en charge la syntaxe (?<name>...) issue de PCRE.

• Correct : (?P<year>\d{4})

• Incorrect : (?<year>\d{4})

2. Fonctionnalités d'expressions régulières non prises en charge

Le moteur RE2 ne prend pas en charge les fonctionnalités d'expressions régulières courantes mais complexes suivantes. Évitez de les utiliser :

• Assertions : (?=...), (?!...), (?<=...) et (?<!...)

• Expressions conditionnelles : (?(condition)true|false)

• Correspondance récursive : (?R) et (?0)

• Références de sous-programmes : (?&name) et (?P>name)

• Groupes atomiques : (?>...)

3. Recommandations

Utilisez un outil tel que Regex101 pour déboguer vos expressions régulières. Afin de garantir la compatibilité, sélectionnez le mode Golang (RE2) pour la validation. L'utilisation d'une syntaxe non prise en charge entraînera l'échec de l'analyse ou de la correspondance de l'expression par le plug-in.

Principaux avantages de la nouvelle sortie standard

• Performances considérablement améliorées

• Réécrite en C++, la nouvelle version offre une amélioration des performances de 180 % à 300 % par rapport à l'implémentation Go précédente.

• Elle prend en charge le traitement des données avec des plug-ins natifs et le traitement parallèle multithread, exploitant ainsi pleinement les ressources système.

• Elle permet des combinaisons flexibles de plug-ins natifs et de plug-ins Go pour répondre aux besoins de scénarios complexes.

• Fiabilité accrue

• Elle prend en charge une file d'attente rotative pour les journaux de sortie standard et unifie le mécanisme de collecte des journaux avec celui de la collecte de fichiers, offrant ainsi une haute fiabilité lors de la rotation rapide des journaux de sortie standard.

• Consommation de ressources réduite

• L'utilisation du CPU est réduite de 20 % à 25 %.

• L'utilisation de la mémoire est réduite de 20 % à 25 %.

• Cohérence O&M renforcée

• Configuration unifiée des paramètres : les paramètres de configuration du nouveau plug-in de collecte de sortie standard sont identiques à ceux du plug-in de collecte de fichiers.

• Gestion unifiée des métadonnées : la dénomination des champs de métadonnées des conteneurs et l'emplacement de stockage des tags sont uniformisés avec le scénario de collecte de fichiers, permettant ainsi au côté consommateur de ne maintenir qu'un seul ensemble de logique de traitement.

Comparaison des fonctionnalités entre les nouvelles et anciennes versions

Mappage des champs de métadonnées des conteneurs

Dans la nouvelle version, tous les champs de métadonnées sont stockés dans la section des tags du journal au format __tag__:<key> au lieu d'être intégrés au contenu du journal.

Impact de la nouvelle version sur les utilisateurs

• Adaptation côté consommateur : étant donné que l'emplacement de stockage passe du contenu au tag, vous devez ajuster votre logique de consommation des journaux en conséquence. Par exemple, vous devez accéder aux champs via __tag__ lors de l'exécution d'une requête.

• Compatibilité SQL : le langage de requête SQL est déjà automatiquement compatible avec les deux versions, vous n'avez donc pas besoin de modifier vos instructions de requête pour traiter les journaux de l'une ou l'autre version.