Chapitre 15. Champs d’enregistrement de journaux

Les champs suivants peuvent être présents dans les enregistrements de log exportés par l’enregistrement. Bien que les enregistrements de journaux soient généralement formatés en tant qu’objets JSON, le même modèle de données peut être appliqué à d’autres encodages.

Afin de rechercher ces champs depuis Elasticsearch et Kibana, utilisez le nom de champ en pointillé complet lors de la recherche. Avec une URL Elasticsearch /_search, par exemple, pour rechercher un nom de pod Kubernetes, utilisez /_search/q=kubernetes.pod_name:name-of-my-pod.

Les champs de niveau supérieur peuvent être présents dans chaque enregistrement.

le message

Le texte d’entrée de journal d’origine, UTF-8 encodé. Ce champ peut être absent ou vide si un champ structuré non vide est présent. Consultez la description de la structure pour plus d’informations.

a) Structure

Entrée de journal d’origine en tant qu’objet structuré. Ce champ peut être présent si l’expéditeur a été configuré pour analyser les journaux JSON structurés. Dans le cas où l’entrée de journal d’origine était un journal structuré valide, ce champ contiendra une structure JSON équivalente. Dans le cas contraire, ce champ sera vide ou absent, et le champ de message contiendra le journal d’origine. Le champ structuré peut avoir tous les sous-champs qui sont inclus dans le message de journal, il n’y a pas de restrictions définies ici.

@timestamp

La valeur UTC qui marque lorsque la charge utile du journal a été créée ou, si l’heure de création n’est pas connue, lorsque la charge utile du journal a été collectée pour la première fois. Le préfixe "@" désigne un champ réservé à une utilisation particulière. La plupart des outils recherchent par défaut "@timestamp" avec ElasticSearch.

le nom d’hôte

Le nom de l’hôte à l’origine de ce message journal. Dans un cluster Kubernetes, c’est la même chose que kubernetes.host.

ipaddr4

L’adresse IPv4 du serveur source. Ça peut être un tableau.

ipaddr6

L’adresse IPv6 du serveur source, si disponible. Ça peut être un tableau.

a) Niveau

Le niveau de journalisation de diverses sources, y compris rsyslog (propriété textuelle), un module de journalisation Python, et d’autres.

Les valeurs suivantes proviennent de syslog.h, et sont précédées de leurs équivalents numériques:

Les deux valeurs suivantes ne font pas partie de syslog.h mais sont largement utilisées:

Cartographiez les niveaux de log ou les priorités des autres systèmes d’enregistrement à leur correspondance la plus proche dans la liste précédente. À partir de l’enregistrement de python, par exemple, vous pouvez faire correspondre CRITICAL avec crit, ERROR avec erreur, et ainsi de suite.

le PID

L’ID de processus de l’entité de journalisation, si disponible.

le service

Le nom du service associé à l’entité d’enregistrement, s’il est disponible. À titre d’exemple, les propriétés APP-NAME de syslog et rsyslog sont cartographiées sur le champ de service.