Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

9.3. Activer le transfert de journaux JSON

Il est possible de configurer l’API Log Forwarding pour analyser les chaînes JSON dans un objet structuré.

9.3.1. Analyse des journaux JSON
Copier lien

Il est possible d’utiliser un objet ClusterLogForwarder pour analyser les logs JSON dans un objet structuré et les transmettre à une sortie prise en charge.

Afin d’illustrer comment cela fonctionne, supposons que vous ayez l’entrée de journal JSON structurée suivante:

Exemple d’entrée de journal JSON structurée

{"level":"info","name":"fred","home":"bedrock"}
Copy to Clipboard Toggle word wrap

Afin d’activer l’analyse du journal JSON, vous ajoutez parse: json à un pipeline dans le ClusterLogForwarder CR, comme indiqué dans l’exemple suivant:

Exemple d’extrait montrant l’analyse: json

pipelines:
- inputRefs: [ application ]
  outputRefs: myFluentd
  parse: json
Copy to Clipboard Toggle word wrap

Lorsque vous activez l’analyse des journaux JSON en utilisant parse: json, le CR copie l’entrée de journal structurée JSON dans un champ structuré, comme indiqué dans l’exemple suivant:

Exemple de sortie structurée contenant l’entrée de journal JSON structurée

{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
 "more fields..."}
Copy to Clipboard Toggle word wrap

Important

Dans le cas où l’entrée de journal ne contient pas de JSON structuré valide, le champ structuré est absent.

Lorsque vos journaux JSON suivent plus d’un schéma, les stocker dans un seul index peut causer des conflits de type et des problèmes de cardinalité. Afin d’éviter cela, vous devez configurer la ressource personnalisée ClusterLogForwarder (CR) pour regrouper chaque schéma en une seule définition de sortie. De cette façon, chaque schéma est transmis à un index séparé.

Important

Lorsque vous transmettez les logs JSON à l’instance Elasticsearch par défaut gérée par OpenShift Logging, elle génère de nouveaux indices en fonction de votre configuration. Afin d’éviter les problèmes de performance associés à un trop grand nombre d’indices, envisagez de maintenir le nombre de schémas possibles en standardisant les schémas communs.

Les types de structure

Dans le ClusterLogForwarder CR, vous pouvez utiliser les types de structure suivants pour construire des noms d’index pour le magasin de journal Elasticsearch:

  • StructureTypeKey est le nom d’un champ de message. La valeur de ce champ est utilisée pour construire le nom de l’index.

    • Kubernetes.labels.<key> est l’étiquette de pod Kubernetes dont la valeur est utilisée pour construire le nom de l’index.
    • l’élément OpenShift.labels.<key> est l’élément pipeline.label.<key> dans le ClusterLogForwarder CR dont la valeur est utilisée pour construire le nom de l’index.
    • Kubernetes.container_name utilise le nom du conteneur pour construire le nom de l’index.
  • StructureTypeName: Si le champ StructureTypeKey n’est pas défini ou que sa clé n’est pas présente, la valeur StructureTypeName est utilisée comme type structuré. Lorsque vous utilisez à la fois le champ StructureTypeKey et le champ StructureTypeName ensemble, la valeur StructureTypeName fournit un nom d’index de retour si la clé dans le champ StructureTypeKey est absente des données de journal JSON.
Note

Bien que vous puissiez définir la valeur de StructureTypeKey à n’importe quel champ affiché dans le sujet "Log Record Fields", les champs les plus utiles sont affichés dans la liste précédente des types de structure.

A StructureTypeKey: kubernetes.labels.<key> exemple

Imaginez ce qui suit:

  • Le cluster exécute des pods d’applications qui produisent des logs JSON dans deux formats différents, "apache" et "google".
  • L’utilisateur étiquete ces pods d’application avec logFormat=apache et logFormat=google.
  • Dans votre fichier ClusterLogForwarder CR YAML, vous utilisez l’extrait suivant. 
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat
1 

      structuredTypeName: nologformat
  pipelines:
  - inputRefs:
    - application
    outputRefs:
    - default
    parse: json
2
Copy to Clipboard Toggle word wrap
1
Utilise la valeur de la paire clé-valeur qui est formée par l’étiquette logFormat Kubernetes.
2
Active l’analyse des journaux JSON.

Dans ce cas, l’enregistrement de journal structuré suivant va à l’index app-apache-écriture: 

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}
Copy to Clipboard Toggle word wrap

Et l’enregistrement de journal structuré suivant va à l’index app-google-écriture: 

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}
Copy to Clipboard Toggle word wrap

Exemple StructureTypeKey: openshift.labels.<key>

Imaginez que vous utilisez l’extrait suivant dans votre fichier ClusterLogForwarder CR YAML. 

outputDefaults:
 elasticsearch:
    structuredTypeKey: openshift.labels.myLabel
1 

    structuredTypeName: nologformat
pipelines:
 - name: application-logs
   inputRefs:
   - application
   - audit
   outputRefs:
   - elasticsearch-secure
   - default
   parse: json
   labels:
     myLabel: myValue
2
Copy to Clipboard Toggle word wrap
1
Utilise la valeur de la paire clé-valeur qui est formée par le label OpenShift myLabel.
2
L’élément myLabel donne sa valeur de chaîne, myValue, à l’enregistrement de journal structuré.

Dans ce cas, l’enregistrement de journal structuré suivant va à l’index app-myValue-write: 

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}
Copy to Clipboard Toggle word wrap

Considérations supplémentaires

  • L’indice Elasticsearch pour les enregistrements structurés est formé en prépendant "app-" au type structuré et en ajoutant "-write".
  • Les enregistrements non structurés ne sont pas envoyés à l’index structuré. Ils sont indexés comme d’habitude dans les indices d’application, d’infrastructure ou d’audit.
  • En l’absence de type structuré non vide, dirigez un enregistrement non structuré sans champ structuré.

Il est important de ne pas surcharger Elasticsearch avec trop d’indices. Il suffit d’utiliser des types structurés distincts pour des formats de journal distincts, pas pour chaque application ou espace de noms. Ainsi, la plupart des applications Apache utilisent le même format de journal JSON et le même type structuré, comme LogApache.

Dans le cas d’un magasin de journal Elasticsearch, si vos entrées de journal JSON suivent différents schémas, configurez la ressource personnalisée ClusterLogForwarder (CR) pour regrouper chaque schéma JSON en une seule définition de sortie. De cette façon, Elasticsearch utilise un index distinct pour chaque schéma.

Important

Étant donné que le transfert de différents schémas vers le même index peut causer des conflits de type et des problèmes de cardinalité, vous devez effectuer cette configuration avant de transmettre les données au magasin Elasticsearch.

Afin d’éviter les problèmes de performance associés à un trop grand nombre d’indices, envisagez de maintenir le nombre de schémas possibles en standardisant les schémas communs.

Procédure

  1. Ajoutez l’extrait suivant à votre fichier ClusterLogForwarder CR YAML. 

    outputDefaults:
 elasticsearch:
    structuredTypeKey: <log record field>
    structuredTypeName: <name>
pipelines:
- inputRefs:
  - application
  outputRefs: default
  parse: json
    Copy to Clipboard Toggle word wrap
  2. Utilisez le champ StructureTypeKey pour spécifier l’un des champs d’enregistrement de log.

  3. Utilisez le champ StructureTypeName pour spécifier un nom.

    Important

    Afin d’analyser les logs JSON, vous devez définir les champs StructureTypeKey et StructureTypeName.

  4. Dans le cas des entréesRefs, spécifiez les types de journaux à transmettre en utilisant ce pipeline, comme l’application, l’infrastructure ou l’audit.
  5. Ajouter l’analyse: élément json aux pipelines.

  6. Créer l’objet CR: 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

    Le Red Hat OpenShift Logging Operator redéploie les pods collector. Cependant, s’ils ne redéployent pas, supprimez les pods collector pour les forcer à redéployer. 

    $ oc delete pod --selector logging-infra=collector
    Copy to Clipboard Toggle word wrap

Il est possible d’envoyer des journaux structurés à partir de différents conteneurs à l’intérieur d’un même pod vers différents indices. Afin d’utiliser cette fonctionnalité, vous devez configurer le pipeline avec le support multi-conteneurs et annoter les pods. Les journaux sont écrits dans des indices avec un préfixe d’application-. Il est recommandé de configurer Elasticsearch avec des alias pour y répondre.

Important

Le formatage JSON des journaux varie selon l’application. Étant donné que la création de trop d’indices impacte la performance, limitez votre utilisation de cette fonctionnalité à la création d’indices pour les journaux qui ont des formats JSON incompatibles. Les requêtes permettent de séparer les journaux de différents espaces de noms ou d’applications avec des formats JSON compatibles.

Conditions préalables

  • Enregistrement pour Red Hat OpenShift: 5.5

Procédure

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat
    1 
    
      structuredTypeName: nologformat
      enableStructuredContainerLogs: true
    2 
    
  pipelines:
  - inputRefs:
    - application
    name: application-logs
    outputRefs:
    - default
    parse: json
    Copy to Clipboard Toggle word wrap
    1
    Utilise la valeur de la paire clé-valeur qui est formée par l’étiquette logFormat Kubernetes.
    2
    Active les sorties multiconteneurs.

  2. Créer ou modifier un fichier YAML qui définit l’objet Pod CR: 

    apiVersion: v1
kind: Pod
metadata:
  annotations:
    containerType.logging.openshift.io/heavy: heavy
    1 
    
    containerType.logging.openshift.io/low: low
spec:
  containers:
  - name: heavy
    2 
    
    image: heavyimage
  - name: low
    image: lowimage
    Copy to Clipboard Toggle word wrap
    1
    Format: containerType.logging.openshift.io/&lt;container-name&gt;: &lt;index&gt;
    2
    Les noms d’annotation doivent correspondre aux noms de conteneurs
Avertissement

Cette configuration pourrait augmenter considérablement le nombre de fragments sur le cluster.

Ressources supplémentaires

Retour au début
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2025 Red Hat