Collect container standard output and file logs in a Kubernetes cluster using the AliyunPipelineConfig CRD - Simple Log Service

La définition des paramètres de collecte sous forme de CustomResourceDefinition (CRD) Kubernetes permet d'unifier la gestion sur tous les clusters, y compris Container Service for Kubernetes (ACK) et les clusters auto-gérés. Cette approche remplace les processus manuels incohérents et sujets aux erreurs par une automatisation versionnée via kubectl et les pipelines CI/CD. Le rechargement à chaud intégré de LoongCollector applique les modifications instantanément sans redémarrage, améliorant ainsi directement l'efficacité opérationnelle et la maintenabilité du système.

L'ancien CRD AliyunLogConfig n'est plus maintenu. Utilisez le nouveau AliyunPipelineConfig CRD à la place. Pour une comparaison entre la nouvelle version et l'ancienne, consultez Types de CRD .

Important

Les configurations de collecte créées à l'aide d'un CRD ne peuvent être modifiées qu'en mettant à jour le CRD correspondant. Les modifications apportées dans la console Simple Log Service (SLS) ne sont pas synchronisées avec le CRD et ne prennent pas effet.

Remarques relatives à l'utilisation

Environnement d'exploitation :
- Prend en charge ACK (éditions managées et dédiées) et les clusters Kubernetes auto-gérés.
- Version Kubernetes 1.16.0 ou ultérieure prenant en charge Mount propagation: HostToContainer.
- Moteur d'exécution de conteneur (uniquement Docker et Containerd)
  - Docker :
    - Nécessite des autorisations d'accès pour docker.sock.
    - La collecte de la sortie standard prend uniquement en charge le pilote de journal JSON.
    - Prend uniquement en charge les pilotes de stockage overlay et overlay2. Pour les autres types, vous devez monter manuellement les répertoires de journaux.
  - Containerd : Nécessite des autorisations d'accès pour containerd.sock.
Exigences en matière de ressources : LoongCollector (Logtail) s'exécute avec la priorité élevée system-cluster-critical. Ne le déployez pas si les ressources du cluster sont insuffisantes, car cela pourrait évincer les pods existants sur le nœud.
- CPU : Réservez au moins 0,1 cœur.
- Mémoire : Au moins 150 Mo pour le composant de collecte et au moins 100 Mo pour le composant contrôleur.
- L'utilisation réelle dépend du taux de collecte, du nombre de répertoires et de fichiers surveillés et de l'étendue des éventuels blocages d'envoi. Assurez-vous que l'utilisation réelle reste inférieure à 80 % de la limite configurée.
Autorisations : Le compte Alibaba Cloud ou l'utilisateur RAM utilisé pour le déploiement doit disposer de l'autorisation AliyunLogFullAccess.

Pour créer des stratégies personnalisées, consultez la stratégie système AliyunCSManagedLogRolePolicy . Copiez les autorisations de cette stratégie et accordez-les à l'utilisateur ou au rôle RAM cible pour configurer des autorisations fines.

Flux de travail de configuration de la collecte

Installer LoongCollector : Déployez LoongCollector en tant que DaemonSet pour garantir qu'un conteneur de collecte s'exécute sur chaque nœud du cluster. Cela permet une collecte unifiée des journaux de tous les conteneurs sur ce nœud.
Create a logstore : Un logstore est une unité de stockage pour les données de journal. Plusieurs logstores peuvent être créés dans un projet.

Créer un fichier YAML de configuration de collecte : Utiliser kubectl pour se connecter au cluster. Créez le fichier de configuration de collecte selon l'une des deux méthodes suivantes :

Méthode 1 : Utiliser le générateur de configuration de collecte

Utilisez le générateur de configuration de collecte dans la console SLS pour saisir visuellement les paramètres et générer automatiquement un fichier YAML standard.
Méthode 2 : Écrire manuellement le fichier YAML

Rédigez un fichier YAML en vous basant sur les exemples et les flux de travail présentés dans cette rubrique. Commencez par une configuration minimale et ajoutez progressivement la logique de traitement et les fonctionnalités avancées.

Pour plus d'informations sur les cas d'utilisation complexes non couverts dans cette rubrique ou sur les champs nécessitant une personnalisation approfondie, consultez Paramètres AliyunPipelineConfig pour obtenir la liste complète des champs, des règles de valeur et des capacités des plug-ins.

Une configuration de collecte complète comprend généralement les parties suivantes :

Configuration minimale (obligatoire) : Construit le tunnel de données du cluster vers SLS. Elle comprend deux parties :
- Entrées (inputs) : Définit la source des journaux. Les journaux de conteneur incluent les deux sources de journaux suivantes. Pour collecter d'autres types de journaux, tels que les résultats de requête MySQL, consultez Plug-ins d'entrée.
  - Sortie standard du conteneur (stdout et stderr) : Contenu du journal imprimé par le programme du conteneur sur la console.
  - Fichiers journaux texte : Fichiers journaux écrits dans un chemin spécifié à l'intérieur du conteneur.
- Sorties (flushers) : Définit la destination du journal. Envoie les journaux collectés vers le logstore spécifié.
  Si le projet ou le logstore cible n'existe pas, le système le crée automatiquement. Vous pouvez également créer manuellement un projet et un logstore à l'avance.
Configurations de traitement courantes (facultatives) : Définit le champ processors pour effectuer une analyse structurée (telle que l'analyse par expression régulière ou par délimiteur), un masquage ou un filtrage sur les journaux bruts.
Cette rubrique décrit uniquement les plug-ins de traitement natifs qui couvrent les cas d'utilisation courants de traitement des journaux. Pour plus de fonctionnalités, consultez Plug-ins de traitement étendus.
Autres configurations avancées (facultatives) : Implémente des fonctionnalités telles que la collecte de journaux multilignes et l'enrichissement des tags de journaux pour répondre à des exigences de collecte plus fines.

Exemple de structure :

apiVersion: telemetry.alibabacloud.com/v1alpha1 # Utilisez la valeur par défaut. Ne pas modifier.
    kind: ClusterAliyunPipelineConfig               # Utilisez la valeur par défaut. Ne pas modifier.
    metadata:
      name: test-config                             # Définissez le nom de la ressource. Il doit être unique au sein du cluster Kubernetes.
    spec:
      project:                                      # Définissez le nom du projet cible.
        name: k8s-your-project                      
      config:                                       # Définissez la configuration de collecte Logtail.
        inputs:                                     # Définissez les plug-ins d'entrée pour la configuration de collecte Logtail.
          ...
        processors:                                 # Définissez les plug-ins de traitement pour la configuration de collecte Logtail.
          ...
        flushers:                                   # Définissez les plug-ins de sortie pour la configuration de collecte Logtail.
          ...

Appliquer la configuration
```
kubectl apply -f <your_yaml>
```

Installer LoongCollector (Logtail)

LoongCollector est un agent de collecte de journaux de nouvelle génération lancé par SLS. Il s'agit d'une version améliorée de Logtail. Les deux ne peuvent pas coexister. Pour installer Logtail, consultez Installer et configurer Logtail .

Cette rubrique décrit uniquement les étapes d'installation de base de LoongCollector. Pour les paramètres détaillés, consultez Installation et configuration. Si vous avez déjà installé LoongCollector ou Logtail, ignorez cette étape et passez à la création d'un logstore pour stocker les journaux collectés.

Cluster ACK

Installez LoongCollector depuis la console Container Service for Kubernetes (ACK). Par défaut, les journaux sont envoyés vers un projet SLS sous le compte Alibaba Cloud actuel.

Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Sur la page Clusters, cliquez sur le nom du cluster cible pour ouvrir sa page de détails.
Dans le volet de navigation de gauche, cliquez sur Add-ons.

Sous l'onglet Logs and Monitoring, recherchez loongcollector et cliquez sur Install.

Remarque

Pour un nouveau cluster, dans la section Advanced Options, sélectionnez Enable Log Service. Ensuite, Create Project ou Select Project.

Une fois l'installation terminée, SLS crée automatiquement les ressources associées dans la région où réside le cluster ACK. Connectez-vous à la console Simple Log Service pour les afficher.

Type de ressource

Nom de la ressource

Fonction

Projet

k8s-log-${cluster_id}

Une unité de gestion des ressources qui isole les journaux pour différents services.

Pour créer un projet afin de gérer les ressources de journaux avec plus de flexibilité, consultez Créer un projet.

Groupe de machines

k8s-group-${cluster_id}

Un ensemble de nœuds de collecte de journaux.

Important

LoongCollector ne créera pas de logstore nommé config-operation-log. Si un logstore portant ce nom existe déjà, LoongCollector arrête d'y écrire des journaux.

Cluster auto-géré

Connectez-vous au cluster Kubernetes et exécutez la commande correspondante pour votre région afin de télécharger LoongCollector et ses composants dépendants :

Régions en 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 de 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

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

# ===================== Required parameters =====================
# The name of the project that manages the collected logs. Example: k8s-log-custom-sd89ehdq.
projectName: ""
# The region of the project. Example for Shanghai: 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. Optional parameters: Internet (public network) and Intranet (internal network). Default value: Internet.
net: Internet
# The AccessKey ID and AccessKey secret of the Alibaba Cloud account or RAM user. The account or user must have the AliyunLogFullAccess system policy.
accessKeyID: ""
accessKeySecret: ""
# The custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-).
clusterID: ""

Dans le répertoire loongcollector-custom-k8s-package, exécutez la commande suivante pour installer LoongCollector et d'autres composants dépendants :
```
bash k8s-custom-install.sh install
```
Une fois l'installation terminée, vérifiez l'état d'exécution des composants.

Si le pod ne démarre pas, vérifiez si la configuration values.yaml est correcte et si les images pertinentes ont été extraites avec succès.
```
# Check the pod status.
kubectl get po -n kube-system | grep loongcollector-ds
```
SLS crée également automatiquement les ressources suivantes. Connectez-vous à la console Simple Log Service pour les afficher.

|
**Type de ressource**
|
**Nom de la ressource**
|
**Fonction**
| | --- | --- | --- | |
Projet
|
La valeur de `projectName` définie dans le fichier values.yaml
|
Une unité de gestion des ressources qui isole les journaux pour différents services.
| |
Groupe de machines
|
`k8s-group-${cluster_id}`
|
Un ensemble de nœuds de collecte de journaux.
|
Important
LoongCollector ne créera pas de logstore nommé config-operation-log. Si un logstore portant ce nom existe déjà, LoongCollector arrête d'y écrire des journaux.

Créer un logstore

Si vous avez déjà créé un logstore, ignorez cette étape et passez à la configuration de la collecte.

Connectez-vous à la console Simple Log Service et cliquez sur le nom du projet cible.
Dans le volet de navigation de gauche, choisissez Log Storage et cliquez sur +.
Sur la page Créer un logstore, configurez les paramètres principaux suivants :
- Logstore Name : Définissez un nom unique au sein du projet. Ce nom ne peut pas être modifié après la création.
- Logstore Type : Choisissez Standard ou Requête en fonction d'une comparaison de leurs spécifications.
- Billing Mode :
  - pay-by-feature : Facturé indépendamment pour chaque ressource, telle que le stockage, l'indexation et les opérations de lecture/écriture. Adapté aux cas d'utilisation à petite échelle ou lorsque l'utilisation des fonctionnalités est incertaine.
  - pay-by-ingested-data: Facturé uniquement en fonction du volume de données brutes ingérées. Offre une période de stockage gratuite de 30 jours et des fonctionnalités gratuites telles que la transformation et la diffusion des données. Le modèle de coût est simple et convient aux cas d'utilisation où la période de stockage est proche de 30 jours ou où le pipeline de traitement des données est complexe.
- Data Retention Period : Définissez le nombre de jours de conservation des journaux. La valeur varie de 1 à 3 650 jours. Une valeur de 3 650 indique un stockage permanent. La valeur par défaut est de 30 jours.
Conservez les paramètres par défaut pour les autres configurations et cliquez sur OK. Pour plus d'informations sur les autres configurations, consultez Gérer les logstores.

Configuration minimale

Dans spec.config, vous configurez les plug-ins d'entrée (inputs) et de sortie (flushers) pour définir le chemin principal de collecte des journaux : la source des journaux et leur destination.

Sortie standard du conteneur - nouvelle version

Objectif : Collecte les journaux de sortie standard du conteneur (stdout/stderr) imprimés directement sur la console.

plug-in inputs

Point de départ de la configuration de collecte. Définit la source du journal. Actuellement, un seul plug-in d'entrée peut être configuré.

Type String (Obligatoire)
Le type de plug-in. Définissez sur input_container_stdio.
IgnoringStderr boolean (Facultatif)
Indique s'il faut ignorer le flux d'erreur standard (stderr). Valeur par défaut : false.
- true : Ne collecte pas stderr.
- false : Collecte stderr.
IgnoringStdout boolean (Facultatif)
Indique s'il faut ignorer le flux de sortie standard (stdout). Valeur par défaut : false.
- true : Ne collecte pas stdout.
- false : Collecte stdout.

Exemple

apiVersion: telemetry.alibabacloud.com/v1alpha1
    kind: ClusterAliyunPipelineConfig
    metadata:
      # Définissez le nom de la ressource. Il doit être unique au sein du cluster Kubernetes et est également le nom de la configuration de collecte Logtail créée.
      name: new-stdio-config
    spec:
      project:
        name: test-not-exist
      logstores:
        - name: new-stdio-logstore

      # Définissez la configuration de collecte et de traitement LoongCollector (Logtail).
      config:
        # --- Plug-in d'entrée : Définit où collecter les journaux ---
        inputs:
          # Utilisez le plug-in input_container_stdio pour collecter la sortie standard du conteneur.
          - Type: input_container_stdio
            IgnoringStderr: false
            IgnoringStdout: false

        # --- Plug-ins de traitement (facultatifs) : Définissent comment analyser et traiter les journaux ---
        processors: []

        # --- Plug-in de sortie : Définit où envoyer les journaux ---
        flushers: # Si vous n'avez pas besoin d'envoyer vers plusieurs destinations, configurez simplement un flusher.
        - Type: flusher_sls # Spécifie l'utilisation du plug-in de sortie SLS.
        Logstore: new-stdio-logstore1
        - Type: flusher_sls # Spécifie l'utilisation du plug-in de sortie SLS.
        Logstore: new-stdio-logstore2

plug-in de sortie flushers

Configurez le plug-in flusher_sls pour envoyer les journaux collectés vers un logstore spécifié dans un projet. Actuellement, jusqu'à cinq plug-ins de sortie peuvent être configurés.

Type String (Obligatoire)
Le type de plug-in. Définissez sur flusher_sls.
Logstore String (Obligatoire)
Le nom du logstore cible. Cela détermine l'emplacement de stockage réel des journaux.
Remarque
- Le logstore spécifié doit exister ou être déclaré dans spec.LogStores.

Collecter les fichiers texte du conteneur

Objectif : Collecte les journaux écrits dans un chemin de fichier spécifique au sein d'un conteneur, tels que les fichiers access.log ou app.log traditionnels.

plug-in inputs

Point de départ de la configuration de collecte. Définit la source du journal. Actuellement, un seul plug-in d'entrée peut être configuré.

Type String (Obligatoire)
Le type de plug-in. Définissez sur input_file.
FilePaths String (Obligatoire)
Une liste des chemins d'accès aux fichiers journaux que vous souhaitez collecter.
- Actuellement, un seul chemin peut être configuré.
- Prend en charge les caractères génériques :
  - * : Correspond aux noms de fichiers dans un répertoire à un seul niveau.
  - ** : Correspond récursivement aux sous-répertoires multi-niveaux. Ne peut apparaître qu'une seule fois et doit précéder le nom du fichier.
MaxDirSearchDepth integer (Facultatif)
Lorsque le chemin contient **, spécifie la profondeur maximale du répertoire. Valeur par défaut : 0. Plage de valeurs : 0 à 1 000.
FileEncoding String (Facultatif)
Le format d'encodage du fichier. Valeur par défaut : utf8. Les valeurs prises en charge sont :
- utf8
- gbk
EnableContainerDiscovery boolean (Facultatif)
Indique s'il faut activer la fonctionnalité de découverte de conteneur. Valeur par défaut : true.
Remarque
Ce paramètre n'est effectif que lorsque LoongCollector (Logtail) s'exécute en mode DaemonSet et que le chemin de collecte du fichier est un chemin au sein du conteneur.

Exemple

apiVersion: telemetry.alibabacloud.com/v1alpha1
    kind: ClusterAliyunPipelineConfig
    metadata:
      name: easy-row-config
    spec:
      # Spécifiez le projet cible vers lequel les journaux sont envoyés.
      project:
        name: test-not-exist
      logstores:
        - name: easy-row-logstore

      # Définissez la configuration de collecte et de traitement LoongCollector (Logtail).
      config:
        # Échantillon de journal (facultatif)
        sample: ''
        # --- Plug-in d'entrée : Définit où collecter les journaux ---
        inputs:
          # Utilisez le plug-in input_file pour collecter les fichiers texte du conteneur.
          - Type: input_file         
            # ... Configuration spécifique pour le plug-in d'entrée ...
            # Chemin du fichier dans le conteneur
            FilePaths:
              - /var/log/text1.log
            # Profondeur maximale de surveillance du répertoire  
            MaxDirSearchDepth: 0
            FileEncoding: utf8  
            # Activez la fonctionnalité de découverte de conteneur.
            EnableContainerDiscovery: true


        # --- Plug-ins de traitement (facultatifs) : Définissent comment analyser et traiter les journaux ---
        processors: []    

        # --- Plug-in de sortie : Définit où envoyer les journaux ---
        flushers: # Si vous n'avez pas besoin d'envoyer vers plusieurs destinations, configurez simplement un flusher.
        - Type: flusher_sls # Spécifie l'utilisation du plug-in de sortie SLS.
        Logstore: easy-row-logstore1
        - Type: flusher_sls # Spécifie l'utilisation du plug-in de sortie SLS.
        Logstore: easy-row-logstore2

plug-in de sortie flushers

Configurez le plug-in flusher_sls pour envoyer les journaux collectés vers un logstore spécifié dans un projet. Actuellement, jusqu'à cinq plug-ins de sortie peuvent être configurés.

Type String (Obligatoire)
Le type de plug-in. Définissez sur flusher_sls.
Logstore String (Obligatoire)
Le nom du logstore cible. Cela détermine l'emplacement de stockage réel des journaux.
Remarque
- Le logstore spécifié doit exister ou être déclaré dans spec.LogStores.

Configurations de traitement courantes

Après avoir terminé la configuration minimale, ajoutez des plug-ins de traitement pour effectuer une analyse structurée, un masquage ou un filtrage sur les journaux bruts.

Configuration principale : Ajoutez processors à spec.config pour configurer les plug-ins de traitement. Plusieurs plug-ins peuvent être ajoutés simultanément.

Cette rubrique décrit uniquement les plug-ins de traitement natifs qui couvrent les cas d'utilisation courants de traitement des journaux. Pour plus d'informations sur d'autres fonctionnalités, consultez Plug-ins de traitement étendus .

Important

Pour les versions Logtail 2.0 et ultérieures et le composant LoongCollector, nous vous recommandons de suivre ces règles de combinaison de plug-ins :

Utilisez d'abord les plug-ins natifs.
Si les plug-ins natifs ne répondent pas à vos besoins, configurez les plug-ins d'extension après les plug-ins natifs.
Les plug-ins natifs ne peuvent être utilisés qu'avant les plug-ins d'extension.

Configuration structurée

Analyse par expression régulière

Extrait les champs de journal à l'aide d'une expression régulière et analyse le journal en paires clé-valeur.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_parse_regex_native.

 # ...Sous spec.config...
     processors:
      # Utilisez le plug-in d'analyse par expression régulière pour analyser le contenu du journal.
      - Type: processor_parse_regex_native
        # Spécifiez la source du champ de journal brut, généralement content.
        SourceKey: content

        # L'expression régulière est utilisée pour faire correspondre et extraire les champs de journal.
        Regex: >-
          (\S+)\s-\s(\S+)\s$$([^]]+)$$\s"
          (\w+)\s(\S+)\s([^"]+)"
          \s(\d+)\s(\d+)\s"
          ([^"]+)"\s"
          ([^"]+).*

        # Liste des champs extraits, correspondant aux groupes regex dans l'ordre.
        Keys:
          - remote_addr
          - remote_user
          - time_local
          - request_method
          - request_uri
          - request_protocol
          - status
          - body_bytes_sent
          - http_referer
          - http_user_agent

        # Indique s'il faut conserver le champ source en cas d'échec de l'analyse.
        KeepingSourceWhenParseFail: true

        # Indique s'il faut conserver le champ source en cas de réussite de l'analyse.
        KeepingSourceWhenParseSucceed: true

        # Si le champ source est conservé, spécifiez un nouveau nom pour celui-ci.
        RenamedSourceKey: fail

SourceKey String (Obligatoire)

Le nom du champ source.

Regex String (Obligatoire)

L'expression régulière pour faire correspondre le journal.

Keys String (Obligatoire)

Une liste des champs extraits.

KeepingSourceWhenParseFail boolean (Facultatif)

Indique s'il faut conserver le champ source en cas d'échec de l'analyse. Valeur par défaut : false.

KeepingSourceWhenParseSucceed boolean (Facultatif)

Indique s'il faut conserver le champ source en cas de réussite de l'analyse. Valeur par défaut : false.

RenamedSourceKey String (Facultatif)

Si le champ source est conservé, il s'agit du nom de champ utilisé pour stocker le champ source. Par défaut, le nom n'est pas modifié.

Analyse par délimiteur

Structure le contenu du journal à l'aide d'un délimiteur, en l'analysant en plusieurs paires clé-valeur. Prend en charge les délimiteurs à caractère unique et à caractères multiples.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_parse_delimiter_native.

# ...Sous spec.config...
    processors:
      # Configuration du plug-in d'analyse par délimiteur
      - Type: processor_parse_delimiter_native
        # Source du champ brut, généralement content
        SourceKey: content

        Separator: ','

        Quote: '"'

        # Définissez les noms de champs extraits dans l'ordre.
        Keys:
          - time
          - ip
          - request
          - status
          - size
          - user_agent

SourceKey String (Obligatoire)

Le nom du champ source.

Separator String (Obligatoire)

Le séparateur de champ. Par exemple, CSV utilise une virgule (,).

Keys [String] (Obligatoire)

Une liste des champs extraits.

Quote String (Facultatif)

Le caractère de guillemet utilisé pour encapsuler le contenu du champ contenant des caractères spéciaux, tels que des virgules.

AllowingShortenedFields boolean (Facultatif)

Indique s'il faut autoriser le nombre de champs extraits à être inférieur au nombre de clés. Valeur par défaut : true. Si non autorisé, ce scénario est traité comme un échec d'analyse.

OverflowedFieldsTreatment String (Facultatif)

Spécifie le comportement lorsque le nombre de champs extraits est supérieur au nombre de clés. Valeur par défaut : extend. Les valeurs prises en charge sont :

extend : Conserve les champs supplémentaires. Chaque champ supplémentaire est ajouté au journal en tant que champ distinct. Le nom de champ pour un champ supplémentaire est _column$i_, où $i représente le numéro ordinal du champ supplémentaire, en commençant par 0.
keep : Conserve les champs supplémentaires, mais ajoute le contenu supplémentaire en tant que champ unique au journal. Le nom du champ est _column0_.
discard : Supprime les champs supplémentaires.

KeepingSourceWhenParseFail boolean (Facultatif)

Indique s'il faut conserver le champ source en cas d'échec de l'analyse. Valeur par défaut : false.

KeepingSourceWhenParseSucceed boolean (Facultatif)

Indique s'il faut conserver le champ source en cas de réussite de l'analyse. Valeur par défaut : false.

RenamedSourceKey String (Facultatif)

Si le champ source est conservé, il s'agit du nom de champ utilisé pour stocker le champ source. Par défaut, le nom n'est pas modifié.

Analyse JSON standard

Structure les journaux JSON de type objet, en les analysant en paires clé-valeur.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_parse_json_native.

# ...Sous spec.config...
    processors:
      # Configuration du plug-in d'analyse JSON
      - Type: processor_parse_json_native
        # Source du champ de journal brut
        SourceKey: content

SourceKey String (Obligatoire)

Le nom du champ source.

KeepingSourceWhenParseFail boolean (Facultatif)

Indique s'il faut conserver le champ source en cas d'échec de l'analyse. Valeur par défaut : false.

KeepingSourceWhenParseSucceed boolean (Facultatif)

Indique s'il faut conserver le champ source en cas de réussite de l'analyse. Valeur par défaut : false.

RenamedSourceKey String (Facultatif)

Si le champ source est conservé, il s'agit du nom de champ utilisé pour stocker le champ source. Par défaut, le nom n'est pas modifié.

Analyse JSON imbriquée

Analyse les journaux JSON imbriqués en paires clé-valeur en spécifiant une profondeur d'expansion.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_json.

# ...Sous spec.config...
    processors:
      # Configurez le plug-in d'expansion de champ JSON.
      - Type: processor_json
        # Spécifiez le nom du champ brut à analyser.
        SourceKey: content

        ExpandDepth: 0

        ExpandConnector: '_'

        Prefix: expand

        IgnoreFirstConnector: false

        # Indique s'il faut développer les éléments de tableau en champs distincts.
        ExpandArray: false

        # Indique s'il faut conserver le contenu du champ brut.
        KeepSource: true

        # Indique s'il faut signaler une erreur si le champ brut est manquant.
        NoKeyError: true

        # Indique s'il faut utiliser le nom du champ brut comme préfixe pour les noms de champs développés.
        UseSourceKeyAsPrefix: false

        # Indique s'il faut conserver les données de journal brutes si l'analyse JSON échoue.
        KeepSourceIfParseError: true

SourceKey String (Obligatoire)

Le nom du champ source.

ExpandDepth integer (Facultatif)

La profondeur d'expansion JSON. Valeur par défaut : 0.

0 : Développe jusqu'au niveau le plus profond pouvant être analysé.
1 : Développe uniquement le niveau actuel, et ainsi de suite.

ExpandConnector String (Facultatif)

Le connecteur pour les noms de champs lors de l'expansion JSON. Valeur par défaut : underscore (_).

Prefix String (Facultatif)

Spécifie un préfixe pour les noms de champs JSON développés.

IgnoreFirstConnector String (Facultatif)

Indique s'il faut ignorer le premier connecteur, c'est-à-dire s'il faut ajouter un connecteur avant le champ de niveau supérieur. Valeur par défaut : false.

ExpandArray boolean (Facultatif)

Indique s'il faut développer les types de tableau. Valeur par défaut : false.

false (par défaut) : Ne développe pas.
true : Développe. Par exemple, {"k":["1","2"]} est développé en {"k[0]":"1","k[1]":"2"}.

Remarque

Ce paramètre est pris en charge dans les versions Logtail 1.8.0 et ultérieures.

KeepSource boolean (Facultatif)

Indique s'il faut conserver le champ brut dans le journal analysé. Valeur par défaut : true.

true : Conserver
false : Supprimer

NoKeyError boolean (Facultatif)

Indique si le système signale une erreur si le champ brut spécifié n'est pas trouvé dans le journal brut. Valeur par défaut : true.

true : Signaler une erreur.
false : Ne pas signaler d'erreur.

UseSourceKeyAsPrefix boolean (Facultatif)

Indique s'il faut utiliser le nom du champ brut comme préfixe pour tous les noms de champs JSON développés.

KeepSourceIfParseError boolean (Facultatif)

Indique s'il faut conserver le journal brut si l'analyse échoue. Valeur par défaut : true.

true : Conserver
false : Supprimer

Analyse de tableau JSON

Utilise la fonction json_extract pour extraire des objets JSON d'un tableau JSON. Pour plus d'informations sur les fonctions JSON, consultez Fonctions JSON.

Champs clés	Exemple
Type `String` (Obligatoire) Le type de plug-in. Le type de plug-in SPL est `processor_spl`.	`# ...Sous spec.config... processors: # Utilisez un script SPL pour traiter les champs de journal. - Type: processor_spl # Délai d'expiration du script (unité : millisecondes) TimeoutMilliSeconds: 1000 # Contenu du script SPL, utilisé pour extraire des éléments d'un tableau JSON dans le champ content. Script: >- * \| extend json1 = json_extract(content, '$[0]'), json2 = json_extract(content, '$[1]')`
Script `String` (Obligatoire) Le contenu du script SPL, utilisé pour extraire des éléments d'un tableau JSON dans le champ content.
TimeoutMilliSeconds `integer` (Facultatif) La période de délai d'expiration du script. Plage de valeurs : 0 à 10 000. Unité : millisecondes. Valeur par défaut : 1 000.

Analyse des journaux NGINX

Structure le contenu du journal en fonction de la définition dans log_format, en l'analysant en plusieurs paires clé-valeur. Si le contenu par défaut ne répond pas à vos besoins, utilisez un format personnalisé.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Le type de plug-in pour l'analyse des journaux Nginx est processor_parse_regex_native.

# ...Sous spec.config...
    processors:
      # Configuration du plug-in d'analyse des journaux NGINX
      - Type: processor_parse_regex_native
        # Source du champ de journal brut
        SourceKey: content

        # Règle d'analyse par expression régulière
        Regex: >-
          (\S*)\s*-\s*(\S*)\s*\[
          (\d+/\S+/\d+:\d+:\d+:\d+)\s+\S+\]
          \s*"(\S+)\s+(\S+)\s+\S+"
          \s*(\S*)\s*(\S*)\s*(\S*)\s*(\S*)
          \s*"([^"]*)"\s*"([^"]*)".*

        # Mappage des champs extraits
        Keys:
          - remote_addr
          - remote_user
          - time_local
          - request_method
          - request_uri
          - request_time
          - request_length
          - status
          - body_bytes_sent
          - http_referer
          - http_user_agent

        # Configuration spécifique à NGINX
        Extra:
          Format: >-
            log_format main  '$remote_addr - $remote_user [$time_local]
            "$request" ''$request_time $request_length ''$status
            $body_bytes_sent "$http_referer" ''"$http_user_agent"';
          LogType: NGINX

SourceKey String (Obligatoire)

Le nom du champ source.

Regex integer (Obligatoire)

L'expression régulière.

Keys String (Obligatoire)

Une liste des champs extraits.

Extra

Format String (Obligatoire)
La section de configuration des journaux dans le fichier de configuration Nginx, commençant par log_format.
Dans un environnement de production, le log_format ici doit être cohérent avec la définition dans le fichier de configuration Nginx, qui se trouve généralement dans le fichier /etc/nginx/nginx.conf.
LogType String (Obligatoire)
Le type de journal à analyser. Définissez sur NGINX.

KeepingSourceWhenParseFail boolean (Facultatif)

Indique s'il faut conserver le champ source en cas d'échec de l'analyse. Valeur par défaut : false.

KeepingSourceWhenParseSucceed boolean (Facultatif)

Indique s'il faut conserver le champ source en cas de réussite de l'analyse. Valeur par défaut : false.

RenamedSourceKey String (Facultatif)

Si le champ source est conservé, il s'agit du nom de champ utilisé pour stocker le champ source. Par défaut, le nom n'est pas modifié.

Analyse des journaux Apache

Structure le contenu du journal en fonction de la définition dans le fichier de configuration des journaux Apache, en l'analysant en plusieurs paires clé-valeur.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_parse_regex_native.

# ...Sous spec.config...
    processors:
      # Configurez le plug-in d'analyse des journaux Apache Combined (basé sur des expressions régulières).
      - Type: processor_parse_regex_native
        # Source du champ de journal brut, généralement content
        SourceKey: content

        # L'expression régulière est utilisée pour faire correspondre et extraire les journaux au format combiné Apache.
        Regex: >-
          ([0-9.-]+)\s                          # remote_addr
          ([\w.-]+)\s                           # remote_ident
          ([\w.-]+)\s                           # remote_user
          (\[[^\[\]]+\]|-)\s                    # time_local
          "((?:[^"]|\")+)"\s                     # request_method + request_uri + request_protocol
          "((?:[^"]|\")+)"\s                     # request_uri (capture répétée ? vérifier la logique)
          "((?:[^"]|\")+)"\s                     # request_protocol
          (\d{3}|-)\s                           # status
          (\d+|-)\s                             # response_size_bytes
          "((?:[^"]|\")+)"\s                     # http_referer
          "((?:[^"]|\"|')+)"                     # http_user_agent

        # Liste des champs extraits, correspondant aux groupes regex dans l'ordre.
        Keys:
          - remote_addr
          - remote_ident
          - remote_user
          - time_local
          - request_method
          - request_uri
          - request_protocol
          - status
          - response_size_bytes
          - http_referer
          - http_user_agent

        # Informations supplémentaires sur le plug-in (facultatives, pour décrire le format du journal)
        Extra:
          Format: >-
            LogFormat "%h %l %u %t \"%r\" %>s %b
            \"%{Referer}i\" \"%{User-Agent}i\"" combined
          LogType: Apache
          SubType: combined

SourceKey String (Obligatoire)

Le nom du champ source.

Regex integer (Obligatoire)

L'expression régulière.

Keys String (Obligatoire)

Une liste des champs extraits.

Extra

Format String (Obligatoire)
La section de configuration des journaux dans le fichier de configuration Apache, commençant généralement par LogFormat.
LogType String (Obligatoire)
Le type de journal à analyser. Définissez sur Apache.
SubType String (Obligatoire)
Le format du journal.
- common
- combined
- custom

KeepingSourceWhenParseFail boolean (Facultatif)

Indique s'il faut conserver le champ source en cas d'échec de l'analyse. Valeur par défaut : false.

KeepingSourceWhenParseSucceed boolean (Facultatif)

Indique s'il faut conserver le champ source en cas de réussite de l'analyse. Valeur par défaut : false.

RenamedSourceKey String (Facultatif)

Si le champ source est conservé, il s'agit du nom de champ utilisé pour stocker le champ source. Par défaut, le nom n'est pas modifié.

Masquage des données

Utilisez le plug-in processor_desensitize_native pour masquer les données sensibles dans les journaux.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_desensitize_native.

# ...Sous spec.config...
    processors:
      # Configurez le plug-in natif de masquage des journaux.
      - Type: processor_desensitize_native

        # Nom du champ brut
        SourceKey: content

        # Méthode de masquage : const indique le remplacement du contenu sensible par une chaîne fixe.
        Method: const

        # La chaîne cible pour remplacer le contenu sensible.
        ReplacingString: '********'

        # L'expression pour le contenu avant la chaîne remplacée.
        ContentPatternBeforeReplacedString: 'password'':'''

        # L'expression régulière pour le contenu sensible lui-même, correspondant au contenu à remplacer.
        ReplacedContentPattern: '[^'']*'

        # Indique s'il faut remplacer toutes les occurrences correspondantes. Valeur par défaut : true.
        ReplacingAll: true

SourceKey String (Obligatoire)

Le nom du champ source.

Method String (Obligatoire)

La méthode de masquage. Les valeurs prises en charge sont :

const : Remplace le contenu sensible par une constante.
md5 : Remplace le contenu sensible par son hachage MD5.

ReplacingString String (Facultatif)

La chaîne constante utilisée pour remplacer le contenu sensible. Ceci est requis lorsque Method est défini sur const.

ContentPatternBeforeReplacedString String (Obligatoire)

L'expression régulière pour le préfixe du contenu sensible.

ReplacedContentPattern String (Obligatoire)

L'expression régulière pour le contenu sensible.

ReplacingAll boolean (Facultatif)

Indique s'il faut conserver le champ d'origine après une analyse réussie. La valeur par défaut est true.

Filtrage du contenu

Configurez le plug-in processor_filter_regex_native pour faire correspondre les valeurs des champs de journal en fonction d'une expression régulière et ne conserver que les journaux qui répondent aux conditions.

Champs clés	Exemple
Type `String` (Obligatoire) Le type de plug-in. Définissez sur `processor_filter_regex_native`.	# ...Sous spec.config... processors: # Configurez le plug-in de filtrage par expression régulière (peut être utilisé pour le masquage de journaux ou le filtrage de mots sensibles). - Type: processor_filter_regex_native # Définissez une liste d'expressions régulières pour faire correspondre le contenu des champs de journal. FilterRegex: # Exemple : Faites correspondre le contenu contenant "WARNING" ou "ERROR" dans la valeur du champ de journal. - WARNING\|ERROR # Spécifiez le nom du champ de journal à faire correspondre. L'exemple filtre le champ level. FilterKey: - level
FilterRegex `String` (Obligatoire) L'expression régulière pour faire correspondre le champ de journal.
FilterKey `String` (Obligatoire) Le nom du champ de journal à faire correspondre.

Analyse temporelle

Configurez le plug-in processor_parse_timestamp_native pour analyser le champ temporel dans un journal et définir le résultat de l'analyse comme champ __time__ du journal.

Champs clés

Exemple

Type String (Obligatoire)

Le type de plug-in. Définissez sur processor_parse_timestamp_native.

# ...Sous spec.config...
    processors:
      # Configurez le plug-in natif d'analyse temporelle.
      - Type: processor_parse_timestamp_native
        # Source du champ de journal brut, généralement content
        SourceKey: content

        # Définition du format temporel, doit correspondre exactement au format du champ temporel dans le journal.
        SourceFormat: '%Y-%m-%d %H:%M:%S'

        SourceTimezone: 'GMT+00:00'

SourceKey String (Obligatoire)

Le nom du champ source.

SourceFormat String (Obligatoire)

Format temporel. Doit correspondre exactement au format du champ temporel dans le journal.

SourceTimezone String (Facultatif)

Le fuseau horaire de l'heure du journal. Par défaut, le fuseau horaire de la machine est utilisé, c'est-à-dire le fuseau horaire de l'environnement où le processus LoongCollector est situé.

Format :

GMT+HH:MM : Fuseau horaire Est
GMT-HH:MM : Fuseau horaire Ouest

Autres configurations avancées

Pour des cas d'utilisation plus avancés, envisagez les configurations suivantes :

Configurer la collecte de journaux multilignes : Lorsqu'une entrée de journal unique, telle qu'une trace de pile d'exception, s'étend sur plusieurs lignes, vous devez activer le mode multiligne et configurer une expression régulière pour le début d'une ligne afin de faire correspondre le début d'un journal. Cela garantit que l'entrée multiligne est collectée et stockée en tant que journal unique dans un logstore SLS.
Configurer les types de sujet de journal : Définissez différents sujets pour différents flux de journaux afin d'organiser et de catégoriser les données de journal. Cela vous aide à mieux gérer et récupérer les journaux pertinents.
Spécifier les conteneurs pour la collecte (filtrage et listes noires) : Spécifiez des conteneurs et des chemins spécifiques pour la collecte, y compris les configurations de liste blanche et de liste noire.
Enrichir les tags de journal : Ajoutez des métadonnées liées aux variables d'environnement et aux labels de pod aux journaux en tant que champs étendus.

Configurer la collecte de journaux multilignes

Pour analyser correctement les entrées de journal qui s'étendent sur plusieurs lignes (comme les traces de pile Java), activez le mode multiligne. Cela garantit que les lignes connexes sont regroupées en une seule entrée de journal en fonction d'un motif de début défini.

Configuration principale : Dans la configuration spec.config.inputs, ajoutez le paramètre Multiline.

Champs clés

Exemple

Multiline

Active la collecte de journaux multilignes.

Mode
La sélection du mode. Valeur par défaut : custom.
- custom : Indique une expression régulière personnalisée pour faire correspondre le début d'une ligne.
- JSON : JSON multiligne.
StartPattern
L'expression régulière pour le début d'une ligne. Ceci est requis lorsque Mode est défini sur custom.

# ...Sous spec.config...
    inputs:
      - Type: input_file
        # Activez la collecte de journaux multilignes.
        Multiline:
          # Sélection du mode : custom indique une expression régulière personnalisée pour faire correspondre le début d'une ligne.
          Mode: custom
          # L'expression régulière fait correspondre le début de chaque entrée de journal (le marqueur d'un nouveau journal).
          StartPattern: '\d+-\d+-\d+\s\d+:\d+:\d+'

Configurer les types de sujet de journal

Configuration principale : Dans spec.config, ajoutez le paramètre global pour définir le sujet.

Champs clés

Exemple

TopicType

Le type de sujet. Valeurs optionnelles :

machine_group_topic : Sujet de groupe de machines, utilisé pour distinguer les journaux de différents groupes de machines.
filepath : Extraction du chemin de fichier, utilisé pour distinguer les données de journal générées par différents utilisateurs ou applications.
custom : Personnalisé, utilise un sujet de journal statique personnalisé.

Sujet de groupe de machines

spec: 
      config:
        global: 
        # Utilisez le sujet de groupe de machines auquel cette configuration est appliquée comme sujet.
          TopicType: machine_group_topic

Extraction du chemin de fichier

spec:  
      config:
        global: 
          TopicType: filepath
        # Format du sujet. Requis lorsque TopicType est défini sur filepath ou custom.
        # Les résultats d'extraction sont __topic__: userA, __topic__: userB et __topic__: userC.
          TopicFormat: \/data\/logs\/(.*)\/serviceA\/.*

Personnalisé

spec:  
      config:
        global: 
          TopicType: custom
        # Format du sujet. Requis lorsque TopicType est défini sur filepath ou custom.
          TopicFormat: customized:// + nom de sujet personnalisé

TopicFormat

Le format du sujet. Ceci est requis lorsque TopicType est défini sur filepath ou custom.

Spécifier les conteneurs pour la collecte (filtrage et listes noires)

Filtrage

Collecte les journaux uniquement des conteneurs qui répondent aux conditions spécifiées. Plusieurs conditions sont combinées avec un ET logique. Une condition vide est ignorée. Les conditions prennent en charge les expressions régulières.

Configuration principale : Dans spec.config.inputs, configurez le paramètre ContainerFilters pour le filtrage des conteneurs.

Champs clés

Exemple

ContainerFilters

Filtrage des conteneurs

Liste noire/Liste blanche des labels de pod
- IncludeK8sLabel
  Liste blanche des labels de pod K8s : Spécifie les conteneurs à partir desquels collecter les journaux.
- ExcludeK8sLabel
  Liste noire des labels de pod K8s : Exclut la collecte de journaux des conteneurs qui répondent à des conditions spécifiques.
Liste noire et liste blanche des variables d'environnement
- IncludeEnv
  Liste blanche des variables d'environnement
- ExcludeInv
  Liste noire des variables d'environnement
Correspondance regex du nom de Pod/Namespace/Conteneur
- K8sNamespaceRegex
  Correspondance regex du namespace
- K8sPodRegex
  Correspondance regex du nom de pod
- K8sContainerRegex
  Correspondance regex du nom de conteneur

Toutes les expressions régulières sont basées sur le moteur regex RE2 dans Go, qui présente certaines limitations par rapport à des moteurs comme PCRE. Reportez-vous à Annexe : Limites des expressions régulières pour le filtrage des conteneurs pour la rédaction d'expressions régulières.

# ...Sous spec.config...
inputs:
  - Type: input_file # ou input_container_stdio
    # Lorsque le type de plug-in d'entrée est input_file, vous devez définir EnableContainerDiscovery sur true.
    EnableContainerDiscovery: true
    # Filtrage des conteneurs
    ContainerFilters:
      # Liste blanche des labels de pod K8s : Spécifie les conteneurs à partir desquels collecter les journaux.
      IncludeK8sLabel:
        # Exemple : Faites correspondre tous les pods ayant le label app avec une valeur nginx ou redis.
        app: ^(nginx|redis)$

      # Liste noire des labels de pod K8s : Exclut la collecte de journaux des conteneurs qui répondent à des conditions spécifiques.
      ExcludeK8sLabel:
        # Exemple : Exclure tous les pods avec le label app:test.
        app: test
      
      # Liste blanche des variables d'environnement
      IncludeEnv:
        # Faites correspondre tous les conteneurs avec NGINX_SERVICE_PORT=80 ou NGINX_SERVICE_PORT=6379.
        NGINX_SERVICE_PORT: ^(80|6379)$

      # Liste noire des variables d'environnement
      ExcludeEnv:
        # Exclure tous les conteneurs avec ENVIRONMENT=test.
        ENVIRONMENT: test
      
      # Correspondance regex du namespace. Exemple : Faites correspondre tous les conteneurs dans les namespaces default et nginx.
      K8sNamespaceRegex: ^(default|nginx)$
      # Correspondance regex du nom de pod. Exemple : Faites correspondre les conteneurs dans tous les pods dont les noms commencent par nginx-log-demo.
      K8sPodRegex: ^(nginx-log-demo.*)$
      # Correspondance regex du nom de conteneur. Exemple : Faites correspondre tous les conteneurs nommés container-test.
      K8sContainerRegex: ^(container-test)$

Liste noire

Pour exclure les fichiers qui répondent à des conditions spécifiées, utilisez les paramètres suivants sous config.inputs dans le fichier YAML selon vos besoins :

Détails des champs clés

Exemple

# ...Sous spec.config...
inputs:
  - Type: input_file
    # Liste noire des chemins de fichier. Exclut les fichiers qui répondent aux conditions spécifiées. Le chemin doit être un chemin absolu et prend en charge le caractère générique *.
    ExcludeFilePaths:
      - /var/log/*.log

    # Liste noire des noms de fichier. Exclut les fichiers qui répondent aux conditions spécifiées. Prend en charge le caractère générique *.
    ExcludeFiles:
      - test

    # Liste noire des répertoires. Exclut les fichiers qui répondent aux conditions spécifiées. Le chemin doit être un chemin absolu et prend en charge le caractère générique *.
    ExcludeDirs:
      - /var/log/backup*

ExcludeFilePaths

Liste noire des chemins de fichier. Exclut les fichiers qui répondent aux conditions spécifiées. Le chemin doit être un chemin absolu et prend en charge le caractère générique *.

ExcludeFiles

Liste noire des noms de fichier. Exclut les fichiers qui répondent aux conditions spécifiées. Prend en charge le caractère générique *.

ExcludeDirs

Liste noire des répertoires. Exclut les fichiers qui répondent aux conditions spécifiées. Le chemin doit être un chemin absolu et prend en charge le caractère générique *.

Enrichir les tags de journal

Configuration principale : En configurant ExternalEnvTag et ExternalK8sLabelTag dans spec.config.inputs, ajoutez des tags liés aux variables d'environnement du conteneur et aux labels de Pod aux journaux.

Champs clés

Exemple

ExternalEnvTag

Mappe la valeur d'une variable d'environnement spécifiée à un champ de tag. Format : <nom_variable_environnement>: <nom_tag>.

# ...Sous spec.config...
    inputs:
      - Type: input_file # ou input_container_stdio
        ExternalEnvTag:
          <nom_variable_environnement>: <nom_tag>

        ExternalK8sLabelTag:
          <nom_label_pod>: <nom_tag>

ExternalK8sLabelTag

Mappe la valeur d'un label de pod Kubernetes à un champ de tag. Format : <nom_label_pod>: <nom_tag>.

Exemples de configuration

Collecter et analyser les journaux d'accès NGINX en champs structurés

Analyse les journaux NGINX et structure le contenu du journal en plusieurs paires clé-valeur en fonction de la définition dans log_format.

Exemple YAML complet

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: nginx-config
spec:
  config:
    aggregators: []
    global: {}
    inputs:
      - Type: input_file
        FilePaths:
          - /root/log/text1.log
        MaxDirSearchDepth: 0
        FileEncoding: utf8
        EnableContainerDiscovery: true
    processors:
      - Type: processor_parse_regex_native
        SourceKey: content
        Regex: >-
          (\S*)\s*-\s*(\S*)\s*\[(\d+/\S+/\d+:\d+:\d+:\d+)\s+\S+\]\s*"(\S+)\s+(\S+)\s+\S+"\s*(\S*)\s*(\S*)\s*(\S*)\s*(\S*)\s*"([^"]*)"\s*"([^"]*)".*
        Keys:
          - remote_addr
          - remote_user
          - time_local
          - request_method
          - request_uri
          - request_time
          - request_length
          - status
          - body_bytes_sent
          - http_referer
          - http_user_agent
        Extra:
          Format: >-
            log_format main  '$remote_addr - $remote_user [$time_local]
            "$request" ''$request_time $request_length ''$status
            $body_bytes_sent "$http_referer" ''"$http_user_agent"';
          LogType: NGINX
    flushers:
      - Type: flusher_sls
        Logstore: my-log-logstore
    sample: >-
      192.168.*.* - - [15/Apr/2025:16:40:00 +0800] "GET /nginx-logo.png
      HTTP/1.1" 0.000 514 200 368 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
      AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.*.* Safari/537.36"
  project:
    name: my-log-project
  logstores:
    - name: my-log-logstore

Collecter et traiter les journaux multilignes

Activez le mode multiligne pour garantir que les lignes connexes sont regroupées en une seule entrée de journal en fonction d'un motif de début défini. Voici un exemple :

Exemple YAML complet

apiVersion: telemetry.alibabacloud.com/v1alpha1
kind: ClusterAliyunPipelineConfig
metadata:
  name: multiline-config
spec:
  config:
    aggregators: []
    global: {}
    inputs:
      - Type: input_file
        FilePaths:
          - /root/log/text1.log
        MaxDirSearchDepth: 0
        FileEncoding: utf8
        Multiline:
          StartPattern: '\[\d+-\d+-\w+:\d+:\d+,\d+]\s\[\w+]\s.*'
          Mode: custom
          UnmatchedContentTreatment: single_line
        EnableContainerDiscovery: true
    processors: []
    flushers:
      - Type: flusher_sls
        Logstore: my-log-logstore
    sample: |-
      [2023-10-01T10:30:01,000] [INFO] java.lang.Exception: exception happened
          at TestPrintStackTrace.f(TestPrintStackTrace.java:3)
          at TestPrintStackTrace.g(TestPrintStackTrace.java:7)
          at TestPrintStackTrace.main(TestPrintStackTrace.java:16)
  project:
    name: my-log-project
  logstores:
    - name: my-log-logstore

FAQ

Comment envoyer les journaux d'un cluster ACK vers un projet dans un autre compte Alibaba Cloud ?

Installez manuellement LoongCollector (Logtail) dans le cluster ACK et configurez-le avec l'ID du compte Alibaba Cloud cible ou l'AccessKey. Cela permet d'envoyer les journaux de conteneur vers un projet SLS dans un autre compte Alibaba Cloud.

Cas d'utilisation : Collectez les données de journal d'un cluster ACK vers un projet SLS dans un autre compte Alibaba Cloud pour des raisons telles que la structure organisationnelle, l'isolation des autorisations ou la surveillance unifiée. Installez manuellement LoongCollector (Logtail) pour la configuration inter-comptes.

Procédure : La procédure suivante utilise l'installation manuelle de LoongCollector comme exemple. Pour savoir comment installer Logtail, consultez Installer et configurer Logtail.

Connectez-vous au cluster Kubernetes et exécutez la commande correspondante pour votre région afin de télécharger LoongCollector et ses composants dépendants :

Régions en 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 de 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

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

# ===================== Required parameters =====================
# The name of the project that manages the collected logs. Example: k8s-log-custom-sd89ehdq.
projectName: ""
# The region of the project. Example for Shanghai: 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. Optional parameters: Internet (public network) and Intranet (internal network). Default value: Internet.
net: Internet
# The AccessKey ID and AccessKey secret of the Alibaba Cloud account or RAM user. The account or user must have the AliyunLogFullAccess system policy.
accessKeyID: ""
accessKeySecret: ""
# The custom cluster ID. The ID can contain only uppercase letters, lowercase letters, digits, and hyphens (-).
clusterID: ""

Dans le répertoire loongcollector-custom-k8s-package, exécutez la commande suivante pour installer LoongCollector et d'autres composants dépendants :
```
bash k8s-custom-install.sh install
```
Une fois l'installation terminée, vérifiez l'état d'exécution des composants.

Si le pod ne démarre pas, vérifiez si la configuration values.yaml est correcte et si les images pertinentes ont été extraites avec succès.
```
# Check the pod status.
kubectl get po -n kube-system | grep loongcollector-ds
```
SLS crée également automatiquement les ressources suivantes. Connectez-vous à la console Simple Log Service pour les afficher.

|
**Type de ressource**
|
**Nom de la ressource**
|
**Fonction**
| | --- | --- | --- | |
Projet
|
La valeur de `projectName` définie dans le fichier values.yaml
|
Une unité de gestion des ressources qui isole les journaux pour différents services.
| |
Groupe de machines
|
`k8s-group-${cluster_id}`
|
Un ensemble de nœuds de collecte de journaux.
|
Important
LoongCollector ne créera pas de logstore nommé config-operation-log. Si un logstore portant ce nom existe déjà, LoongCollector arrête d'y écrire des journaux.

Comment le même fichier journal ou la même sortie standard de conteneur peut-il être collecté par plusieurs configurations de collecte en même temps ?

Par défaut, chaque source de journal n'est collectée qu'une seule fois pour éviter la duplication des données. Pour permettre à plusieurs configurations de collecter à partir de la même source, activez l'option correspondante dans les paramètres de configuration Logtail :

Connectez-vous à la console Simple Log Service et accédez au projet cible.
Dans le volet de navigation, choisissez Logstores et trouvez le logstore cible.
Cliquez sur l'icône devant son nom pour développer le logstore.
Cliquez sur Logtail Configurations. Dans la liste des configurations, trouvez la configuration Logtail cible et cliquez sur Manage Logtail Configuration dans la colonne Actions.
Sur la page Configurations Logtail, cliquez sur Edit et faites défiler vers le bas jusqu'à la section Input Configurations :
- Pour collecter les journaux de fichiers texte : Activez Allow File to Be Collected for Multiple Times.
- Pour collecter la sortie standard du conteneur : Activez Allow Collection by Different Logtail Configurations.

Annexe : Limites des expressions régulières pour le filtrage des conteneurs

Les expressions régulières pour le filtrage des conteneurs sont basées sur le moteur Go RE2. Ce moteur présente certaines limitations syntaxiques par rapport à d'autres moteurs, tels que PCRE. Tenez compte des limitations suivantes lors de la rédaction d'expressions régulières :

1. Différences dans la syntaxe des groupes nommés

Go utilise la syntaxe (?P<name>...) pour les groupes nommés. Il ne prend pas en charge la syntaxe (?<name>...) utilisée dans PCRE.

Exemple correct : (?P<year>\d{4})
Syntaxe incorrecte : (?<year>\d{4})

2. Fonctionnalités d'expression régulière non prises en charge

Les fonctionnalités d'expression régulière courantes mais complexes suivantes ne sont pas disponibles dans RE2 :

Assertions : (?=...), (?!...), (?<=...), (?<!...)
Expressions conditionnelles : (?(condition)true|false)
Correspondance récursive : (?R), (?0)
Références de sous-programmes : (?&name), (?P>name)
Groupes atomiques : (?>...)

3. Recommandations

Lors du débogage d'expressions régulières avec un outil tel que Regex101, sélectionnez le mode Golang (RE2) pour assurer la compatibilité. Si vous utilisez une syntaxe non prise en charge, le plug-in ne pourra pas analyser ou faire correspondre correctement l'expression.