Simple Log Service:Collecte des journaux de conteneurs Kubernetes

Fonctionnalités

SLS offre les capacités suivantes pour la collecte des journaux de conteneurs Kubernetes :

• Prise en charge multi-source

  • Collecte de divers types de journaux : sortie standard (stdout), erreur standard (stderr) et fichiers texte de conteneurs.

• Filtrage granulaire des conteneurs

  • Incluez ou excluez des conteneurs selon le nom du namespace, le nom du pod, le nom du conteneur, les labels du conteneur ou les variables d'environnement.

• Traitement avancé des journaux

  • Collectez des journaux multilignes : fusionnez les entrées multilignes, telles que les traces de pile Java, en événements de journal uniques.

  • Prétraitez les journaux : éliminez les données invalides via un plugin de filtrage des données, ou masquez et structurez les données sensibles grâce aux plugins de masquage et de chiffrement des données et aux plugins de traitement des champs.

  • Analysez les champs : structurez les journaux bruts avant stockage à l'aide des plugins d'analyse des données.

• Association intelligente des métadonnées

  • Associez automatiquement les métadonnées aux journaux des conteneurs, notamment le nom du conteneur, l'image, le pod, le namespace et les variables d'environnement.

• Fiabilité

  • Un mécanisme de checkpoint enregistre la position actuelle de la collecte pour garantir l'intégrité des journaux.

  • Gérez les journaux lors de l'arrêt d'un conteneur grâce à différentes stratégies adaptées aux divers environnements d'exécution de conteneurs.

Limites

• Environnement d'exécution des conteneurs : seuls Docker et Containerd sont pris en charge.

  Docker :

  • Nécessite des permissions d'accès à docker.sock.

  • Pour la collecte de la sortie standard, seul le driver de journalisation json-file est pris en charge.

  • Seuls les drivers de stockage overlay et overlay2 sont pris en charge. Pour les autres drivers de stockage, montez le répertoire des journaux via un volume.

  Containerd :

  • Nécessite des permissions d'accès à containerd.sock.

• Limite des journaux multilignes :

  Par défaut, la dernière ligne collectée reste en mémoire tampon pendant 3 secondes afin d'éviter que les journaux multilignes ne soient scindés en raison de retards de sortie. Ajustez ce comportement avec le paramètre BeginLineTimeoutMs (minimum : 1 000 ms).

• Sortie standard :

  La taille maximale par défaut d'une entrée de journal est de 512 Ko (524 288 octets), avec une limite supérieure de 8 Mo (8 388 608 octets). Pour augmenter cette limite, définissez la variable d'environnement max_read_buffer_size sur le conteneur LoongCollector.

  Important

  N'activez pas simultanément la collecte de stdout et stderr. Cela risquerait d'entraîner une imbrication incorrecte des entrées de journal.

Vue d'ensemble du flux de collecte

1. Préparer la source de journaux : identifiez les journaux de sortie standard ou les fichiers texte à collecter.

2. Installer LoongCollector : déployez le collecteur pour transmettre les journaux à SLS.

3. Configurer les règles de collecte : définissez les règles de collecte des journaux et les plugins d'analyse.

4. Interroger et analyser les journaux : surveillez vos services à l'aide des données de journalisation collectées.

Processus clés

Exigences relatives à la source de journaux et au point de montage

• Pour les journaux de sortie standard, LoongCollector découvre automatiquement le chemin du fichier de journal en fonction des métadonnées du conteneur.

• Pour les fichiers texte de conteneurs, LoongCollector monte par défaut le répertoire racine de l'hôte sur /logtail_host. Un montage manuel n'est généralement pas nécessaire. Si vous utilisez un point de montage personnalisé, assurez-vous qu'il respecte les exigences suivantes :

  Exigences relatives aux points de montage personnalisés

  Chemin du fichier de journal :

  • N'utilisez pas de liens symboliques :

    • Configuration incorrecte : /var/log -> /mnt/logs.

    • Configuration correcte : utilisez directement le chemin physique /mnt/logs.

  • Règle de correspondance des chemins de montage : si le répertoire de données de votre conteneur d'application est monté via un volume, le chemin de collecte doit être identique au point de montage ou en être un sous-répertoire.

    1Mount point: /var/log/service
    2✅ Valid collection path: /var/log/service or /var/log/service/subdir
    3❌ Invalid collection path: /var/log (The path is not specific enough)

Installer le collecteur

LoongCollector prend en charge deux modes de déploiement :

Mode de déploiement : DaemonSet ou sidecar.

• Mode DaemonSet : déploie automatiquement un agent LoongCollector sur chaque nœud. Ce mode convient à la plupart des scénarios.

  • En mode DaemonSet, la méthode de déploiement dépend du type de cluster et de la relation avec le compte SLS.

    • Pour les clusters Container Service for Kubernetes (ACK), le composant loongcollector-ds est pré-intégré. Activez-le dans la console ACK pour terminer l'installation. Par défaut, les journaux sont stockés dans le projet SLS du compte propriétaire du cluster. Installation et configuration.

    • Pour collecter les journaux d'un cluster ACK vers un projet SLS appartenant à un autre compte Alibaba Cloud, installez manuellement LoongCollector et configurez-le avec l'ID ou l'AccessKey du compte de destination. Installation et configuration.

    • Pour les clusters auto-gérés, installez manuellement LoongCollector et configurez-le avec l'ID ou l'AccessKey du compte Alibaba Cloud de destination. Installation et configuration.

    LoongCollector doit être installé avant de pouvoir commencer la collecte des journaux. Collecter les journaux de conteneurs d'un cluster Kubernetes à l'aide d'une CRD (sortie standard/fichier) .

• Mode Sidecar : injecte un conteneur LoongCollector dans chaque pod d'application. Utilisez ce mode pour les conteneurs serverless, les pods à fort volume dépassant la capacité du mode DaemonSet, ou les clusters utilisant des environnements d'exécution de conteneurs sécurisés. Collecter les journaux texte des pods Kubernetes (mode sidecar).

Règles de collecte

SLS propose deux méthodes pour définir les règles de collecte :

Concepts clés

• Kubernetes : plateforme open source d'orchestration de conteneurs qui automatise le déploiement, la mise à l'échelle et la gestion des applications conteneurisées.

• Sortie standard, erreur standard et fichiers texte de journaux : la sortie standard (stdout) capture la sortie normale du programme (journaux métier, enregistrements opérationnels). L'erreur standard (stderr) capture les erreurs et les avertissements (traces de pile, échecs de démarrage). Toutes deux sont dirigées vers le terminal et capturées par le moteur de conteneur. Les fichiers texte de journaux sont écrits dans des fichiers par les applications (par exemple, Nginx access.log) et sont supprimés lors de la destruction du conteneur, sauf s'ils sont conservés via un volume.

• Mécanisme de checkpoint : enregistre la position de la collecte dans un fichier, sauvegardé par défaut dans /tmp/logtail_checkpoint. Garantit une collecte fiable après le redémarrage de LoongCollector ou en cas de défaillance d'un nœud.

• LoongCollector (Logtail) : collecteur de journaux haute performance développé par Alibaba Cloud, prenant en charge le déploiement DaemonSet et sidecar dans Kubernetes. LoongCollector succède à Logtail et est entièrement rétrocompatible.

• CRD Kubernetes : une CustomResourceDefinition permettant de définir des ressources personnalisées pour la configuration. SLS utilise AliyunPipelineConfig comme type de CRD.

• Configuration de collecte : définit les règles concernant les types de journaux, les chemins de collecte, le filtrage, l'analyse et l'emplacement de stockage. Qu'est-ce qu'une configuration de collecte ?.

• Plugin d'analyse : unité de traitement au sein de la configuration des plugins de traitement servant à structurer, fractionner, filtrer ou désensibiliser le contenu des journaux. Prend en charge les modes expression régulière, séparateur, JSON et multiligne.

Fonctionnement

1. Un utilisateur crée une ressource personnalisée (CR) à l'aide de kubectl pour définir une règle de collecte.

2. Le composant loongcollector-operator surveille en permanence les modifications des CR dans le cluster.

3. Lorsqu'une modification est détectée, l'Operator convertit la CR en une configuration LoongCollector et l'applique à Simple Log Service.

4. L'agent LoongCollector envoie périodiquement des signaux de présence (heartbeats) à Simple Log Service pour récupérer les mises à jour de configuration, télécharge la dernière configuration de collecte et l'applique dynamiquement.

5. L'agent loongcollector-ds collecte les journaux conformément à la nouvelle configuration et les envoie à SLS via l'endpoint configuré.

Mode DaemonSet

Déploie un agent LoongCollector sur chaque nœud pour collecter les journaux de tous les conteneurs présents sur ce nœud. Offre une exploitation simple, une faible consommation de ressources et une configuration flexible, mais avec une isolation des locataires moins stricte.

Fonctionnement du mode DaemonSet

• En mode DaemonSet, Kubernetes exécute exactement un conteneur LoongCollector sur chaque nœud afin de collecter les journaux de tous les conteneurs de ce nœud.

• Kubernetes crée et détruit automatiquement les conteneurs LoongCollector lorsque des nœuds rejoignent ou quittent le cluster, ce qui élimine la gestion manuelle des instances.

Mode Sidecar

Injecte un sidecar LoongCollector aux côtés du conteneur d'application dans chaque pod. Le répertoire des journaux de l'application est partagé via un volume Kubernetes (emptyDir, hostPath ou PVC), permettant à LoongCollector de lire directement les fichiers de journaux. Assure une forte isolation des locataires et des performances élevées, mais consomme davantage de ressources.

Fonctionnement du mode sidecar

• En mode sidecar, chaque pod exécute un conteneur LoongCollector dédié. La collecte des journaux est isolée entre les pods.

• Un volume partagé doit être monté à la fois sur le conteneur d'application et sur le conteneur LoongCollector pour permettre l'accès aux fichiers de journaux.

• Lorsque le volume de journaux d'un pod dépasse la capacité du mode DaemonSet, le mode sidecar permet d'allouer des ressources dédiées à LoongCollector.

• Les environnements serverless ne comportant pas de nœuds, le mode DaemonSet n'est pas applicable. Le mode sidecar s'intègre directement aux architectures serverless.

Découverte des conteneurs

Avant de collecter leurs journaux, LoongCollector doit identifier les conteneurs en cours d'exécution sur le nœud. Ce processus est appelé découverte des conteneurs.

• LoongCollector communique directement avec le démon de l'environnement d'exécution de conteneurs sur le nœud, et non avec le kube-apiserver du cluster. Cela évite de surcharger le kube-apiserver.

• LoongCollector accède au socket de l'environnement d'exécution de conteneurs (Docker ou Containerd) sur l'hôte. Il permet d'inclure ou d'exclure des conteneurs par namespace, nom de pod, labels de pod ou variables d'environnement.

Collecte de la sortie standard

LoongCollector identifie automatiquement l'API ou le driver de journalisation approprié pour chaque environnement d'exécution de conteneurs (Docker, Containerd) en fonction des métadonnées. Il lit directement le flux stdout sans accéder aux systèmes de fichiers des conteneurs.

Collecte des journaux de fichiers texte de conteneurs

• Kubernetes isole les systèmes de fichiers des conteneurs ; un collecteur ne peut donc pas accéder directement aux fichiers d'autres conteneurs. LoongCollector monte le système de fichiers racine de l'hôte pour accéder indirectement aux fichiers du conteneur d'application.

• Par défaut, le système de fichiers racine de l'hôte est monté sur /logtail_host. Un montage manuel n'est généralement pas nécessaire. Par exemple, si un fichier de journal de conteneur se trouve dans /log/app.log et que son chemin sur l'hôte est /var/lib/docker/containers/<container-id>/log/app.log, LoongCollector le lit depuis /logtail_host/var/lib/docker/containers/<container-id>/log/app.log.

Analyse des journaux multilignes

LoongCollector utilise une expression régulière définie par l'utilisateur pour détecter le début d'une ligne de journal.

• Correspondance trouvée : la ligne est considérée comme le début d'une nouvelle entrée de journal.

• Aucune correspondance : la ligne est ajoutée à l'entrée de journal en cours.

Lorsqu'une autre ligne correspond à l'expression régulière de début de ligne, l'entrée de journal en cours est finalisée et une nouvelle commence.

Traitement des journaux lors de l'arrêt d'un conteneur

Après la suppression d'un pod, les journaux déjà collectés dans le LogStore Simple Log Service ne sont pas affectés. Ils sont conservés pendant la durée de rétention des données du LogStore et restent interrogeables durant cette période. Vous pouvez modifier la durée de rétention dans la console Simple Log Service.

Après la suppression d'un pod, les configurations de collecte basées sur des labels ou des namespaces s'appliquent automatiquement aux nouveaux pods portant les mêmes labels. Lors d'une mise à jour progressive (rolling update) d'un Deployment qui supprime les anciens pods et en crée de nouveaux, Simple Log Service collecte automatiquement les journaux des nouveaux pods, sans qu'il soit nécessaire de reconfigurer les règles de collecte.

Récupération des métadonnées de conteneurs

LoongCollector récupère les métadonnées Kubernetes directement via l'API CRI (Container Runtime Interface), ce qui permet un étiquetage non intrusif et en temps réel des métadonnées pendant la collecte.

• Docker : LoongCollector utilise le client Docker pour communiquer avec le démon Docker afin de récupérer les métadonnées. Les principales API incluent :

  • ContainerList : liste les conteneurs en cours d'exécution sur le nœud.

  • ContainerInspect : renvoie la configuration détaillée et l'état du conteneur.

  • Events : écoute les événements du cycle de vie des conteneurs en temps réel.

  Principaux champs de métadonnées récupérés via le client Docker :

  • LogPath : chemin sur l'hôte du fichier de journal stdout du conteneur.

  • GraphDriver.Data : chemin sur l'hôte du rootfs du conteneur, utilisé pour l'accès au système de fichiers et le dépannage.

• Containerd : LoongCollector utilise le CRI pour prendre en charge les environnements containerd et CRI-O, en collectant les métadonnées des environnements d'exécution sous-jacents tels que runc ou Kata Containers.

  • Le CRI fournit le chemin sur l'hôte du fichier de journal stdout, mais pas le chemin du rootfs du conteneur. LoongCollector utilise ces méthodes pour le trouver :

    • Recherche de chemin de fichier : recherche le chemin du rootfs du conteneur dans le système de fichiers de l'hôte à l'aide de l'ID du conteneur.

    • Interaction directe avec containerd : LoongCollector peut contourner le CRI et communiquer directement avec containerd pour obtenir le chemin du rootfs et d'autres métadonnées non disponibles via le CRI.