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.
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-loggingpour 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
Modifiez la ressource personnalisée (CR)
ClusterLoggingdans le projetopenshift-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.
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.
| Paramètres | Description | Défaut |
|---|---|---|
|
| 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. |
|
|
| 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. |
|
|
|
Intervalle entre les vidages de blocs. Vous pouvez utiliser |
|
|
| La méthode pour effectuer les rinçages :
|
|
|
| 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. |
|
|
| Le comportement de découpage lorsque la file d'attente est pleine :
|
|
|
|
Délai maximum en secondes pour la méthode de réessai |
|
|
| La méthode de réessai en cas d'échec de la vidange :
|
|
|
| Intervalle de temps maximum entre les tentatives avant que l'enregistrement ne soit rejeté. |
|
|
| Temps en secondes avant le prochain vidage de la mémoire. |
|
Pour plus d'informations sur le cycle de vie des chunk de Fluentd, voir Buffer Plugins dans la documentation de Fluentd.
Procédure
Modifiez la ressource personnalisée (CR)
ClusterLoggingdans le projetopenshift-logging:$ oc edit ClusterLogging instance
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, ouimmediate. - 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, oudrop_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_backoffouperiodic. - 8
- Indiquer le délai en secondes avant le prochain vidage de morceaux.
- 9
- Spécifier la taille maximale de la mémoire tampon.
Vérifier que les pods Fluentd sont redéployés :
$ oc get pods -l component=collector -n openshift-logging
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
ClusterLogForwarderCR que vous avez utilisé pour configurer le transfert de journaux. Vérifiez qu'il does not comporte un élémentoutputRefsqui spécifiedefault. Par exemple :outputRefs: - default
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
Modifiez la ressource personnalisée (CR)
ClusterLoggingdans le projetopenshift-logging:$ oc edit ClusterLogging instance
-
S'ils sont présents, supprimez les strophes
logStoreetvisualizationdu CRClusterLogging. Conservez la strophe
collectionde la CRClusterLogging. 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: {}Vérifier que les pods collecteurs sont redéployés :
$ oc get pods -l component=collector -n openshift-logging
Ressources complémentaires
