Chapitre 9. Collecte et transfert de journaux


9.1. À propos de la collecte et du transfert de journaux

Le Red Hat OpenShift Logging Operator déploie un collecteur basé sur la spécification de ressources ClusterLogForwarder. Il existe deux options de collecteur prises en charge par cet opérateur : l’ancien collectionneur Fluentd et le collecteur Vecteur.

Note

Fluentd est déprécié et devrait être retiré dans une version ultérieure. Le Red Hat fournit des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne reçoit plus d’améliorations. Comme alternative à Fluentd, vous pouvez utiliser Vector à la place.

9.1.1. Collection de journaux

Le collecteur de journaux est un jeu de démons qui déploie des pods sur chaque nœud dédié OpenShift pour collecter les logs des conteneurs et des nœuds.

Le collecteur de journaux utilise par défaut les sources suivantes:

  • Journaux système et infrastructure générés par les messages journalisés du système d’exploitation, du temps d’exécution du conteneur et d’OpenShift Dedicated.
  • /Var/log/containers/*.log pour tous les journaux de conteneurs.

Lorsque vous configurez le collecteur de journaux pour collecter les journaux d’audit, il les recueille à partir de /var/log/audit/audit.log.

Le collecteur de journaux recueille les journaux à partir de ces sources et les transmet en interne ou en externe en fonction de votre configuration de journalisation.

9.1.1.1. Les types de collecteurs de journaux

Le vecteur est un collecteur de journaux offert comme alternative à Fluentd pour l’enregistrement.

Configurez le type de collecteur de journalisation utilisé par votre cluster en modifiant la spécification de collecte de ressources personnalisées ClusterLogging (CR):

Exemple ClusterLogging CR qui configure Vector en tant que collecteur

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    logs:
      type: vector
      vector: {}
# ...
Copy to Clipboard

9.1.1.2. Limites de collecte des journaux

Les temps d’exécution du conteneur fournissent des informations minimales pour identifier la source des messages journaux : projet, nom de pod et ID du conteneur. Cette information ne suffit pas à identifier de manière unique la source des journaux. Lorsqu’une pod avec un nom et un projet est supprimée avant que le collecteur de journaux ne commence à traiter ses journaux, les informations provenant du serveur API, telles que les étiquettes et les annotations, pourraient ne pas être disponibles. Il n’y a peut-être pas de moyen de distinguer les messages de log d’un pod et de projeter ou de tracer les journaux jusqu’à leur source. Cette limitation signifie que la collecte et la normalisation des logs sont considérées comme les meilleurs efforts.

Important

Les temps d’exécution des conteneurs disponibles fournissent des informations minimales pour identifier la source des messages journaux et ne garantissent pas que les messages de journal individuels uniques ou que ces messages puissent être tracés à leur source.

9.1.1.3. Caractéristiques du collecteur de journaux par type

Tableau 9.1. Journal des sources
CaractéristiqueFluentdLe vecteur

Journaux de conteneurs d’applications

Routage spécifique à l’application

Routage spécifique à l’application par namespace

Journaux de conteneurs infra

Journaux de journaux infra

Journaux d’audit d’API Kube

Journaux d’audit d’API OpenShift

Journaux d’audit Open Virtual Network (OVN)

Tableau 9.2. Autorisation et authentification
CaractéristiqueFluentdLe vecteur

Certificats Elasticsearch

Elasticsearch nom d’utilisateur / mot de passe

Clés Amazon Cloudwatch

Amazon Cloudwatch STS

Certificats Kafka

Kafka Nom d’utilisateur / mot de passe

Kafka SASL

Jeton au porteur Loki

Tableau 9.3. Les normalisations et les transformations
CaractéristiqueFluentdLe vecteur

Le modèle de données VIAQ - app

Le modèle de données VIAQ - infra

Le modèle de données VIAQ - infra(journal)

Le modèle de données VIAQ - Audit Linux

Le modèle de données VIAQ - audit kube-apiserver

Le modèle de données VIAQ - Audit d’API OpenShift

Données VIAQ - OVN

LogLevel Normalisation

JSON parsing

Indice structuré

Détection d’erreurs multilignes

Indices multiconteneurs / fractionnés

Étiquettes aplaties

Étiquettes statiques CLF

Tableau 9.4. Le réglage
CaractéristiqueFluentdLe vecteur

Fluentd readlinelimit

 

Le tampon Fluentd

 

- chunklimitsize

 

- totallimitsize

 

- débordement

 

- flushthreadcount

 

- FlushMode

 

- flushinterval

 

- réessayer d’attendre

 

- retrytype

 

- retrymaxinterval

 

- RetryTimeout

 
Tableau 9.5. La visibilité
CaractéristiqueFluentdLe vecteur

Les métriques

Tableau de bord

Alertes

Tableau 9.6. Divers
CaractéristiqueFluentdLe vecteur

La prise en charge globale des proxys

assistance x86

Le soutien d’ARM

Le support IBM Power®

Le support IBM Z®

Assistance IPv6

Enregistrement de l’événement tampon

 

Cluster déconnecté

9.1.1.4. Les sorties du collecteur

Les extrants suivants sont pris en charge:

Tableau 9.7. Extrants pris en charge
CaractéristiqueFluentdLe vecteur

Elasticsearch v6-v8

Fluent vers l’avant

 

À propos de Syslog RFC3164

✓ (Enregistrement 5.7+)

À propos de Syslog RFC5424

✓ (Enregistrement 5.7+)

Kafka

Amazon Cloudwatch

Amazon Cloudwatch STS

Loki

HTTP

✓ (Enregistrement 5.7+)

Google Cloud Logging

À propos de Splunk

 

✓ (Enregistrement 5.6+)

9.1.2. Envoi de journaux

Les administrateurs peuvent créer des ressources ClusterLogForwarder qui spécifient quels journaux sont recueillis, comment ils sont transformés et où ils sont transférés.

Les ressources ClusterLogForwarder peuvent être utilisées pour transférer des journaux de conteneurs, d’infrastructures et d’audits vers des points de terminaison spécifiques à l’intérieur ou à l’extérieur d’un cluster. La sécurité de la couche de transport (TLS) est prise en charge afin que les transmetteurs de journaux puissent être configurés pour envoyer des journaux en toute sécurité.

Les administrateurs peuvent également autoriser les autorisations RBAC qui définissent les comptes de service et les utilisateurs qui peuvent accéder et transmettre les types de journaux.

9.1.2.1. Implémentations de transfert journalier

Il existe deux implémentations de transfert de journaux disponibles: l’implémentation héritée et la fonction d’expéditeur multi log.

Important

Le collecteur Vecteur seul est pris en charge pour une utilisation avec la fonction d’expéditeur multi log. Le collecteur Fluentd ne peut être utilisé qu’avec des implémentations héritées.

9.1.2.1.1. La mise en œuvre de l’héritage

Dans les implémentations héritées, vous ne pouvez utiliser qu’un seul transmetteur de journaux dans votre cluster. La ressource ClusterLogForwarder dans ce mode doit être nommée instance, et doit être créée dans l’espace de noms openshift-logging. La ressource ClusterLogForwarder nécessite également une ressource ClusterLogging correspondante nommée instance dans l’espace de noms openshift-logging.

9.1.2.1.2. Fonction d’expéditeur multi log

La fonction d’expéditeur multi log est disponible dans la journalisation 5.8 et ultérieure, et fournit les fonctionnalités suivantes:

  • Les administrateurs peuvent contrôler quels utilisateurs sont autorisés à définir la collection de journaux et quels journaux ils sont autorisés à collecter.
  • Les utilisateurs qui ont les autorisations requises sont en mesure de spécifier des configurations supplémentaires de collecte de journaux.
  • Les administrateurs qui migrent du collecteur Fluentd déprécié vers le collecteur Vector peuvent déployer un nouveau transmetteur de journaux séparément de leur déploiement existant. Les transmetteurs de journaux existants et nouveaux peuvent fonctionner simultanément pendant la migration des charges de travail.

Dans les implémentations de transfert de journaux multiples, vous n’êtes pas tenu de créer une ressource ClusterLogging correspondante pour votre ressource ClusterLogForwarder. Il est possible de créer plusieurs ressources ClusterLogForwarder en utilisant n’importe quel nom, dans n’importe quel espace de noms, avec les exceptions suivantes:

  • Il est impossible de créer une instance de ressource ClusterLogForwarder nommée instance dans l’espace de noms openshift-logging, car elle est réservée à un transmetteur de journaux qui prend en charge le flux de travail existant à l’aide du collecteur Fluentd.
  • Il est impossible de créer une ressource ClusterLogForwarder nommée collector dans l’espace de noms openshift-logging, car cela est réservé au collectionneur.

9.1.2.2. Activer la fonction d’expéditeur multi log pour un cluster

Afin d’utiliser la fonction d’expéditeur multi log, vous devez créer un compte de service et des liaisons de rôle de cluster pour ce compte de service. Ensuite, vous pouvez consulter le compte de service dans la ressource ClusterLogForwarder pour contrôler les autorisations d’accès.

Important

Afin de prendre en charge le transfert de journaux multiples dans des espaces de noms supplémentaires autres que l’espace de noms openshift, vous devez mettre à jour l’opérateur de journalisation Red Hat OpenShift pour regarder tous les espaces de noms. Cette fonctionnalité est prise en charge par défaut dans les nouvelles installations Red Hat OpenShift Logging Operator version 5.8.

9.1.2.2.1. Autoriser la collecte de journaux d’autorisations RBAC

Dans l’enregistrement 5.8 et plus tard, le Red Hat OpenShift Logging Operator fournit des rôles de cluster collect-audit-logs, collect-application-logs et collect-infrastructure-logs, qui permettent au collecteur de collecter des journaux d’audit, des journaux d’applications et des journaux d’infrastructure respectivement.

Les autorisations RBAC pour la collecte de journaux peuvent être autorisées en liant les rôles de cluster requis à un compte de service.

Conditions préalables

  • Le Red Hat OpenShift Logging Operator est installé dans l’espace de noms openshift-logging.
  • Il y a des autorisations d’administrateur.

Procédure

  1. Créez un compte de service pour le collecteur. Lorsque vous souhaitez écrire des journaux au stockage qui nécessite un jeton pour l’authentification, vous devez inclure un jeton dans le compte de service.
  2. Lier les rôles de cluster appropriés au compte de service:

    Exemple de commande de liaison

    $ oc adm policy add-cluster-role-to-user <cluster_role_name> system:serviceaccount:<namespace_name>:<service_account_name>
    Copy to Clipboard

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