Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

9.5. Configuration du collecteur de journalisation

L’enregistrement de Red Hat OpenShift recueille les opérations et les journaux d’applications de votre cluster et enrichit les données avec des métadonnées de Pod et de projet Kubernetes. Les modifications prises en charge au collecteur de journaux peuvent être effectuées par le biais de la strophe spec.collection dans la ressource personnalisée ClusterLogging (CR).

9.5.1. Configuration du collecteur de journaux
Copier lien

En modifiant la ressource personnalisée ClusterLogging (CR), vous pouvez configurer le type de collecteur de journaux que vous utilisez.

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.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • L’OpenShift CLI (oc) a été installé.
  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • C’est vous qui avez créé un ClusterLogging CR.

Procédure

  1. De modifier la spécification de collecte ClusterLogging CR:

    Exemple de ClusterLogging CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  collection:
    type: <log_collector_type>
    1 
    
    resources: {}
    tolerations: {}
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le type de collecteur de journaux que vous souhaitez utiliser pour l’enregistrement. Cela peut être vecteur ou fluide.

  2. Appliquez le ClusterLogging CR en exécutant la commande suivante: 

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

9.5.2. Création d’une ressource LogFileMetricExporter
Copier lien

Dans la version de journalisation 5.8 et les versions plus récentes, le LogFileMetricExporter n’est plus déployé avec le collecteur par défaut. Il faut créer manuellement une ressource personnalisée LogFileMetricExporter (CR) pour générer des métriques à partir des journaux produits par l’exécution de conteneurs.

Dans le cas où vous ne créez pas le LogFileMetricExporter CR, vous pouvez voir un message Aucun point de données trouvé dans le service Red Hat OpenShift sur le tableau de bord de la console Web AWS pour les journaux produits.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Créer un fichier LogFileMetricExporter CR en tant que fichier YAML:

    Exemple LogFileMetricExporter CR

    apiVersion: logging.openshift.io/v1alpha1
kind: LogFileMetricExporter
metadata:
  name: instance
  namespace: openshift-logging
spec:
  nodeSelector: {}
    1 
    
  resources:
    2 
    
    limits:
      cpu: 500m
      memory: 256Mi
    requests:
      cpu: 200m
      memory: 128Mi
  tolerations: []
    3 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Facultatif: Le nodeSelector stanza définit les nœuds sur lesquels les pods sont programmés.
    2
    La strophe de ressources définit les besoins de ressources pour le LogFileMetricExporter CR.
    3
    Facultatif : La strophe de tolérance définit les tolérances que les pods acceptent.

  2. Appliquez le LogFileMetricExporter CR en exécutant la commande suivante: 

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

La vérification

Le pod de logfilesmetricexporter fonctionne en même temps qu’un pod de collecteur sur chaque nœud.

  • Assurez-vous que les pods logfilesmetricexporter s’exécutent dans l’espace de noms où vous avez créé le LogFileMetricExporter CR, en exécutant la commande suivante et en observant la sortie: 

    $ oc get pods -l app.kubernetes.io/component=logfilesmetricexporter -n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                           READY   STATUS    RESTARTS   AGE
logfilesmetricexporter-9qbjj   1/1     Running   0          2m46s
logfilesmetricexporter-cbc4v   1/1     Running   0          2m46s
    Copy to Clipboard Toggle word wrap

Le collecteur de journaux permet d’ajuster les limites du CPU et de la mémoire.

Procédure

  • Éditer la ressource personnalisée ClusterLogging (CR) dans le projet openshift-logging: 

    $ oc -n openshift-logging edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap 
    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    type: fluentd
    resources:
      limits:
    1 
    
        memory: 736Mi
      requests:
        cpu: 100m
        memory: 736Mi
# ...
    Copy to Clipboard Toggle word wrap
    1
    Indiquez les limites et les requêtes du CPU et de la mémoire au besoin. Les valeurs affichées sont les valeurs par défaut.

9.5.4. Configuration des récepteurs d’entrée
Copier lien

Le Red Hat OpenShift Logging Operator déploie un service pour chaque récepteur d’entrée configuré afin que les clients puissent écrire au collecteur. Ce service expose le port spécifié pour le récepteur d’entrée. Le nom du service est généré en fonction des éléments suivants:

  • Dans le cas des déploiements ClusterLogForwarder CR, le nom du service est au format &lt;ClusterLogForwarder_CR_name&gt;-&lt;input_name&gt;. Exemple-http-récepteur.
  • Dans le cas des déploiements ClusterLogForwarder CR existants, c’est-à-dire ceux nommés instance et situés dans l’espace de noms openshift-logging, le nom du service est dans le format collector-&lt;input_name&gt;. À titre d’exemple, collector-http-récepteur.

Configurez votre collecteur de journaux pour écouter les connexions HTTP et recevoir des journaux d’audit en tant que serveur HTTP en spécifiant http comme une entrée de récepteur dans la ressource personnalisée ClusterLogForwarder (CR). Cela vous permet d’utiliser un log store commun pour les journaux d’audit qui sont collectés à l’intérieur et à l’extérieur de votre Red Hat OpenShift Service sur AWS cluster.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • L’OpenShift CLI (oc) a été installé.
  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • ClusterLogForwarder CR a créé un ClusterLogForwarder CR.

Procédure

  1. De modifier le ClusterLogForwarder CR pour ajouter la configuration de l’entrée du récepteur http:

    Exemple ClusterLogForwarder CR si vous utilisez un déploiement multi log

    apiVersion: logging.openshift.io/v1beta1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  serviceAccountName: <service_account_name>
  inputs:
    - name: http-receiver
    1 
    
      receiver:
        type: http
    2 
    
        http:
          format: kubeAPIAudit
    3 
    
          port: 8443
    4 
    
  pipelines:
    5 
    
    - name: http-pipeline
      inputRefs:
        - http-receiver
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indiquez un nom pour votre récepteur d’entrée.
    2
    Indiquez le type de récepteur d’entrée comme http.
    3
    Actuellement, seul le format webhook kube-apiserver est pris en charge pour les récepteurs d’entrée http.
    4
    Facultatif: Spécifiez le port que le récepteur d’entrée écoute. Cela doit être une valeur entre 1024 et 65535. La valeur par défaut est 8443 si cela n’est pas spécifié.
    5
    Configurez un pipeline pour votre récepteur d’entrée.

    Exemple ClusterLogForwarder CR si vous utilisez un déploiement hérité

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  inputs:
    - name: http-receiver
    1 
    
      receiver:
        type: http
    2 
    
        http:
          format: kubeAPIAudit
    3 
    
          port: 8443
    4 
    
  pipelines:
    5 
    
  - inputRefs:
    - http-receiver
    name: http-pipeline
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indiquez un nom pour votre récepteur d’entrée.
    2
    Indiquez le type de récepteur d’entrée comme http.
    3
    Actuellement, seul le format webhook kube-apiserver est pris en charge pour les récepteurs d’entrée http.
    4
    Facultatif: Spécifiez le port que le récepteur d’entrée écoute. Cela doit être une valeur entre 1024 et 65535. La valeur par défaut est 8443 si cela n’est pas spécifié.
    5
    Configurez un pipeline pour votre récepteur d’entrée.

  2. Appliquez les modifications au ClusterLogForwarder CR en exécutant la commande suivante: 

    $ oc apply -f <filename>.yaml
    Copy to Clipboard Toggle word wrap
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.

La journalisation comprend plusieurs paramètres Fluentd que vous pouvez utiliser pour régler les performances du transmetteur de journal Fluentd. Avec ces paramètres, vous pouvez modifier les comportements Fluentd suivants:

  • Dimensions de tampons de morceaux et de morceaux
  • Comportement de rinçage des morceaux
  • Comportement de réessayer de transfert de chunk

Fluentd recueille les données de log dans un seul blob appelé un morceau. Lorsque Fluentd crée un morceau, le morceau est considéré comme étant dans le stade, où le morceau est rempli de données. Lorsque le morceau est plein, Fluentd déplace le morceau vers la file d’attente, où des morceaux sont conservés avant d’être rincés, ou écrits à leur destination. Fluentd peut ne pas rincer un morceau pour un certain nombre de raisons, telles que les problèmes de réseau ou les problèmes de capacité à destination. Lorsqu’un morceau ne peut pas être rincé, Fluentd retries rinçage comme configuré.

Dans Red Hat OpenShift Service sur AWS, Fluentd utilise la méthode exponentielle de recul pour réessayer le flushing, où Fluentd double le temps qu’il attend entre les tentatives de réessayer à nouveau, ce qui aide à réduire les demandes de connexion à la destination. À la place, vous pouvez désactiver le recul exponentiel et utiliser la méthode de réessai périodique, qui récupère les morceaux à un intervalle spécifié.

Ces paramètres peuvent vous aider à déterminer les compromis entre la latence et le débit.

  • Afin d’optimiser Fluentd pour le débit, vous pouvez utiliser ces paramètres pour réduire le nombre de paquets réseau en configurant de plus grands tampons et files d’attente, en retardant les flushes et en définissant des temps plus longs entre les retries. Gardez à l’esprit que les plus grands tampons nécessitent plus d’espace sur le système de fichiers des nœuds.
  • Afin d’optimiser la latence, vous pouvez utiliser les paramètres pour envoyer des données dès que possible, éviter l’accumulation de lots, avoir des files d’attente et des tampons plus courts, et utiliser des chasses et des retries plus fréquentes.

Il est possible de configurer le comportement d’étranglement et de rinçage à l’aide des paramètres suivants dans la ressource personnalisée ClusterLogging (CR). Les paramètres sont ensuite automatiquement ajoutés à la carte de configuration Fluentd pour une utilisation par Fluentd.

Note

Ces paramètres sont:

  • Ce n’est pas pertinent pour la plupart des utilisateurs. Les paramètres par défaut devraient donner de bonnes performances générales.
  • Ce n’est que pour les utilisateurs avancés ayant une connaissance détaillée de la configuration et des performances Fluentd.
  • Ce n’est que pour le réglage des performances. Ils n’ont aucun effet sur les aspects fonctionnels de l’exploitation forestière.
Expand
Tableau 9.11. Configuration fluide avancée Paramètres
Le paramètreDescriptionDéfaut par défaut

chunkLimitSize

La taille maximale de chaque morceau. Fluentd arrête d’écrire des données sur un morceau lorsqu’il atteint cette taille. Ensuite, Fluentd envoie le morceau à la file d’attente et ouvre un nouveau morceau.

8M

la taille totaleLimitSize

La taille maximale du tampon, qui est la taille totale de la scène et de la file d’attente. Lorsque la taille du tampon dépasse cette valeur, Fluentd cesse d’ajouter des données aux morceaux et échoue avec une erreur. Les données qui ne sont pas en morceaux sont perdues.

Environ 15% du disque de nœud distribué sur toutes les sorties.

flushInterval

L’intervalle entre les bouffées de morceaux. Il est possible d’utiliser s (secondes), m (minutes), h (heures) ou d (jours).

1s

FlushMode

La méthode pour effectuer des bouffées:

  • Lazy: Les morceaux de flush basés sur le paramètre timekey. Il est impossible de modifier le paramètre timekey.
  • intervalle: morceaux de flush basé sur le paramètre flushInterval.
  • immédiatement après l’ajout des données à un morceau.

intervalle

flushThreadCount

Le nombre de fils qui effectuent le rinçage en morceaux. L’augmentation du nombre de fils améliore le débit de flush, ce qui masque la latence du réseau.

2

action de débordement

Le comportement d’étranglement lorsque la file d’attente est pleine:

  • throw_exception: Montez une exception à afficher dans le journal.
  • bloc : Arrêtez la réduction des données jusqu’à ce que le problème de tampon complet soit résolu.
  • drop_oldest_chunk: Déposez la partie la plus ancienne pour accepter de nouveaux morceaux entrants. Les morceaux plus anciens ont moins de valeur que les morceaux plus récents.

bloc

à propos de RetryMaxInterval

Le temps maximum en secondes pour la méthode de réessayer exponentielle_backoff.

300s

le RetryType

La méthode de réessayer lors du rinçage échoue:

  • exponentielle_backoff: Augmenter le temps entre les retries de chasse. Fluentd double le temps qu’il attend jusqu’à ce que le paramètre retry_max_interval soit atteint.
  • les Retries flushent périodiquement, en fonction du paramètre retryWait.

exponentielle_backoff

à propos de RetryTimeout

L’intervalle de temps maximum pour tenter de retries avant que l’enregistrement ne soit éliminé.

60M

à propos de RetryWait

Le temps en quelques secondes avant la prochaine partie de la chasse.

1s

En savoir plus sur le cycle de vie des morceaux Fluentd, voir Plugins Buffer dans la documentation Fluentd.

Procédure

  1. Éditer la ressource personnalisée ClusterLogging (CR) dans le projet openshift-logging: 

    $ oc edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap

  2. Ajouter ou modifier l’un des paramètres suivants: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    fluentd:
      buffer:
        chunkLimitSize: 8m
    1 
    
        flushInterval: 5s
    2 
    
        flushMode: interval
    3 
    
        flushThreadCount: 3
    4 
    
        overflowAction: throw_exception
    5 
    
        retryMaxInterval: "300s"
    6 
    
        retryType: periodic
    7 
    
        retryWait: 1s
    8 
    
        totalLimitSize: 32m
    9 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    Indiquez la taille maximale de chaque morceau avant qu’il ne soit mis en file d’attente pour le rinçage.
    2
    Indiquez l’intervalle entre les bouffées de morceaux.
    3
    Indiquez la méthode pour effectuer des bouffées de morceaux: paresseux, intervalle ou immédiat.
    4
    Indiquez le nombre de fils à utiliser pour les bouffées de morceaux.
    5
    Indiquez le comportement d’étranglement lorsque la file d’attente est pleine: throw_exception, block ou drop_oldest_chunk.
    6
    Indiquez l’intervalle maximal en secondes pour la méthode de rinçage de chunk exponentielle_backoff.
    7
    Indiquez le type de réessayer en cas d’échec du rinçage: exponentielle_backoff ou périodique.
    8
    Indiquez le temps en quelques secondes avant la prochaine chasse.
    9
    Indiquez la taille maximale du tampon de morceaux.

  3. Assurez-vous que les gousses Fluentd sont redéployées: 

    $ oc get pods -l component=collector -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. Assurez-vous que les nouvelles valeurs sont dans la carte de configuration fluide: 

    $ oc extract configmap/collector-config --confirm
    Copy to Clipboard Toggle word wrap

    Exemple fluentd.conf

    <buffer>
  @type file
  path '/var/lib/fluentd/default'
  flush_mode interval
  flush_interval 5s
  flush_thread_count 3
  retry_type periodic
  retry_wait 1s
  retry_max_interval 300s
  retry_timeout 60m
  queued_chunks_limit_size "#{ENV['BUFFER_QUEUE_LIMIT'] || '32'}"
  total_limit_size "#{ENV['TOTAL_LIMIT_SIZE_PER_BUFFER'] || '8589934592'}"
  chunk_limit_size 8m
  overflow_action throw_exception
  disable_chunk_backup true
</buffer>
    Copy to Clipboard Toggle word wrap

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