11.2. Configuration des données de journalisation JSON pour Elasticsearch


Si vos journaux JSON suivent plusieurs schémas, leur stockage dans un index unique peut entraîner des conflits de type et des problèmes de cardinalité. Pour éviter cela, vous devez configurer la ressource personnalisée (CR) ClusterLogForwarder pour regrouper chaque schéma dans une définition de sortie unique. De cette manière, chaque schéma est transmis à un index distinct.

Important

Si vous transmettez des logs JSON à l'instance Elasticsearch par défaut gérée par OpenShift Logging, celle-ci génère de nouveaux index en fonction de votre configuration. Pour éviter les problèmes de performance associés à un trop grand nombre d'index, envisagez de maintenir le nombre de schémas possibles à un niveau bas en standardisant les schémas communs.

Types de structures

Vous pouvez utiliser les types de structure suivants dans le CR ClusterLogForwarder pour construire des noms d'index pour le magasin de journaux Elasticsearch :

  • structuredTypeKey (chaîne, facultatif) est le nom d'un champ de message. La valeur de ce champ, si elle est présente, est utilisée pour construire le nom de l'index.

    • kubernetes.labels.<key> est l'étiquette du pod Kubernetes dont la valeur est utilisée pour construire le nom de l'index.
    • openshift.labels.<key> est l'élément pipeline.label.<key> du CR ClusterLogForwarder 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.
  • structuredTypeName: (string, optional) Si structuredTypeKey n'est pas défini ou si sa clé n'est pas présente, OpenShift Logging utilise la valeur de structuredTypeName comme type structuré. Lorsque vous utilisez à la fois structuredTypeKey et structuredTypeName, structuredTypeName fournit un nom d'index de repli si la clé de structuredTypeKey est absente des données du journal JSON.
Note

Bien que vous puissiez attribuer à structuredTypeKey la valeur de n'importe quel champ présenté dans la rubrique "Champs d'enregistrement des journaux", les champs les plus utiles sont présentés dans la liste précédente des types de structure.

Une clé structuréeTypeKey : kubernetes.labels.<key> example

Supposons ce qui suit :

  • Votre cluster exécute des pods d'application qui produisent des journaux JSON dans deux formats différents, "apache" et "google".
  • L'utilisateur étiquette ces modules d'application avec logFormat=apache et logFormat=google.
  • Vous utilisez l'extrait suivant dans votre fichier YAML ClusterLogForwarder CR.
outputDefaults:
 elasticsearch:
    structuredTypeKey: kubernetes.labels.logFormat 1
    structuredTypeName: nologformat
pipelines:
- inputRefs: <application>
  outputRefs: default
  parse: json 2
1
Utilise la valeur de la paire clé-valeur formée par l'étiquette Kubernetes logFormat.
2
Permet d'analyser les journaux JSON.

Dans ce cas, l'enregistrement structuré suivant est placé dans l'index app-apache-write:

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}

L'enregistrement structuré suivant est placé dans l'index app-google-write:

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}

Une clé structuréeTypeKey : openshift.labels.<key> exemple

Supposons que vous utilisiez l'extrait suivant dans votre fichier YAML ClusterLogForwarder CR.

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
1
Utilise la valeur de la paire clé-valeur formée par le label OpenShift myLabel.
2
L'élément myLabel donne sa valeur de chaîne, myValue, à l'enregistrement structuré.

Dans ce cas, l'enregistrement structuré suivant est placé dans l'index app-myValue-write:

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}

Autres considérations

  • Le site Elasticsearch index pour les enregistrements structurés est formé en ajoutant "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 index d'application, d'infrastructure ou d'audit.
  • S'il n'y a pas de type structuré non vide, transmettre un enregistrement unstructured sans champ structured.

Il est important de ne pas surcharger Elasticsearch avec un trop grand nombre d'indices. N'utilisez que des types structurés distincts pour des journaux distincts formats, not pour chaque application ou espace de noms. Par exemple, la plupart des applications Apache utilisent le même format de journal JSON et le même type structuré, comme LogApache.

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.

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 leBlog 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.

© 2024 Red Hat, Inc.