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.
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émentpipeline.label.<key>
du CRClusterLogForwarder
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) SistructuredTypeKey
n'est pas défini ou si sa clé n'est pas présente, OpenShift Logging utilise la valeur destructuredTypeName
comme type structuré. Lorsque vous utilisez à la foisstructuredTypeKey
etstructuredTypeName
,structuredTypeName
fournit un nom d'index de repli si la clé destructuredTypeKey
est absente des données du journal JSON.
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
etlogFormat=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
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
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
.