6.2. Configuration du collecteur de journalisation

Le sous-système de journalisation pour Red Hat OpenShift collecte les opérations et les journaux d'application de votre cluster et enrichit les données avec les métadonnées des pods et des projets Kubernetes.

Vous pouvez configurer les limites de CPU et de mémoire pour le collecteur de logs et déplacer les pods du collecteur de logs vers des nœuds spécifiques. Toutes les modifications prises en charge pour le collecteur de journaux peuvent être effectuées via la strophe spec.collection.log.fluentd dans la ressource personnalisée (CR) ClusterLogging.

6.2.1. À propos des configurations non prises en charge

La manière supportée de configurer le sous-système de journalisation pour Red Hat OpenShift est de le configurer en utilisant les options décrites dans cette documentation. N'utilisez pas d'autres configurations, car elles ne sont pas prises en charge. Les paradigmes de configuration peuvent changer à travers les versions d'OpenShift Container Platform, et de tels cas ne peuvent être gérés avec élégance que si toutes les possibilités de configuration sont contrôlées. Si vous utilisez des configurations autres que celles décrites dans cette documentation, vos changements disparaîtront car l'OpenShift Elasticsearch Operator et le Red Hat OpenShift Logging Operator réconcilient toutes les différences. Les opérateurs inversent tout à l'état défini par défaut et par conception.

Note

Si vous must effectuez des configurations non décrites dans la documentation d'OpenShift Container Platform, vous must configurez votre Red Hat OpenShift Logging Operator ou OpenShift Elasticsearch Operator sur Unmanaged. Un environnement OpenShift Logging non géré est not supported et ne reçoit pas de mises à jour jusqu'à ce que vous remettiez OpenShift Logging sur Managed.

6.2.2. Visualisation des pods du collecteur de journalisation

Vous pouvez visualiser les pods du collecteur de logs Fluentd et les nœuds correspondants sur lesquels ils s'exécutent. Les pods Fluentd logging collector s'exécutent uniquement dans le projet openshift-logging.

Procédure

  • Exécutez la commande suivante dans le projet openshift-logging pour afficher les pods du collecteur de logs Fluentd et leurs détails : 
$ oc get pods --selector component=collector -o wide -n openshift-logging

Exemple de sortie

NAME           READY  STATUS    RESTARTS   AGE     IP            NODE                  NOMINATED NODE   READINESS GATES
fluentd-8d69v  1/1    Running   0          134m    10.130.2.30   master1.example.com   <none>           <none>
fluentd-bd225  1/1    Running   0          134m    10.131.1.11   master2.example.com   <none>           <none>
fluentd-cvrzs  1/1    Running   0          134m    10.130.0.21   master3.example.com   <none>           <none>
fluentd-gpqg2  1/1    Running   0          134m    10.128.2.27   worker1.example.com   <none>           <none>
fluentd-l9j7j  1/1    Running   0          134m    10.129.2.31   worker2.example.com   <none>           <none>

6.2.3. Configurer les limites du processeur et de la mémoire du collecteur de journaux

Le collecteur de journaux permet d'ajuster les limites de l'unité centrale et de la mémoire.

Procédure

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

    $ oc -n openshift-logging edit ClusterLogging instance
    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: openshift-logging

...

spec:
  collection:
    logs:
      fluentd:
        resources:
          limits: 1
            memory: 736Mi
          requests:
            cpu: 100m
            memory: 736Mi
    1
    Spécifiez les limites et les demandes de CPU et de mémoire si nécessaire. Les valeurs indiquées sont les valeurs par défaut.

6.2.4. Configuration avancée du redirecteur de logs

Le sous-système de journalisation pour Red Hat OpenShift inclut plusieurs paramètres Fluentd que vous pouvez utiliser pour régler la performance du transitaire de journaux Fluentd. Avec ces paramètres, vous pouvez changer les comportements suivants de Fluentd :

  • Taille des blocs et des tampons de blocs
  • Comportement d'évacuation des morceaux
  • Comportement des tentatives de réacheminement de morceaux

Fluentd collecte les données de log dans un blob unique appelé chunk. Quand Fluentd crée un chunk, le chunk est considéré comme étant dans le stage, où le chunk est rempli de données. Lorsque le bloc est plein, Fluentd le déplace vers queue, où les blocs sont conservés avant d'être vidés, ou écrits vers leur destination. Fluentd peut échouer à vider un chunk pour un certain nombre de raisons, comme des problèmes de réseau ou de capacité à la destination. Si un chunk ne peut pas être flushé, Fluentd retente le flushing comme configuré.

Par défaut dans OpenShift Container Platform, Fluentd utilise la méthode exponential backoff pour réessayer le flushing, où Fluentd double le temps qu'il attend entre les tentatives pour réessayer le flushing, ce qui aide à réduire les demandes de connexion à la destination. Vous pouvez désactiver le backoff exponentiel et utiliser la méthode periodic retry à la place, qui réessaie de vider les chunks à un intervalle spécifié.

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

  • Pour optimiser le débit de Fluentd, vous pouvez utiliser ces paramètres pour réduire le nombre de paquets réseau en configurant des tampons et des files d'attente plus grands, en retardant les vidages et en fixant des délais plus longs entre les tentatives. Sachez que des tampons plus grands nécessitent plus d'espace sur le système de fichiers du nœud.
  • Pour optimiser la latence, vous pouvez utiliser les paramètres pour envoyer les données dès que possible, éviter l'accumulation de lots, avoir des files d'attente et des tampons plus courts, et utiliser plus fréquemment des tentatives d'effacement et de réessai.

Vous pouvez configurer le comportement du chunking et du flushing en utilisant les paramètres suivants dans la ressource personnalisée (CR) ClusterLogging. Les paramètres sont alors automatiquement ajoutés à la carte de configuration de Fluentd pour être utilisés par Fluentd.

Note

Ces paramètres sont les suivants

  • Non pertinent pour la plupart des utilisateurs. Les paramètres par défaut devraient permettre d'obtenir de bonnes performances générales.
  • Uniquement pour les utilisateurs avancés ayant une connaissance détaillée de la configuration et des performances de Fluentd.
  • Uniquement pour l'optimisation des performances. Elles n'ont aucun effet sur les aspects fonctionnels de la journalisation.

Tableau 6.1. Paramètres de configuration avancée de Fluentd

ParamètresDescriptionDéfaut

chunkLimitSize

La taille maximale de chaque bloc. Fluentd arrête d'écrire des données dans un chunk lorsqu'il atteint cette taille. Ensuite, Fluentd envoie le chunk dans la file d'attente et ouvre un nouveau chunk.

8m

totalLimitSize

La taille maximale du tampon, qui est la taille totale de l'étape et de la file d'attente. Si la taille du tampon dépasse cette valeur, Fluentd arrête d'ajouter des données aux chunks et échoue avec une erreur. Toutes les données qui ne sont pas dans des chunks sont perdues.

8G

flushInterval

Intervalle entre les vidages de blocs. Vous pouvez utiliser s (secondes), m (minutes), h (heures) ou d (jours).

1s

flushMode

La méthode pour effectuer les rinçages :

  • lazy: Vider les chunks en fonction du paramètre timekey. Vous ne pouvez pas modifier le paramètre timekey.
  • interval: Purge des blocs en fonction du paramètre flushInterval.
  • immediate: Vider les blocs immédiatement après que des données ont été ajoutées à un bloc.

interval

flushThreadCount

Le nombre de threads qui effectuent la vidange des blocs. L'augmentation du nombre de threads améliore le débit de vidage, ce qui masque la latence du réseau.

2

overflowAction

Le comportement de découpage lorsque la file d'attente est pleine :

  • throw_exception: Lève une exception et l'affiche dans le journal.
  • block: Arrêter le découpage des données jusqu'à ce que le problème de la mémoire tampon complète soit résolu.
  • drop_oldest_chunk: Abandonner le morceau le plus ancien pour accepter les nouveaux morceaux entrants. Les morceaux plus anciens ont moins de valeur que les morceaux plus récents.

block

retryMaxInterval

Délai maximum en secondes pour la méthode de réessai exponential_backoff.

300s

retryType

La méthode de réessai en cas d'échec de la vidange :

  • exponential_backoff: Augmenter le temps entre les tentatives de rinçage. Fluentd double le temps d'attente avant la prochaine tentative jusqu'à ce que le paramètre retry_max_interval soit atteint.
  • periodic: Réitère les tentatives d'effacement périodiquement, en fonction du paramètre retryWait.

exponential_backoff

retryTimeOut

Intervalle de temps maximum entre les tentatives avant que l'enregistrement ne soit rejeté.

60m

retryWait

Temps en secondes avant le prochain vidage de la mémoire.

1s

Pour plus d'informations sur le cycle de vie des chunk de Fluentd, voir Buffer Plugins dans la documentation de Fluentd.

Procédure

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

    $ oc edit ClusterLogging instance

  2. Ajoutez ou modifiez l'un des paramètres suivants : 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  forwarder:
    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
...
    1
    Spécifiez la taille maximale de chaque bloc avant qu'il ne soit mis en file d'attente pour la vidange.
    2
    Spécifiez l'intervalle entre les vidanges de blocs.
    3
    Spécifiez la méthode pour effectuer les vidanges de blocs : lazy, interval, ou immediate.
    4
    Spécifier le nombre de threads à utiliser pour les vidanges de blocs.
    5
    Spécifiez le comportement de découpage lorsque la file d'attente est pleine : throw_exception, block, ou drop_oldest_chunk.
    6
    Spécifiez l'intervalle maximal en secondes pour la méthode de vidange des blocs exponential_backoff.
    7
    Spécifiez le type de réessai en cas d'échec de la vidange des blocs : exponential_backoff ou periodic.
    8
    Indiquer le délai en secondes avant le prochain vidage de morceaux.
    9
    Spécifier la taille maximale de la mémoire tampon.

  3. Vérifier que les pods Fluentd sont redéployés : 

    $ oc get pods -l component=collector -n openshift-logging

  4. Vérifiez que les nouvelles valeurs se trouvent dans la carte de configuration fluentd: 

    $ oc extract configmap/fluentd --confirm

    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 32m
 chunk_limit_size 8m
 overflow_action throw_exception
</buffer>

6.2.5. Suppression des composants inutilisés si vous n'utilisez pas le magasin de logs Elasticsearch par défaut

En tant qu'administrateur, dans le cas rare où vous transmettez les journaux à un magasin de journaux tiers et n'utilisez pas le magasin de journaux Elasticsearch par défaut, vous pouvez supprimer plusieurs composants inutilisés de votre cluster de journalisation.

En d'autres termes, si vous n'utilisez pas le magasin de logs Elasticsearch par défaut, vous pouvez supprimer les composants internes Elasticsearch logStore et Kibana visualization de la ressource personnalisée (CR) ClusterLogging. La suppression de ces composants est facultative mais permet d'économiser des ressources.

Conditions préalables

  • Vérifiez que votre redirecteur de logs n'envoie pas les données de logs au cluster Elasticsearch interne par défaut. Inspectez le fichier YAML ClusterLogForwarder CR que vous avez utilisé pour configurer le transfert de journaux. Vérifiez qu'il does not comporte un élément outputRefs qui spécifie default. Par exemple : 

    outputRefs:
- default
Avertissement

Supposons que la CR ClusterLogForwarder transmette les données de journal au cluster Elasticsearch interne et que vous supprimiez le composant logStore de la CR ClusterLogging. Dans ce cas, le cluster Elasticsearch interne ne sera pas présent pour stocker les données du journal. Cette absence peut entraîner une perte de données.

Procédure

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

    $ oc edit ClusterLogging instance
  2. S'ils sont présents, supprimez les strophes logStore et visualization du CR ClusterLogging.

  3. Conservez la strophe collection de la CR ClusterLogging. Le résultat devrait ressembler à l'exemple suivant : 

    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
  namespace: "openshift-logging"
spec:
  managementState: "Managed"
  collection:
    logs:
      type: "fluentd"
      fluentd: {}

  4. Vérifier que les pods collecteurs sont redéployés : 

    $ oc get pods -l component=collector -n openshift-logging

Ressources complémentaires