Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

L’exploitation forestière

Red Hat OpenShift Service on AWS 4

Enregistrement de l’installation, de l’utilisation et de la publication des notes sur Red Hat OpenShift Service sur AWS

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des instructions pour configurer OpenShift Logging dans Red Hat OpenShift Service sur AWS (ROSA).

Chapitre 1. Libération des notes
Copier lien

1.1. Journalisation 5,9
Copier lien

Note

La journalisation est fournie en tant que composant installable, avec un cycle de sortie distinct du noyau Red Hat OpenShift Service sur AWS. La politique sur le cycle de vie de la plate-forme de conteneur Red Hat OpenShift décrit la compatibilité des versions.

Note

Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

1.1.1. Journalisation 5.9.3
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.9.3

1.1.1.1. Correction des bugs
Copier lien
  • Avant cette mise à jour, il y avait un retard dans le redémarrage des Ingesters lors de la configuration de LokiStack, car l’opérateur Loki définit le journal d’écriture replay_memory_ceiling à zéro octets pour la taille 1x.demo. Avec cette mise à jour, la valeur minimale utilisée pour le replay_memory_ceiling a été augmentée afin d’éviter les retards. (LOG-5614)
  • Avant cette mise à jour, la surveillance de l’état tampon de sortie du collecteur vectoriel n’était pas possible. Avec cette mise à jour, la surveillance et l’alerte de la taille du tampon de sortie du collecteur de vecteurs sont possibles, ce qui améliore les capacités d’observabilité et aide à maintenir le fonctionnement optimal du système. (LOG-5586)
1.1.1.2. CVEs
Copier lien

1.1.2. Enregistrement de l’enregistrement 5.9.2
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.9.2

1.1.2.1. Correction des bugs
Copier lien
  • Avant cette mise à jour, les modifications apportées à l’opérateur de journalisation ont causé une erreur en raison d’une configuration incorrecte dans le ClusterLogForwarder CR. En conséquence, les mises à niveau vers la journalisation ont supprimé le collecteur daemonset. Avec cette mise à jour, l’opérateur de journalisation recrée des démons de collecte, sauf lorsqu’une erreur non autorisée à collecter se produit. (LOG-4910)
  • Avant cette mise à jour, les fichiers journaux d’infrastructure rotatifs étaient envoyés à l’index de l’application dans certains scénarios en raison d’une configuration incorrecte dans le collecteur de journaux de vecteurs. Avec cette mise à jour, la configuration du collecteur de journal Vector évite de collecter des fichiers journaux d’infrastructure rotatifs. (LOG-5156)
  • Avant cette mise à jour, l’opérateur de journalisation n’a pas surveillé les modifications apportées à la carte de configuration grafana-dashboard-cluster-logging. Avec cette mise à jour, l’opérateur de journalisation surveille les changements dans les objets ConfigMap, s’assurant que le système reste synchronisé et répond efficacement à la configuration des modifications de la carte. (LOG-5308)
  • Avant cette mise à jour, un problème dans le code de collecte des métriques de l’opérateur de journalisation l’a amené à signaler des métriques de télémétrie périmées. Avec cette mise à jour, l’opérateur de journalisation ne signale pas les métriques de télémétrie périmées. (LOG-5426)
  • Avant ce changement, le plugin Fluentd out_http ignorait la variable d’environnement no_proxy. Avec cette mise à jour, Fluentd corrige la méthode HTTP#start de ruby pour honorer la variable d’environnement no_proxy. (LOG-5466)
1.1.2.2. CVEs
Copier lien

1.1.3. Journalisation 5.9.1
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.9.1

1.1.3.1. Améliorations
Copier lien
  • Avant cette mise à jour, l’opérateur Loki a configuré Loki pour utiliser l’accès de style basé sur le chemin pour le service de stockage simple Amazon (S3), qui a été obsolète. Avec cette mise à jour, l’opérateur Loki par défaut au style hôte virtuel sans que les utilisateurs aient besoin de modifier leur configuration. (LOG-5401)
  • Avant cette mise à jour, l’opérateur Loki n’a pas validé le point de terminaison Amazon Simple Storage Service (S3) utilisé dans le secret de stockage. Avec cette mise à jour, le processus de validation garantit que le point d’extrémité S3 est une URL S3 valide, et les mises à jour de statut LokiStack pour indiquer toute URL invalide. (LOG-5395)
1.1.3.2. Correction des bugs
Copier lien
  • Avant cette mise à jour, un bug dans l’analyse LogQL a laissé de côté certains filtres de ligne de la requête. Avec cette mise à jour, l’analyse inclut maintenant tous les filtres de ligne tout en gardant la requête originale inchangée. (LOG-5268)
  • Avant cette mise à jour, un filtre de prunes sans pruneFilterSpec défini provoquerait un segfault. Avec cette mise à jour, il y a une erreur de validation si un filtre de taille n’est pas défini puneFilterSpec. (LOG-5322)
  • Avant cette mise à jour, un filtre de goutte sans dropTestsSpec défini entraînerait un ségfault. Avec cette mise à jour, il y a une erreur de validation si un filtre de taille n’est pas défini puneFilterSpec. (LOG-5323)
  • Avant cette mise à jour, l’opérateur Loki n’a pas validé le format d’URL du point de terminaison Amazon Simple Storage Service (S3) utilisé dans le secret de stockage. Avec cette mise à jour, l’URL du point de terminaison S3 passe par une étape de validation qui reflète l’état du LokiStack. (LOG-5397)
  • Avant cette mise à jour, les champs d’horodatage mal formatés dans les enregistrements de journaux d’audit ont conduit à des messages WARN dans les journaux Red Hat OpenShift Logging Operator. Avec cette mise à jour, une transformation de remap garantit que le champ horodatage est correctement formaté. (LOG-4672)
  • Avant cette mise à jour, le message d’erreur lancé lors de la validation d’un nom de ressource ClusterLogForwarder et de l’espace de noms ne correspondait pas à l’erreur correcte. Avec cette mise à jour, le système vérifie si une ressource ClusterLogForwarder avec le même nom existe dans le même espace de noms. Dans le cas contraire, cela correspond à l’erreur correcte. (LOG-5062)
  • Avant cette mise à jour, la fonction de validation de la configuration de sortie nécessitait une URL TLS, même pour des services tels qu’Amazon CloudWatch ou Google Cloud Logging où une URL n’est pas nécessaire par conception. Avec cette mise à jour, la logique de validation des services sans URL est améliorée et le message d’erreur est plus informatif. (LOG-5307)
  • Avant cette mise à jour, la définition d’un type d’entrée d’infrastructure n’excluait pas l’enregistrement des charges de travail de la collection. Avec cette mise à jour, la collection exclut les services d’enregistrement pour éviter les boucles de rétroaction. (LOG-5309)
1.1.3.3. CVEs
Copier lien

Il n’y a pas de VEC.

1.1.4. Journalisation 5.9.0
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.9.0

1.1.4.1. Avis de renvoi
Copier lien

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Les instances d’OpenShift Elasticsearch Operator à partir des versions antérieures de journalisation, restent prises en charge jusqu’à ce que l’EOL de la libération de journalisation. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

1.1.4.2. Avis de déprécation
Copier lien
  • Dans Logging 5.9, Fluentd et Kibana sont obsolètes et devraient être supprimés dans Logging 6.0, qui devrait être expédié en même temps qu’une future version de Red Hat OpenShift Service sur AWS. Le Red Hat fournira des corrections de bogues critiques et supérieures à CVE et une prise en charge de ces composants pendant le cycle de vie de la version actuelle, mais ces composants ne recevront plus d’améliorations de fonctionnalités. Le collecteur Vector fourni par l’opérateur de journalisation OpenShift Red Hat et LokiStack fourni par l’opérateur Loki sont les opérateurs préférés pour la collecte et le stockage des journaux. « nous encourageons tous les utilisateurs à adopter la pile de journal Vector et Loki, car ce sera la pile qui sera améliorée à l’avenir. »
  • Dans Logging 5.9, l’option Champs pour le type de sortie Splunk n’a jamais été implémentée et est maintenant obsolète. Il sera supprimé dans une future version.
1.1.4.3. Améliorations
Copier lien
1.1.4.3.1. Collection de journaux
Copier lien
  • Cette amélioration ajoute la possibilité d’affiner le processus de collecte de journaux en utilisant les métadonnées d’une charge de travail pour supprimer ou tailler les journaux en fonction de leur contenu. En outre, il permet à la collecte de journaux d’infrastructure, tels que les journaux de journal ou de conteneurs, et les journaux d’audit, tels que les journaux kube api ou ovn, de collecter uniquement des sources individuelles. (LOG-2155)
  • Cette amélioration introduit un nouveau type de récepteur de journal à distance, le récepteur syslog. Il peut être configuré pour exposer un port sur un réseau, permettant aux systèmes externes d’envoyer des journaux syslog à l’aide d’outils compatibles tels que rsyslog. (LOG-3527)
  • Avec cette mise à jour, l’API ClusterLogForwarder prend désormais en charge le transfert de journaux vers Azure Monitor Logs, offrant aux utilisateurs de meilleures capacités de surveillance. Cette fonctionnalité aide les utilisateurs à maintenir des performances optimales du système et à rationaliser les processus d’analyse de log dans Azure Monitor, ce qui accélère la résolution des problèmes et améliore l’efficacité opérationnelle. (LOG-4605)
  • Cette amélioration améliore l’utilisation des ressources du collecteur en déployant des collecteurs en tant que déploiement avec deux répliques. Cela se produit lorsque la seule source d’entrée définie dans la ressource personnalisée ClusterLogForwarder (CR) est une entrée de récepteur au lieu d’utiliser un démon défini sur tous les nœuds. De plus, les collecteurs déployés de cette manière ne montent pas le système de fichiers hôte. Afin d’utiliser cette amélioration, vous devez annoter le ClusterLogForwarder CR avec l’annotation logging.openshift.io/dev-preview-enable-collector-as-deployment. (LOG-4779)
  • Cette amélioration introduit la capacité de configuration personnalisée des locataires dans tous les extrants pris en charge, facilitant l’organisation des enregistrements de log de manière logique. Cependant, il n’autorise pas la configuration personnalisée des locataires pour enregistrer le stockage géré. (LOG-4843)
  • Avec cette mise à jour, le ClusterLogForwarder CR qui spécifie une entrée d’application avec un ou plusieurs espaces de noms d’infrastructure comme par défaut, openshift* ou kube*, nécessite maintenant un compte de service avec le rôle collect-infrastructure-logs. (LOG-4943)
  • Cette amélioration introduit la capacité de réglage de certains paramètres de sortie, tels que la compression, la durée de réessayer et les charges utiles maximales, pour correspondre aux caractéristiques du récepteur. En outre, cette fonctionnalité comprend un mode de livraison pour permettre aux administrateurs de choisir entre le débit et la durabilité du journal. À titre d’exemple, l’option AtLeastOnce configure un tampon de disque minimal des journaux collectés afin que le collecteur puisse livrer ces journaux après un redémarrage. (LOG-5026)
  • Cette amélioration ajoute trois nouvelles alertes Prometheus, avertissant les utilisateurs de la déprécation d’Elasticsearch, Fluentd et Kibana. (LOG-5055)
1.1.4.3.2. Journal de stockage
Copier lien
  • Cette amélioration de LokiStack améliore la prise en charge d’OTEL en utilisant le nouveau format de stockage d’objets V13 et en permettant un sharding automatique de flux par défaut. Cela prépare également le collecteur pour les améliorations et configurations futures. (LOG-4538)
  • Cette amélioration introduit la prise en charge de la fédération d’identité de jetons de courte durée avec Azure et AWS log stores pour STS activé Red Hat OpenShift Service sur AWS 4.14 et les clusters ultérieurs. Le stockage local nécessite l’ajout d’un CredentialMode: annotation statique sous spec.storage.secret dans le LokiStack CR. (LOG-4540)
  • Avec cette mise à jour, la validation du secret de stockage Azure est maintenant étendue pour donner un avertissement précoce pour certaines conditions d’erreur. (LOG-4571)
  • Avec cette mise à jour, Loki ajoute maintenant la prise en charge en amont et en aval du mécanisme de fédération d’identité de la charge de travail GCP. Cela permet l’accès authentifié et autorisé aux services de stockage d’objet correspondants. (LOG-4754)
1.1.4.4. Correction des bugs
Copier lien
  • Avant cette mise à jour, le journal must-collectther ne pouvait pas collecter de journaux sur un cluster compatible FIPS. Avec cette mise à jour, un nouveau client oc est disponible dans cluster-logging-rhel9-operator, et must-collectther fonctionne correctement sur les clusters FIPS. (LOG-4403)
  • Avant cette mise à jour, les pods de règle LokiStack ne pouvaient pas formater l’IPv6 pod dans les URL HTTP utilisées pour la communication cross-pod. Ce problème a causé l’échec des règles d’interrogation et des alertes via l’API compatible Prometheus. Avec cette mise à jour, les pods de règle LokiStack encapsulent l’IPv6 pod entre crochets, résolvant le problème. Désormais, l’interrogation des règles et des alertes via l’API compatible Prometheus fonctionne comme dans les environnements IPv4. (LOG-4709)
  • Avant ce correctif, le contenu YAML du journal must-collectther a été exporté en une seule ligne, ce qui le rend illisible. Avec cette mise à jour, les espaces blancs YAML sont préservés, assurant que le fichier est correctement formaté. (LOG-4792)
  • Avant cette mise à jour, lorsque le ClusterLogForwarder CR a été activé, le Red Hat OpenShift Logging Operator pouvait tomber dans une exception de pointeur nul lorsque ClusterLogging.Spec.Collection était nul. Avec cette mise à jour, le problème est maintenant résolu dans Red Hat OpenShift Logging Operator. (LOG-5006)
  • Avant cette mise à jour, dans des cas spécifiques de coin, le remplacement du champ d’état ClusterLogForwarder CR a amené la resourceVersion à mettre à jour constamment en raison de changements d’horodatage dans les conditions d’état. Cette condition a conduit à une boucle de réconciliation infinie. Avec cette mise à jour, toutes les conditions d’état se synchronisent, de sorte que les horodatages restent inchangés si les conditions restent les mêmes. (LOG-5007)
  • Avant cette mise à jour, il y avait un comportement de tampon interne à drop_newest pour répondre à la consommation de mémoire élevée par le collecteur entraînant une perte de log significative. Avec cette mise à jour, le comportement revient à l’utilisation du collecteur par défaut. (LOG-5123)
  • Avant cette mise à jour, le Loki Operator ServiceMonitor dans l’espace de noms openshift-operators-redhat utilisait des fichiers de jetons statiques et de CA pour l’authentification, causant des erreurs dans l’opérateur Prometheus dans la spécification de surveillance de la charge de travail de l’utilisateur sur la configuration ServiceMonitor. Avec cette mise à jour, le Loki Operator ServiceMonitor dans openshift-operators-redhat namespace référence maintenant un jeton de service secret par un objet LocalReference. Cette approche permet à la spécification de surveillance de la charge de travail de l’opérateur Prometheus de gérer avec succès le Loki Operator ServiceMonitor, permettant à Prometheus de gratter les métriques Loki Operator. (LOG-5165)
  • Avant cette mise à jour, la configuration du Loki Operator ServiceMonitor pourrait correspondre à de nombreux services Kubernetes, ce qui signifie que les métriques Loki Operator sont collectées plusieurs fois. Avec cette mise à jour, la configuration de ServiceMonitor correspond désormais uniquement au service métrique dédié. (LOG-5212)
1.1.4.5. Les problèmes connus
Copier lien

Aucun.

1.1.4.6. CVEs
Copier lien

1.2. Enregistrement 5.8
Copier lien

Note

La journalisation est fournie en tant que composant installable, avec un cycle de sortie distinct du noyau Red Hat OpenShift Service sur AWS. La politique sur le cycle de vie de la plate-forme de conteneur Red Hat OpenShift décrit la compatibilité des versions.

Note

Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

1.2.1. Enregistrement 5.8.4
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.8.4.

1.2.1.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, les journaux de la console développeur ne comptaient pas pour l’espace de noms actuel, ce qui a entraîné le rejet de requêtes pour les utilisateurs sans accès au journal à l’échelle du cluster. Avec cette mise à jour, toutes les versions OCP prises en charge assurent l’inclusion correcte de l’espace de noms. (LOG-4905)
  • Avant cette mise à jour, l’opérateur de journalisation du cluster a déployé ClusterRoles prenant en charge les déploiements LokiStack uniquement lorsque la sortie de journal par défaut était LokiStack. Avec cette mise à jour, les rôles sont divisés en deux groupes: lire et écrire. Les rôles d’écriture se déploient en fonction du réglage du stockage journal par défaut, tout comme tous les rôles utilisés auparavant. Les rôles de lecture se déploient selon que le plugin de la console de journalisation est actif. (LOG-4987)
  • Avant cette mise à jour, plusieurs ClusterLogForwarders définissant le même nom de récepteur d’entrée avaient leur service sans cesse réconcilié en raison de l’évolution des références du propriétaire sur un seul service. Avec cette mise à jour, chaque entrée de récepteur aura son propre service nommé avec la convention <CLF.Name>-<input.Name>. (LOG-5009)
  • Avant cette mise à jour, le ClusterLogForwarder n’a pas signalé d’erreurs lors de la transmission de journaux à cloudwatch sans secret. Avec cette mise à jour, le message d’erreur suivant apparaît lors du transfert de journaux vers Cloudwatch sans secret : le secret doit être fourni pour la sortie cloudwatch. (LOG-5021)
  • Avant cette mise à jour, log_forwarder_input_info comprenait des points métriques d’entrée d’application, d’infrastructure et d’audit. Avec cette mise à jour, http est également ajouté en tant que point métrique. (LOG-5043)
1.2.1.2. CVEs
Copier lien

1.2.2. Enregistrement 5.8.3
Copier lien

Cette version inclut Logging Bug Fix 5.8.3 et Logging Security Fix 5.8.3

1.2.2.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, lorsqu’il est configuré pour lire une autorité de certification S3 personnalisée, l’opérateur Loki n’a pas mis à jour automatiquement la configuration lorsque le nom du ConfigMap ou le contenu a changé. Avec cette mise à jour, l’opérateur Loki surveille les modifications apportées au ConfigMap et met automatiquement à jour la configuration générée. (LOG-4969)
  • Avant cette mise à jour, les sorties Loki configurées sans URL valide ont causé le crash des pods collector. Avec cette mise à jour, les sorties sont soumises à la validation de l’URL, ce qui résout le problème. (LOG-4822)
  • Avant cette mise à jour, l’opérateur de journalisation du cluster générerait des champs de configuration de collector pour les sorties qui ne spécifiaient pas un secret pour utiliser le jeton porteur de compte de service. Avec cette mise à jour, une sortie ne nécessite pas d’authentification, résolvant le problème. (LOG-4962)
  • Avant cette mise à jour, le champ tls.insecureSkipVerify d’une sortie n’était pas défini à une valeur de true sans un secret défini. Avec cette mise à jour, un secret n’est plus nécessaire pour définir cette valeur. (LOG-4963)
  • Avant cette mise à jour, les configurations de sortie autorisaient la combinaison d’une URL non sécurisée (HTTP) avec l’authentification TLS. Avec cette mise à jour, les sorties configurées pour l’authentification TLS nécessitent une URL sécurisée (HTTPS). (LOG-4893)
1.2.2.2. CVEs
Copier lien

1.2.3. Journalisation 5.8.2
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.8.2.

1.2.3.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, les pods de règle LokiStack ne formataient pas l’IPv6 pod dans les URL HTTP utilisées pour la communication de pod croisés, provoquant l’échec des règles d’interrogation et des alertes via l’API compatible Prometheus. Avec cette mise à jour, les pods de règle LokiStack encapsulent l’IPv6 pod entre crochets, résolvant le problème. (LOG-4890)
  • Avant cette mise à jour, les journaux des consoles de développeurs ne comptaient pas pour l’espace de noms actuel, ce qui a entraîné le rejet de requêtes pour les utilisateurs sans accès au journal à l’échelle du cluster. Avec cette mise à jour, l’inclusion de l’espace de noms a été corrigée, résolvant le problème. (LOG-4947)
  • Avant cette mise à jour, le plugin de la vue de journalisation du Red Hat OpenShift Service sur la console web AWS ne permettait pas le placement et les tolérances de nœuds personnalisés. Avec cette mise à jour, la définition de placements et de tolérances de nœuds personnalisés a été ajoutée au plugin de visualisation de journalisation du Red Hat OpenShift Service sur la console web AWS. (LOG-4912)
1.2.3.2. CVEs
Copier lien

1.2.4. Journalisation 5.8.1
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.8.1 et OpenShift Logging Bug Fix Release 5.8.1 Kibana.

1.2.4.1. Améliorations
Copier lien
1.2.4.1.1. Collection de journaux
Copier lien
  • Avec cette mise à jour, tout en configurant Vector en tant que collectionneur, vous pouvez ajouter une logique au Red Hat OpenShift Logging Operator pour utiliser un jeton spécifié dans le secret à la place du jeton associé au compte de service. (LOG-4780)
  • Avec cette mise à jour, les tableaux de bord BoltDB Shipper Loki sont maintenant renommés en tableaux de bord Index. (LOG-4828)
1.2.4.2. Corrections de bogues
Copier lien
  • Avant cette mise à jour, le ClusterLogForwarder a créé des indices vides après avoir activé l’analyse des logs JSON, même lorsque les conditions de roulement n’étaient pas remplies. Avec cette mise à jour, le ClusterLogForwarder saute le rollover lorsque l’index d’écriture est vide. (LOG-4452)
  • Avant cette mise à jour, le vecteur définit le niveau de journal par défaut de manière incorrecte. Avec cette mise à jour, le niveau de journal correct est défini en améliorant l’amélioration de l’expression régulière, ou regexp, pour la détection de niveau de journal. (LOG-4480)
  • Avant cette mise à jour, pendant le processus de création de modèles d’index, l’alias par défaut était absent de l’index initial dans chaque sortie de journal. En conséquence, les utilisateurs de Kibana n’ont pas été en mesure de créer des modèles d’index en utilisant OpenShift Elasticsearch Operator. Cette mise à jour ajoute les alias manquants à OpenShift Elasticsearch Operator, résolvant le problème. Les utilisateurs de Kibana peuvent maintenant créer des modèles d’index qui incluent les index {app, infra, audit}-000001. (LOG-4683)
  • Avant cette mise à jour, les pods de collector Fluentd étaient dans un état CrashLoopBackOff en raison de la liaison du serveur Prometheus sur les clusters IPv6. Avec cette mise à jour, les collecteurs fonctionnent correctement sur les clusters IPv6. (LOG-4706)
  • Avant cette mise à jour, le Red Hat OpenShift Logging Operator subirait de nombreux rapprochements chaque fois qu’il y avait un changement dans le ClusterLogForwarder. Avec cette mise à jour, le Red Hat OpenShift Logging Operator ignore les changements de statut dans les démons de collecte qui ont déclenché les rapprochements. (LOG-4741)
  • Avant cette mise à jour, les pods de collecteur de log Vector étaient coincés dans l’état CrashLoopBackOff sur les machines IBM Power. Avec cette mise à jour, les pods de collecteurs de journaux Vector démarrent avec succès sur les machines d’architecture IBM Power. (LOG-4768)
  • Avant cette mise à jour, l’envoi avec un expéditeur existant vers un LokiStack interne produisait des erreurs de certificat SSL à l’aide de pods de collecte Fluentd. Avec cette mise à jour, le compte de service collecteur de journaux est utilisé par défaut pour l’authentification, en utilisant le jeton associé et ca.crt. (LOG-4791)
  • Avant cette mise à jour, l’envoi avec un expéditeur existant vers un LokiStack interne produisait des erreurs de certificat SSL à l’aide de pods de collecteur Vector. Avec cette mise à jour, le compte de service collecteur de journaux est utilisé par défaut pour l’authentification et également en utilisant le jeton associé et ca.crt. (LOG-4852)
  • Avant cette correction, les adresses IPv6 ne seraient pas analysées correctement après avoir évalué un hôte ou plusieurs hôtes pour les espaces réservés. Avec cette mise à jour, les adresses IPv6 sont correctement analysées. (LOG-4811)
  • Avant cette mise à jour, il était nécessaire de créer un ClusterRoleBinding pour collecter les autorisations d’audit pour les entrées de récepteur HTTP. Avec cette mise à jour, il n’est pas nécessaire de créer le ClusterRoleBinding car le point de terminaison dépend déjà de l’autorité de certification du cluster. (LOG-4815)
  • Avant cette mise à jour, l’opérateur Loki n’a pas monté un paquet CA personnalisé aux pods de règle. En conséquence, pendant le processus d’évaluation des règles d’alerte ou d’enregistrement, l’accès au stockage d’objet a échoué. Avec cette mise à jour, l’opérateur Loki monte le paquet CA personnalisé à tous les pods de règle. Les pods de règle peuvent télécharger des journaux de stockage d’objets pour évaluer les règles d’alerte ou d’enregistrement. (LOG-4836)
  • Avant cette mise à jour, tout en supprimant la section input.receiver du ClusterLogForwarder, les services d’entrée HTTP et ses secrets associés n’ont pas été supprimés. Avec cette mise à jour, les ressources d’entrée HTTP sont supprimées lorsqu’elles ne sont pas nécessaires. (LOG-4612)
  • Avant cette mise à jour, le ClusterLogForwarder indiquait des erreurs de validation dans l’état, mais les extrants et l’état du pipeline ne reflétaient pas exactement les problèmes spécifiques. Avec cette mise à jour, l’état du pipeline affiche correctement les raisons d’échec de validation en cas de sorties mal configurées, d’entrées ou de filtres. (LOG-4821)
  • Avant cette mise à jour, la modification d’une requête LogQL qui a utilisé des contrôles tels que la plage de temps ou la gravité a changé l’opérateur de matcheur d’étiquettes la définissant comme une expression régulière. Avec cette mise à jour, les opérateurs d’expression réguliers restent inchangés lors de la mise à jour de la requête. (LOG-4841)
1.2.4.3. CVEs
Copier lien

1.2.5. Journalisation 5.8.0
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.8.0 et OpenShift Logging Bug Fix Release 5.8.0 Kibana.

1.2.5.1. Avis de déprécation
Copier lien

Dans Logging 5.8, Elasticsearch, Fluentd et Kibana sont dépréciés et devraient être supprimés dans Logging 6.0, qui devrait être expédié en même temps qu’une future version de Red Hat OpenShift Service sur AWS. Le Red Hat fournira des corrections de bogues critiques et supérieures à CVE et une prise en charge de ces composants pendant le cycle de vie de la version actuelle, mais ces composants ne recevront plus d’améliorations de fonctionnalités. Le collecteur Vector fourni par l’opérateur de journalisation OpenShift Red Hat et LokiStack fourni par l’opérateur Loki sont les opérateurs préférés pour la collecte et le stockage des journaux. « nous encourageons tous les utilisateurs à adopter la pile de journal Vector et Loki, car ce sera la pile qui sera améliorée à l’avenir. »

1.2.5.2. Améliorations
Copier lien
1.2.5.2.1. Collection de journaux
Copier lien
  • Avec cette mise à jour, 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. (LOG-3819)

  • Avec cette mise à jour, vous pouvez déployer plusieurs instances ClusterLogForwarder (CR) personnalisées, isolées et protégées par RBAC dans n’importe quel espace de noms. Cela permet aux groupes indépendants d’envoyer les journaux souhaités vers n’importe quelle destination tout en isolant leur configuration à partir d’autres déploiements de collecteurs. (LOG-1343)

    Important

    Afin de prendre en charge le transfert de journaux multi-cluster 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.

  • Avec cette mise à jour, vous pouvez utiliser le mécanisme de contrôle de débit ou de limitation de débit pour limiter le volume des données de log qui peuvent être collectées ou transmises en abandonnant les enregistrements de journal excédentaires. Les limites d’entrée empêchent les conteneurs mal performants de surcharger l’enregistrement et les limites de sortie imposent un plafond au taux des logs expédiés dans un magasin de données donné. (LOG-884)
  • Avec cette mise à jour, vous pouvez configurer le collecteur de journaux pour rechercher des connexions HTTP et recevoir des journaux en tant que serveur HTTP, également connu sous le nom de webhook. (LOG-4562)
  • Avec cette mise à jour, vous pouvez configurer des stratégies d’audit pour contrôler quels événements Kubernetes et OpenShift API sont transférés par le collecteur de journaux. (LOG-3982)
1.2.5.2.2. Journal de stockage
Copier lien
  • Avec cette mise à jour, les administrateurs LokiStack peuvent avoir un contrôle plus précis sur qui peut accéder aux journaux en accordant l’accès aux journaux sur la base de l’espace de noms. (LOG-3841)
  • Avec cette mise à jour, l’opérateur Loki introduit la configuration PodDisruptionBudget sur les déploiements LokiStack pour assurer des opérations normales pendant le service OpenShift Red Hat sur le redémarrage du cluster AWS en gardant l’ingestion et le chemin de requête disponibles. (LOG-3839)
  • Avec cette mise à jour, la fiabilité des installations LokiStack existantes est améliorée de manière transparente grâce à l’application d’un ensemble de politiques d’affinité et d’anti-Affinité par défaut. (LOG-3840)
  • Avec cette mise à jour, vous pouvez gérer la réplication de données conscientes de la zone en tant qu’administrateur dans LokiStack, afin d’améliorer la fiabilité en cas de défaillance de la zone. (LOG-3266)
  • Avec cette mise à jour, une nouvelle petite taille de LokiStack prise en charge de 1x.extra-petit est introduite pour Red Hat OpenShift Service sur les clusters AWS hébergeant quelques charges de travail et des volumes d’ingestion plus petits (jusqu’à 100 Go / jour). (LOG-4329)
  • Avec cette mise à jour, l’administrateur LokiStack a accès à un tableau de bord officiel Loki pour inspecter les performances de stockage et la santé de chaque composant. (LOG-4327)
1.2.5.2.3. Console de journal
Copier lien
  • Avec cette mise à jour, vous pouvez activer le plugin de la console d’enregistrement lorsque Elasticsearch est le Log Store par défaut. (LOG-3856)
  • Avec cette mise à jour, Red Hat OpenShift Service sur AWS les propriétaires d’applications peuvent recevoir des notifications pour les alertes basées sur le journal d’application sur le Red Hat OpenShift Service sur la console web AWS perspective Développeur pour Red Hat OpenShift Service sur AWS version 4.14 et ultérieure. (LOG-3548)
1.2.5.3. Les problèmes connus
Copier lien

  • Actuellement, le transfert de journal Splunk pourrait ne pas fonctionner après la mise à niveau vers la version 5.8 du Red Hat OpenShift Logging Operator. Ce problème est causé par la transition d’OpenSSL version 1.1.1 à la version 3.0.7. Dans la nouvelle version OpenSSL, il y a un changement de comportement par défaut, où les connexions aux points de terminaison TLS 1.2 sont rejetées s’ils n’exposent pas l’extension RFC 5746.

    Comme solution de contournement, activez la prise en charge de TLS 1.3 sur l’équilibreur de charge terminant TLS devant le point d’extrémité Splunk HEC (HTTP Event Collector). Le Splunk est un système tiers qui doit être configuré à partir de l’extrémité Splunk.

  • Actuellement, il y a une faille dans la gestion des flux multiplexés dans le protocole HTTP/2, où vous pouvez à plusieurs reprises faire une demande pour un nouveau flux multiplex et envoyer immédiatement une image RST_STREAM pour l’annuler. Cela a créé un travail supplémentaire pour le serveur configuré et déchiré les flux, ce qui a entraîné un déni de service en raison de la consommation de ressources du serveur. Il n’y a actuellement aucune solution de contournement pour ce problème. (LOG-4609)
  • Actuellement, lorsque vous utilisez FluentD comme collecteur, le pod de collecteur ne peut pas démarrer sur le Red Hat OpenShift Service sur AWS IPv6-enabled cluster. Les logs de pod produisent le pod fluentd [erreur]: erreur inattendue erreur_class=SocketError error="getaddrinfo: Nom ou service non connu erreur. Il n’y a actuellement aucune solution de contournement pour ce problème. (LOG-4706)
  • Actuellement, l’alerte de journal n’est pas disponible sur un cluster compatible IPv6. Il n’y a actuellement aucune solution de contournement pour ce problème. (LOG-4709)
  • Actuellement, must-collectther ne peut pas recueillir de journaux sur un cluster compatible FIPS, car la bibliothèque OpenSSL requise n’est pas disponible dans l’opérateur cluster-logging-rhel9-. Il n’y a actuellement aucune solution de contournement pour ce problème. (LOG-4403)
  • Actuellement, lors du déploiement de la version de journalisation 5.8 sur un cluster compatible FIPS, les pods collector ne peuvent pas démarrer et sont bloqués dans le statut CrashLoopBackOff, tout en utilisant FluentD comme collecteur. Il n’y a actuellement aucune solution de contournement pour ce problème. (LOG-3933)
1.2.5.4. CVEs
Copier lien

1.3. Enregistrement 5.7
Copier lien

Note

La journalisation est fournie en tant que composant installable, avec un cycle de sortie distinct du noyau Red Hat OpenShift Service sur AWS. La politique sur le cycle de vie de la plate-forme de conteneur Red Hat OpenShift décrit la compatibilité des versions.

Note

Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

1.3.1. Enregistrement 5.7.8
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.8.

1.3.1.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, il y avait un conflit potentiel lorsque le même nom a été utilisé pour les paramètres de sortieRefs et inputRefs dans la ressource personnalisée ClusterLogForwarder (CR). En conséquence, les pods de collecteur sont entrés dans un statut CrashLoopBackOff. Avec cette mise à jour, les étiquettes de sortie contiennent le préfixe OUTPUT_ pour assurer une distinction entre les étiquettes de sortie et les noms de pipelines. (LOG-4383)
  • Avant cette mise à jour, lors de la configuration de l’analyseur de journal JSON, si vous n’avez pas défini les paramètres StructureTypeKey ou StructureTypeName pour l’opérateur de journalisation du cluster, aucune alerte n’afficherait une configuration invalide. Avec cette mise à jour, l’opérateur de journalisation du cluster vous informe sur le problème de configuration. (LOG-4441)
  • Avant cette mise à jour, si la clé hecToken était manquante ou incorrecte dans le secret spécifié pour une sortie Splunk, la validation a échoué parce que le vecteur a transmis des journaux à Splunk sans jeton. Avec cette mise à jour, si la clé hecToken est manquante ou incorrecte, la validation échoue avec l’entrée hecToken non vide est requise message d’erreur. (LOG-4580)
  • Avant cette mise à jour, la sélection d’une date dans la plage de temps personnalisée pour les journaux a causé une erreur dans la console Web. Avec cette mise à jour, vous pouvez sélectionner une date à partir du modèle de plage de temps dans la console Web avec succès. (LOG-4684)
1.3.1.2. CVEs
Copier lien

1.3.2. Enregistrement 5.7.7
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.7.

1.3.2.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, FluentD normalisait les logs émis par le EventRouter différemment de Vector. Avec cette mise à jour, le vecteur produit des enregistrements de log dans un format cohérent. (LOG-4178)
  • Avant cette mise à jour, il y avait une erreur dans la requête utilisée pour le graphique FluentD Buffer Disponibilité dans le tableau de bord des métriques créé par l’opérateur de journalisation du cluster car il montrait l’utilisation minimale du tampon. Avec cette mise à jour, le graphique montre l’utilisation maximale du tampon et est maintenant rebaptisé FluentD Buffer Usage. (LOG-4555)
  • Avant cette mise à jour, le déploiement d’un LokiStack sur IPv6 uniquement ou à double pile Red Hat OpenShift Service sur les clusters AWS a causé l’échec de l’enregistrement de la liste des membres LokiStack. En conséquence, les gousses de distributeur sont entrées dans une boucle d’accident. Avec cette mise à jour, un administrateur peut activer IPv6 en définissant la valeur lokistack.spec.hashRing.memberlist.enableIPv6: valeur true, qui résout le problème. (LOG-4569)
  • Avant cette mise à jour, le collecteur de journaux s’appuyait sur les paramètres de configuration par défaut pour lire les lignes de journal des conteneurs. En conséquence, le collecteur de journaux n’a pas lu efficacement les fichiers tournants. Avec cette mise à jour, il y a une augmentation du nombre d’octets lus, ce qui permet au collecteur de journaux de traiter efficacement les fichiers tournants. (LOG-4575)
  • Avant cette mise à jour, les métriques inutilisées dans le routeur d’événement ont causé l’échec du conteneur en raison d’une utilisation excessive de la mémoire. Avec cette mise à jour, il y a une réduction de l’utilisation de la mémoire du routeur d’événement en supprimant les métriques inutilisées. (LOG-4686)
1.3.2.2. CVEs
Copier lien

1.3.3. Enregistrement 5.7.6
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.6.

1.3.3.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, le collecteur s’appuyait sur les paramètres de configuration par défaut pour lire les lignes de journal des conteneurs. En conséquence, le collecteur n’a pas lu efficacement les fichiers tournants. Avec cette mise à jour, il y a une augmentation du nombre d’octets lus, ce qui permet au collecteur de traiter efficacement les fichiers tournants. (LOG-4501)
  • Avant cette mise à jour, lorsque les utilisateurs collaient une URL avec des filtres prédéfinis, certains filtres ne se réfléchissaient pas. Avec cette mise à jour, l’interface utilisateur reflète tous les filtres de l’URL. (LOG-4459)
  • Avant cette mise à jour, le transfert vers Loki à l’aide d’étiquettes personnalisées a généré une erreur lors du passage de Fluentd à Vector. Avec cette mise à jour, la configuration Vector désinfecte les étiquettes de la même manière que Fluentd pour s’assurer que le collecteur démarre et traite correctement les étiquettes. (LOG-4460)
  • Avant cette mise à jour, le champ de recherche de la console Observability Logs n’acceptait pas les caractères spéciaux qu’il devrait échapper. Avec cette mise à jour, il s’échappe correctement des caractères spéciaux dans la requête. (LOG-4456)
  • Avant cette mise à jour, le message d’avertissement suivant est apparu lors de l’envoi de journaux à Splunk: Timestamp n’a pas été trouvé. Avec cette mise à jour, le changement remplace le nom du champ de journal utilisé pour récupérer le Timestamp et l’envoie à Splunk sans avertissement. (LOG-4413)
  • Avant cette mise à jour, l’utilisation du CPU et de la mémoire de Vector augmentait au fil du temps. Avec cette mise à jour, la configuration Vector contient maintenant le paramètre expire_metrics_secs=60 pour limiter la durée de vie des métriques et plafonner l’utilisation du CPU et l’empreinte mémoire associées. (LOG-4171)
  • Avant cette mise à jour, la passerelle LokiStack en cache très largement les demandes autorisées. En conséquence, cela a causé de mauvais résultats d’autorisation. Avec cette mise à jour, la passerelle LokiStack met en cache sur une base plus fine qui résout ce problème. (LOG-4393)
  • Avant cette mise à jour, l’image d’exécution Fluentd comprenait des outils de constructeur qui n’étaient pas nécessaires à l’exécution. Avec cette mise à jour, les outils de constructeur sont supprimés, résolvant le problème. (LOG-4467)
1.3.3.2. CVEs
Copier lien

1.3.4. Enregistrement 5.7.4
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.4.

1.3.4.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, lors de l’envoi de journaux à CloudWatch, une valeur d’espace de nomsUUID n’était pas ajoutée au champ logGroupName. Avec cette mise à jour, la valeur namespaceUUID est incluse, de sorte qu’un logGroupName dans CloudWatch apparaît comme logGroupName: vectorcw.b443fb9e-bd4c-4b6a-b9d3-c0097f9ed286. (LOG-2701)
  • Avant cette mise à jour, lors de la transmission des journaux sur HTTP vers une destination hors-cluster, le collecteur de vecteurs n’était pas en mesure d’authentifier le proxy HTTP à l’échelle du cluster, même si des informations d’identification correctes étaient fournies dans l’URL proxy. Avec cette mise à jour, le collecteur de journaux vectoriels peut désormais s’authentifier au proxy HTTP à l’échelle du cluster. (LOG-3381)
  • Avant cette mise à jour, l’opérateur échouerait si le collecteur Fluentd était configuré avec Splunk comme sortie, en raison de cette configuration n’étant pas prise en charge. Avec cette mise à jour, la validation de la configuration rejette les sorties non prises en charge, résolvant le problème. (LOG-4237)
  • Avant cette mise à jour, lorsque le collecteur Vector a été mis à jour, une valeur activée = vraie dans la configuration TLS pour les journaux AWS Cloudwatch et le GCP Stackdriver a causé une erreur de configuration. Avec cette mise à jour, activé = valeur réelle sera supprimé pour ces sorties, résolvant le problème. (LOG-4242)
  • Avant cette mise à jour, le collecteur Vecteur a parfois paniqué avec le message d’erreur suivant dans son journal: thread 'vector-worker' paniqué à 'toutes les branches sont désactivées et il n’y a pas d’autre branche', src/kubernetes/reflector.rs:26:9. Avec cette mise à jour, l’erreur a été résolue. (LOG-4275)
  • Avant cette mise à jour, un problème dans l’opérateur Loki a fait disparaître la configuration du gestionnaire d’alerte pour le locataire de l’application si l’opérateur était configuré avec des options supplémentaires pour ce locataire. Avec cette mise à jour, la configuration Loki générée contient désormais à la fois la configuration personnalisée et la configuration générée automatiquement. (LOG-4361)
  • Avant cette mise à jour, lorsque plusieurs rôles ont été utilisés pour s’authentifier en utilisant STS avec AWS Cloudwatch, une mise à jour récente a rendu les informations d’identification non uniques. Avec cette mise à jour, de multiples combinaisons de rôles STS et d’identifications statiques peuvent une fois de plus être utilisées pour authentifier avec AWS Cloudwatch. (LOG-4368)
  • Avant cette mise à jour, Loki a filtré les valeurs des étiquettes pour les flux actifs, mais n’a pas supprimé les doublons, ce qui rend le navigateur d’étiquettes de Grafana inutilisable. Avec cette mise à jour, Loki filtre les valeurs d’étiquettes dupliquées pour les flux actifs, ce qui résout le problème. (LOG-4389)
  • Les pipelines sans nom spécifiés dans la ressource personnalisée ClusterLogForwarder (CR) ont cessé de fonctionner après la mise à niveau vers OpenShift Logging 5.7. Avec cette mise à jour, l’erreur a été résolue. (LOG-4120)
1.3.4.2. CVEs
Copier lien

1.3.5. Enregistrement 5.7.3
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.3.

1.3.5.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, lors de l’affichage des journaux dans le Red Hat OpenShift Service sur la console web AWS, les fichiers mis en cache ont empêché les données de se rafraîchir. Avec cette mise à jour, les fichiers bootstrap ne sont pas mis en cache, résolvant le problème. (LOG-4100)
  • Avant cette mise à jour, l’opérateur Loki réinitialise les erreurs d’une manière qui rend l’identification des problèmes de configuration difficile à résoudre. Avec cette mise à jour, les erreurs persistent jusqu’à ce que l’erreur de configuration soit résolue. (LOG-4156)
  • Avant cette mise à jour, la règle LokiStack ne redémarrait pas après que des modifications aient été apportées à la ressource personnalisée RulerConfig (CR). Avec cette mise à jour, l’opérateur Loki redémarre les pods de règle après la mise à jour de RulerConfig CR. (LOG-4161)
  • Avant cette mise à jour, le collecteur vectoriel s’est terminé de manière inattendue lorsque les valeurs d’étiquette de correspondance d’entrée contenaient un / caractère dans le ClusterLogForwarder. Cette mise à jour résout le problème en citant l’étiquette de correspondance, permettant au collecteur de démarrer et de collecter des journaux. (LOG-4176)
  • Avant cette mise à jour, l’opérateur Loki se terminait de manière inattendue lorsqu’un LokiStack CR définissait des limites de locataire, mais pas des limites globales. Avec cette mise à jour, l’opérateur Loki peut traiter les CR LokiStack sans limites globales, ce qui résout le problème. (LOG-4198)
  • Avant cette mise à jour, Fluentd n’a pas envoyé de journaux à un cluster Elasticsearch lorsque la clé privée fournie était protégée par la phrase. Avec cette mise à jour, Fluentd gère correctement les clés privées protégées par la phrase lors de l’établissement d’une connexion avec Elasticsearch. (LOG-4258)
  • Avant cette mise à jour, les clusters avec plus de 8 000 espaces de noms ont poussé Elasticsearch à rejeter les requêtes parce que la liste des espaces de noms était plus grande que le paramètre http.max_header_size. Avec cette mise à jour, la valeur par défaut pour la taille de l’en-tête a été augmentée, résolvant le problème. (LOG-4277)
  • Avant cette mise à jour, les valeurs d’étiquette contenant un / caractère dans le ClusterLogForwarder CR entraîneraient la fin inattendue du collecteur. Avec cette mise à jour, les slashs sont remplacés par des accents, résolvant le problème. (LOG-4095)
  • Avant cette mise à jour, l’opérateur de journalisation du cluster s’est arrêté de manière inattendue lorsqu’il est défini à un état non géré. Avec cette mise à jour, une vérification pour s’assurer que la ressource ClusterLogging est dans l’état de gestion correct avant d’initier la réconciliation du ClusterLogForwarder CR, résoudre le problème. (LOG-4177)
  • Avant cette mise à jour, lors de l’affichage des journaux dans le Red Hat OpenShift Service sur la console web AWS, la sélection d’une plage de temps en faisant glisser sur l’histogramme ne fonctionnait pas sur la vue des journaux agrégés à l’intérieur du détail du pod. Avec cette mise à jour, la plage de temps peut être sélectionnée en faisant glisser sur l’histogramme dans cette vue. (LOG-4108)
  • Avant cette mise à jour, lors de l’affichage des journaux dans le service Red Hat OpenShift sur la console web AWS, les requêtes ont dépassé plus de 30 secondes. Avec cette mise à jour, la valeur timeout peut être configurée dans le configmap/logging-view-plugin. (LOG-3498)
  • Avant cette mise à jour, lors de l’affichage des journaux dans le Red Hat OpenShift Service sur la console web AWS, en cliquant sur l’option plus de données disponibles chargée plus d’entrées de journal seulement la première fois qu’elle a été cliquée. Avec cette mise à jour, plus d’entrées sont chargées de chaque clic. (OU 188)
  • Avant cette mise à jour, lors de l’affichage des journaux dans le Red Hat OpenShift Service sur la console web AWS, cliquer sur l’option de streaming n’afficherait que le message des journaux de streaming sans afficher les journaux réels. Avec cette mise à jour, le message et le flux journal sont affichés correctement. (OU-166)
1.3.5.2. CVEs
Copier lien

1.3.6. Journalisation 5.7.2
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.2.

1.3.6.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, il n’était pas possible de supprimer l’espace de noms openshift-logging directement en raison de la présence d’un finalisateur en attente. Avec cette mise à jour, le finalisateur n’est plus utilisé, permettant la suppression directe de l’espace de noms. (LOG-3316)
  • Avant cette mise à jour, le script run.sh afficherait une valeur de chunk_limit_size incorrecte si elle était modifiée selon le service Red Hat OpenShift sur la documentation AWS. Cependant, lorsque vous définissez la taille chunk_limit_size via la variable d’environnement $BUFFER_SIZE_LIMIT, le script afficherait la valeur correcte. Avec cette mise à jour, le script run.sh affiche désormais systématiquement la valeur chunk_limit_size correcte dans les deux scénarios. (LOG-3330)
  • Avant cette mise à jour, le Red Hat OpenShift Service sur le plugin d’affichage de journalisation de la console web AWS ne permettait pas le placement de nœuds personnalisés ou les tolérances. Cette mise à jour ajoute la possibilité de définir le placement des nœuds et les tolérances pour le plugin d’affichage de journalisation. (LOG-3749)
  • Avant cette mise à jour, l’opérateur de journalisation du cluster a rencontré une exception de type multimédia non pris en charge lorsque vous essayez d’envoyer des journaux à DataDog via le plugin HTTP Fluentd. Avec cette mise à jour, les utilisateurs peuvent assigner en toute transparence le type de contenu pour le transfert de journaux en configurant l’en-tête HTTP Content-Type. La valeur fournie est automatiquement attribuée au paramètre content_type dans le plugin, assurant ainsi une transmission réussie du journal. (LOG-3784)
  • Avant cette mise à jour, lorsque le champ detectMultilineErrors a été défini à true dans la ressource personnalisée ClusterLogForwarder (CR), les erreurs multilignes PHP ont été enregistrées sous forme d’entrées de journal séparées, ce qui a entraîné la division de la trace de pile entre plusieurs messages. Avec cette mise à jour, la détection d’erreur multi-lignes pour PHP est activée, assurant que toute la trace de la pile est incluse dans un seul message de journal. (LOG-3878)
  • Avant cette mise à jour, les pipelines ClusterLogForwarder contenant un espace à leur nom ont causé un crash continu des pods de collecteur de vecteurs. Avec cette mise à jour, tous les espaces, tirets (-) et points (.) dans les noms de pipelines sont remplacés par des accents (_). (LOG-3945)
  • Avant cette mise à jour, la métrique log_forwarder_output n’incluait pas le paramètre http. Cette mise à jour ajoute le paramètre manquant à la métrique. (LOG-3997)
  • Avant cette mise à jour, Fluentd n’identifiait pas certaines exceptions client JavaScript multilignes lorsqu’ils se terminaient par un côlon. Avec cette mise à jour, le nom du tampon Fluentd est préfixé avec un accent, résolvant le problème. (LOG-4019)
  • Avant cette mise à jour, lors de la configuration du transfert de journal pour écrire sur un sujet de sortie Kafka correspondant à une clé de la charge utile, les journaux ont chuté en raison d’une erreur. Avec cette mise à jour, le nom de tampon de Fluentd a été préfixé avec un accent, résolvant le problème.(LOG-4027)
  • Avant cette mise à jour, la passerelle LokiStack a renvoyé des valeurs d’étiquette pour les espaces de noms sans appliquer les droits d’accès d’un utilisateur. Avec cette mise à jour, la passerelle LokiStack applique des autorisations aux demandes de valeur d’étiquette, résolvant le problème. (LOG-4049)

  • Avant cette mise à jour, l’API Cluster Logging Operator exigeait qu’un certificat soit fourni par un secret lorsque l’option tls.insecureSkipVerify a été définie sur true. Avec cette mise à jour, l’API Cluster Logging Operator n’exige plus qu’un certificat soit fourni par un secret dans de tels cas. La configuration suivante a été ajoutée au CR de l’opérateur: 

    tls.verify_certificate = false
tls.verify_hostname = false
    Copy to Clipboard Toggle word wrap

    (LOG-3445)

  • Avant cette mise à jour, la configuration de l’itinéraire LokiStack a causé des requêtes en cours d’exécution de plus de 30 secondes. Avec cette mise à jour, les paramètres de requête globale et par locataire LokiStack affectent les paramètres de délai d’itinéraire, résolvant le problème. (LOG-4052)
  • Avant cette mise à jour, un correctif préalable pour supprimer le défaut de collecte.type avait pour conséquence que l’opérateur n’honorait plus les spécifications dépréciées pour les sélections de ressources, de nœuds et de tolérances. Cette mise à jour modifie le comportement de l’opérateur pour toujours préférer la spécification collection.logs par rapport à ceux de la collection. Cela varie du comportement précédent qui permettait d’utiliser à la fois les champs préférés et les champs dépréciés, mais ignorerait les champs dépréciés lorsque collection.type a été peuplé. (LOG-4185)
  • Avant cette mise à jour, le collecteur de journaux Vector n’a pas généré la configuration TLS pour transférer des journaux à plusieurs courtiers Kafka si les URL du courtier n’étaient pas spécifiées dans la sortie. Avec cette mise à jour, la configuration TLS est générée de manière appropriée pour plusieurs courtiers. (LOG-4163)
  • Avant cette mise à jour, l’option pour activer la phrase de passe pour le transfert de journal à Kafka n’était pas disponible. Cette limitation présentait un risque pour la sécurité car elle pourrait potentiellement exposer des informations sensibles. Avec cette mise à jour, les utilisateurs disposent désormais d’une option transparente pour activer la phrase de passe pour le transfert de journal à Kafka. (LOG-3314)
  • Avant cette mise à jour, Vector log collector n’a pas honoré les paramètres tlsSecurityProfile pour les connexions TLS sortantes. Après cette mise à jour, Vector gère correctement les paramètres de connexion TLS. (LOG-4011)
  • Avant cette mise à jour, tous les types de sortie disponibles n’étaient pas inclus dans les métriques log_forwarder_output_info. Avec cette mise à jour, les métriques contiennent des données Splunk et Google Cloud Logging qui manquaient auparavant. (LOG-4098)
  • Avant cette mise à jour, lorsque follow_inodes était défini sur true, le collecteur Fluentd pouvait s’écraser sur la rotation des fichiers. Avec cette mise à jour, le paramètre follow_inodes ne bloque pas le collecteur. (LOG-4151)
  • Avant cette mise à jour, le collecteur Fluentd pouvait fermer incorrectement les fichiers qui devraient être surveillés en raison de la façon dont ces fichiers ont été suivis. Avec cette mise à jour, les paramètres de suivi ont été corrigés. (LOG-4149)

  • Avant cette mise à jour, l’envoi de journaux avec le collecteur vectoriel et la désignation d’un pipeline dans l’audit, l’application ou l’infrastructure de l’instance ClusterLogForwarder ont conduit les pods de collecteur à rester dans l’état CrashLoopBackOff avec l’erreur suivante dans le journal de collecte: 

    ERROR vector::cli: Configuration error. error=redefinition of table transforms.audit for key transforms.audit
    Copy to Clipboard Toggle word wrap

    Après cette mise à jour, les noms de pipelines ne sont plus en conflit avec les noms d’entrée réservés, et les pipelines peuvent être nommés audit, application ou infrastructure. (LOG-4218)

  • Avant cette mise à jour, lors de l’envoi de journaux vers une destination syslog avec le collecteur Vector et de définir le drapeau addLogSource sur true, les champs vides supplémentaires suivants ont été ajoutés aux messages envoyés : namespace_name=, container_name= et pod_name=. Avec cette mise à jour, ces champs ne sont plus ajoutés aux journaux de journaux. (LOG-4219)
  • Avant cette mise à jour, lorsqu’une structureTypeKey n’a pas été trouvée, et qu’une structureTypeName n’a pas été spécifiée, les messages journaux étaient toujours analysés en objet structuré. Avec cette mise à jour, l’analyse des journaux est comme prévu. (LOG-4220)
1.3.6.2. CVEs
Copier lien

1.3.7. Journalisation 5.7.1
Copier lien

Cette version inclut: OpenShift Logging Bug Fix Release 5.7.1.

1.3.7.1. Corrections de bogues
Copier lien
  • Avant cette mise à jour, la présence de nombreux messages bruyants dans les journaux de pod de l’opérateur de journalisation du cluster a entraîné une diminution de la lisibilité des journaux et une difficulté accrue à identifier les événements importants du système. Avec cette mise à jour, le problème est résolu en réduisant considérablement les messages bruyants dans les journaux de pod de cluster Logging Operator. (LOG-3482)
  • Avant cette mise à jour, le serveur API réinitialisait la valeur du champ CollectorSpec.Type en vecteur, même lorsque la ressource personnalisée utilisait une valeur différente. Cette mise à jour supprime la valeur par défaut du champ CollectorSpec.Type pour restaurer le comportement précédent. (LOG-4086)
  • Avant cette mise à jour, une plage de temps ne pouvait pas être sélectionnée dans le Red Hat OpenShift Service sur la console web AWS en cliquant et en glissant sur l’histogramme des journaux. Avec cette mise à jour, le clic et le glisser peuvent être utilisés pour sélectionner avec succès une plage de temps. (LOG-4501)
  • Avant cette mise à jour, cliquer sur le lien Afficher les ressources dans le service Red Hat OpenShift sur la console web AWS n’a produit aucun effet. Avec cette mise à jour, le problème est résolu en fixant la fonctionnalité du lien « Afficher les ressources » pour activer l’affichage des ressources pour chaque entrée de journal. (LOG-3218)
1.3.7.2. CVEs
Copier lien

1.3.8. Journalisation 5.7.0
Copier lien

Cette version inclut OpenShift Logging Bug Fix Release 5.7.0.

1.3.8.1. Améliorations
Copier lien

Avec cette mise à jour, vous pouvez activer la journalisation pour détecter les exceptions multilignes et les réassembler en une seule entrée de journal.

Afin de permettre à l’enregistrement de détecter des exceptions multilignes et de les réassembler en une seule entrée de journal, assurez-vous que la ressource personnalisée ClusterLogForwarder (CR) contient un champ DétecterMultilineErrors, avec une valeur de true.

1.3.8.2. Les problèmes connus
Copier lien

Aucun.

1.3.8.3. Corrections de bogues
Copier lien
  • Avant cette mise à jour, l’attribut nodeSelector pour le composant Gateway du LokiStack n’a pas eu d’impact sur la programmation des nœuds. Avec cette mise à jour, l’attribut nodeSelector fonctionne comme prévu. (LOG-3713)
1.3.8.4. CVEs
Copier lien

Chapitre 2. Le soutien
Copier lien

Les options de configuration décrites dans cette documentation ne sont prises en charge que pour l’enregistrement.

Il ne faut pas utiliser d’autres options de configuration, car elles ne sont pas prises en charge. Les paradigmes de configuration peuvent changer dans Red Hat OpenShift Service sur les versions AWS, et de tels cas ne peuvent être traités que si toutes les possibilités de configuration sont contrôlées. Lorsque vous utilisez des configurations autres que celles décrites dans cette documentation, vos modifications seront écrasées, car les opérateurs sont conçus pour concilier toute différence.

Note

Lorsque vous devez effectuer des configurations non décrites dans le Service OpenShift Red Hat sur la documentation AWS, vous devez définir votre opérateur de journalisation Red Hat OpenShift sur non géré. Aucune instance de journalisation non gérée n’est prise en charge et ne reçoit pas de mises à jour jusqu’à ce que vous renvoyiez son statut à Managed.

Note

La journalisation est fournie en tant que composant installable, avec un cycle de sortie distinct du noyau Red Hat OpenShift Service sur AWS. La politique sur le cycle de vie de la plate-forme de conteneur Red Hat OpenShift décrit la compatibilité des versions.

Journalisation pour Red Hat OpenShift est un collectionneur avisé et normalisateur des journaux d’applications, d’infrastructures et d’audits. Il est destiné à être utilisé pour le transfert de journaux vers divers systèmes pris en charge.

L’enregistrement n’est pas:

  • Le système de collecte de journaux à grande échelle
  • Information de sécurité et surveillance des événements (SIEM)
  • Configuration du collecteur de journal "Amenez votre propre" (BYO)
  • Conservation ou stockage de journaux historiques ou à long terme
  • Évier en rondins garantis
  • Stockage sécurisé - Les journaux d’audit ne sont pas stockés par défaut

Le tableau suivant décrit les API de journalisation prises en charge.

Expand
Tableau 2.1. États de support de l’API Loki
CustomResourceDefinition (CRD)ApiVersionÉtat de soutien

LokiStack

lokistack.loki.grafana.com/v1

Compatible à partir de 5.5

À propos de RulerConfig

accueil > Rulerconfig.loki.grafana/v1

Compatible à partir de 5.7

AlerteRule

alertingrule.loki.grafana/v1

Compatible à partir de 5.7

EnregistrementRule

recordingrule.loki.grafana/v1

Compatible à partir de 5.7

LogFileMetricExporter

LogFileMetricExporter.logging.openshift.io/v1alpha1

Compatible à partir de 5.8

ClusterLogForwarder

clusterlogforwarder.logging.openshift.io/v1

Prise en charge de 4.5.

2.2. Configurations non prises en charge
Copier lien

L’opérateur de journalisation Red Hat OpenShift doit être configuré sur l’état non géré pour modifier les composants suivants:

  • Le fichier fluent.conf
  • Le jeu de démon Fluentd
  • Le fichier vector.toml pour les déploiements de collectionneurs vectoriels

Les cas explicitement non étayés comprennent:

  • Configuration de l’emplacement du journal collecté. Il est impossible de modifier l’emplacement du fichier de sortie du collecteur de journaux, qui est par défaut /var/log/fluentd/fluentd.log.
  • Collection de rondins d’étranglement. Il est impossible de réduire la vitesse à laquelle les journaux sont lus par le collecteur de journaux.
  • Configuration du collecteur de journalisation à l’aide de variables d’environnement. Il n’est pas possible d’utiliser des variables d’environnement pour modifier le collecteur de journaux.
  • Configuration de la façon dont le collecteur de journaux normalise les journaux. Il est impossible de modifier la normalisation par défaut du journal.

2.3. La politique de soutien pour les opérateurs non gérés
Copier lien

L’état de gestion d’un opérateur détermine si un opérateur gère activement les ressources de sa composante connexe dans le cluster tel qu’il a été conçu. Lorsqu’un opérateur est réglé sur un état non géré, il ne répond pas aux changements de configuration et ne reçoit pas de mises à jour.

Bien que cela puisse être utile dans les clusters de non-production ou pendant le débogage, les opérateurs dans un état non géré ne sont pas pris en charge et l’administrateur du cluster assume le contrôle total des configurations et des mises à niveau des composants individuels.

L’opérateur peut être réglé à un état non géré en utilisant les méthodes suivantes:

  • Configuration individuelle de l’opérateur

    Les opérateurs individuels ont un paramètre managementState dans leur configuration. Il est possible d’y accéder de différentes manières, en fonction de l’opérateur. À titre d’exemple, le Red Hat OpenShift Logging Operator accomplit cela en modifiant une ressource personnalisée (CR) qu’il gère, tandis que l’opérateur d’échantillons de cluster utilise une ressource de configuration à l’échelle du cluster.

    Changer le paramètre managementState en non géré signifie que l’Opérateur ne gère pas activement ses ressources et ne prendra aucune mesure liée à la composante connexe. Certains opérateurs pourraient ne pas prendre en charge cet état de gestion car il pourrait endommager le cluster et nécessiter une récupération manuelle.

    Avertissement

    Changer les opérateurs individuels à l’état non géré rend ce composant et cette fonctionnalité particuliers non pris en charge. Les problèmes signalés doivent être reproduits dans l’état géré pour que le soutien puisse être poursuivi.

  • L’opérateur de la version cluster (CVO) remplace

    Le paramètre spec.overrides peut être ajouté à la configuration du CVO pour permettre aux administrateurs de fournir une liste de dépassements au comportement du CVO pour un composant. Définir le paramètre spec.overrides[].ungaged sur true pour un cluster de blocs de composants met à jour et alerte l’administrateur après qu’une override CVO a été définie: 

    Disabling ownership via cluster version overrides prevents upgrades. Please remove overrides before continuing.
    Copy to Clipboard Toggle word wrap
    Avertissement

    La mise en place d’un CVO remplace l’ensemble du cluster dans un état non pris en charge. Les problèmes signalés doivent être reproduits après avoir retiré toute dérogation à l’appui.

Jusqu’à l’approche de la version de la Disponibilité Générale (GA) du Cluster Observability Operator (COO), qui est actuellement dans Technology Preview (TP), Red Hat fournit un soutien aux clients qui utilisent Logging 6.0 ou plus tard avec le COO pour son plugin UI de journalisation sur Red Hat OpenShift Service sur AWS 4.14 ou version ultérieure. Cette exception de support est temporaire car le COO comprend plusieurs fonctionnalités indépendantes, dont certaines sont encore des fonctionnalités TP, mais le plugin Logging UI est prêt pour GA.

Lors de l’ouverture d’un cas de support, il est utile de fournir des informations de débogage sur votre cluster à Red Hat Support.

Il est possible d’utiliser l’outil must-collectther pour recueillir des informations diagnostiques pour les ressources au niveau du projet, les ressources au niveau du cluster et chacune des composantes d’enregistrement. Fournir rapidement des informations de diagnostic pour Red Hat OpenShift Service sur AWS et l’enregistrement.

2.5.1. À propos de l’outil must-collectther
Copier lien

La commande oc adm must-collectther CLI collecte les informations de votre cluster qui sont probablement nécessaires pour les problèmes de débogage.

Dans le cadre de votre enregistrement, must-collectther recueille les informations suivantes:

  • Les ressources au niveau du projet, y compris les pods, les cartes de configuration, les comptes de service, les rôles, les liens de rôles et les événements au niveau du projet
  • Les ressources au niveau des clusters, y compris les nœuds, les rôles et les liens de rôle au niveau des clusters
  • Les ressources de journalisation OpenShift dans les espaces de noms openshift-logging et openshift-operators-redhat, y compris l’état de santé du collecteur de journaux, du magasin de journal et du visualiseur de journal

Lorsque vous exécutez oc adm must-collectther, un nouveau pod est créé sur le cluster. Les données sont collectées sur ce pod et enregistrées dans un nouveau répertoire qui commence par must-collectther.local. Ce répertoire est créé dans le répertoire de travail actuel.

2.5.2. Collecte de données d’enregistrement
Copier lien

La commande oc adm must-collectther CLI vous permet de collecter des informations sur l’enregistrement.

Procédure

Collecter des informations d’enregistrement avec must-collectther:

  1. Accédez au répertoire où vous souhaitez stocker les informations must-collectther.

  2. Exécutez la commande oc adm must-collectther contre l’image de journalisation: 

    $ oc adm must-gather --image=$(oc -n openshift-logging get deployment.apps/cluster-logging-operator -o jsonpath='{.spec.template.spec.containers[?(@.name == "cluster-logging-operator")].image}')
    Copy to Clipboard Toggle word wrap

    L’outil must-collectther crée un nouveau répertoire qui commence par must-collectther.local dans le répertoire actuel. A titre d’exemple: must-collectther.local.4157245944708210408.

  3. Créez un fichier compressé à partir du répertoire must-collectther qui vient d’être créé. À titre d’exemple, sur un ordinateur qui utilise un système d’exploitation Linux, exécutez la commande suivante: 

    $ tar -cvaf must-gather.tar.gz must-gather.local.4157245944708210408
    Copy to Clipboard Toggle word wrap
  4. Attachez le fichier compressé à votre dossier d’assistance sur le portail client Red Hat.

Chapitre 3. Dépannage de l’enregistrement
Copier lien

3.1. Affichage de l’état de journalisation
Copier lien

Le statut de Red Hat OpenShift Logging Operator et d’autres composants d’enregistrement peut être visualisé.

Le statut de Red Hat OpenShift Logging Operator vous permet d’afficher le statut de l’opérateur de journalisation Red Hat OpenShift.

Conditions préalables

  • Le Red Hat OpenShift Logging Operator et OpenShift Elasticsearch Operator sont installés.

Procédure

  1. Changer le projet openshift-logging en exécutant la commande suivante: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Accédez à l’état de l’instance ClusterLogging en exécutant la commande suivante: 

    $ oc get clusterlogging instance -o yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
# ...
status:
    1 
    
  collection:
    logs:
      fluentdStatus:
        daemonSet: fluentd
    2 
    
        nodes:
          collector-2rhqp: ip-10-0-169-13.ec2.internal
          collector-6fgjh: ip-10-0-165-244.ec2.internal
          collector-6l2ff: ip-10-0-128-218.ec2.internal
          collector-54nx5: ip-10-0-139-30.ec2.internal
          collector-flpnn: ip-10-0-147-228.ec2.internal
          collector-n2frh: ip-10-0-157-45.ec2.internal
        pods:
          failed: []
          notReady: []
          ready:
          - collector-2rhqp
          - collector-54nx5
          - collector-6fgjh
          - collector-6l2ff
          - collector-flpnn
          - collector-n2frh
  logstore:
    3 
    
    elasticsearchStatus:
    - ShardAllocationEnabled:  all
      cluster:
        activePrimaryShards:    5
        activeShards:           5
        initializingShards:     0
        numDataNodes:           1
        numNodes:               1
        pendingTasks:           0
        relocatingShards:       0
        status:                 green
        unassignedShards:       0
      clusterName:             elasticsearch
      nodeConditions:
        elasticsearch-cdm-mkkdys93-1:
      nodeCount:  1
      pods:
        client:
          failed:
          notReady:
          ready:
          - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
        data:
          failed:
          notReady:
          ready:
          - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
        master:
          failed:
          notReady:
          ready:
          - elasticsearch-cdm-mkkdys93-1-7f7c6-mjm7c
  visualization:
    4 
    
    kibanaStatus:
    - deployment: kibana
      pods:
        failed: []
        notReady: []
        ready:
        - kibana-7fb4fd4cc9-f2nls
      replicaSets:
      - kibana-7fb4fd4cc9
      replicas: 1
    Copy to Clipboard Toggle word wrap

    1
    Dans la sortie, les champs d’état du cluster apparaissent dans la strophe d’état.
    2
    Informations sur les gousses Fluentd.
    3
    Informations sur les pods Elasticsearch, y compris Elasticsearch cluster santé, vert, jaune ou rouge.
    4
    Informations sur les pods de Kibana.
3.1.1.1. Exemple de messages de condition
Copier lien

Ce qui suit sont des exemples de messages de condition de la section Status.Nodes de l’instance ClusterLogging.

Le message d’état similaire à ce qui suit indique qu’un nœud a dépassé le filigrane faible configuré et qu’aucun fragment ne sera attribué à ce nœud:

Exemple de sortie

  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-clientdatamaster-0-1
    upgradeStatus: {}
Copy to Clipboard Toggle word wrap

Le message d’état similaire à ce qui suit indique qu’un nœud a dépassé le filigrane élevé configuré et les éclats seront déplacés vers d’autres nœuds:

Exemple de sortie

  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: cluster-logging-operator
    upgradeStatus: {}
Copy to Clipboard Toggle word wrap

Le message d’état similaire à ce qui suit indique que le sélecteur de nœuds Elasticsearch dans le CR ne correspond à aucun nœud dans le cluster:

Exemple de sortie

    Elasticsearch Status:
      Shard Allocation Enabled:  shard allocation unknown
      Cluster:
        Active Primary Shards:  0
        Active Shards:          0
        Initializing Shards:    0
        Num Data Nodes:         0
        Num Nodes:              0
        Pending Tasks:          0
        Relocating Shards:      0
        Status:                 cluster health unknown
        Unassigned Shards:      0
      Cluster Name:             elasticsearch
      Node Conditions:
        elasticsearch-cdm-mkkdys93-1:
          Last Transition Time:  2019-06-26T03:37:32Z
          Message:               0/5 nodes are available: 5 node(s) didn't match node selector.
          Reason:                Unschedulable
          Status:                True
          Type:                  Unschedulable
        elasticsearch-cdm-mkkdys93-2:
      Node Count:  2
      Pods:
        Client:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
        Data:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
        Master:
          Failed:
          Not Ready:
            elasticsearch-cdm-mkkdys93-1-75dd69dccd-f7f49
            elasticsearch-cdm-mkkdys93-2-67c64f5f4c-n58vl
          Ready:
Copy to Clipboard Toggle word wrap

Le message d’état semblable à ce qui suit indique que le PVC demandé ne pouvait pas se lier au PV:

Exemple de sortie

      Node Conditions:
        elasticsearch-cdm-mkkdys93-1:
          Last Transition Time:  2019-06-26T03:37:32Z
          Message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
          Reason:                Unschedulable
          Status:                True
          Type:                  Unschedulable
Copy to Clipboard Toggle word wrap

Le message d’état similaire à ce qui suit indique que les gousses Fluentd ne peuvent pas être programmées parce que le sélecteur de nœuds ne correspondait à aucun nœud:

Exemple de sortie

Status:
  Collection:
    Logs:
      Fluentd Status:
        Daemon Set:  fluentd
        Nodes:
        Pods:
          Failed:
          Not Ready:
          Ready:
Copy to Clipboard Toggle word wrap

3.1.2. Affichage de l’état des composants de journalisation
Copier lien

Il est possible d’afficher l’état d’un certain nombre de composants de journalisation.

Conditions préalables

  • Le Red Hat OpenShift Logging Operator et OpenShift Elasticsearch Operator sont installés.

Procédure

  1. Changement au projet openshift-logging. 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Afficher l’état de l’environnement d’exploitation forestière: 

    $ oc describe deployment cluster-logging-operator
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Name:                   cluster-logging-operator

....

Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    True    NewReplicaSetAvailable

....

Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  62m   deployment-controller  Scaled up replica set cluster-logging-operator-574b8987df to 1----
    Copy to Clipboard Toggle word wrap

  3. Afficher l’état de l’ensemble de la réplique de journalisation:

    1. Demandez le nom d’un ensemble de répliques:

      Exemple de sortie

      $ oc get replicaset
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                      DESIRED   CURRENT   READY   AGE
cluster-logging-operator-574b8987df       1         1         1       159m
elasticsearch-cdm-uhr537yu-1-6869694fb    1         1         1       157m
elasticsearch-cdm-uhr537yu-2-857b6d676f   1         1         1       156m
elasticsearch-cdm-uhr537yu-3-5b6fdd8cfd   1         1         1       155m
kibana-5bd5544f87                         1         1         1       157m
      Copy to Clipboard Toggle word wrap

    2. Bénéficiez de l’état de l’ensemble de réplique: 

      $ oc describe replicaset cluster-logging-operator-574b8987df
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      Name:           cluster-logging-operator-574b8987df

....

Replicas:       1 current / 1 desired
Pods Status:    1 Running / 0 Waiting / 0 Succeeded / 0 Failed

....

Events:
  Type    Reason            Age   From                   Message
  ----    ------            ----  ----                   -------
  Normal  SuccessfulCreate  66m   replicaset-controller  Created pod: cluster-logging-operator-574b8987df-qjhqv----
      Copy to Clipboard Toggle word wrap

3.2. Dépannage du transfert de journaux
Copier lien

3.2.1. Le redéploiement des gousses Fluentd
Copier lien

Lorsque vous créez une ressource personnalisée ClusterLogForwarder (CR), si le Red Hat OpenShift Logging Operator ne redéploie pas automatiquement les gousses Fluentd, vous pouvez supprimer les gousses Fluentd pour les forcer à redéployer.

Conditions préalables

  • ClusterLogForwarder a créé un objet de ressource personnalisée (CR) ClusterLogForwarder.

Procédure

  • Supprimez les gousses Fluentd pour les forcer à redéployer en exécutant la commande suivante: 

    $ oc delete pod --selector logging-infra=collector
    Copy to Clipboard Toggle word wrap

3.2.2. Dépannage des erreurs de limite de taux Loki
Copier lien

Lorsque l’API Log Forwarder transmet un grand bloc de messages qui dépasse la limite de taux à Loki, Loki génère des erreurs de limite de débit (429).

Ces erreurs peuvent se produire pendant le fonctionnement normal. À titre d’exemple, lors de l’ajout de la journalisation à un cluster qui possède déjà certains journaux, des erreurs de limite de taux peuvent se produire pendant que la journalisation tente d’ingérer toutes les entrées de journal existantes. Dans ce cas, si le taux d’ajout de nouveaux journaux est inférieur à la limite de taux totale, les données historiques sont finalement ingérées, et les erreurs de limite de taux sont résolues sans nécessiter l’intervention de l’utilisateur.

Dans les cas où les erreurs de limite de taux continuent de se produire, vous pouvez résoudre le problème en modifiant la ressource personnalisée LokiStack (CR).

Important

Le LokiStack CR n’est pas disponible sur Grafana-hosted Loki. Cette rubrique ne s’applique pas aux serveurs Loki hébergés par Grafana.

Les conditions

  • L’API Log Forwarder est configurée pour transférer les journaux vers Loki.

  • Le système envoie un bloc de messages de plus de 2 Mo à Loki. À titre d’exemple: 

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
    Copy to Clipboard Toggle word wrap

  • Après avoir entré les journaux oc -n openshift-logging -l component=collector, les journaux collecteurs de votre cluster affichent une ligne contenant l’un des messages d’erreur suivants: 

    429 Too Many Requests Ingestion rate limit exceeded
    Copy to Clipboard Toggle word wrap

    Exemple de message d’erreur vectoriel

    2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
    Copy to Clipboard Toggle word wrap

    Exemple de message d’erreur Fluentd

    2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
    Copy to Clipboard Toggle word wrap

    L’erreur est également visible à l’extrémité de réception. À titre d’exemple, dans la pod LokiStack ingester:

    Exemple de message d’erreur Loki ingester

    level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
    Copy to Clipboard Toggle word wrap

Procédure

  • Actualisez les champs ingestionBurstSize et ingestionRate dans le LokiStack CR: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16
    1 
    
        ingestionRate: 8
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    Le champ ingestionBurstSize définit la taille maximale de l’échantillon par distributeur en MB. Cette valeur est une limite dure. Définissez cette valeur sur au moins la taille maximale des logs attendue dans une seule requête push. Les demandes uniques qui sont plus grandes que la valeur d’ingestionBurstSize ne sont pas autorisées.
    2
    Le champ ingestionRate est une limite molle sur la quantité maximale d’échantillons ingérés par seconde en MB. Les erreurs de limite de taux se produisent si le taux de logs dépasse la limite, mais le collecteur retries en envoyant les journaux. Aussi longtemps que la moyenne totale est inférieure à la limite, le système récupère et les erreurs sont résolues sans intervention de l’utilisateur.

3.3. Dépannage des alertes de journalisation
Copier lien

Les procédures suivantes vous permettent de dépanner les alertes d’enregistrement sur votre cluster.

3.3.1. L’état de santé du cluster Elasticsearch est rouge
Copier lien

Au moins un fragment primaire et ses répliques ne sont pas attribués à un nœud. Appliquez la procédure suivante pour résoudre cette alerte.

Astuce

Certaines commandes dans cette documentation font référence à un pod Elasticsearch en utilisant une variable shell $ES_POD_NAME. Lorsque vous souhaitez copier et coller les commandes directement à partir de cette documentation, vous devez définir cette variable sur une valeur valide pour votre cluster Elasticsearch.

Liste des pods Elasticsearch disponibles en exécutant la commande suivante: 

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

Choisissez l’un des pods listés et définissez la variable $ES_POD_NAME, en exécutant la commande suivante: 

$ export ES_POD_NAME=<elasticsearch_pod_name>
Copy to Clipboard Toggle word wrap

Désormais, vous pouvez utiliser la variable $ES_POD_NAME dans les commandes.

Procédure

  1. Consultez l’état de santé du cluster Elasticsearch et vérifiez que l’état du cluster est rouge en exécutant la commande suivante: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- health
    Copy to Clipboard Toggle word wrap

  2. Énumérez les nœuds qui ont rejoint le cluster en exécutant la commande suivante: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/nodes?v
    Copy to Clipboard Toggle word wrap

  3. Énumérez les pods Elasticsearch et comparez-les avec les nœuds de la sortie de commande de l’étape précédente, en exécutant la commande suivante: 

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

  4. Lorsque certains des nœuds Elasticsearch n’ont pas rejoint le cluster, effectuez les étapes suivantes.

    1. Confirmez que Elasticsearch a un nœud maître élu en exécutant la commande suivante et en observant la sortie: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/master?v
      Copy to Clipboard Toggle word wrap

    2. Examinez les journaux de pod du nœud maître élu pour les problèmes en exécutant la commande suivante et en observant la sortie: 

      $ oc logs <elasticsearch_master_pod_name> -c elasticsearch -n openshift-logging
      Copy to Clipboard Toggle word wrap

    3. Examinez les journaux des nœuds qui n’ont pas rejoint le cluster pour les problèmes en exécutant la commande suivante et en observant la sortie: 

      $ oc logs <elasticsearch_node_name> -c elasticsearch -n openshift-logging
      Copy to Clipboard Toggle word wrap

  5. Lorsque tous les nœuds ont rejoint le cluster, vérifiez si le cluster est en cours de récupération en exécutant la commande suivante et en observant la sortie: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/recovery?active_only=true
    Copy to Clipboard Toggle word wrap

    En l’absence de sortie de commande, le processus de récupération peut être retardé ou bloqué par des tâches en attente.

  6. Vérifiez s’il y a des tâches en attente en exécutant la commande suivante et en observant la sortie: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- health | grep number_of_pending_tasks
    Copy to Clipboard Toggle word wrap
  7. En cas de tâches en attente, surveillez leur statut. Lorsque leur statut change et indique que le cluster est en cours de récupération, continuez à attendre. Le temps de récupération varie en fonction de la taille du cluster et d’autres facteurs. Dans le cas contraire, si le statut des tâches en attente ne change pas, cela indique que la récupération est bloquée.

  8. Lorsqu’il semble que la récupération ait décroché, vérifiez si la valeur cluster.routing.allocation.enable n’est pas réglée, en exécutant la commande suivante et en observant la sortie: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/settings?pretty
    Copy to Clipboard Toggle word wrap

  9. Lorsque la valeur cluster.routing.allocation.enable n’est pas définie, définissez-la à tous, en exécutant la commande suivante: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/settings?pretty \
  -X PUT -d '{"persistent": {"cluster.routing.allocation.enable":"all"}}'
    Copy to Clipboard Toggle word wrap

  10. Vérifiez si des indices sont encore rouges en exécutant la commande suivante et en observant la sortie: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/indices?v
    Copy to Clipboard Toggle word wrap

  11. Lorsque des indices sont encore rouges, essayez de les effacer en effectuant les étapes suivantes.

    1. Effacer le cache en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name>/_cache/clear?pretty
      Copy to Clipboard Toggle word wrap

    2. Augmentez les retries d’allocation maximale en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name>/_settings?pretty \
  -X PUT -d '{"index.allocation.max_retries":10}'
      Copy to Clipboard Toggle word wrap

    3. Effacer tous les éléments de défilement en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_search/scroll/_all -X DELETE
      Copy to Clipboard Toggle word wrap

    4. Augmentez le délai d’exécution en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name>/_settings?pretty \
  -X PUT -d '{"index.unassigned.node_left.delayed_timeout":"10m"}'
      Copy to Clipboard Toggle word wrap

  12. Lorsque les étapes précédentes n’effacent pas les indices rouges, supprimez les indices individuellement.

    1. Identifiez le nom de l’index rouge en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cat/indices?v
      Copy to Clipboard Toggle word wrap

    2. Effacer l’index rouge en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_red_index_name> -X DELETE
      Copy to Clipboard Toggle word wrap

  13. En l’absence d’indices rouges et l’état du cluster est rouge, vérifiez une charge de traitement lourde continue sur un nœud de données.

    1. Vérifiez si l’utilisation d’Elasticsearch JVM Heap est élevée en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_nodes/stats?pretty
      Copy to Clipboard Toggle word wrap

      Dans la sortie de commande, examinez le champ node_name.jvm.mem.heap_used_percent pour déterminer l’utilisation de JVM Heap.

    2. Contrôlez l’utilisation élevée du CPU. En savoir plus sur l’utilitzation CPU, consultez la documentation de Red Hat OpenShift Service sur AWS "Reviewing Monitoring dashboards".

3.3.2. L’état de santé du cluster Elasticsearch est jaune
Copier lien

Les fragments de réplique pour au moins un fragment primaire ne sont pas attribués aux nœuds. Augmentez le nombre de nœuds en ajustant la valeur nodeCount dans la ressource personnalisée ClusterLogging (CR).

3.3.3. Elasticsearch disque de nœud bas filigrane atteint
Copier lien

Elasticsearch n’attribue pas de fragments aux nœuds qui atteignent le filigrane bas.

Astuce

Certaines commandes dans cette documentation font référence à un pod Elasticsearch en utilisant une variable shell $ES_POD_NAME. Lorsque vous souhaitez copier et coller les commandes directement à partir de cette documentation, vous devez définir cette variable sur une valeur valide pour votre cluster Elasticsearch.

Liste des pods Elasticsearch disponibles en exécutant la commande suivante: 

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

Choisissez l’un des pods listés et définissez la variable $ES_POD_NAME, en exécutant la commande suivante: 

$ export ES_POD_NAME=<elasticsearch_pod_name>
Copy to Clipboard Toggle word wrap

Désormais, vous pouvez utiliser la variable $ES_POD_NAME dans les commandes.

Procédure

  1. Identifiez le nœud sur lequel Elasticsearch est déployé en exécutant la commande suivante: 

    $ oc -n openshift-logging get po -o wide
    Copy to Clipboard Toggle word wrap

  2. Vérifiez s’il y a des éclats non attribués en exécutant la commande suivante: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/health?pretty | grep unassigned_shards
    Copy to Clipboard Toggle word wrap

  3. En cas de fragments non attribués, vérifiez l’espace disque de chaque nœud, en exécutant la commande suivante: 

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
  do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
  -- df -h /elasticsearch/persistent; done
    Copy to Clipboard Toggle word wrap

  4. Dans la sortie de commande, cochez la colonne Utiliser pour déterminer le pourcentage de disque utilisé sur ce nœud.

    Exemple de sortie

    elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent
    Copy to Clipboard Toggle word wrap

    Lorsque le pourcentage de disque utilisé est supérieur à 85 %, le nœud a dépassé le filigrane bas, et les éclats ne peuvent plus être attribués à ce nœud.

  5. Afin de vérifier la redondance actuelle, exécutez la commande suivante: 

    $ oc -n openshift-logging get es elasticsearch \
  -o jsonpath='{.spec.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque vous utilisez une ressource ClusterLogging sur votre cluster, exécutez la commande suivante: 

    $ oc -n openshift-logging get cl \
  -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque la valeur de redondance du cluster est supérieure à la valeur SingleRedundancy, définissez-la sur la valeur SingleRedundancy et enregistrez ce changement.

  6. Lorsque les étapes précédentes ne règlent pas le problème, supprimez les anciens indices.

    1. Consultez l’état de tous les indices sur Elasticsearch en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
      Copy to Clipboard Toggle word wrap
    2. Identifiez un ancien index qui peut être supprimé.

    3. Effacer l’index en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name> -X DELETE
      Copy to Clipboard Toggle word wrap

3.3.4. Elasticsearch disque de nœud haute filigrane atteint
Copier lien

Elasticsearch tente de déplacer des fragments loin d’un nœud qui a atteint le filigrane élevé vers un nœud avec une faible utilisation du disque qui n’a franchi aucune limite de seuil de filigrane.

Afin d’attribuer des éclats à un nœud particulier, vous devez libérer de l’espace sur ce nœud. Lorsque l’augmentation de l’espace disque n’est pas possible, essayez d’ajouter un nouveau nœud de données au cluster ou diminuez la politique de redondance totale des clusters.

Astuce

Certaines commandes dans cette documentation font référence à un pod Elasticsearch en utilisant une variable shell $ES_POD_NAME. Lorsque vous souhaitez copier et coller les commandes directement à partir de cette documentation, vous devez définir cette variable sur une valeur valide pour votre cluster Elasticsearch.

Liste des pods Elasticsearch disponibles en exécutant la commande suivante: 

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

Choisissez l’un des pods listés et définissez la variable $ES_POD_NAME, en exécutant la commande suivante: 

$ export ES_POD_NAME=<elasticsearch_pod_name>
Copy to Clipboard Toggle word wrap

Désormais, vous pouvez utiliser la variable $ES_POD_NAME dans les commandes.

Procédure

  1. Identifiez le nœud sur lequel Elasticsearch est déployé en exécutant la commande suivante: 

    $ oc -n openshift-logging get po -o wide
    Copy to Clipboard Toggle word wrap

  2. Consultez l’espace disque de chaque nœud: 

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
  do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
  -- df -h /elasticsearch/persistent; done
    Copy to Clipboard Toggle word wrap

  3. Vérifiez si le cluster est en train de rééquilibrer: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_cluster/health?pretty | grep relocating_shards
    Copy to Clipboard Toggle word wrap

    Lorsque la sortie de commande montre le déplacement des éclats, le filigrane élevé a été dépassé. La valeur par défaut du filigrane élevé est de 90%.

  4. Augmentez l’espace disque sur tous les nœuds. Lorsque l’augmentation de l’espace disque n’est pas possible, essayez d’ajouter un nouveau nœud de données au cluster ou diminuez la politique de redondance totale des clusters.

  5. Afin de vérifier la redondance actuelle, exécutez la commande suivante: 

    $ oc -n openshift-logging get es elasticsearch \
  -o jsonpath='{.spec.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque vous utilisez une ressource ClusterLogging sur votre cluster, exécutez la commande suivante: 

    $ oc -n openshift-logging get cl \
  -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque la valeur de redondance du cluster est supérieure à la valeur SingleRedundancy, définissez-la sur la valeur SingleRedundancy et enregistrez ce changement.

  6. Lorsque les étapes précédentes ne règlent pas le problème, supprimez les anciens indices.

    1. Consultez l’état de tous les indices sur Elasticsearch en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
      Copy to Clipboard Toggle word wrap
    2. Identifiez un ancien index qui peut être supprimé.

    3. Effacer l’index en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name> -X DELETE
      Copy to Clipboard Toggle word wrap

Elasticsearch applique un bloc d’index en lecture seule sur chaque index qui a ces deux conditions:

  • Il y a un ou plusieurs éclats qui sont attribués au nœud.
  • Il y a un ou plusieurs disques qui dépassent le stade d’inondation.

Appliquez la procédure suivante pour résoudre cette alerte.

Astuce

Certaines commandes dans cette documentation font référence à un pod Elasticsearch en utilisant une variable shell $ES_POD_NAME. Lorsque vous souhaitez copier et coller les commandes directement à partir de cette documentation, vous devez définir cette variable sur une valeur valide pour votre cluster Elasticsearch.

Liste des pods Elasticsearch disponibles en exécutant la commande suivante: 

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

Choisissez l’un des pods listés et définissez la variable $ES_POD_NAME, en exécutant la commande suivante: 

$ export ES_POD_NAME=<elasticsearch_pod_name>
Copy to Clipboard Toggle word wrap

Désormais, vous pouvez utiliser la variable $ES_POD_NAME dans les commandes.

Procédure

  1. Bénéficiez de l’espace disque du nœud Elasticsearch: 

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
  do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
  -- df -h /elasticsearch/persistent; done
    Copy to Clipboard Toggle word wrap

  2. Dans la sortie de commande, vérifiez la colonne Avail pour déterminer l’espace disque libre sur ce nœud.

    Exemple de sortie

    elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent
    Copy to Clipboard Toggle word wrap

  3. Augmentez l’espace disque sur tous les nœuds. Lorsque l’augmentation de l’espace disque n’est pas possible, essayez d’ajouter un nouveau nœud de données au cluster ou diminuez la politique de redondance totale des clusters.

  4. Afin de vérifier la redondance actuelle, exécutez la commande suivante: 

    $ oc -n openshift-logging get es elasticsearch \
  -o jsonpath='{.spec.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque vous utilisez une ressource ClusterLogging sur votre cluster, exécutez la commande suivante: 

    $ oc -n openshift-logging get cl \
  -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque la valeur de redondance du cluster est supérieure à la valeur SingleRedundancy, définissez-la sur la valeur SingleRedundancy et enregistrez ce changement.

  5. Lorsque les étapes précédentes ne règlent pas le problème, supprimez les anciens indices.

    1. Consultez l’état de tous les indices sur Elasticsearch en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
      Copy to Clipboard Toggle word wrap
    2. Identifiez un ancien index qui peut être supprimé.

    3. Effacer l’index en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name> -X DELETE
      Copy to Clipboard Toggle word wrap

  6. Continuez à libérer et à surveiller l’espace disque. Après que l’espace disque utilisé tombe en dessous de 90%, débloquez l’écriture sur ce nœud en exécutant la commande suivante: 

    $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=_all/_settings?pretty \
  -X PUT -d '{"index.blocks.read_only_allow_delete": null}'
    Copy to Clipboard Toggle word wrap

3.3.6. Elasticsearch JVM heap utilisation est élevé
Copier lien

La mémoire de tas du nœud Elasticsearch Java (JVM) utilisée est supérieure à 75%. Envisagez d’augmenter la taille du tas.

L’utilisation du CPU système sur le nœud est élevée. Cochez le CPU du nœud cluster. Envisagez d’allouer plus de ressources CPU au nœud.

3.3.8. Elasticsearch process CPU est élevé
Copier lien

L’utilisation du CPU de processus Elasticsearch sur le nœud est élevée. Cochez le CPU du nœud cluster. Envisagez d’allouer plus de ressources CPU au nœud.

3.3.9. L’espace disque Elasticsearch est faible
Copier lien

Elasticsearch devrait manquer d’espace disque dans les 6 prochaines heures en fonction de l’utilisation actuelle du disque. Appliquez la procédure suivante pour résoudre cette alerte.

Procédure

  1. Bénéficiez de l’espace disque du nœud Elasticsearch: 

    $ for pod in `oc -n openshift-logging get po -l component=elasticsearch -o jsonpath='{.items[*].metadata.name}'`; \
  do echo $pod; oc -n openshift-logging exec -c elasticsearch $pod \
  -- df -h /elasticsearch/persistent; done
    Copy to Clipboard Toggle word wrap

  2. Dans la sortie de commande, vérifiez la colonne Avail pour déterminer l’espace disque libre sur ce nœud.

    Exemple de sortie

    elasticsearch-cdm-kcrsda6l-1-586cc95d4f-h8zq8
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1     19G  522M   19G   3% /elasticsearch/persistent
elasticsearch-cdm-kcrsda6l-2-5b548fc7b-cwwk7
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme2n1     19G  522M   19G   3% /elasticsearch/persistent
elasticsearch-cdm-kcrsda6l-3-5dfc884d99-59tjw
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme3n1     19G  528M   19G   3% /elasticsearch/persistent
    Copy to Clipboard Toggle word wrap

  3. Augmentez l’espace disque sur tous les nœuds. Lorsque l’augmentation de l’espace disque n’est pas possible, essayez d’ajouter un nouveau nœud de données au cluster ou diminuez la politique de redondance totale des clusters.

  4. Afin de vérifier la redondance actuelle, exécutez la commande suivante: 

    $ oc -n openshift-logging get es elasticsearch -o jsonpath='{.spec.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque vous utilisez une ressource ClusterLogging sur votre cluster, exécutez la commande suivante: 

    $ oc -n openshift-logging get cl \
  -o jsonpath='{.items[*].spec.logStore.elasticsearch.redundancyPolicy}'
    Copy to Clipboard Toggle word wrap

    Lorsque la valeur de redondance du cluster est supérieure à la valeur SingleRedundancy, définissez-la sur la valeur SingleRedundancy et enregistrez ce changement.

  5. Lorsque les étapes précédentes ne règlent pas le problème, supprimez les anciens indices.

    1. Consultez l’état de tous les indices sur Elasticsearch en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME -- indices
      Copy to Clipboard Toggle word wrap
    2. Identifiez un ancien index qui peut être supprimé.

    3. Effacer l’index en exécutant la commande suivante: 

      $ oc exec -n openshift-logging -c elasticsearch $ES_POD_NAME \
  -- es_util --query=<elasticsearch_index_name> -X DELETE
      Copy to Clipboard Toggle word wrap

3.3.10. Elasticsearch FileDescriptor utilisation est élevé
Copier lien

En fonction des tendances actuelles d’utilisation, le nombre prévu de descripteurs de fichiers sur le nœud est insuffisant. Cochez la valeur de max_file_descriptors pour chaque nœud tel que décrit dans la documentation des Descripteurs de fichiers Elasticsearch.

3.4. Consulte le statut de Elasticsearch log store
Copier lien

Consultez l’état de l’opérateur OpenShift Elasticsearch et pour un certain nombre de composants Elasticsearch.

3.4.1. Consulte le statut de Elasticsearch log store
Copier lien

Le journal Elasticsearch vous permet d’afficher l’état de la boutique de journal Elasticsearch.

Conditions préalables

  • Le Red Hat OpenShift Logging Operator et OpenShift Elasticsearch Operator sont installés.

Procédure

  1. Changer le projet openshift-logging en exécutant la commande suivante: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Afficher l’état:

    1. Accédez au nom de l’instance du magasin de journal Elasticsearch en exécutant la commande suivante: 

      $ oc get Elasticsearch
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME            AGE
elasticsearch   5h9m
      Copy to Clipboard Toggle word wrap

    2. Bénéficiez de l’état de la boutique de journal Elasticsearch en exécutant la commande suivante: 

      $ oc get Elasticsearch <Elasticsearch-instance> -o yaml
      Copy to Clipboard Toggle word wrap

      À titre d’exemple: 

      $ oc get Elasticsearch elasticsearch -n openshift-logging -o yaml
      Copy to Clipboard Toggle word wrap

      Le produit comprend des informations similaires à ce qui suit:

      Exemple de sortie

      status:
      1 
      
  cluster:
      2 
      
    activePrimaryShards: 30
    activeShards: 60
    initializingShards: 0
    numDataNodes: 3
    numNodes: 3
    pendingTasks: 0
    relocatingShards: 0
    status: green
    unassignedShards: 0
  clusterHealth: ""
  conditions: []
      3 
      
  nodes:
      4 
      
  - deploymentName: elasticsearch-cdm-zjf34ved-1
    upgradeStatus: {}
  - deploymentName: elasticsearch-cdm-zjf34ved-2
    upgradeStatus: {}
  - deploymentName: elasticsearch-cdm-zjf34ved-3
    upgradeStatus: {}
  pods:
      5 
      
    client:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
    data:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
    master:
      failed: []
      notReady: []
      ready:
      - elasticsearch-cdm-zjf34ved-1-6d7fbf844f-sn422
      - elasticsearch-cdm-zjf34ved-2-dfbd988bc-qkzjz
      - elasticsearch-cdm-zjf34ved-3-c8f566f7c-t7zkt
  shardAllocationEnabled: all
      Copy to Clipboard Toggle word wrap

      1
      Dans la sortie, les champs d’état du cluster apparaissent dans la strophe d’état.
      2
      L’état de la boutique de journal Elasticsearch:
      • Le nombre de fragments primaires actifs.
      • Le nombre de fragments actifs.
      • Le nombre de fragments qui sont en train d’initialiser.
      • Le nombre de nœuds de journal Elasticsearch stocke des nœuds de données.
      • Le nombre total de nœuds de journal Elasticsearch.
      • Le nombre de tâches en attente.
      • Le statut du magasin de journal Elasticsearch: vert, rouge, jaune.
      • Le nombre de fragments non attribués.
      3
      Conditions de statut, si elles sont présentes. L’état de la boutique de journal Elasticsearch indique les raisons du programmeur si un pod n’a pas pu être placé. Les événements liés aux conditions suivantes sont indiqués:
      • Conteneur En attente pour le magasin de journal Elasticsearch et les conteneurs proxy.
      • Conteneur Terminé pour le magasin de journal Elasticsearch et les conteneurs proxy.
      • La pod est imprévue. En outre, une condition est affichée pour un certain nombre de problèmes; voir Exemple des messages de condition.
      4
      Les nœuds de journal Elasticsearch dans le cluster, avec upgradeStatus.
      5
      Le journal Elasticsearch stocke le client, les données et les pods maîtres dans le cluster, listés sous échec, pasReady, ou état prêt.
3.4.1.1. Exemple de messages de condition
Copier lien

Ce qui suit sont des exemples de messages de condition de la section État de l’instance Elasticsearch.

Le message d’état suivant indique qu’un nœud a dépassé le filigrane faible configuré, et aucun fragment ne sera attribué à ce nœud. 

status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T15:57:22Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be not
        be allocated on this node.
      reason: Disk Watermark Low
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}
Copy to Clipboard Toggle word wrap

Le message d’état suivant indique qu’un nœud a dépassé le filigrane élevé configuré, et les éclats seront déplacés vers d’autres nœuds. 

status:
  nodes:
  - conditions:
    - lastTransitionTime: 2019-03-15T16:04:45Z
      message: Disk storage usage for node is 27.5gb (36.74%). Shards will be relocated
        from this node.
      reason: Disk Watermark High
      status: "True"
      type: NodeStorage
    deploymentName: example-elasticsearch-cdm-0-1
    upgradeStatus: {}
Copy to Clipboard Toggle word wrap

Le message d’état suivant indique que le sélecteur de nœuds de journal Elasticsearch dans la ressource personnalisée (CR) ne correspond à aucun nœud dans le cluster: 

status:
    nodes:
    - conditions:
      - lastTransitionTime: 2019-04-10T02:26:24Z
        message: '0/8 nodes are available: 8 node(s) didn''t match node selector.'
        reason: Unschedulable
        status: "True"
        type: Unschedulable
Copy to Clipboard Toggle word wrap

Le message d’état suivant indique que le magasin de journal Elasticsearch CR utilise une revendication de volume persistant inexistante (PVC). 

status:
   nodes:
   - conditions:
     - last Transition Time:  2019-04-10T05:55:51Z
       message:               pod has unbound immediate PersistentVolumeClaims (repeated 5 times)
       reason:                Unschedulable
       status:                True
       type:                  Unschedulable
Copy to Clipboard Toggle word wrap

Le message d’état suivant indique que votre cluster de log Store Elasticsearch n’a pas assez de nœuds pour soutenir la stratégie de redondance. 

status:
  clusterHealth: ""
  conditions:
  - lastTransitionTime: 2019-04-17T20:01:31Z
    message: Wrong RedundancyPolicy selected. Choose different RedundancyPolicy or
      add more nodes with data roles
    reason: Invalid Settings
    status: "True"
    type: InvalidRedundancy
Copy to Clipboard Toggle word wrap

Ce message d’état indique que votre cluster a trop de nœuds de plan de contrôle: 

status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: '2019-04-17T20:12:34Z'
      message: >-
        Invalid master nodes count. Please ensure there are no more than 3 total
        nodes with master roles
      reason: Invalid Settings
      status: 'True'
      type: InvalidMasters
Copy to Clipboard Toggle word wrap

Le message d’état suivant indique que le stockage Elasticsearch ne prend pas en charge le changement que vous avez essayé d’effectuer.

À titre d’exemple: 

status:
  clusterHealth: green
  conditions:
    - lastTransitionTime: "2021-05-07T01:05:13Z"
      message: Changing the storage structure for a custom resource is not supported
      reason: StorageStructureChangeIgnored
      status: 'True'
      type: StorageStructureChangeIgnored
Copy to Clipboard Toggle word wrap

Les champs raison et type spécifient le type de changement non pris en charge:

StorageClassNameChangeIgnored
Changement non pris en charge du nom de la classe de stockage.
StorageSizeChangeIgnored
Changez la taille de stockage non prise en charge.
StorageStructureChangeIgnored

Changement non pris en charge entre les structures de stockage éphémères et persistantes.

Important

Lorsque vous essayez de configurer le ClusterLogging CR pour passer d’un stockage éphémère à un stockage persistant, l’opérateur OpenShift Elasticsearch crée une revendication de volume persistant (PVC) mais ne crée pas de volume persistant (PV). Afin d’effacer le statut StorageStructureChangeIgnored, vous devez revenir sur le ClusterLogging CR et supprimer le PVC.

3.4.2. Affichage de l’état des composants de log store
Copier lien

Il est possible d’afficher l’état d’un certain nombre de composants du log store.

Indices Elasticsearch

Consultez l’état des indices Elasticsearch.

  1. Demandez le nom d’un pod Elasticsearch: 

    $ oc get pods --selector component=elasticsearch -o name
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n
pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7
    Copy to Clipboard Toggle word wrap

  2. Bénéficiez de l’état des indices: 

    $ oc exec elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -- indices
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    Defaulting container name to elasticsearch.
Use 'oc describe pod/elasticsearch-cdm-4vjor49p-2-6d4d7db474-q2w7z -n openshift-logging' to see all of the containers in this pod.

green  open   infra-000002                                                     S4QANnf1QP6NgCegfnrnbQ   3   1     119926            0        157             78
green  open   audit-000001                                                     8_EQx77iQCSTzFOXtxRqFw   3   1          0            0          0              0
green  open   .security                                                        iDjscH7aSUGhIdq0LheLBQ   1   1          5            0          0              0
green  open   .kibana_-377444158_kubeadmin                                     yBywZ9GfSrKebz5gWBZbjw   3   1          1            0          0              0
green  open   infra-000001                                                     z6Dpe__ORgiopEpW6Yl44A   3   1     871000            0        874            436
green  open   app-000001                                                       hIrazQCeSISewG3c2VIvsQ   3   1       2453            0          3              1
green  open   .kibana_1                                                        JCitcBMSQxKOvIq6iQW6wg   1   1          0            0          0              0
green  open   .kibana_-1595131456_user1                                        gIYFIEGRRe-ka0W3okS-mQ   3   1          1            0          0              0
    Copy to Clipboard Toggle word wrap

Log store pods

Il est possible d’afficher l’état des pods qui hébergent le log store.

  1. Donnez le nom d’un pod: 

    $ oc get pods --selector component=elasticsearch -o name
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    pod/elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
pod/elasticsearch-cdm-1godmszn-2-5769cf-9ms2n
pod/elasticsearch-cdm-1godmszn-3-f66f7d-zqkz7
    Copy to Clipboard Toggle word wrap

  2. Bénéficiez du statut d’un pod: 

    $ oc describe pod elasticsearch-cdm-1godmszn-1-6f8495-vp4lw
    Copy to Clipboard Toggle word wrap

    Le produit comprend les informations suivantes sur l’état d’avancement:

    Exemple de sortie

    ....
Status:             Running

....

Containers:
  elasticsearch:
    Container ID:   cri-o://b7d44e0a9ea486e27f47763f5bb4c39dfd2
    State:          Running
      Started:      Mon, 08 Jun 2020 10:17:56 -0400
    Ready:          True
    Restart Count:  0
    Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3

....

  proxy:
    Container ID:  cri-o://3f77032abaddbb1652c116278652908dc01860320b8a4e741d06894b2f8f9aa1
    State:          Running
      Started:      Mon, 08 Jun 2020 10:18:38 -0400
    Ready:          True
    Restart Count:  0

....

Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True

....

Events:          <none>
    Copy to Clipboard Toggle word wrap

Configuration de déploiement de pod de stockage log

L’état de la configuration de déploiement de log store peut être affiché.

  1. Bénéficiez du nom d’une configuration de déploiement: 

    $ oc get deployment --selector component=elasticsearch -o name
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    deployment.extensions/elasticsearch-cdm-1gon-1
deployment.extensions/elasticsearch-cdm-1gon-2
deployment.extensions/elasticsearch-cdm-1gon-3
    Copy to Clipboard Toggle word wrap

  2. Bénéficiez de l’état de configuration de déploiement: 

    $ oc describe deployment elasticsearch-cdm-1gon-1
    Copy to Clipboard Toggle word wrap

    Le produit comprend les informations suivantes sur l’état d’avancement:

    Exemple de sortie

    ....
  Containers:
   elasticsearch:
    Image:      registry.redhat.io/openshift-logging/elasticsearch6-rhel8
    Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3

....

Conditions:
  Type           Status   Reason
  ----           ------   ------
  Progressing    Unknown  DeploymentPaused
  Available      True     MinimumReplicasAvailable

....

Events:          <none>
    Copy to Clipboard Toggle word wrap

Ensemble de réplica de log store

Il est possible d’afficher l’état de l’ensemble des répliques de log store.

  1. Demandez le nom d’un ensemble de répliques: 

    $ oc get replicaSet --selector component=elasticsearch -o name

replicaset.extensions/elasticsearch-cdm-1gon-1-6f8495
replicaset.extensions/elasticsearch-cdm-1gon-2-5769cf
replicaset.extensions/elasticsearch-cdm-1gon-3-f66f7d
    Copy to Clipboard Toggle word wrap

  2. Bénéficiez de l’état de l’ensemble de réplique: 

    $ oc describe replicaSet elasticsearch-cdm-1gon-1-6f8495
    Copy to Clipboard Toggle word wrap

    Le produit comprend les informations suivantes sur l’état d’avancement:

    Exemple de sortie

    ....
  Containers:
   elasticsearch:
    Image:      registry.redhat.io/openshift-logging/elasticsearch6-rhel8@sha256:4265742c7cdd85359140e2d7d703e4311b6497eec7676957f455d6908e7b1c25
    Readiness:  exec [/usr/share/elasticsearch/probe/readiness.sh] delay=10s timeout=30s period=5s #success=1 #failure=3

....

Events:          <none>
    Copy to Clipboard Toggle word wrap

3.4.3. État du cluster Elasticsearch
Copier lien

Dans la section Observe du gestionnaire de cluster OpenShift, un tableau de bord affiche l’état du cluster Elasticsearch.

Afin d’obtenir l’état du cluster OpenShift Elasticsearch, visitez le tableau de bord dans la section Observer du gestionnaire de cluster OpenShift à &lt;cluster_url&gt;/monitoring/dashboards/grafana-dashboard-cluster-logging.

Champs de statut Elasticsearch

eo_elasticsearch_cr_cluster_management_state

Indique si le cluster Elasticsearch est dans un état géré ou non géré. À titre d’exemple: 

eo_elasticsearch_cr_cluster_management_state{state="managed"} 1
eo_elasticsearch_cr_cluster_management_state{state="unmanaged"} 0
Copy to Clipboard Toggle word wrap
eo_elasticsearch_cr_restart_total

Indique le nombre de fois que les nœuds Elasticsearch ont redémarré pour les redémarrages de certificats, les redémarrages roulants ou les redémarrages programmés. À titre d’exemple: 

eo_elasticsearch_cr_restart_total{reason="cert_restart"} 1
eo_elasticsearch_cr_restart_total{reason="rolling_restart"} 1
eo_elasticsearch_cr_restart_total{reason="scheduled_restart"} 3
Copy to Clipboard Toggle word wrap
es_index_namespaces_total

Affiche le nombre total d’espaces de noms d’index Elasticsearch. À titre d’exemple: 

Total number of Namespaces.
es_index_namespaces_total 5
Copy to Clipboard Toggle word wrap
es_index_document_count

Affiche le nombre d’enregistrements pour chaque espace de noms. À titre d’exemple: 

es_index_document_count{namespace="namespace_1"} 25
es_index_document_count{namespace="namespace_2"} 10
es_index_document_count{namespace="namespace_3"} 5
Copy to Clipboard Toggle word wrap

Les champs "Secret Elasticsearch sont manquants ou vides"

Lorsque Elasticsearch manque les fichiers admin-cert, admin-key, logging-es.crt ou logging-es.key, le tableau de bord affiche un message d’état similaire à l’exemple suivant: 

message": "Secret \"elasticsearch\" fields are either missing or empty: [admin-cert, admin-key, logging-es.crt, logging-es.key]",
"reason": "Missing Required Secrets",
Copy to Clipboard Toggle word wrap

Chapitre 4. À propos de Logging
Copier lien

En tant qu’administrateur de cluster, vous pouvez déployer l’enregistrement sur un Red Hat OpenShift Service sur AWS cluster, et l’utiliser pour collecter et agréger les journaux d’audit système de nœuds, les journaux de conteneurs d’applications et les journaux d’infrastructure. Il est possible d’envoyer les journaux vers les sorties de journal que vous avez choisies, y compris le stockage de journaux géré par Red Hat. Il est également possible de visualiser les données de votre journal dans le Red Hat OpenShift Service sur la console web AWS ou la console Web Kibana, en fonction de votre solution de stockage de log déployée.

Note

La console Web Kibana est maintenant désapprouvée est prévue pour être supprimée dans une prochaine version de journalisation.

Le service OpenShift de Red Hat sur les administrateurs de cluster AWS peut déployer la journalisation à l’aide d’opérateurs. À titre d’information, voir xref :././observability/logging/cluster-logging-deploying.adoc#cluster-logging-déploying[Installing logging].

Les opérateurs sont responsables du déploiement, de la mise à niveau et de la maintenance de l’enregistrement. Après l’installation des opérateurs, vous pouvez créer une ressource personnalisée ClusterLogging (CR) pour programmer les pods de journalisation et d’autres ressources nécessaires pour prendre en charge la journalisation. Il est également possible de créer un ClusterLogForwarder CR pour spécifier quels journaux sont recueillis, comment ils sont transformés et où ils sont transférés.

Note

Étant donné que le Red Hat OpenShift Service interne sur AWS Elasticsearch log store ne fournit pas de stockage sécurisé pour les journaux d’audit, les journaux d’audit ne sont pas stockés dans l’instance interne Elasticsearch par défaut. Lorsque vous souhaitez envoyer les journaux d’audit dans le journal interne Elasticsearch par défaut, par exemple pour afficher les journaux d’audit dans Kibana, vous devez utiliser l’API Log Forwarding comme décrit dans xref :.././observability/logging/log_storage/logging-config-es-store.adoc#cluster-logging-elasticsearch-audit_logging-config-es-store[Forward les journaux d’audit dans le log store].

4.1. Architecture d’enregistrement
Copier lien

Les principales composantes de l’exploitation forestière sont:

Collectionneur

Le collectionneur est un daemonset qui déploie des pods dans chaque Red Hat OpenShift Service sur AWS. Il collecte les données de log de chaque nœud, transforme les données et les transmet aux sorties configurées. Il est possible d’utiliser le collectionneur Vecteur ou l’ancien collectionneur Fluentd.

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.

Log Store

Le log store stocke les données de log pour analyse et est la sortie par défaut pour l’expéditeur de journal. Il est possible d’utiliser le log store LokiStack par défaut, l’ancien magasin de journal Elasticsearch ou les journaux vers d’autres magasins de journaux externes.

Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

La visualisation

Il est possible d’utiliser un composant d’interface utilisateur pour visualiser une représentation visuelle de vos données de journal. L’interface utilisateur fournit une interface graphique pour rechercher, interroger et afficher les journaux stockés. Le Red Hat OpenShift Service sur AWS console Web UI est fourni en activant le Red Hat OpenShift Service sur le plugin de console AWS.

Note

La console Web Kibana est maintenant désapprouvée est prévue pour être supprimée dans une prochaine version de journalisation.

L’enregistrement collecte les journaux de conteneurs et les journaux de nœuds. Ceux-ci sont classés en types:

Journaux des applications
Journaux de conteneurs générés par les applications utilisateur s’exécutant dans le cluster, à l’exception des applications de conteneurs d’infrastructure.
Journaux de l’infrastructure
Journaux de conteneurs générés par des espaces de noms d’infrastructure: openshift*, kube* ou par défaut, ainsi que des messages journalisés à partir de nœuds.
Journaux d’audit
Journaux générés par audit, le système d’audit des nœuds, qui sont stockés dans le fichier /var/log/audit/audit.log, et les journaux des services audités, kube-apiserver, openshift-apiserver, ainsi que le projet ovn si activé.

4.2. À propos du déploiement de l’enregistrement
Copier lien

Les administrateurs peuvent déployer la journalisation en utilisant le service Red Hat OpenShift sur la console web AWS ou l’OpenShift CLI (oc) pour installer les opérateurs de journalisation. Les opérateurs sont responsables du déploiement, de la mise à niveau et de la maintenance de l’enregistrement.

Les administrateurs et les développeurs d’applications peuvent afficher les journaux des projets auxquels ils ont accès.

4.2.1. Journalisation des ressources personnalisées
Copier lien

Il est possible de configurer votre déploiement de journalisation avec des fichiers YAML de ressources personnalisées (CR) implémentés par chaque opérateur.

L’opérateur de journalisation de Red Hat OpenShift:

  • ClusterLogging (CL) - Après l’installation des opérateurs, vous créez une ressource personnalisée ClusterLogging (CR) pour programmer les pods de journalisation et d’autres ressources nécessaires à la prise en charge de la journalisation. Le ClusterLogging CR déploie le collecteur et l’expéditeur, qui sont actuellement tous deux implémentés par un daemonset fonctionnant sur chaque nœud. Le Red Hat OpenShift Logging Operator surveille le ClusterLogging CR et ajuste le déploiement de la journalisation en conséquence.
  • ClusterLogForwarder (CLF) - Génère la configuration du collecteur pour transférer les journaux par configuration utilisateur.

Loki Opérateur:

  • LokiStack - Contrôle le cluster Loki en tant que log store et le proxy Web avec Red Hat OpenShift Service sur l’intégration d’authentification AWS pour appliquer la multi-tenance.

L’opérateur OpenShift Elasticsearch:

Note

Ces CR sont générés et gérés par l’opérateur OpenShift Elasticsearch. Les modifications manuelles ne peuvent pas être effectuées sans avoir été écrasées par l’opérateur.

  • Elasticsearch - Configurez et déployez une instance Elasticsearch en tant que log store par défaut.
  • Kibana - Configurez et déployez l’instance Kibana pour rechercher, interroger et afficher les journaux.

4.2.2. Exigences en matière d’exploitation forestière
Copier lien

L’hébergement de votre propre pile de journalisation nécessite une grande quantité de ressources de calcul et de stockage, qui peuvent dépendre de votre quota de service cloud. Les besoins en ressources de calcul peuvent commencer à 48 Go ou plus, tandis que l’exigence de stockage peut être aussi grande que 1600 Go ou plus. La pile de journalisation s’exécute sur vos nœuds de travail, ce qui réduit votre ressource de charge de travail disponible. Avec ces considérations, l’hébergement de votre propre pile de journalisation augmente les coûts d’exploitation de votre cluster.

À titre d’information, voir xref :./../observability/logging/log_collection_forwarding/log-forwarding.adoc#about-log-collection_log-forwarding[En ce qui concerne la collecte et la transmission des journaux].

La connexion JSON vous permet de configurer l’API Log Forwarding pour analyser les chaînes JSON dans un objet structuré. Il est possible d’effectuer les tâches suivantes:

  • Analyser les journaux JSON
  • Configurer les données de journal JSON pour Elasticsearch
  • Envoyer les journaux JSON à la boutique de journal Elasticsearch

Le Red Hat OpenShift Service sur AWS Event Router est un pod qui regarde les événements Kubernetes et les enregistre pour la collecte par Red Hat OpenShift Service sur AWS Logging. Il faut déployer manuellement le routeur d’événements.

À titre d’information, voir xref :./../observability/logging/log_collection_forwarding/cluster-logging-eventrouter.adoc#cluster-logging-eventrouter[À propos de la collecte et du stockage des événements Kubernetes].

Il est possible de résoudre les problèmes de journalisation en effectuant les tâches suivantes:

  • Affichage du statut de journalisation
  • Affichez le statut de log store
  • Comprendre les alertes de journalisation
  • Collecte de données d’enregistrement pour Red Hat Support
  • Dépannage des alertes critiques

4.2.6. À propos des champs d’exportation
Copier lien

Le système d’exploitation forestière exporte des champs. Les champs exportés sont présents dans les registres des journaux et sont disponibles pour la recherche chez Elasticsearch et Kibana.

À titre d’information, voir xref :./../observability/logging/cluster-logging-exported-fields.adoc#cluster-logging-exported-fields[À propos des champs d’exportation].

4.2.7. À propos du routage des événements
Copier lien

Le routeur d’événements est un pod qui regarde Red Hat OpenShift Service sur les événements AWS afin qu’ils puissent être collectés par enregistrement. Le routeur de l’événement recueille les événements de tous les projets et les écrit à STDOUT. Fluentd collecte ces événements et les transmet dans l’instance Red Hat OpenShift sur AWS Elasticsearch. Elasticsearch indexe les événements à l’indice infra.

Il faut déployer manuellement le routeur d’événements.

À titre d’information, voir xref :./../observability/logging/log_collection_forwarding/cluster-logging-eventrouter.adoc#cluster-logging-eventrouter[Collecter et stocker les événements Kubernetes].

Chapitre 5. Installation de Logging
Copier lien

Les opérateurs AWS utilisent des ressources personnalisées (CR) pour gérer les applications et leurs composants. La configuration et les paramètres de haut niveau sont fournis par l’utilisateur dans un CR. L’opérateur traduit les directives de haut niveau en actions de bas niveau, basées sur les meilleures pratiques intégrées dans la logique de l’opérateur. La définition de ressource personnalisée (CRD) définit un CR et répertorie toutes les configurations disponibles pour les utilisateurs de l’opérateur. L’installation d’un opérateur crée les CRD, qui sont ensuite utilisés pour générer des CR.

Important

Après l’opérateur de journalisation, vous devez installer l’opérateur de journalisation OpenShift Red Hat.

Déployez l’enregistrement en installant l’opérateur Loki ou l’opérateur OpenShift Elasticsearch pour gérer votre log store, suivi par l’opérateur de journalisation Red Hat OpenShift pour gérer les composants de la journalisation. Il est possible d’utiliser le service Red Hat OpenShift sur la console web AWS ou le service Red Hat OpenShift sur AWS CLI pour installer ou configurer l’enregistrement.

Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

Astuce

Alternativement, vous pouvez appliquer tous les exemples d’objets.

Il est possible d’utiliser le service Red Hat OpenShift sur la console web AWS pour installer les opérateurs OpenShift Elasticsearch et Red Hat OpenShift Logging. Elasticsearch est une application à forte intensité de mémoire. Le service Red Hat OpenShift sur AWS installe par défaut trois nœuds Elasticsearch avec des requêtes de mémoire et des limites de 16 Go. Cet ensemble initial de trois Red Hat OpenShift Service sur les nœuds AWS pourrait ne pas avoir assez de mémoire pour exécuter Elasticsearch dans votre cluster. Lorsque vous rencontrez des problèmes de mémoire liés à Elasticsearch, ajoutez plus de nœuds Elasticsearch à votre cluster plutôt que d’augmenter la mémoire sur les nœuds existants.

Note

Dans le cas où vous ne souhaitez pas utiliser le log store Elasticsearch par défaut, vous pouvez supprimer les composants internes de visualisation Elasticsearch logStore et Kibana de la ressource personnalisée ClusterLogging (CR). La suppression de ces composants est facultative, mais permet d’économiser des ressources.

Conditions préalables

  • Assurez-vous que vous avez le stockage persistant nécessaire pour Elasticsearch. A noter que chaque nœud Elasticsearch nécessite son propre volume de stockage.

    Note

    Lorsque vous utilisez un volume local pour le stockage persistant, n’utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: bloc dans l’objet LocalVolume. Elasticsearch ne peut pas utiliser les volumes de blocs bruts.

Procédure

Installer l’opérateur OpenShift Elasticsearch et Red Hat OpenShift Logging Operator à l’aide du service Red Hat OpenShift sur la console web AWS:

  1. Installez l’opérateur OpenShift Elasticsearch:

    1. Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → OperatorHub.
    2. Choisissez OpenShift Elasticsearch Operator dans la liste des opérateurs disponibles, puis cliquez sur Installer.
    3. Assurez-vous que tous les espaces de noms du cluster sont sélectionnés sous Mode d’installation.

    4. Assurez-vous que l’openshift-operators-redhat est sélectionné sous la rubrique Installed Namespace.

      Il faut spécifier l’espace de noms openshift-operators-redhat. L’espace de noms openshift-operators peut contenir des opérateurs communautaires, qui ne sont pas fiables et pourraient publier une métrique avec le même nom qu’un service OpenShift Red Hat sur AWS, ce qui provoquerait des conflits.

    5. Activer l’opérateur recommande la surveillance des clusters sur cet espace de noms.

      Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-operators-redhat.

    6. Choisissez stable-5.y comme canal de mise à jour.

      Note

      Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

    7. Choisissez une stratégie d’approbation.

      • La stratégie automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible.
      • La stratégie du Manuel exige qu’un utilisateur ayant les informations d’identification appropriées approuve la mise à jour de l’opérateur.
    8. Cliquez sur Install.
    9. Assurez-vous que l’opérateur OpenShift Elasticsearch est installé en passant à la page Opérateurs installés.
    10. Assurez-vous que l’opérateur OpenShift Elasticsearch est répertorié dans tous les projets ayant un statut de Succès.

  2. Installez l’opérateur de journalisation Red Hat OpenShift:

    1. Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → OperatorHub.
    2. Choisissez Red Hat OpenShift Logging dans la liste des opérateurs disponibles, puis cliquez sur Installer.
    3. Assurez-vous que l’espace de noms A spécifique sur le cluster est sélectionné sous Mode d’installation.
    4. Assurez-vous que l’espace de noms recommandé par l’opérateur est ouvert de connexion sous Namespace installé.

    5. Activer l’opérateur recommande la surveillance des clusters sur cet espace de noms.

      Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-logging.

    6. Choisissez stable-5.y comme canal de mise à jour.

    7. Choisissez une stratégie d’approbation.

      • La stratégie automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible.
      • La stratégie du Manuel exige qu’un utilisateur ayant les informations d’identification appropriées approuve la mise à jour de l’opérateur.
    8. Cliquez sur Install.
    9. Assurez-vous que l’opérateur de journalisation Red Hat OpenShift est installé en passant à la page Opérateurs installés →

    10. Assurez-vous que Red Hat OpenShift Logging est listé dans le projet openshift-logging avec un statut de Succeed.

      Dans le cas où l’opérateur n’apparaît pas comme installé, il est possible de résoudre les problèmes suivants:

      • Basculez sur la page Opérateurs installés → Installed Operators et inspectez la colonne État pour détecter toute erreur ou défaillance.
      • Basculez sur la page Charges de travail → Pods et vérifiez les journaux de tous les pods du projet openshift-logging qui sont des problèmes de signalement.

  3. Créer une instance OpenShift Logging:

    1. Basculez à la page Administration → Définitions de ressources personnalisées.
    2. Dans la page Définitions de ressources personnalisées, cliquez sur ClusterLogging.
    3. Dans la page Détails de la définition des ressources personnalisées, sélectionnez Afficher les instances dans le menu Actions.

    4. Dans la page ClusterLoggings, cliquez sur Créer ClusterLogging.

      Il vous faudra peut-être actualiser la page pour charger les données.

    5. Dans le champ YAML, remplacer le code par ce qui suit:

      Note

      Cette configuration OpenShift Logging par défaut devrait prendre en charge un large éventail d’environnements. Examinez les sujets sur le réglage et la configuration des composants d’enregistrement pour obtenir des informations sur les modifications que vous pouvez apporter à votre cluster OpenShift Logging. 

      apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
      1 
      
  namespace: openshift-logging
spec:
  managementState: Managed
      2 
      
  logStore:
    type: elasticsearch
      3 
      
    retentionPolicy:
      4 
      
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
      5 
      
      storage:
        storageClassName: <storage_class_name>
      6 
      
        size: 200G
      resources:
      7 
      
          limits:
            memory: 16Gi
          requests:
            memory: 16Gi
      proxy:
      8 
      
        resources:
          limits:
            memory: 256Mi
          requests:
            memory: 256Mi
      redundancyPolicy: SingleRedundancy
  visualization:
    type: kibana
      9 
      
    kibana:
      replicas: 1
  collection:
    type: fluentd
      10 
      
    fluentd: {}
      Copy to Clipboard Toggle word wrap
      1
      Le nom doit être instance.
      2
      L’état de gestion OpenShift Logging. Dans certains cas, si vous modifiez les valeurs par défaut OpenShift Logging, vous devez définir ceci sur Ungaged. Cependant, un déploiement non géré ne reçoit pas de mises à jour tant qu’OpenShift Logging n’est pas placé dans un état géré.
      3
      Configuration d’Elasticsearch. En utilisant le CR, vous pouvez configurer la stratégie de réplication shard et le stockage persistant.
      4
      Indiquez la durée pendant laquelle Elasticsearch doit conserver chaque source de journal. Entrez un entier et une désignation de temps: semaines (w), heures (h/H), minutes(m) et secondes(s). À titre d’exemple, 7d pendant sept jours. Les journaux plus anciens que le maxAge sont supprimés. Il faut spécifier une stratégie de rétention pour chaque source de journal ou les indices Elasticsearch ne seront pas créés pour cette source.
      5
      Indiquez le nombre de nœuds Elasticsearch. Consultez la note qui suit cette liste.
      6
      Entrez le nom d’une classe de stockage existante pour le stockage Elasticsearch. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Dans le cas où vous ne spécifiez pas une classe de stockage, OpenShift Logging utilise le stockage éphémère.
      7
      Indiquez les requêtes CPU et mémoire pour Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut qui devraient être suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 16Gi pour la requête mémoire et 1 pour la requête CPU.
      8
      Indiquez les requêtes CPU et mémoire pour le proxy Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut qui devraient être suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 256Mi pour la requête mémoire et 100m pour la requête CPU.
      9
      Configuration de Kibana. En utilisant le CR, vous pouvez mettre à l’échelle Kibana pour la redondance et configurer le CPU et la mémoire pour vos nœuds Kibana. Consultez Configuring the log visualizer pour plus d’informations.
      10
      Configuration de Fluentd. En utilisant le CR, vous pouvez configurer le CPU Fluentd et les limites de mémoire. En savoir plus, voir « Configuring Fluentd ».
      Note

      Le nombre maximum de nœuds maîtres est de trois. Lorsque vous spécifiez un nodeCount supérieur à 3, Red Hat OpenShift Service sur AWS crée trois nœuds Elasticsearch qui sont des nœuds éligibles au Master, avec les rôles de maître, de client et de données. Les nœuds Elasticsearch supplémentaires sont créés en tant que nœuds de données uniquement, en utilisant des rôles de client et de données. Les nœuds maîtres effectuent des actions à l’échelle du cluster, telles que la création ou la suppression d’un index, l’allocation de fragments et le suivi des nœuds. Les nœuds de données conservent les fragments et effectuent des opérations liées aux données telles que CRUD, recherche et agrégations. Les opérations liées aux données sont intensives en E/S, en mémoire et en CPU. Il est important de surveiller ces ressources et d’ajouter d’autres nœuds de données si les nœuds actuels sont surchargés.

      Ainsi, si nodeCount=4, les nœuds suivants sont créés: 

      $ oc get deployment
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      cluster-logging-operator-66f77ffccb-ppzbg       1/1    Running 0 7m
elasticsearch-cd-tuhduuw-1-f5c885dbf-dlqws      1/1    Running 0 2m4s
elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2    Running 0 2m40s
elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2    Running 0 2m36s
elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2    Running 0 2m4s
      Copy to Clipboard Toggle word wrap

    6. Cliquez sur Create. Cela crée les composants de journalisation, la ressource et les composants personnalisés Elasticsearch, ainsi que l’interface Kibana.

  4. Contrôlez l’installation:

    1. Basculez sur la page Charges de travail → Pods.

    2. Choisissez le projet openshift-logging.

      Il faut voir plusieurs pods pour OpenShift Logging, Elasticsearch, votre collectionneur et Kibana similaires à la liste suivante:

      Exemple de sortie

      cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
collector-587vb                                   1/1     Running   0          2m26s
collector-7mpb9                                   1/1     Running   0          2m30s
collector-flm6j                                   1/1     Running   0          2m33s
collector-gn4rn                                   1/1     Running   0          2m26s
collector-nlgb6                                   1/1     Running   0          2m30s
collector-snpkt                                   1/1     Running   0          2m28s
kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s
      Copy to Clipboard Toggle word wrap

Elasticsearch est une application à forte intensité de mémoire. Le service Red Hat OpenShift sur AWS installe par défaut trois nœuds Elasticsearch avec des requêtes de mémoire et des limites de 16 Go. Cet ensemble initial de trois Red Hat OpenShift Service sur les nœuds AWS pourrait ne pas avoir assez de mémoire pour exécuter Elasticsearch dans votre cluster. Lorsque vous rencontrez des problèmes de mémoire liés à Elasticsearch, ajoutez plus de nœuds Elasticsearch à votre cluster plutôt que d’augmenter la mémoire sur les nœuds existants.

Conditions préalables

  • Assurez-vous que vous avez le stockage persistant nécessaire pour Elasticsearch. A noter que chaque nœud Elasticsearch nécessite son propre volume de stockage.

    Note

    Lorsque vous utilisez un volume local pour le stockage persistant, n’utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: bloc dans l’objet LocalVolume. Elasticsearch ne peut pas utiliser les volumes de blocs bruts.

Procédure

  1. Créer un objet Namespace pour l’opérateur OpenShift Elasticsearch:

    Exemple d’objet Namespace

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-operators-redhat
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true"
    2
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat. L’espace de noms openshift-operators peut contenir des opérateurs communautaires, qui ne sont pas fiables et pourraient publier une métrique avec le même nom qu’un service OpenShift Red Hat sur AWS, ce qui provoquerait des conflits.
    2
    La valeur de chaîne qui spécifie l’étiquette comme indiqué pour s’assurer que la surveillance du cluster gratte l’espace de noms openshift-operators-redhat.

  2. Appliquez l’objet Namespace en exécutant la commande suivante: 

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

  3. Créer un objet Namespace pour l’opérateur de journalisation OpenShift Red Hat:

    Exemple d’objet Namespace

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true"
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier openshift-logging comme espace de noms pour la journalisation des versions 5.7 et antérieures. Dans l’enregistrement 5.8 et plus tard, vous pouvez utiliser n’importe quel espace de noms.

  4. Appliquez l’objet Namespace en exécutant la commande suivante: 

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

  5. Créer un objet OperatorGroup pour l’opérateur OpenShift Elasticsearch:

    Exemple d’objet OperatorGroup

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-operators-redhat
  namespace: openshift-operators-redhat
    1 
    
spec: {}
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat.

  6. Appliquez l’objet OperatorGroup en exécutant la commande suivante: 

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

  7. Créer un objet d’abonnement pour abonner un espace de noms à l’opérateur OpenShift Elasticsearch:

    Note

    Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

    Exemple d’objet d’abonnement

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: elasticsearch-operator
  namespace: openshift-operators-redhat
    1 
    
spec:
  channel: <channel>
    2 
    
  installPlanApproval: Automatic
    3 
    
  source: redhat-operators
    4 
    
  sourceNamespace: openshift-marketplace
  name: elasticsearch-operator
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat.
    2
    Indiquez stable, ou stable-<x.y> comme canal.
    3
    Automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible. Le manuel exige qu’un utilisateur avec les informations d’identification appropriées approuve la mise à jour de l’opérateur.
    4
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également appelé cluster déconnecté, spécifiez le nom de l’objet CatalogSource que vous avez créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM)

  8. Appliquer l’abonnement en exécutant la commande suivante: 

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

  9. Contrôlez l’installation de l’opérateur en exécutant la commande suivante: 

    $ oc get csv --all-namespaces
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
default                                            elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
kube-node-lease                                    elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
kube-public                                        elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
kube-system                                        elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-apiserver-operator                       elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-apiserver                                elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-authentication-operator                  elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-authentication                           elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-cloud-controller-manager-operator        elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-cloud-controller-manager                 elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
openshift-cloud-credential-operator                elasticsearch-operator.v5.8.3   OpenShift Elasticsearch Operator   5.8.3            elasticsearch-operator.v5.8.2   Succeeded
    Copy to Clipboard Toggle word wrap

  10. Créer un objet OperatorGroup pour l’opérateur de journalisation Red Hat OpenShift:

    Exemple d’objet OperatorGroup

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
    1 
    
spec:
  targetNamespaces:
  - openshift-logging
    2
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier openshift-logging comme espace de noms pour la journalisation des versions 5.7 et antérieures. Dans l’enregistrement 5.8 et plus tard, vous pouvez utiliser n’importe quel espace de noms.
    2
    Il faut spécifier openshift-logging comme espace de noms pour la journalisation des versions 5.7 et antérieures. Dans l’enregistrement 5.8 et plus tard, vous pouvez utiliser n’importe quel espace de noms.

  11. Appliquez l’objet OperatorGroup en exécutant la commande suivante: 

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

  12. Créez un objet d’abonnement pour souscrire l’espace de noms à l’opérateur de journalisation Red Hat OpenShift:

    Exemple d’objet d’abonnement

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
    1 
    
spec:
  channel: stable
    2 
    
  name: cluster-logging
  source: redhat-operators
    3 
    
  sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-logging pour la journalisation des versions 5.7 et antérieures. Lors de l’enregistrement des versions 5.8 et ultérieures, vous pouvez utiliser n’importe quel espace de noms.
    2
    Indiquez stable ou stable-x.y comme canal.
    3
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également appelé cluster déconnecté, spécifiez le nom de l’objet CatalogSource que vous avez créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM).

  13. Appliquez l’objet d’abonnement en exécutant la commande suivante: 

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

  14. Créer un objet ClusterLogging en tant que fichier YAML:

    Exemple ClusterLogging objet

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
    1 
    
  namespace: openshift-logging
spec:
  managementState: Managed
    2 
    
  logStore:
    type: elasticsearch
    3 
    
    retentionPolicy:
    4 
    
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
    5 
    
      storage:
        storageClassName: <storage_class_name>
    6 
    
        size: 200G
      resources:
    7 
    
          limits:
            memory: 16Gi
          requests:
            memory: 16Gi
      proxy:
    8 
    
        resources:
          limits:
            memory: 256Mi
          requests:
            memory: 256Mi
      redundancyPolicy: SingleRedundancy
  visualization:
    type: kibana
    9 
    
    kibana:
      replicas: 1
  collection:
    type: fluentd
    10 
    
    fluentd: {}
    Copy to Clipboard Toggle word wrap

    1
    Le nom doit être instance.
    2
    L’état de gestion OpenShift Logging. Dans certains cas, si vous modifiez les valeurs par défaut OpenShift Logging, vous devez définir ceci sur Ungaged. Cependant, un déploiement non géré ne reçoit pas de mises à jour tant qu’OpenShift Logging n’est pas placé dans un état géré.
    3
    Configuration d’Elasticsearch. En utilisant le CR, vous pouvez configurer la stratégie de réplication shard et le stockage persistant.
    4
    Indiquez la durée pendant laquelle Elasticsearch doit conserver chaque source de journal. Entrez un entier et une désignation de temps: semaines (w), heures (h/H), minutes(m) et secondes(s). À titre d’exemple, 7d pendant sept jours. Les journaux plus anciens que le maxAge sont supprimés. Il faut spécifier une stratégie de rétention pour chaque source de journal ou les indices Elasticsearch ne seront pas créés pour cette source.
    5
    Indiquez le nombre de nœuds Elasticsearch.
    6
    Entrez le nom d’une classe de stockage existante pour le stockage Elasticsearch. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Dans le cas où vous ne spécifiez pas une classe de stockage, OpenShift Logging utilise le stockage éphémère.
    7
    Indiquez les requêtes CPU et mémoire pour Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut qui devraient être suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 16Gi pour la requête mémoire et 1 pour la requête CPU.
    8
    Indiquez les requêtes CPU et mémoire pour le proxy Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut qui devraient être suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 256Mi pour la requête mémoire et 100m pour la requête CPU.
    9
    Configuration de Kibana. En utilisant le CR, vous pouvez mettre à l’échelle Kibana pour la redondance et configurer le CPU et la mémoire pour vos nœuds Kibana.
    10
    Configuration de Fluentd. En utilisant le CR, vous pouvez configurer le CPU Fluentd et les limites de mémoire.
    Note

    Le nombre maximum de nœuds maîtres est de trois. Lorsque vous spécifiez un nodeCount supérieur à 3, Red Hat OpenShift Service sur AWS crée trois nœuds Elasticsearch qui sont des nœuds éligibles au Master, avec les rôles de maître, de client et de données. Les nœuds Elasticsearch supplémentaires sont créés en tant que nœuds de données uniquement, en utilisant des rôles de client et de données. Les nœuds maîtres effectuent des actions à l’échelle du cluster, telles que la création ou la suppression d’un index, l’allocation de fragments et le suivi des nœuds. Les nœuds de données conservent les fragments et effectuent des opérations liées aux données telles que CRUD, recherche et agrégations. Les opérations liées aux données sont intensives en E/S, en mémoire et en CPU. Il est important de surveiller ces ressources et d’ajouter d’autres nœuds de données si les nœuds actuels sont surchargés.

    Ainsi, si nodeCount=4, les nœuds suivants sont créés: 

    $ oc get deployment
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
    Copy to Clipboard Toggle word wrap

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

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

  16. Contrôlez l’installation en exécutant la commande suivante: 

    $ oc get pods -n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                            READY   STATUS    RESTARTS   AGE
cluster-logging-operator-66f77ffccb-ppzbg       1/1     Running   0          7m
elasticsearch-cdm-ftuhduuw-1-ffc4b9566-q6bhp    2/2     Running   0          2m40s
elasticsearch-cdm-ftuhduuw-2-7b4994dbfc-rd2gc   2/2     Running   0          2m36s
elasticsearch-cdm-ftuhduuw-3-84b5ff7ff8-gqnm2   2/2     Running   0          2m4s
collector-587vb                                 1/1     Running   0          2m26s
collector-7mpb9                                 1/1     Running   0          2m30s
collector-flm6j                                 1/1     Running   0          2m33s
collector-gn4rn                                 1/1     Running   0          2m26s
collector-nlgb6                                 1/1     Running   0          2m30s
collector-snpkt                                 1/1     Running   0          2m28s
kibana-d6d5668c5-rppqm                          2/2     Running   0          2m39s
    Copy to Clipboard Toggle word wrap

Important

Lorsqu’il n’y a pas de période de conservation définie sur le seau s3 ou dans la ressource personnalisée LokiStack (CR), les journaux ne sont pas taillés et ils restent dans le s3 pour toujours, ce qui pourrait remplir le stockage s3.

Afin d’installer et de configurer la connexion de votre Red Hat OpenShift Service sur le cluster AWS, un opérateur tel que Loki Operator pour le stockage des journaux doit être installé en premier. Cela peut être fait à partir du service Red Hat OpenShift sur AWS CLI.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Installation de l’OpenShift CLI (oc).
  • Accès à un magasin d’objets pris en charge. AWS S3, Google Cloud Storage, Azure, Swift, Minio ou OpenShift Data Foundation.
Note

Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

  1. Créer un objet Namespace pour Loki Operator:

    Exemple d’objet Namespace

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-operators-redhat
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true"
    2
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat. Afin d’éviter d’éventuels conflits avec les métriques, vous devez configurer la pile Prometheus Cluster Monitoring pour gratter les métriques de l’espace de noms openshift-operators-redhat et non de l’espace de noms openshift-operators. L’espace de noms openshift-operators peut contenir des opérateurs communautaires, qui ne sont pas fiables et pourraient publier une métrique avec le même nom qu’un service OpenShift Red Hat sur la métrique AWS, ce qui provoquerait des conflits.
    2
    La valeur de chaîne qui spécifie l’étiquette comme indiqué pour s’assurer que la surveillance du cluster gratte l’espace de noms openshift-operators-redhat.

  2. Appliquez l’objet Namespace en exécutant la commande suivante: 

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

  3. Créer un objet d’abonnement pour Loki Operator:

    Exemple d’objet d’abonnement

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
    1 
    
spec:
  channel: stable
    2 
    
  name: loki-operator
  source: redhat-operators
    3 
    
  sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat.
    2
    Indiquez stable, ou stable-5.&lt;y&gt; comme canal.
    3
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également appelé cluster déconnecté, spécifiez le nom de l’objet CatalogSource que vous avez créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM).

  4. Appliquer l’objet Abonnement en exécutant la commande suivante: 

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

  5. Créer un objet d’espace de noms pour l’opérateur de journalisation OpenShift Red Hat:

    Exemple d’objet namespace

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-logging: "true"
    openshift.io/cluster-monitoring: "true"
    2
    Copy to Clipboard Toggle word wrap

    1
    L’opérateur de journalisation OpenShift de Red Hat n’est déployable que dans l’espace de noms openshift-logging.
    2
    La valeur de chaîne qui spécifie l’étiquette comme indiqué pour s’assurer que la surveillance du cluster gratte l’espace de noms openshift-operators-redhat.

  6. Appliquez l’objet namespace en exécutant la commande suivante: 

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

  7. Créer un objet OperatorGroup

    Exemple d’objet OperatorGroup

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
    1 
    
spec:
  targetNamespaces:
  - openshift-logging
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-logging.

  8. Appliquez l’objet OperatorGroup en exécutant la commande suivante: 

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

  9. Créer un objet d’abonnement: 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
    1 
    
spec:
  channel: stable
    2 
    
  name: cluster-logging
  source: redhat-operators
    3 
    
  sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap
    1
    Il faut spécifier l’espace de noms openshift-logging.
    2
    Indiquez stable, ou stable-5.&lt;y&gt; comme canal.
    3
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également appelé cluster déconnecté, spécifiez le nom de l’objet CatalogSource que vous avez créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM).

  10. Appliquer l’objet Abonnement en exécutant la commande suivante: 

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

  11. Créer un LokiStack CR:

    Exemple LokiStack CR

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  size: 1x.small
    3 
    
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3
    4 
    
      type: s3
    5 
    
      credentialMode:
    6 
    
  storageClassName: <storage_class_name>
    7 
    
  tenants:
    mode: openshift-logging
    8
    Copy to Clipboard Toggle word wrap

    1
    J’utilise le nom logging-loki.
    2
    Il faut spécifier l’espace de noms openshift-logging.
    3
    Indiquez la taille du déploiement. Dans l’enregistrement 5.8 et les versions ultérieures, les options de taille prises en charge pour les instances de production de Loki sont 1x.extra-petit, 1x.petit, ou 1x.medium.
    4
    Indiquez le nom de votre log store secret.
    5
    Indiquez le type de stockage correspondant.
    6
    Champ optionnel, journalisation 5.9 et ultérieure. Les valeurs configurées par l’utilisateur pris en charge sont les suivantes: statique est le mode d’authentification par défaut disponible pour tous les types de stockage d’objet pris en charge à l’aide d’informations d’identification stockées dans un Secret. jetons pour les jetons de courte durée récupérés à partir d’une source d’identification. Dans ce mode, la configuration statique ne contient pas d’informations d’identification nécessaires au stockage d’objets. Au lieu de cela, ils sont générés pendant l’exécution à l’aide d’un service, ce qui permet des informations d’identification plus courtes et un contrôle beaucoup plus granulaire. Ce mode d’authentification n’est pas pris en charge pour tous les types de stockage d’objets. le token-cco est la valeur par défaut lorsque Loki s’exécute en mode STS géré et utilise CCO sur les clusters STS/WIF.
    7
    Indiquez le nom d’une classe de stockage pour le stockage temporaire. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l’aide de la commande oc get storageclasses.
    8
    LokiStack par défaut s’exécute en mode multi-locataires, qui ne peut pas être modifié. Il y a un locataire pour chaque type de journal : audit, infrastructure et journaux d’applications. Cela permet le contrôle d’accès pour les utilisateurs individuels et les groupes d’utilisateurs à différents flux de journaux.

  12. Appliquez l’objet LokiStack CR en exécutant la commande suivante: 

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

  13. Créer un objet ClusterLogging CR:

    Exemple ClusterLogging objet CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    retentionPolicy:
      application:
        maxAge: 7d
      audit:
        maxAge: 7d
      infra:
        maxAge: 7d
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15
  managementState: Managed
    Copy to Clipboard Toggle word wrap

    1
    Le nom doit être instance.
    2
    L’espace de noms doit être ouvert-logging.

  14. Appliquez l’objet ClusterLogging CR en exécutant la commande suivante: 

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

  15. Contrôlez l’installation en exécutant la commande suivante: 

    $ oc get pods -n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    $ oc get pods -n openshift-logging
NAME                                               READY   STATUS    RESTARTS   AGE
cluster-logging-operator-fb7f7cf69-8jsbq           1/1     Running   0          98m
collector-222js                                    2/2     Running   0          18m
collector-g9ddv                                    2/2     Running   0          18m
collector-hfqq8                                    2/2     Running   0          18m
collector-sphwg                                    2/2     Running   0          18m
collector-vv7zn                                    2/2     Running   0          18m
collector-wk5zz                                    2/2     Running   0          18m
logging-view-plugin-6f76fbb78f-n2n4n               1/1     Running   0          18m
lokistack-sample-compactor-0                       1/1     Running   0          42m
lokistack-sample-distributor-7d7688bcb9-dvcj8      1/1     Running   0          42m
lokistack-sample-gateway-5f6c75f879-bl7k9          2/2     Running   0          42m
lokistack-sample-gateway-5f6c75f879-xhq98          2/2     Running   0          42m
lokistack-sample-index-gateway-0                   1/1     Running   0          42m
lokistack-sample-ingester-0                        1/1     Running   0          42m
lokistack-sample-querier-6b7b56bccc-2v9q4          1/1     Running   0          42m
lokistack-sample-query-frontend-84fb57c578-gq2f7   1/1     Running   0          42m
    Copy to Clipboard Toggle word wrap

Afin d’installer et de configurer la connexion de votre Red Hat OpenShift Service sur le cluster AWS, un opérateur tel que Loki Operator pour le stockage des journaux doit être installé en premier. Cela peut être fait à partir de OperatorHub dans la console Web.

Conditions préalables

  • Accès à un magasin d’objets pris en charge (AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation).
  • Il y a des autorisations d’administrateur.
  • Accès au service Red Hat OpenShift sur la console web AWS.

Procédure

  1. Dans le Red Hat OpenShift Service sur AWS Web console Administrator perspective, allez à Opérateurs → OperatorHub.

  2. Entrez Loki Opérateur dans le champ Filtrer par mot-clé. Cliquez sur l’opérateur Loki dans la liste des opérateurs disponibles, puis cliquez sur Installer.

    Important

    L’opérateur Loki communautaire n’est pas soutenu par Red Hat.

  3. Choisissez stable ou stable-x.y comme canal de mise à jour.

    Note

    Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

    L’opérateur Loki doit être déployé dans l’espace de noms du groupe d’opérateur mondial openshift-operators-redhat, de sorte que le mode Installation et Namespace installé sont déjà sélectionnés. Lorsque cet espace de noms n’existe pas déjà, il est créé pour vous.

  4. Activez la surveillance des clusters recommandée par l’opérateur sur cet espace de noms.

    Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-operators-redhat.

  5. Dans le cas de l’approbation de mise à jour, sélectionnez Automatique, puis cliquez sur Installer.

    Lorsque la stratégie d’approbation de l’abonnement est définie sur Automatique, le processus de mise à jour démarre dès qu’une nouvelle version de l’opérateur est disponible dans le canal sélectionné. Lorsque la stratégie d’approbation est définie sur Manuel, vous devez approuver manuellement les mises à jour en attente.

  6. Installez l’opérateur de journalisation Red Hat OpenShift:

    1. Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → OperatorHub.
    2. Choisissez Red Hat OpenShift Logging dans la liste des opérateurs disponibles, puis cliquez sur Installer.
    3. Assurez-vous que l’espace de noms A spécifique sur le cluster est sélectionné sous Mode d’installation.
    4. Assurez-vous que l’espace de noms recommandé par l’opérateur est ouvert de connexion sous Namespace installé.

    5. Activer l’opérateur recommande la surveillance des clusters sur cet espace de noms.

      Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-logging.

    6. Choisissez stable-5.y comme canal de mise à jour.

    7. Choisissez une stratégie d’approbation.

      • La stratégie automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible.
      • La stratégie du Manuel exige qu’un utilisateur ayant les informations d’identification appropriées approuve la mise à jour de l’opérateur.
    8. Cliquez sur Install.
  7. Accédez à la page Opérateurs installés → Opérateurs installés. Cliquez sur l’onglet Toutes les instances.
  8. Dans la liste déroulante Créer une nouvelle liste déroulante, sélectionnez LokiStack.

  9. Choisissez la vue YAML, puis utilisez le modèle suivant pour créer un LokiStack CR:

    Exemple LokiStack CR

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  size: 1x.small
    3 
    
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3
    4 
    
      type: s3
    5 
    
      credentialMode:
    6 
    
  storageClassName: <storage_class_name>
    7 
    
  tenants:
    mode: openshift-logging
    8
    Copy to Clipboard Toggle word wrap

    1
    J’utilise le nom logging-loki.
    2
    Il faut spécifier l’espace de noms openshift-logging.
    3
    Indiquez la taille du déploiement. Dans l’enregistrement 5.8 et les versions ultérieures, les options de taille prises en charge pour les instances de production de Loki sont 1x.extra-petit, 1x.petit, ou 1x.medium.
    4
    Indiquez le nom de votre log store secret.
    5
    Indiquez le type de stockage correspondant.
    6
    Champ optionnel, journalisation 5.9 et ultérieure. Les valeurs configurées par l’utilisateur pris en charge sont les suivantes: statique est le mode d’authentification par défaut disponible pour tous les types de stockage d’objet pris en charge à l’aide d’informations d’identification stockées dans un jeton Secret. Dans ce mode, la configuration statique ne contient pas d’informations d’identification nécessaires au stockage d’objets. Au lieu de cela, ils sont générés pendant l’exécution à l’aide d’un service, ce qui permet des informations d’identification plus courtes et un contrôle beaucoup plus granulaire. Ce mode d’authentification n’est pas pris en charge pour tous les types de stockage d’objets. token-cco est la valeur par défaut lorsque Loki s’exécute en mode STS géré et utilise CCO sur les clusters STS/WIF.
    7
    Indiquez le nom d’une classe de stockage pour le stockage temporaire. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l’aide de la commande oc get storageclasses.
    8
    LokiStack par défaut s’exécute en mode multi-locataires, qui ne peut pas être modifié. Il y a un locataire pour chaque type de journal : audit, infrastructure et journaux d’applications. Cela permet le contrôle d’accès pour les utilisateurs individuels et les groupes d’utilisateurs à différents flux de journaux.
    Important

    Il n’est pas possible de modifier le nombre 1x pour la taille du déploiement.

  10. Cliquez sur Create.

  11. Créer une instance OpenShift Logging:

    1. Basculez à la page Administration → Définitions de ressources personnalisées.
    2. Dans la page Définitions de ressources personnalisées, cliquez sur ClusterLogging.
    3. Dans la page Détails de la définition des ressources personnalisées, sélectionnez Afficher les instances dans le menu Actions.

    4. Dans la page ClusterLoggings, cliquez sur Créer ClusterLogging.

      Il vous faudra peut-être actualiser la page pour charger les données.

    5. Dans le champ YAML, remplacer le code par ce qui suit: 

      apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
      1 
      
  namespace: openshift-logging
      2 
      
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    retentionPolicy:
      application:
        maxAge: 7d
      audit:
        maxAge: 7d
      infra:
        maxAge: 7d
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15

  managementState: Managed
      Copy to Clipboard Toggle word wrap
      1
      Le nom doit être instance.
      2
      L’espace de noms doit être ouvert-logging.

La vérification

  1. Allez à Opérateurs → Opérateurs installés.
  2. Assurez-vous que le projet openshift-logging est sélectionné.
  3. Dans la colonne État, vérifiez que vous voyez des cocheries vertes avec InstallSucceeded et le texte à jour.
Note

L’opérateur peut afficher un état d’échec avant la fin de l’installation. Lorsque l’opérateur installe avec un message InstallSucceeded, actualisez la page.

Chapitre 6. La mise à jour de l’enregistrement
Copier lien

Il existe deux types de mises à jour de journalisation: les mises à jour mineures (5.y.z) et les principales mises à jour des versions (5.y).

6.1. Des mises à jour mineures
Copier lien

En installant les opérateurs de journalisation à l’aide de l’option Automatique d’approbation de mise à jour, vos opérateurs reçoivent automatiquement des mises à jour mineures. Il n’est pas nécessaire de compléter les étapes de mise à jour manuelle.

Lorsque vous avez installé les opérateurs d’enregistrement à l’aide de l’option d’approbation de mise à jour manuelle, vous devez approuver manuellement les mises à jour mineures des versions. Afin d’obtenir de plus amples renseignements, voir Approbation manuelle d’une mise à jour de l’opérateur en attente.

6.2. Les principales mises à jour de la version
Copier lien

En ce qui concerne les principales mises à jour des versions, vous devez compléter quelques étapes manuelles.

En ce qui concerne la compatibilité des versions majeures et les informations de support, consultez OpenShift Operator Life Cycles.

Dans l’enregistrement des versions 5.7 et anciennes, le Red Hat OpenShift Logging Operator ne regarde que l’espace de noms openshift-logging. Lorsque vous souhaitez que le Red Hat OpenShift Logging Operator surveille tous les espaces de noms de votre cluster, vous devez redéployer l’opérateur. Il est possible d’achever la procédure suivante pour redéployer l’opérateur sans supprimer vos composants d’enregistrement.

Conditions préalables

  • L’OpenShift CLI (oc) a été installé.
  • Il y a des autorisations d’administrateur.

Procédure

  1. Effacer l’abonnement en exécutant la commande suivante: 

    $ oc -n openshift-logging delete subscription <subscription>
    Copy to Clipboard Toggle word wrap

  2. Effacer le groupe d’opérateurs en exécutant la commande suivante: 

    $ oc -n openshift-logging delete operatorgroup <operator_group_name>
    Copy to Clipboard Toggle word wrap

  3. Effacer la version de service cluster (CSV) en exécutant la commande suivante: 

    $ oc delete clusterserviceversion cluster-logging.<version>
    Copy to Clipboard Toggle word wrap
  4. Déployez l’opérateur de journalisation OpenShift Red Hat en suivant la documentation « Installing Logging ».

La vérification

  • Assurez-vous que le champ targetNamespaces dans la ressource OperatorGroup n’est pas présent ou qu’il est défini sur une chaîne vide.

    À cette fin, exécutez la commande suivante et inspectez la sortie: 

    $ oc get operatorgroup <operator_group_name> -o yaml
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-logging-f52cn
  namespace: openshift-logging
spec:
  upgradeStrategy: Default
status:
  namespaces:
  - ""
# ...
    Copy to Clipboard Toggle word wrap

Afin de mettre à jour l’opérateur de journalisation Red Hat OpenShift vers une nouvelle version majeure, vous devez modifier le canal de mise à jour de l’abonnement à l’opérateur.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • Il y a des autorisations d’administrateur.
  • Accès au service Red Hat OpenShift sur la console web AWS et visualisez la perspective de l’administrateur.

Procédure

  1. Accédez aux opérateurs → Opérateurs installés.
  2. Choisissez le projet openshift-logging.
  3. Cliquez sur l’opérateur de journalisation Red Hat OpenShift.
  4. Cliquez sur Abonnement. Dans la section Détails de l’abonnement, cliquez sur le lien Mise à jour du canal. Ce texte de lien peut être stable ou stable-5.9, en fonction de votre canal de mise à jour actuel.
  5. Dans la fenêtre Modifier la mise à jour de l’abonnement, sélectionnez le dernier canal de mise à jour de version majeure, stable-5.9, et cliquez sur Enregistrer. A noter la version cluster-logging.v5.9.&lt;z&gt;.
  6. Attendez quelques secondes, puis allez dans Opérateurs → Opérateurs installés pour vérifier que la version Red Hat OpenShift Logging Operator correspond à la dernière version cluster-logging.v5.9.&lt;z&gt;.
  7. Dans la page Opérateurs installés, attendez que le champ État indique Succeeded.
  8. Cochez si la ressource personnalisée LokiStack contient la version du schéma v13 et ajoutez-la si elle est manquante. Afin d’ajouter correctement la version de schéma v13, voir « Mise à niveau du schéma de stockage LokiStack ».

6.5. La mise à jour de l’opérateur Loki
Copier lien

Afin de mettre à jour l’opérateur Loki vers une nouvelle version majeure, vous devez modifier le canal de mise à jour de l’abonnement Opérateur.

Conditions préalables

  • « vous avez installé l’opérateur Loki.
  • Il y a des autorisations d’administrateur.
  • Accès au service Red Hat OpenShift sur la console web AWS et visualisez la perspective de l’administrateur.

Procédure

  1. Accédez aux opérateurs → Opérateurs installés.
  2. Choisissez le projet openshift-operators-redhat.
  3. Cliquez sur l’opérateur Loki.
  4. Cliquez sur Abonnement. Dans la section Détails de l’abonnement, cliquez sur le lien Mise à jour du canal. Ce texte de lien peut être stable ou stable-5.y, en fonction de votre canal de mise à jour actuel.
  5. Dans la fenêtre Modifier la mise à jour de l’abonnement, sélectionnez le dernier canal de mise à jour de version majeure, stable-5.y, et cliquez sur Enregistrer. A noter la version loki-operator.v5.y.z.
  6. Attendez quelques secondes, puis cliquez sur Opérateurs → Opérateurs installés. Assurez-vous que la version Loki Operator correspond à la dernière version loki-operator.v5.y.z.
  7. Dans la page Opérateurs installés, attendez que le champ État indique Succeeded.
  8. Cochez si la ressource personnalisée LokiStack contient la version du schéma v13 et ajoutez-la si elle est manquante. Afin d’ajouter correctement la version de schéma v13, voir « Mise à niveau du schéma de stockage LokiStack ».

6.6. Amélioration du schéma de stockage LokiStack
Copier lien

Lorsque vous utilisez l’opérateur de journalisation Red Hat OpenShift avec l’opérateur Loki, le Red Hat OpenShift Logging Operator 5.9 ou version ultérieure prend en charge la version de schéma v13 dans la ressource personnalisée LokiStack. La mise à niveau vers la version de schéma v13 est recommandée car c’est la version de schéma à prendre en charge à l’avenir.

Procédure

  • Ajoutez la version de schéma v13 dans la ressource personnalisée LokiStack comme suit: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
# ...
spec:
# ...
  storage:
    schemas:
    # ...
      version: v12
    1 
    
    - effectiveDate: "<yyyy>-<mm>-<future_dd>"
    2 
    
      version: v13
# ...
    Copy to Clipboard Toggle word wrap
    1
    Il ne s’agit pas de supprimer. Les données persistent dans sa version de schéma d’origine. Gardez les versions de schéma précédentes pour éviter la perte de données.
    2
    Définissez une date future qui n’a pas encore commencé dans le fuseau horaire du Temps Universel Coordonné (UTC).
    Astuce

    Afin d’éditer la ressource personnalisée LokiStack, vous pouvez exécuter la commande oc edit: 

    $ oc edit lokistack <name> -n openshift-logging
    Copy to Clipboard Toggle word wrap

La vérification

  • À ou après la date d’entrée en vigueur spécifiée, vérifiez qu’il n’y a pas d’alerte LokistackSchemaUpgradesRequired dans la console Web dans Administrator → Observer → Alerter.

6.7. La mise à jour de l’opérateur OpenShift Elasticsearch
Copier lien

Afin de mettre à jour l’opérateur OpenShift Elasticsearch vers la version actuelle, vous devez modifier l’abonnement.

Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

Conditions préalables

  • Lorsque vous utilisez Elasticsearch comme log store par défaut, et Kibana comme interface utilisateur, mettez à jour l’opérateur OpenShift Elasticsearch avant de mettre à jour l’opérateur de journalisation Red Hat OpenShift.

    Important

    Lorsque vous mettez à jour les Opérateurs dans le mauvais ordre, Kibana ne met pas à jour et la ressource personnalisée Kibana (CR) n’est pas créée. Afin de résoudre ce problème, supprimer le pod Red Hat OpenShift Logging Operator. Lorsque le pod Red Hat OpenShift Logging Operator redéploye, il crée le Kibana CR et Kibana devient disponible à nouveau.

  • L’état de journalisation est sain:

    • Les gousses sont prêtes.
    • Le cluster Elasticsearch est sain.
  • Les données Elasticsearch et Kibana sont sauvegardées.
  • Il y a des autorisations d’administrateur.
  • L’OpenShift CLI (oc) est installé pour les étapes de vérification.

Procédure

  1. Dans la console de cloud hybride Red Hat, cliquez sur Opérateurs → Opérateurs installés.
  2. Choisissez le projet openshift-operators-redhat.
  3. Cliquez sur OpenShift Elasticsearch Operator.
  4. Cliquez sur Abonnement → Canal.
  5. Dans la fenêtre Modifier la mise à jour de l’abonnement, sélectionnez stable-5.y et cliquez sur Enregistrer. À noter la version élastique-operator.v5.y.z.
  6. Attendez quelques secondes, puis cliquez sur Opérateurs → Opérateurs installés. Assurez-vous que la version OpenShift Elasticsearch Operator correspond à la dernière version d’élasticité-operator.v5.y.z.
  7. Dans la page Opérateurs installés, attendez que le champ État indique Succeeded.

La vérification

  1. Assurez-vous que tous les pods Elasticsearch ont un statut prêt en entrant la commande suivante et en observant la sortie: 

    $ oc get pod -n openshift-logging --selector component=elasticsearch
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                                            READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk   2/2     Running   0          31m
elasticsearch-cdm-1pbrl44l-2-5c6d87589f-gx5hk   2/2     Running   0          30m
elasticsearch-cdm-1pbrl44l-3-88df5d47-m45jc     2/2     Running   0          29m
    Copy to Clipboard Toggle word wrap

  2. Assurez-vous que l’état du cluster Elasticsearch est vert en entrant la commande suivante et en observant la sortie: 

    $ oc exec -n openshift-logging -c elasticsearch elasticsearch-cdm-1pbrl44l-1-55b7546f4c-mshhk -- health
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {
  "cluster_name" : "elasticsearch",
  "status" : "green",
}
    Copy to Clipboard Toggle word wrap

  3. Assurez-vous que les travaux d’Elasticsearch cron sont créés en entrant les commandes suivantes et en observant la sortie: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap 
    $ oc get cronjob
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
elasticsearch-im-app     */15 * * * *   False     0        <none>          56s
elasticsearch-im-audit   */15 * * * *   False     0        <none>          56s
elasticsearch-im-infra   */15 * * * *   False     0        <none>          56s
    Copy to Clipboard Toggle word wrap

  4. Assurez-vous que le log store est mis à jour à la bonne version et que les indices sont verts en entrant la commande suivante et en observant la sortie: 

    $ oc exec -c elasticsearch <any_es_pod_in_the_cluster> -- indices
    Copy to Clipboard Toggle word wrap

    Assurez-vous que la sortie comprend l’app-00000x, l’infra-00000x, l’audit-00000x, les indices de sécurité:

    Exemple 6.1. Échantillon de sortie avec des indices dans un état vert

    Tue Jun 30 14:30:54 UTC 2020
health status index                                                                 uuid                   pri rep docs.count docs.deleted store.size pri.store.size
green  open   infra-000008                                                          bnBvUFEXTWi92z3zWAzieQ   3 1       222195            0        289            144
green  open   infra-000004                                                          rtDSzoqsSl6saisSK7Au1Q   3 1       226717            0        297            148
green  open   infra-000012                                                          RSf_kUwDSR2xEuKRZMPqZQ   3 1       227623            0        295            147
green  open   .kibana_7                                                             1SJdCqlZTPWlIAaOUd78yg   1 1            4            0          0              0
green  open   infra-000010                                                          iXwL3bnqTuGEABbUDa6OVw   3 1       248368            0        317            158
green  open   infra-000009                                                          YN9EsULWSNaxWeeNvOs0RA   3 1       258799            0        337            168
green  open   infra-000014                                                          YP0U6R7FQ_GVQVQZ6Yh9Ig   3 1       223788            0        292            146
green  open   infra-000015                                                          JRBbAbEmSMqK5X40df9HbQ   3 1       224371            0        291            145
green  open   .orphaned.2020.06.30                                                  n_xQC2dWQzConkvQqei3YA   3 1            9            0          0              0
green  open   infra-000007                                                          llkkAVSzSOmosWTSAJM_hg   3 1       228584            0        296            148
green  open   infra-000005                                                          d9BoGQdiQASsS3BBFm2iRA   3 1       227987            0        297            148
green  open   infra-000003                                                          1-goREK1QUKlQPAIVkWVaQ   3 1       226719            0        295            147
green  open   .security                                                             zeT65uOuRTKZMjg_bbUc1g   1 1            5            0          0              0
green  open   .kibana-377444158_kubeadmin                                           wvMhDwJkR-mRZQO84K0gUQ   3 1            1            0          0              0
green  open   infra-000006                                                          5H-KBSXGQKiO7hdapDE23g   3 1       226676            0        295            147
green  open   infra-000001                                                          eH53BQ-bSxSWR5xYZB6lVg   3 1       341800            0        443            220
green  open   .kibana-6                                                             RVp7TemSSemGJcsSUmuf3A   1 1            4            0          0              0
green  open   infra-000011                                                          J7XWBauWSTe0jnzX02fU6A   3 1       226100            0        293            146
green  open   app-000001                                                            axSAFfONQDmKwatkjPXdtw   3 1       103186            0        126             57
green  open   infra-000016                                                          m9c1iRLtStWSF1GopaRyCg   3 1        13685            0         19              9
green  open   infra-000002                                                          Hz6WvINtTvKcQzw-ewmbYg   3 1       228994            0        296            148
green  open   infra-000013                                                          KR9mMFUpQl-jraYtanyIGw   3 1       228166            0        298            148
green  open   audit-000001                                                          eERqLdLmQOiQDFES1LBATQ   3 1            0            0          0              0
    Copy to Clipboard Toggle word wrap

  5. Assurez-vous que le visualiseur de log est mis à jour vers la bonne version en entrant la commande suivante et en observant la sortie: 

    $ oc get kibana kibana -o json
    Copy to Clipboard Toggle word wrap

    Assurez-vous que la sortie comprend un pod Kibana avec le statut prêt:

    Exemple 6.2. Échantillon de sortie avec un pod Kibana prêt

    [
{
"clusterCondition": {
"kibana-5fdd766ffd-nb2jj": [
{
"lastTransitionTime": "2020-06-30T14:11:07Z",
"reason": "ContainerCreating",
"status": "True",
"type": ""
},
{
"lastTransitionTime": "2020-06-30T14:11:07Z",
"reason": "ContainerCreating",
"status": "True",
"type": ""
}
]
},
"deployment": "kibana",
"pods": {
"failed": [],
"notReady": []
"ready": []
},
"replicaSets": [
"kibana-5fdd766ffd"
],
"replicas": 1
}
]
    Copy to Clipboard Toggle word wrap

Chapitre 7. Affichage des journaux
Copier lien

7.1. À propos de la visualisation des journaux
Copier lien

Il est possible de visualiser les données de votre journal dans le Red Hat OpenShift Service sur la console web AWS, ou dans la console Web Kibana, en fonction de votre solution de stockage de log déployée. La console Kibana peut être utilisée avec les log stores ElasticSearch, et le Red Hat OpenShift Service sur la console web AWS peut être utilisé avec le log store ElasticSearch ou le LokiStack.

Note

La console Web Kibana est maintenant désapprouvée est prévue pour être supprimée dans une prochaine version de journalisation.

7.1.1. Configuration du visualiseur de log
Copier lien

Il est possible de configurer le visualiseur de journal utilisé par votre journal en modifiant la ressource personnalisée ClusterLogging (CR).

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.
Important

Lorsque vous souhaitez utiliser le service Red Hat OpenShift sur la console web AWS pour la visualisation, vous devez activer le plugin de la console de journalisation. Consultez la documentation sur « Visualisation de l’enregistrement avec la console web ».

Procédure

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

    Exemple de ClusterLogging CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  visualization:
    type: <visualizer_type>
    1 
    
    kibana:
    2 
    
      resources: {}
      nodeSelector: {}
      proxy: {}
      replicas: {}
      tolerations: {}
    ocpConsole:
    3 
    
      logsLimit: {}
      timeout: {}
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le type de visualiseur que vous souhaitez utiliser pour votre journalisation. Cela peut être soit kibana ou ocp-console. La console Kibana n’est compatible qu’avec les déploiements utilisant le stockage journal Elasticsearch, tandis que le Red Hat OpenShift Service sur la console AWS n’est compatible qu’avec les déploiements LokiStack.
    2
    Configurations optionnelles pour la console Kibana.
    3
    Configurations optionnelles pour le Red Hat OpenShift Service sur la console web AWS.

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

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

7.1.2. Affichage des journaux pour une ressource
Copier lien

Les journaux de ressources sont une fonctionnalité par défaut qui fournit une capacité limitée de visualisation des journaux. En utilisant OpenShift CLI (oc) et la console Web, vous pouvez consulter les journaux pour diverses ressources, telles que les builds, les déploiements et les pods.

Astuce

Afin d’améliorer votre expérience de récupération et de visualisation de journaux, installez la journalisation. L’enregistrement agrége tous les journaux de votre Red Hat OpenShift Service sur le cluster AWS, tels que les journaux d’audit système de nœuds, les journaux de conteneurs d’application et les journaux d’infrastructure, dans un journal de journal dédié. Ensuite, vous pouvez interroger, découvrir et visualiser vos données de log via la console Kibana ou le Red Hat OpenShift Service sur la console web AWS. Les journaux des ressources n’ont pas accès au journal de journalisation.

7.1.2.1. Affichage des journaux des ressources
Copier lien

Il est possible d’afficher le journal pour diverses ressources dans OpenShift CLI (oc) et la console Web. Journaux lus à partir de la queue, ou de la fin, du journal.

Conditions préalables

  • Accès à l’OpenShift CLI (oc).

La procédure (UI)

  1. Dans le Red Hat OpenShift Service sur la console AWS, accédez à Workloads → Pods ou accédez au pod à travers la ressource que vous souhaitez enquêter.

    Note

    Certaines ressources, telles que les builds, n’ont pas de pods à interroger directement. Dans de tels cas, vous pouvez localiser le lien Logs sur la page Détails de la ressource.

  2. Choisissez un projet dans le menu déroulant.
  3. Cliquez sur le nom du pod que vous souhaitez enquêter.
  4. Cliquez sur Logs.

La procédure (CLI)

  • Consultez le journal pour un pod spécifique: 

    $ oc logs -f <pod_name> -c <container_name>
    Copy to Clipboard Toggle word wrap

    là où:

    -F
    Facultatif : Spécifie que la sortie suit ce qui est écrit dans les journaux.
    &lt;pod_name&gt;
    Indique le nom du pod.
    &lt;container_name&gt;
    Facultatif: Spécifie le nom d’un conteneur. Lorsqu’une gousse a plus d’un conteneur, vous devez spécifier le nom du conteneur.

    À titre d’exemple: 

    $ oc logs ruby-58cd97df55-mww7r
    Copy to Clipboard Toggle word wrap 
    $ oc logs -f ruby-57f7f4855b-znl92 -c ruby
    Copy to Clipboard Toggle word wrap

    Le contenu des fichiers journaux est imprimé.

  • Consultez le journal pour une ressource spécifique: 

    $ oc logs <object_type>/<resource_name>
    1
    Copy to Clipboard Toggle word wrap
    1
    Indique le type de ressource et le nom.

    À titre d’exemple: 

    $ oc logs deployment/ruby
    Copy to Clipboard Toggle word wrap

    Le contenu des fichiers journaux est imprimé.

7.2. Journalisation de la visualisation avec la console web
Copier lien

Le Red Hat OpenShift Service sur la console web AWS permet de visualiser les données de log en configurant le plugin de la console de journalisation. Des options de configuration sont disponibles lors de l’installation de l’enregistrement sur la console Web.

Lorsque vous avez déjà installé l’enregistrement et que vous souhaitez configurer le plugin, utilisez l’une des procédures suivantes.

Dans le cadre de l’installation Red Hat OpenShift Logging Operator, vous pouvez activer le plug-in de la console d’enregistrement, mais vous pouvez également activer le plugin si vous avez déjà installé l’opérateur de journalisation Red Hat OpenShift avec le plugin désactivé.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • L’opérateur de journalisation Red Hat OpenShift a été installé et sélectionné Désactiver pour le plugin Console.
  • Accès au service Red Hat OpenShift sur la console web AWS.

Procédure

  1. Dans le Red Hat OpenShift Service sur la perspective de l’administrateur de la console Web AWS, accédez aux opérateurs → Opérateurs installés.
  2. Cliquez sur Red Hat OpenShift Logging. Cela vous amène à la page Détails de l’opérateur.
  3. Dans la page Détails, cliquez sur Désactiver pour l’option du plugin Console.
  4. Dans la boîte de dialogue d’activation du plugin Console, sélectionnez Activer.
  5. Cliquez sur Save.
  6. Assurez-vous que l’option du plugin Console affiche désormais Enabled.
  7. La console Web affiche une fenêtre contextuelle lorsque des modifications ont été appliquées. La fenêtre vous invite à recharger la console Web. Actualisez le navigateur lorsque vous voyez la fenêtre contextuelle pour appliquer les modifications.

Dans la version de journalisation 5.8 et ultérieure, si le log store Elasticsearch est votre log store par défaut mais que vous avez également installé le LokiStack, vous pouvez activer le plugin de la console d’enregistrement en utilisant la procédure suivante.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • L’opérateur de journalisation Red Hat OpenShift, l’opérateur OpenShift Elasticsearch et l’opérateur Loki ont été installés.
  • L’OpenShift CLI (oc) a été installé.
  • Création d’une ressource personnalisée ClusterLogging (CR).

Procédure

  1. Assurez-vous que le plugin de la console d’enregistrement est activé en exécutant la commande suivante: 

    $ oc get consoles.operator.openshift.io cluster -o yaml |grep logging-view-plugin  \
|| oc patch consoles.operator.openshift.io cluster  --type=merge \
--patch '{ "spec": { "plugins": ["logging-view-plugin"]}}'
    Copy to Clipboard Toggle word wrap

  2. Ajouter la commande .metadata.annotations.logging.openshift.io/ocp-console-migration-target: lokistack-dev annotation à ClusterLogging CR, en exécutant la commande suivante: 

    $ oc patch clusterlogging instance --type=merge --patch \
'{ "metadata": { "annotations": { "logging.openshift.io/ocp-console-migration-target": "lokistack-dev" }}}' \
-n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    clusterlogging.logging.openshift.io/instance patched
    Copy to Clipboard Toggle word wrap

La vérification

  • Assurez-vous que l’annotation a été ajoutée avec succès, en exécutant la commande suivante et en observant la sortie: 

    $ oc get clusterlogging instance \
-o=jsonpath='{.metadata.annotations.logging\.openshift\.io/ocp-console-migration-target}' \
-n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    "lokistack-dev"
    Copy to Clipboard Toggle word wrap

Le module Plugin de la console de journalisation est maintenant déployé. Il est possible d’afficher les données d’enregistrement en naviguant vers le service Red Hat OpenShift sur la console web AWS et en consultant la page Observe → Logs.

7.3. Affichage des tableaux de bord de cluster
Copier lien

Les tableaux de bord Logging/Elasticsearch et Openshift Logging dans OpenShift Cluster Manager contiennent des détails approfondis sur votre instance Elasticsearch et les nœuds Elasticsearch individuels que vous pouvez utiliser pour prévenir et diagnostiquer les problèmes.

Le tableau de bord OpenShift Logging contient des graphiques qui montrent des détails sur votre instance Elasticsearch à un niveau de cluster, y compris les ressources de cluster, la collecte des ordures, les fragments dans le cluster et les statistiques Fluentd.

Le tableau de bord Logging/Elasticsearch Nodes contient des graphiques qui montrent des détails sur votre instance Elasticsearch, beaucoup au niveau des nœuds, y compris des détails sur l’indexation, les éclats, les ressources, etc.

Dans OpenShift Cluster Manager, vous pouvez consulter les tableaux de bord Logging/Elasticsearch et OpenShift Logging.

Procédure

Lancer les tableaux de bord:

  1. Dans le Red Hat OpenShift Service sur AWS Red Hat Hybrid Cloud Console, cliquez sur Observer → Tableau de bord.

  2. Dans la page Tableau de bord, sélectionnez Logging/Elasticsearch Nodes ou OpenShift Logging dans le menu Tableau de bord.

    Dans le tableau de bord Logging/Elasticsearch Nodes, vous pouvez sélectionner le nœud Elasticsearch que vous souhaitez afficher et définir la résolution des données.

    Le tableau de bord approprié est affiché, montrant plusieurs graphiques de données.

  3. Facultatif: Sélectionnez une plage de temps différente pour afficher ou rafraîchir le taux des données dans les menus Time Range et Refresh Interval.

Informations sur les tableaux de bord, voir À propos du tableau de bord OpenShift Logging et About the Logging/Elastisearch Nodes dashboard.

7.3.2. À propos du tableau de bord OpenShift Logging
Copier lien

Le tableau de bord OpenShift Logging contient des graphiques qui montrent des détails sur votre instance Elasticsearch à un niveau de cluster que vous pouvez utiliser pour diagnostiquer et anticiper les problèmes.

Expand
Tableau 7.1. Diagrammes de journalisation OpenShift
De la métriqueDescription

État du cluster élastique

Le statut actuel Elasticsearch:

  • EN LIGNE - Indique que l’instance Elasticsearch est en ligne.
  • OFFLINE - Indique que l’instance Elasticsearch est hors ligne.

Les nœuds élastiques

Le nombre total de nœuds Elasticsearch dans l’instance Elasticsearch.

Des Shards élastiques

Le nombre total de fragments Elasticsearch dans l’instance Elasticsearch.

Documents élastiques

Le nombre total de documents Elasticsearch dans l’instance Elasticsearch.

La taille totale de l’indice sur le disque

L’espace disque total utilisé pour les indices Elasticsearch.

Élastique en attente des tâches

Le nombre total de changements Elasticsearch qui n’ont pas été achevés, tels que la création d’indices, la cartographie de l’index, l’allocation de fragments ou l’échec du fragment.

Elastique JVM GC temps

Le temps que le JVM a passé à exécuter les opérations de collecte des ordures Elasticsearch dans le cluster.

Elastique JVM GC Rate

Le nombre total de fois que JVM a exécuté des activités d’ordures par seconde.

Élastique Query/Fetch Latency Sum

  • Latence de requête: Le temps moyen de chaque requête de recherche Elasticsearch prend pour exécuter.
  • Le temps moyen pour chaque requête de recherche Elasticsearch passe à chercher des données.

La latence de recherche prend généralement moins de temps que la latence de requête. Lorsque la latence augmente constamment, elle peut indiquer des disques lents, l’enrichissement des données ou de grandes demandes avec trop de résultats.

Le taux de requête élastique

Le total des requêtes exécutées contre l’instance Elasticsearch par seconde pour chaque nœud Elasticsearch.

CPU

La quantité de CPU utilisée par Elasticsearch, Fluentd et Kibana, affichée pour chaque composant.

Élastique JVM Heap Utilisé

La quantité de mémoire JVM utilisée. Dans un cluster sain, le graphique montre des gouttes régulières lorsque la mémoire est libérée par la collecte des ordures JVM.

Elasticsearch Disk Usage

L’espace disque total utilisé par l’instance Elasticsearch pour chaque nœud Elasticsearch.

Descripteurs de fichiers utilisés

Le nombre total de descripteurs de fichiers utilisés par Elasticsearch, Fluentd et Kibana.

Comptage d’émission Fluentd

Le nombre total de messages Fluentd par seconde pour la sortie par défaut Fluentd, et le nombre de réessayer pour la sortie par défaut.

Fluentd Buffer Utilisation

Le pourcentage du tampon Fluentd qui est utilisé pour les morceaux. Le tampon complet pourrait indiquer que Fluentd n’est pas en mesure de traiter le nombre de logs reçus.

Élastique rx octets

Le nombre total d’octets qu’Elasticsearch a reçu de FluentD, des nœuds Elasticsearch et d’autres sources.

Indice élastique Taux d’échec

Le nombre total de fois par seconde qu’un indice Elasticsearch échoue. Le taux élevé peut indiquer un problème d’indexation.

Débit d’erreur de sortie Fluentd

Le nombre total de fois par seconde que FluentD n’est pas capable de produire des journaux.

Le tableau de bord Logging/Elasticsearch Nodes contient des graphiques qui montrent des détails sur votre instance Elasticsearch, beaucoup au niveau des nœuds, pour d’autres diagnostics.

Elasticsearch statut
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur l’état de votre instance Elasticsearch.
Expand
Tableau 7.2. Champs de statut Elasticsearch
De la métriqueDescription

État du cluster

L’état de santé des grappes au cours de la période sélectionnée, en utilisant les statuts vert, jaune et rouge Elasticsearch:

  • 0 - indique que l’instance Elasticsearch est en statut vert, ce qui signifie que tous les éclats sont alloués.
  • 1 - indique que l’instance Elasticsearch est en état jaune, ce qui signifie que les répliques pour au moins un fragment ne sont pas allouées.
  • 2 - indique que l’instance Elasticsearch est en état rouge, ce qui signifie qu’au moins un fragment primaire et ses répliques ne sont pas alloués.

Les nœuds de cluster

Le nombre total de nœuds Elasticsearch dans le cluster.

Cluster des nœuds de données

Le nombre de nœuds de données Elasticsearch dans le cluster.

Groupe de tâches en attente

Le nombre de changements d’état de cluster qui ne sont pas terminés et qui attendent dans une file d’attente de cluster, par exemple, la création d’index, la suppression d’index ou l’allocation shard. La tendance croissante indique que le cluster n’est pas en mesure de suivre les changements.

Elasticsearch cluster index shard status
Chaque indice Elasticsearch est un groupe logique d’un ou de plusieurs fragments, qui sont des unités de base de données persistantes. Il existe deux types de fragments d’index: les fragments primaires et les répliques. Lorsqu’un document est indexé dans un index, il est stocké dans l’un de ses fragments primaires et copié dans chaque réplique de ce fragment. Le nombre de fragments primaires est spécifié lorsque l’index est créé, et le nombre ne peut pas changer pendant la durée de vie de l’index. Il est possible de modifier le nombre de répliques à tout moment.

Le fragment d’index peut être dans plusieurs états en fonction de sa phase de cycle de vie ou des événements se produisant dans le cluster. Lorsque le shard est capable d’effectuer des requêtes de recherche et d’indexation, le shard est actif. Dans le cas où le shard ne peut pas exécuter ces requêtes, le shard n’est pas actif. Il se peut qu’un fragment ne soit pas actif si le fragment est initialisant, réaffectant, non affecté, et ainsi de suite.

Les fragments d’index se composent d’un certain nombre de blocs internes plus petits, appelés segments d’index, qui sont des représentations physiques des données. Le segment d’index est un indice de Lucene relativement petit et immuable qui est créé lorsque Lucene commet des données nouvellement indexées. Lucene, une bibliothèque de recherche utilisée par Elasticsearch, fusionne les segments d’index en segments plus grands en arrière-plan pour maintenir le nombre total de segments bas. Lorsque le processus de fusion des segments est plus lent que la vitesse à laquelle de nouveaux segments sont créés, cela pourrait indiquer un problème.

Lorsque Lucene effectue des opérations de données, telles qu’une opération de recherche, Lucene effectue l’opération contre les segments d’index dans l’index pertinent. À cette fin, chaque segment contient des structures de données spécifiques qui sont chargées dans la mémoire et cartographiées. La cartographie des index peut avoir un impact significatif sur la mémoire utilisée par les structures de données segmentées.

Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur les fragments d’index Elasticsearch.

Expand
Tableau 7.3. Elasticsearch cluster shard status charts
De la métriqueDescription

Fragments actifs

Le nombre de fragments primaires actifs et le nombre total de fragments, y compris les répliques, dans le cluster. Lorsque le nombre de fragments augmente, les performances des clusters peuvent commencer à se dégrader.

Les fragments d’initialisation du cluster

Le nombre de fragments non actifs dans le cluster. Le fragment non actif est celui qui initialise, est réaffecté à un nœud différent, ou qui n’est pas affecté. En général, un cluster a des fragments non actifs pendant de courtes périodes. De plus en plus de fragments non actifs sur des périodes plus longues pourraient indiquer un problème.

A) Déplacement des fragments de clusters

Le nombre de fragments qu’Elasticsearch déménage vers un nouveau nœud. Elasticsearch déplace les nœuds pour plusieurs raisons, telles que l’utilisation de mémoire élevée sur un nœud ou après l’ajout d’un nouveau nœud au cluster.

Fragments non attribués

Le nombre de fragments non attribués. Les fragments d’Elasticsearch peuvent être non attribués pour des raisons telles qu’un nouvel index est ajouté ou l’échec d’un nœud.

Elasticsearch métriques des nœuds
Chaque nœud Elasticsearch a une quantité limitée de ressources qui peuvent être utilisées pour traiter les tâches. Lorsque toutes les ressources sont utilisées et qu’Elasticsearch tente d’effectuer une nouvelle tâche, Elasticsearch met les tâches dans une file d’attente jusqu’à ce que certaines ressources deviennent disponibles.

Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur l’utilisation des ressources pour un nœud sélectionné et le nombre de tâches en attente dans la file d’attente Elasticsearch.

Expand
Tableau 7.4. Cartes métriques des nœuds Elasticsearch
De la métriqueDescription

Les tâches de threadpool

Le nombre de tâches d’attente dans les files d’attente individuelles, affichée par type de tâche. L’accumulation à long terme de tâches dans n’importe quelle file d’attente pourrait indiquer des pénuries de ressources de nœuds ou un autre problème.

L’utilisation du CPU

La quantité de CPU utilisée par le nœud Elasticsearch sélectionné en pourcentage du CPU total alloué au conteneur hôte.

L’utilisation de la mémoire

La quantité de mémoire utilisée par le nœud Elasticsearch sélectionné.

L’utilisation du disque

L’espace disque total utilisé pour les données d’index et les métadonnées sur le nœud Elasticsearch sélectionné.

Le taux d’indexation des documents

Le taux que les documents sont indexés sur le nœud Elasticsearch sélectionné.

Latence d’indexation

Le temps nécessaire pour indexer les documents sur le nœud Elasticsearch sélectionné. La latence d’indexation peut être affectée par de nombreux facteurs, tels que la mémoire JVM Heap et la charge globale. La latence croissante indique une pénurie de ressources dans le cas.

Le taux de recherche

Le nombre de requêtes de recherche s’exécute sur le nœud Elasticsearch sélectionné.

Latence de recherche

Le temps nécessaire pour remplir les demandes de recherche sur le nœud Elasticsearch sélectionné. La latence de recherche peut être affectée par de nombreux facteurs. La latence croissante indique une pénurie de ressources dans le cas.

Comptage des documents (avec répliques)

Le nombre de documents Elasticsearch stockés sur le nœud Elasticsearch sélectionné, y compris les documents stockés dans les fragments primaires et les fragments de réplique qui sont alloués sur le nœud.

Le taux de suppression des documents

Le nombre de documents Elasticsearch supprimés de l’un des fragments d’index qui sont attribués au nœud Elasticsearch sélectionné.

Le taux de fusion des documents

Le nombre de documents Elasticsearch étant fusionnés dans l’un des fragments d’index qui sont attribués au nœud Elasticsearch sélectionné.

Données de terrain des nœuds Elasticsearch
FieldData est une structure de données Elasticsearch qui contient des listes de termes dans un index et est conservée dans le JVM Heap. Etant donné que la construction de données de terrain est une opération coûteuse, Elasticsearch met en cache les structures de données de terrain. Elasticsearch peut expulser un cache de données de champ lorsque le segment d’index sous-jacent est supprimé ou fusionné, ou s’il n’y a pas assez de mémoire JVM HEAP pour tous les caches de données de terrain.

Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur les données de terrain Elasticsearch.

Expand
Tableau 7.5. Elasticsearch diagrammes de données de terrain des nœuds
De la métriqueDescription

FieldData taille de la mémoire

La quantité de JVM Heap utilisée pour le cache de données de terrain sur le nœud Elasticsearch sélectionné.

Expulsions de données de terrain

Le nombre de structures de données de terrain qui ont été supprimées du nœud Elasticsearch sélectionné.

Elasticsearch Node Query cache
Dans le cas où les données stockées dans l’index ne changent pas, les résultats des requêtes de recherche sont mis en cache dans un cache de requête de niveau nœud pour réutilisation par Elasticsearch.

Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur le cache de requête de nœud Elasticsearch.

Expand
Tableau 7.6. Elasticsearch Node Query charts
De la métriqueDescription

La taille du cache de requête

La quantité totale de mémoire utilisée pour le cache de requête pour tous les fragments alloués au nœud Elasticsearch sélectionné.

Expulsions de cache de requête

Le nombre d’expulsions de cache de requête sur le nœud Elasticsearch sélectionné.

Cliquez sur le cache de requête

Le nombre de cache de requête frappe sur le nœud Elasticsearch sélectionné.

Le cache de requête manque

Le nombre de cache de requête manque sur le nœud Elasticsearch sélectionné.

Elasticsearch index d’étroitesse
Lors de l’indexation des documents, Elasticsearch stocke les documents dans des segments d’index, qui sont des représentations physiques des données. Dans le même temps, Elasticsearch fusionne périodiquement des segments plus petits dans un segment plus large afin d’optimiser l’utilisation des ressources. Lorsque l’indexation est plus rapide alors la possibilité de fusionner des segments, le processus de fusion ne se termine pas assez rapidement, ce qui peut entraîner des problèmes de recherche et de performance. Afin d’éviter cette situation, Elasticsearch accélère l’indexation, généralement en réduisant le nombre de threads alloués à l’indexation en un seul thread.

Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants au sujet de l’accélération de l’index Elasticsearch.

Expand
Tableau 7.7. Diagrammes d’accélération de l’index
De la métriqueDescription

Indexation de l’étroitesse

Le temps qu’Elasticsearch a réduit les opérations d’indexation sur le nœud Elasticsearch sélectionné.

Fusion de l’étroitesse

Le temps pendant lequel Elasticsearch a été en train de freiner les opérations de fusion du segment sur le nœud Elasticsearch sélectionné.

Les statistiques de Node JVM Heap
Le tableau de bord Logging/Elasticsearch Nodes contient les graphiques suivants sur les opérations JVM Heap.
Expand
Tableau 7.8. Graphiques statistiques de JVM Heap
De la métriqueDescription

Le tas utilisé

Le montant de l’espace JVM Heap alloué qui est utilisé sur le nœud Elasticsearch sélectionné.

Compte de GC

Le nombre d’opérations de collecte des ordures qui ont été effectuées sur le nœud Elasticsearch sélectionné, par collecte des ordures âgées et jeunes.

Heure du GC

Le temps que le JVM a consacré à l’exécution des opérations de collecte des ordures sur le nœud Elasticsearch sélectionné, par la collecte des ordures âgées et jeunes.

7.4. Journalisation avec Kibana
Copier lien

Lorsque vous utilisez le log store ElasticSearch, vous pouvez utiliser la console Kibana pour visualiser les données de log collectées.

En utilisant Kibana, vous pouvez faire ce qui suit avec vos données:

  • Faites une recherche et parcourez les données à l’aide de l’onglet Découvrir.
  • Graphiquez et cartographiez les données à l’aide de l’onglet Visualize.
  • Créez et visualisez des tableaux de bord personnalisés à l’aide de l’onglet Tableau de bord.

L’utilisation et la configuration de l’interface Kibana dépassent le champ d’application de cette documentation. Consultez la documentation Kibana pour plus d’informations sur l’utilisation de l’interface.

Note

Les journaux d’audit ne sont pas stockés par défaut dans l’instance interne Red Hat OpenShift sur AWS Elasticsearch. Afin d’afficher les journaux d’audit dans Kibana, vous devez utiliser l’API Log Forwarding pour configurer un pipeline qui utilise la sortie par défaut pour les journaux d’audit.

7.4.1. Définition des schémas d’indice de Kibana
Copier lien

Le modèle d’index définit les indices Elasticsearch que vous souhaitez visualiser. Afin d’explorer et de visualiser les données dans Kibana, vous devez créer un modèle d’index.

Conditions préalables

  • L’utilisateur doit avoir le rôle de cluster-admin, le rôle de lecture de cluster, ou les deux rôles pour visualiser les indices infra et d’audit dans Kibana. L’utilisateur par défaut de kubeadmin a les autorisations appropriées pour afficher ces indices.

    Lorsque vous pouvez afficher les pods et logs dans les projets par défaut, kube- et openshift, vous devriez pouvoir accéder à ces indices. La commande suivante vous permet de vérifier si l’utilisateur actuel dispose des autorisations appropriées: 

    $ oc auth can-i get pods --subresource log -n <project>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    yes
    Copy to Clipboard Toggle word wrap

    Note

    Les journaux d’audit ne sont pas stockés par défaut dans l’instance interne Red Hat OpenShift sur AWS Elasticsearch. Afin d’afficher les journaux d’audit dans Kibana, vous devez utiliser l’API Log Forwarding pour configurer un pipeline qui utilise la sortie par défaut pour les journaux d’audit.

  • Les documents Elasticsearch doivent être indexés avant de pouvoir créer des modèles d’index. Cela se fait automatiquement, mais cela peut prendre quelques minutes dans un cluster nouveau ou mis à jour.

Procédure

Définir des modèles d’index et créer des visualisations dans Kibana:

  1. Dans le Red Hat OpenShift Service sur la console AWS, cliquez sur le lanceur d’applications et sélectionnez Logging.

  2. Créez vos modèles d’index Kibana en cliquant sur Gestion → Index Patterns → Créer un modèle d’index:

    • Chaque utilisateur doit créer manuellement des modèles d’index lors de la connexion à Kibana la première fois pour voir les journaux de leurs projets. Les utilisateurs doivent créer un modèle d’index nommé application et utiliser le champ temps @timestamp pour afficher leurs journaux de conteneurs.
    • Chaque utilisateur admin doit créer des modèles d’index lorsqu’il est connecté à Kibana la première fois pour l’application, l’infra et les indices d’audit en utilisant le champ temporel @timestamp.
  3. Créez des visualisations Kibana à partir des nouveaux modèles d’index.

7.4.2. Affichage des journaux de clusters dans Kibana
Copier lien

Consultez les journaux des clusters dans la console Web Kibana. Les méthodes de visualisation et de visualisation de vos données dans Kibana qui sont au-delà du champ d’application de cette documentation. Consultez la documentation Kibana pour plus d’informations.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.
  • Les modèles d’indice de Kibana doivent exister.

  • L’utilisateur doit avoir le rôle de cluster-admin, le rôle de lecture de cluster, ou les deux rôles pour visualiser les indices infra et d’audit dans Kibana. L’utilisateur par défaut de kubeadmin a les autorisations appropriées pour afficher ces indices.

    Lorsque vous pouvez afficher les pods et logs dans les projets par défaut, kube- et openshift, vous devriez pouvoir accéder à ces indices. La commande suivante vous permet de vérifier si l’utilisateur actuel dispose des autorisations appropriées: 

    $ oc auth can-i get pods --subresource log -n <project>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    yes
    Copy to Clipboard Toggle word wrap

    Note

    Les journaux d’audit ne sont pas stockés par défaut dans l’instance interne Red Hat OpenShift sur AWS Elasticsearch. Afin d’afficher les journaux d’audit dans Kibana, vous devez utiliser l’API Log Forwarding pour configurer un pipeline qui utilise la sortie par défaut pour les journaux d’audit.

Procédure

Afficher les journaux dans Kibana:

  1. Dans le Red Hat OpenShift Service sur la console AWS, cliquez sur le lanceur d’applications et sélectionnez Logging.

  2. Connectez-vous en utilisant les mêmes informations d’identification que vous utilisez pour vous connecter au service OpenShift Red Hat sur la console AWS.

    L’interface Kibana est lancée.

  3. Dans Kibana, cliquez sur Découvrir.

  4. Choisissez le modèle d’index que vous avez créé dans le menu déroulant dans le coin supérieur gauche: application, audit ou infra.

    Les données du journal s’affichent sous forme de documents horodatés.

  5. Développez l’un des documents chronométrés.

  6. Cliquez sur l’onglet JSON pour afficher l’entrée de journal de ce document.

    Exemple 7.1. Exemple d’entrée de journal d’infrastructure à Kibana

    {
  "_index": "infra-000001",
  "_type": "_doc",
  "_id": "YmJmYTBlNDkZTRmLTliMGQtMjE3NmFiOGUyOWM3",
  "_version": 1,
  "_score": null,
  "_source": {
    "docker": {
      "container_id": "f85fa55bbef7bb783f041066be1e7c267a6b88c4603dfce213e32c1"
    },
    "kubernetes": {
      "container_name": "registry-server",
      "namespace_name": "openshift-marketplace",
      "pod_name": "redhat-marketplace-n64gc",
      "container_image": "registry.redhat.io/redhat/redhat-marketplace-index:v4.7",
      "container_image_id": "registry.redhat.io/redhat/redhat-marketplace-index@sha256:65fc0c45aabb95809e376feb065771ecda9e5e59cc8b3024c4545c168f",
      "pod_id": "8f594ea2-c866-4b5c-a1c8-a50756704b2a",
      "host": "ip-10-0-182-28.us-east-2.compute.internal",
      "master_url": "https://kubernetes.default.svc",
      "namespace_id": "3abab127-7669-4eb3-b9ef-44c04ad68d38",
      "namespace_labels": {
        "openshift_io/cluster-monitoring": "true"
      },
      "flat_labels": [
        "catalogsource_operators_coreos_com/update=redhat-marketplace"
      ]
    },
    "message": "time=\"2020-09-23T20:47:03Z\" level=info msg=\"serving registry\" database=/database/index.db port=50051",
    "level": "unknown",
    "hostname": "ip-10-0-182-28.internal",
    "pipeline_metadata": {
      "collector": {
        "ipaddr4": "10.0.182.28",
        "inputname": "fluent-plugin-systemd",
        "name": "fluentd",
        "received_at": "2020-09-23T20:47:15.007583+00:00",
        "version": "1.7.4 1.6.0"
      }
    },
    "@timestamp": "2020-09-23T20:47:03.422465+00:00",
    "viaq_msg_id": "YmJmYTBlNDktMDMGQtMjE3NmFiOGUyOWM3",
    "openshift": {
      "labels": {
        "logging": "infra"
      }
    }
  },
  "fields": {
    "@timestamp": [
      "2020-09-23T20:47:03.422Z"
    ],
    "pipeline_metadata.collector.received_at": [
      "2020-09-23T20:47:15.007Z"
    ]
  },
  "sort": [
    1600894023422
  ]
}
    Copy to Clipboard Toggle word wrap

7.4.3. Configuration de Kibana
Copier lien

Il est possible de configurer à l’aide de la console Kibana en modifiant la ressource personnalisée ClusterLogging (CR).

7.4.3.1. Configuration des limites CPU et mémoire
Copier lien

Les composants de journalisation permettent d’ajuster les limites du CPU et de la mémoire.

Procédure

  1. É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:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources:
    1 
    
        limits:
          memory: 16Gi
        requests:
          cpu: 200m
          memory: 16Gi
      storage:
        storageClassName: "gp2"
        size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
    2 
    
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      proxy:
        resources:
    3 
    
          limits:
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      replicas: 2
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
    4 
    
          limits:
            memory: 736Mi
          requests:
            cpu: 200m
            memory: 736Mi
    Copy to Clipboard Toggle word wrap
    1
    Indiquez les limites du CPU et de la mémoire et les demandes pour le log Store au besoin. Dans le cas d’Elasticsearch, vous devez ajuster à la fois la valeur de la demande et la valeur limite.
    2 3
    Indiquez les limites du CPU et de la mémoire et les demandes pour le visualiseur de journal au besoin.
    4
    Indiquez les limites de CPU et de mémoire et les demandes pour le collecteur de journaux au besoin.

Il est possible de mettre à l’échelle le pod qui héberge le visualiseur de log pour la redondance.

Procédure

  1. É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 
    $ oc edit ClusterLogging instance

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

spec:
  visualization:
    type: "kibana"
    kibana:
      replicas: 1
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez le nombre de nœuds Kibana.

Chapitre 8. Configuration de votre déploiement Logging
Copier lien

Il est possible de configurer les limites CPU et mémoire pour chacun des composants d’enregistrement au besoin.

8.1.1. Configuration des limites CPU et mémoire
Copier lien

Les composants de journalisation permettent d’ajuster les limites du CPU et de la mémoire.

Procédure

  1. É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:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      resources:
    1 
    
        limits:
          memory: 16Gi
        requests:
          cpu: 200m
          memory: 16Gi
      storage:
        storageClassName: "gp2"
        size: "200G"
      redundancyPolicy: "SingleRedundancy"
  visualization:
    type: "kibana"
    kibana:
      resources:
    2 
    
        limits:
          memory: 1Gi
        requests:
          cpu: 500m
          memory: 1Gi
      proxy:
        resources:
    3 
    
          limits:
            memory: 100Mi
          requests:
            cpu: 100m
            memory: 100Mi
      replicas: 2
  collection:
    logs:
      type: "fluentd"
      fluentd:
        resources:
    4 
    
          limits:
            memory: 736Mi
          requests:
            cpu: 200m
            memory: 736Mi
    Copy to Clipboard Toggle word wrap
    1
    Indiquez les limites du CPU et de la mémoire et les demandes pour le log Store au besoin. Dans le cas d’Elasticsearch, vous devez ajuster à la fois la valeur de la demande et la valeur limite.
    2 3
    Indiquez les limites du CPU et de la mémoire et les demandes pour le visualiseur de journal au besoin.
    4
    Indiquez les limites de CPU et de mémoire et les demandes pour le collecteur de journaux au besoin.

Chapitre 9. Collecte et transfert de journaux
Copier lien

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

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
Copier lien

Le collecteur de journaux est un jeu de démons qui déploie des pods dans chaque Red Hat OpenShift Service sur AWS pour collecter les journaux de conteneurs et de 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 du service OpenShift Red Hat sur AWS.
  • /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
Copier lien

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 Toggle word wrap

9.1.1.2. Limites de collecte des journaux
Copier lien

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
Copier lien
Expand
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)

✓

✓

Expand
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

✓

✓

Expand
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

✓

✓

Expand
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

✓

 
Expand
Tableau 9.5. La visibilité
CaractéristiqueFluentdLe vecteur

Les métriques

✓

✓

Tableau de bord

✓

✓

Alertes

✓

✓

Expand
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
Copier lien

Les extrants suivants sont pris en charge:

Expand
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
Copier lien

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
Copier lien

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
Copier lien

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
Copier lien

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.

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-logging, 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.

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 Toggle word wrap

9.2. Log types de sortie
Copier lien

Les sorties définissent la destination où les journaux sont envoyés à partir d’un transmetteur de journaux. Il est possible de configurer plusieurs types de sorties dans la ressource personnalisée ClusterLogForwarder (CR) pour envoyer des journaux à des serveurs prenant en charge différents protocoles.

9.2.1. Les sorties de transfert de journal prises en charge
Copier lien

Les sorties peuvent être l’un des types suivants:

Expand
Tableau 9.8. Les types de sortie de journal pris en charge
Le type de sortieLe ProtocoleTesté avecJournalisation des versionsLe type de collecteur pris en charge

Elasticsearch v6

HTTP 1.1

6.8.1, 6.8.23

5.6+

Fluentd, vecteur

Elasticsearch v7

HTTP 1.1

7.12.2, 7.17.7, 7.10.1

5.6+

Fluentd, vecteur

Elasticsearch v8

HTTP 1.1

8.4.3, 8.6.1

5.6+

Fluentd [1], Vecteur

Fluent vers l’avant

Fluentd forward v1

Fluentd 1.14.6, Logstash 7.10.1, Fluentd 1.14.5

5.4+

Fluentd

Google Cloud Logging

EST sur HTTPS

Les dernières

5.7+

Le vecteur

HTTP

HTTP 1.1

Fluentd 1.14.6, vecteur 0,21

5.7+

Fluentd, vecteur

Kafka

Kafka 0.11

Kafka 2.4.1, 2.7.0, 3.3.1

5.4+

Fluentd, vecteur

Loki

EST sur HTTP et HTTPS

2.3.0, 2.5.0, 2.7, 2.2.1

5.4+

Fluentd, vecteur

À propos de Splunk

HEC

8.2.9, 9.0.0

5.7+

Le vecteur

Le syslog

LE RFC3164, RFC5424

8.37.0-9.el7, rsyslog-8.39.0

5.4+

Fluentd, Vecteur [2]

Amazon CloudWatch

EST sur HTTPS

Les dernières

5.4+

Fluentd, vecteur

  1. Fluentd ne prend pas en charge Elasticsearch 8 dans la version d’enregistrement 5.6.2.
  2. Le vecteur prend en charge Syslog dans la version de journalisation 5.7 et supérieure.

9.2.2. Descriptions de type de sortie
Copier lien

défaut par défaut

Le magasin de journaux sur le groupe, Red Hat a géré le log store. Il n’est pas nécessaire de configurer la sortie par défaut.

Note

Lorsque vous configurez une sortie par défaut, vous recevez un message d’erreur, car le nom de sortie par défaut est réservé pour référencer le log Store géré par Red Hat.

Loki
Loki, un système d’agrégation de log multi-locataires, évolutif horizontalement, hautement disponible.
Kafka
C’est un courtier Kafka. La sortie kafka peut utiliser une connexion TCP ou TLS.
Elasticsearch
Instance externe Elasticsearch. La sortie de recherche élastique peut utiliser une connexion TLS.
FluentdForward

C’est une solution externe d’agrégation de log qui prend en charge Fluentd. Cette option utilise les protocoles Fluentd forward. La sortie fluentForward peut utiliser une connexion TCP ou TLS et prend en charge l’authentification à clé partagée en fournissant un champ_key partagé dans un secret. L’authentification à clé partagée peut être utilisée avec ou sans TLS.

Important

La sortie fluentdForward n’est prise en charge que si vous utilisez le collecteur Fluentd. Il n’est pas pris en charge si vous utilisez le collecteur vectoriel. Lorsque vous utilisez le collecteur vectoriel, vous pouvez transférer les journaux vers Fluentd en utilisant la sortie http.

le syslog
C’est une solution d’agrégation de journal externe qui prend en charge les protocoles syslog RFC3164 ou RFC5424. La sortie syslog peut utiliser une connexion UDP, TCP ou TLS.
CloudWatch
Amazon CloudWatch, un service de surveillance et de stockage log hébergé par Amazon Web Services (AWS).
cloudlogging
Google Cloud Logging, un service de surveillance et de stockage log hébergé par Google Cloud Platform (GCP).

9.3. Activer le transfert de journaux JSON
Copier lien

Il est possible de configurer l’API Log Forwarding pour analyser les chaînes JSON dans un objet structuré.

9.3.1. Analyse des journaux JSON
Copier lien

Il est possible d’utiliser un objet ClusterLogForwarder pour analyser les logs JSON dans un objet structuré et les transmettre à une sortie prise en charge.

Afin d’illustrer comment cela fonctionne, supposons que vous ayez l’entrée de journal JSON structurée suivante:

Exemple d’entrée de journal JSON structurée

{"level":"info","name":"fred","home":"bedrock"}
Copy to Clipboard Toggle word wrap

Afin d’activer l’analyse du journal JSON, vous ajoutez parse: json à un pipeline dans le ClusterLogForwarder CR, comme indiqué dans l’exemple suivant:

Exemple d’extrait montrant l’analyse: json

pipelines:
- inputRefs: [ application ]
  outputRefs: myFluentd
  parse: json
Copy to Clipboard Toggle word wrap

Lorsque vous activez l’analyse des journaux JSON en utilisant parse: json, le CR copie l’entrée de journal structurée JSON dans un champ structuré, comme indiqué dans l’exemple suivant:

Exemple de sortie structurée contenant l’entrée de journal JSON structurée

{"structured": { "level": "info", "name": "fred", "home": "bedrock" },
 "more fields..."}
Copy to Clipboard Toggle word wrap

Important

Dans le cas où l’entrée de journal ne contient pas de JSON structuré valide, le champ structuré est absent.

Lorsque vos journaux JSON suivent plus d’un schéma, les stocker dans un seul index peut causer des conflits de type et des problèmes de cardinalité. Afin d’éviter cela, vous devez configurer la ressource personnalisée ClusterLogForwarder (CR) pour regrouper chaque schéma en une seule définition de sortie. De cette façon, chaque schéma est transmis à un index séparé.

Important

Lorsque vous transmettez les logs JSON à l’instance Elasticsearch par défaut gérée par OpenShift Logging, elle génère de nouveaux indices en fonction de votre configuration. Afin d’éviter les problèmes de performance associés à un trop grand nombre d’indices, envisagez de maintenir le nombre de schémas possibles en standardisant les schémas communs.

Les types de structure

Dans le ClusterLogForwarder CR, vous pouvez utiliser les types de structure suivants pour construire des noms d’index pour le magasin de journal Elasticsearch:

  • StructureTypeKey est le nom d’un champ de message. La valeur de ce champ est utilisée pour construire le nom de l’index.

    • Kubernetes.labels.&lt;key&gt; est l’étiquette de pod Kubernetes dont la valeur est utilisée pour construire le nom de l’index.
    • l’élément OpenShift.labels.&lt;key&gt; est l’élément pipeline.label.&lt;key&gt; dans le ClusterLogForwarder CR dont la valeur est utilisée pour construire le nom de l’index.
    • Kubernetes.container_name utilise le nom du conteneur pour construire le nom de l’index.
  • StructureTypeName: Si le champ StructureTypeKey n’est pas défini ou que sa clé n’est pas présente, la valeur StructureTypeName est utilisée comme type structuré. Lorsque vous utilisez à la fois le champ StructureTypeKey et le champ StructureTypeName ensemble, la valeur StructureTypeName fournit un nom d’index de retour si la clé dans le champ StructureTypeKey est absente des données de journal JSON.
Note

Bien que vous puissiez définir la valeur de StructureTypeKey à n’importe quel champ affiché dans le sujet "Log Record Fields", les champs les plus utiles sont affichés dans la liste précédente des types de structure.

A StructureTypeKey: kubernetes.labels.&lt;key&gt; exemple

Imaginez ce qui suit:

  • Le cluster exécute des pods d’applications qui produisent des logs JSON dans deux formats différents, "apache" et "google".
  • L’utilisateur étiquete ces pods d’application avec logFormat=apache et logFormat=google.
  • Dans votre fichier ClusterLogForwarder CR YAML, vous utilisez l’extrait suivant. 
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat
1 

      structuredTypeName: nologformat
  pipelines:
  - inputRefs:
    - application
    outputRefs:
    - default
    parse: json
2
Copy to Clipboard Toggle word wrap
1
Utilise la valeur de la paire clé-valeur qui est formée par l’étiquette logFormat Kubernetes.
2
Active l’analyse des journaux JSON.

Dans ce cas, l’enregistrement de journal structuré suivant va à l’index app-apache-écriture: 

{
  "structured":{"name":"fred","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "apache", ...}}
}
Copy to Clipboard Toggle word wrap

Et l’enregistrement de journal structuré suivant va à l’index app-google-écriture: 

{
  "structured":{"name":"wilma","home":"bedrock"},
  "kubernetes":{"labels":{"logFormat": "google", ...}}
}
Copy to Clipboard Toggle word wrap

Exemple StructureTypeKey: openshift.labels.&lt;key&gt;

Imaginez que vous utilisez l’extrait suivant dans votre fichier ClusterLogForwarder CR YAML. 

outputDefaults:
 elasticsearch:
    structuredTypeKey: openshift.labels.myLabel
1 

    structuredTypeName: nologformat
pipelines:
 - name: application-logs
   inputRefs:
   - application
   - audit
   outputRefs:
   - elasticsearch-secure
   - default
   parse: json
   labels:
     myLabel: myValue
2
Copy to Clipboard Toggle word wrap
1
Utilise la valeur de la paire clé-valeur qui est formée par le label OpenShift myLabel.
2
L’élément myLabel donne sa valeur de chaîne, myValue, à l’enregistrement de journal structuré.

Dans ce cas, l’enregistrement de journal structuré suivant va à l’index app-myValue-write: 

{
  "structured":{"name":"fred","home":"bedrock"},
  "openshift":{"labels":{"myLabel": "myValue", ...}}
}
Copy to Clipboard Toggle word wrap

Considérations supplémentaires

  • L’indice Elasticsearch pour les enregistrements structurés est formé en prépendant "app-" au type structuré et en ajoutant "-write".
  • Les enregistrements non structurés ne sont pas envoyés à l’index structuré. Ils sont indexés comme d’habitude dans les indices d’application, d’infrastructure ou d’audit.
  • En l’absence de type structuré non vide, dirigez un enregistrement non structuré sans champ structuré.

Il est important de ne pas surcharger Elasticsearch avec trop d’indices. Il suffit d’utiliser des types structurés distincts pour des formats de journal distincts, pas pour chaque application ou espace de noms. Ainsi, la plupart des applications Apache utilisent le même format de journal JSON et le même type structuré, comme LogApache.

Dans le cas d’un magasin de journal Elasticsearch, si vos entrées de journal JSON suivent différents schémas, configurez la ressource personnalisée ClusterLogForwarder (CR) pour regrouper chaque schéma JSON en une seule définition de sortie. De cette façon, Elasticsearch utilise un index distinct pour chaque schéma.

Important

Étant donné que le transfert de différents schémas vers le même index peut causer des conflits de type et des problèmes de cardinalité, vous devez effectuer cette configuration avant de transmettre les données au magasin Elasticsearch.

Afin d’éviter les problèmes de performance associés à un trop grand nombre d’indices, envisagez de maintenir le nombre de schémas possibles en standardisant les schémas communs.

Procédure

  1. Ajoutez l’extrait suivant à votre fichier ClusterLogForwarder CR YAML. 

    outputDefaults:
 elasticsearch:
    structuredTypeKey: <log record field>
    structuredTypeName: <name>
pipelines:
- inputRefs:
  - application
  outputRefs: default
  parse: json
    Copy to Clipboard Toggle word wrap
  2. Utilisez le champ StructureTypeKey pour spécifier l’un des champs d’enregistrement de log.

  3. Utilisez le champ StructureTypeName pour spécifier un nom.

    Important

    Afin d’analyser les logs JSON, vous devez définir les champs StructureTypeKey et StructureTypeName.

  4. Dans le cas des entréesRefs, spécifiez les types de journaux à transmettre en utilisant ce pipeline, comme l’application, l’infrastructure ou l’audit.
  5. Ajouter l’analyse: élément json aux pipelines.

  6. Créer l’objet CR: 

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

    Le Red Hat OpenShift Logging Operator redéploie les pods collector. Cependant, s’ils ne redéployent pas, supprimez les pods collector pour les forcer à redéployer. 

    $ oc delete pod --selector logging-infra=collector
    Copy to Clipboard Toggle word wrap

Il est possible d’envoyer des journaux structurés à partir de différents conteneurs à l’intérieur d’un même pod vers différents indices. Afin d’utiliser cette fonctionnalité, vous devez configurer le pipeline avec le support multi-conteneurs et annoter les pods. Les journaux sont écrits dans des indices avec un préfixe d’application-. Il est recommandé de configurer Elasticsearch avec des alias pour y répondre.

Important

Le formatage JSON des journaux varie selon l’application. Étant donné que la création de trop d’indices impacte la performance, limitez votre utilisation de cette fonctionnalité à la création d’indices pour les journaux qui ont des formats JSON incompatibles. Les requêtes permettent de séparer les journaux de différents espaces de noms ou d’applications avec des formats JSON compatibles.

Conditions préalables

  • Enregistrement pour Red Hat OpenShift: 5.5

Procédure

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputDefaults:
    elasticsearch:
      structuredTypeKey: kubernetes.labels.logFormat
    1 
    
      structuredTypeName: nologformat
      enableStructuredContainerLogs: true
    2 
    
  pipelines:
  - inputRefs:
    - application
    name: application-logs
    outputRefs:
    - default
    parse: json
    Copy to Clipboard Toggle word wrap
    1
    Utilise la valeur de la paire clé-valeur qui est formée par l’étiquette logFormat Kubernetes.
    2
    Active les sorties multiconteneurs.

  2. Créer ou modifier un fichier YAML qui définit l’objet Pod CR: 

    apiVersion: v1
kind: Pod
metadata:
  annotations:
    containerType.logging.openshift.io/heavy: heavy
    1 
    
    containerType.logging.openshift.io/low: low
spec:
  containers:
  - name: heavy
    2 
    
    image: heavyimage
  - name: low
    image: lowimage
    Copy to Clipboard Toggle word wrap
    1
    Format: containerType.logging.openshift.io/&lt;container-name&gt;: &lt;index&gt;
    2
    Les noms d’annotation doivent correspondre aux noms de conteneurs
Avertissement

Cette configuration pourrait augmenter considérablement le nombre de fragments sur le cluster.

Ressources supplémentaires

9.4. Configuration du transfert de journaux
Copier lien

Dans un déploiement de journalisation, les journaux de conteneurs et d’infrastructures sont transférés au log store interne défini dans la ressource personnalisée ClusterLogging (CR) par défaut.

Les journaux d’audit ne sont pas transmis au log store interne par défaut, car cela ne fournit pas de stockage sécurisé. Il vous incombe de vous assurer que le système vers lequel vous transmettez les journaux d’audit est conforme à vos réglementations organisationnelles et gouvernementales et qu’il est correctement sécurisé.

Lorsque cette configuration par défaut répond à vos besoins, vous n’avez pas besoin de configurer un ClusterLogForwarder CR. En cas d’existence d’un ClusterLogForwarder CR, les journaux ne sont pas transmis au log store interne à moins qu’un pipeline ne soit défini qui contient la sortie par défaut.

Afin d’envoyer des journaux à des points de terminaison spécifiques à l’intérieur et à l’extérieur de votre service OpenShift Red Hat sur le cluster AWS, vous spécifiez une combinaison de sorties et de pipelines dans une ressource personnalisée ClusterLogForwarder (CR). Il est également possible d’utiliser des entrées pour transmettre les journaux d’applications associés à un projet spécifique vers un point de terminaison. L’authentification est fournie par un objet Kubernetes Secret.

gazoduc

Définit le routage simple d’un type de journal vers une ou plusieurs sorties, ou les journaux que vous souhaitez envoyer. Les types de journaux sont l’un des suivants:

  • demande. Journaux de conteneurs générés par les applications utilisateur s’exécutant dans le cluster, à l’exception des applications de conteneurs d’infrastructure.
  • C) Infrastructures. Journaux de conteneurs à partir des pods qui s’exécutent dans les projets openshift*, kube* ou par défaut et journaux de journal provenant du système de fichiers de nœuds.
  • audit. Journaux d’audit générés par le système d’audit des nœuds, audité, serveur API Kubernetes, serveur API OpenShift et réseau OVN.

Il est possible d’ajouter des étiquettes aux messages de log sortants en utilisant des paires key:value dans le pipeline. À titre d’exemple, vous pouvez ajouter une étiquette aux messages qui sont transférés à d’autres centres de données ou étiqueter les journaux par type. Les étiquettes qui sont ajoutées aux objets sont également transmises avec le message journal.

entrée

Transmet les journaux d’application associés à un projet spécifique à un pipeline.

Dans le pipeline, vous définissez les types de journaux à transmettre à l’aide d’un paramètre inputRef et où transférer les journaux à l’aide d’un paramètre outputRef.

Le secret
Carte key:value qui contient des données confidentielles telles que les identifiants d’utilisateur.

À noter ce qui suit:

  • Lorsque vous ne définissez pas de pipeline pour un type de journal, les journaux des types non définis sont supprimés. À titre d’exemple, si vous spécifiez un pipeline pour les types d’application et d’audit, mais que vous ne spécifiez pas un pipeline pour le type d’infrastructure, les journaux d’infrastructure sont supprimés.
  • Il est possible d’utiliser plusieurs types de sorties dans la ressource personnalisée ClusterLogForwarder (CR) pour envoyer des journaux à des serveurs prenant en charge différents protocoles.

L’exemple suivant transmet les journaux d’audit à une instance externe sécurisée Elasticsearch, les journaux d’infrastructure à une instance externe Elasticsearch non sécurisée, les journaux des applications à un courtier Kafka et les journaux d’applications du projet my-apps-logs à l’instance interne Elasticsearch.

Exemple de sortie de journal et de pipelines

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
1 

  namespace: <log_forwarder_namespace>
2 

spec:
  serviceAccountName: <service_account_name>
3 

  outputs:
   - name: elasticsearch-secure
4 

     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: elasticsearch
   - name: elasticsearch-insecure
5 

     type: "elasticsearch"
     url: http://elasticsearch.insecure.com:9200
   - name: kafka-app
6 

     type: "kafka"
     url: tls://kafka.secure.com:9093/app-topic
  inputs:
7 

   - name: my-app-logs
     application:
        namespaces:
        - my-project
  pipelines:
   - name: audit-logs
8 

     inputRefs:
      - audit
     outputRefs:
      - elasticsearch-secure
      - default
     labels:
       secure: "true"
9 

       datacenter: "east"
   - name: infrastructure-logs
10 

     inputRefs:
      - infrastructure
     outputRefs:
      - elasticsearch-insecure
     labels:
       datacenter: "west"
   - name: my-app
11 

     inputRefs:
      - my-app-logs
     outputRefs:
      - default
   - inputRefs:
12 

      - application
     outputRefs:
      - kafka-app
     labels:
       datacenter: "south"
Copy to Clipboard Toggle word wrap

1
Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
2
Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
3
Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
4
Configuration pour une sortie Elasticsearch sécurisée à l’aide d’un secret avec une URL sécurisée.
  • Il s’agit d’un nom pour décrire la sortie.
  • Le type de sortie: la recherche élastique.
  • L’URL sécurisée et le port de l’instance Elasticsearch en tant qu’URL absolue valide, y compris le préfixe.
  • Le secret requis par le point de terminaison pour la communication TLS. Le secret doit exister dans le projet openshift-logging.
5
Configuration pour une sortie Elasticsearch non sécurisée:
  • Il s’agit d’un nom pour décrire la sortie.
  • Le type de sortie: la recherche élastique.
  • L’URL et le port non sécurisés de l’instance Elasticsearch en tant qu’URL absolue valide, y compris le préfixe.
6
Configuration d’une sortie Kafka à l’aide d’une communication TLS authentifiée par le client via une URL sécurisée:
  • Il s’agit d’un nom pour décrire la sortie.
  • Le type de sortie: kafka.
  • Indiquez l’URL et le port du courtier Kafka comme URL absolue valide, y compris le préfixe.
7
Configuration pour une entrée pour filtrer les journaux des applications à partir de l’espace de noms de mon projet.
8
Configuration d’un pipeline pour envoyer des journaux d’audit à l’instance externe sécurisée Elasticsearch:
  • C’est un nom pour décrire le pipeline.
  • L’entréeRefs est le type de journal, dans cet exemple d’audit.
  • La sortieRefs est le nom de la sortie à utiliser, dans cet exemple élastique-sécurisé pour transmettre à l’instance sécurisée Elasticsearch et par défaut pour transmettre à l’instance interne Elasticsearch.
  • Facultatif: Étiquettes à ajouter aux journaux.
9
Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux. Citez des valeurs comme "vrai" afin qu’elles soient reconnues comme des valeurs de chaîne, et non comme un booléen.
10
Configuration d’un pipeline pour envoyer des journaux d’infrastructure à l’instance externe Elasticsearch non sécurisée.
11
Configuration d’un pipeline pour envoyer des journaux du projet de mon projet à l’instance interne Elasticsearch.
  • C’est un nom pour décrire le pipeline.
  • L’entréeRefs est une entrée spécifique: my-app-logs.
  • La sortieRefs est par défaut.
  • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.
12
Configuration d’un pipeline pour envoyer des journaux au courtier Kafka, sans nom de pipeline:
  • L’entréeRefs est le type de journal, dans cet exemple d’application.
  • La sortieRefs est le nom de la sortie à utiliser.
  • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.
Gestion du journal Fluentd lorsque l’agrégateur de journal externe n’est pas disponible

Lorsque votre agrégateur de journalisation externe devient indisponible et ne peut pas recevoir de journaux, Fluentd continue de collecter des journaux et de les stocker dans un tampon. Lorsque l’agrégateur de journal devient disponible, le transfert de journaux reprend, y compris les journaux tamponnés. Lorsque le tampon se remplit complètement, Fluentd cesse de collecter les journaux. Le service Red Hat OpenShift sur AWS tourne les journaux et les supprime. Il n’est pas possible d’ajuster la taille du tampon ou d’ajouter une revendication de volume persistant (PVC) à l’ensemble ou aux pods Fluentd daemon.

Clés d’autorisation prises en charge

Les types de clés communs sont fournis ici. Certains types de sortie prennent en charge d’autres clés spécialisées, documentées avec le champ de configuration spécifique à la sortie. Les clés secrètes sont facultatives. Activez les fonctions de sécurité que vous souhaitez en définissant les clés pertinentes. Il vous incombe de créer et de maintenir toute configuration supplémentaire que des destinations externes pourraient nécessiter, telles que des clés et des secrets, des comptes de service, des ouvertures de ports ou une configuration proxy globale. L’enregistrement de décalage ouvert ne tentera pas de vérifier une inadéquation entre les combinaisons d’autorisation.

La sécurité des couches de transport (TLS)

L’utilisation d’une URL TLS (http://... ou ssl://...) sans secret permet une authentification basique côté serveur TLS. Des fonctionnalités TLS supplémentaires sont activées en incluant un secret et en définissant les champs optionnels suivants:

  • phrase de passe: (string) Passphrase pour décoder une clé privée TLS codée. J’ai besoin de tls.key.
  • ca-bundle.crt: (string) Nom du fichier d’une CA client pour l’authentification du serveur.
Nom d’utilisateur et mot de passe
  • nom d’utilisateur: (string) Nom d’utilisateur d’authentification. Demande un mot de passe.
  • mot de passe: (string) Mot de passe d’authentification. Nécessite un nom d’utilisateur.
Couche de sécurité d’authentification simple (SASL)
  • activez ou désactivez explicitement SASL.enable (boolean). En cas de manque, SASL est automatiquement activé lorsque l’une des autres touches sasl.
  • liste des noms de mécanisme SASL.Mécanismes: (array) Liste des noms de mécanisme SASL autorisés. En cas de manque ou de vide, le système par défaut est utilisé.
  • (boolean) Autoriser les mécanismes qui envoient des mots de passe en texte clair. Défaut à false.
9.4.1.1. Créer un secret
Copier lien

Il est possible de créer un secret dans le répertoire qui contient votre certificat et vos fichiers clés à l’aide de la commande suivante: 

$ oc create secret generic -n <namespace> <secret_name> \
  --from-file=ca-bundle.crt=<your_bundle_file> \
  --from-literal=username=<your_username> \
  --from-literal=password=<your_password>
Copy to Clipboard Toggle word wrap
Note

Les secrets génériques ou opaques sont recommandés pour les meilleurs résultats.

9.4.2. Création d’un transmetteur de journaux
Copier lien

Afin de créer un transmetteur de journaux, vous devez créer un ClusterLogForwarder CR qui spécifie les types d’entrée de journal que le compte de service peut collecter. Il est également possible de spécifier les sorties vers lesquelles les journaux peuvent être transférés. Lorsque vous utilisez la fonction d’expéditeur multi log, vous devez également consulter le compte de service dans le ClusterLogForwarder CR.

Dans n’importe quel nom, vous pouvez créer des ressources personnalisées ClusterLogForwarder (CRs) dans n’importe quel espace de noms. Lorsque vous utilisez une implémentation héritée, le ClusterLogForwarder CR doit être nommé instance, et doit être créé dans l’espace de noms openshift-logging.

Important

Il vous faut des autorisations d’administrateur pour l’espace de noms où vous créez le ClusterLogForwarder CR.

Exemple de ressource ClusterLogForwarder

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
1 

  namespace: <log_forwarder_namespace>
2 

spec:
  serviceAccountName: <service_account_name>
3 

  pipelines:
   - inputRefs:
     - <log_type>
4 

     outputRefs:
     - <output_name>
5 

  outputs:
  - name: <output_name>
6 

    type: <output_type>
7 

    url: <log_output_url>
8 

# ...
Copy to Clipboard Toggle word wrap

1
Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
2
Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
3
Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
4
Les types de journaux qui sont collectés. La valeur de ce champ peut être l’audit pour les journaux d’audit, les applications pour les journaux d’applications, l’infrastructure pour les journaux d’infrastructure ou une entrée nommée qui a été définie pour votre application.
5 7
Le type de sortie vers lequel vous souhaitez transférer les journaux. La valeur de ce champ peut être par défaut, loki, kafka, élastique, fluentdForward, syslog ou cloudwatch.
Note

Le type de sortie par défaut n’est pas pris en charge dans les implémentations mutli log forwarder.

6
Le nom de la sortie vers laquelle vous souhaitez transférer les journaux.
8
L’URL de la sortie vers laquelle vous souhaitez transférer les journaux.

9.4.3. Charge utile du journal de réglage et livraison
Copier lien

Dans l’enregistrement des versions 5.9 et plus récentes, la spécification de réglage de la ressource personnalisée ClusterLogForwarder (CR) fournit un moyen de configurer votre déploiement pour prioriser le débit ou la durabilité des journaux.

Ainsi, si vous devez réduire la possibilité de perte de journal lorsque le collecteur redémarre, ou si vous avez besoin de messages de journal recueillis pour survivre à un redémarrage du collecteur pour soutenir les mandats réglementaires, vous pouvez régler votre déploiement pour prioriser la durabilité des journaux. Lorsque vous utilisez des sorties qui ont des limites strictes sur la taille des lots qu’ils peuvent recevoir, vous voudrez peut-être régler votre déploiement pour prioriser le débit des journaux.

Important

Afin d’utiliser cette fonctionnalité, votre déploiement de journalisation doit être configuré pour utiliser le collecteur vectoriel. La spécification de réglage dans le ClusterLogForwarder CR n’est pas prise en charge lors de l’utilisation du collecteur Fluentd.

L’exemple suivant montre les options ClusterLogForwarder CR que vous pouvez modifier pour régler les sorties de l’expéditeur journal:

Exemple ClusterLogForwarder CR options de réglage

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  tuning:
    delivery: AtLeastOnce
1 

    compression: none
2 

    maxWrite: <integer>
3 

    minRetryDuration: 1s
4 

    maxRetryDuration: 1s
5 

# ...
Copy to Clipboard Toggle word wrap

1
Indiquez le mode de livraison pour le transfert de journaux.
  • La livraison AtLeastOnce signifie que si l’expéditeur de journaux se bloque ou est redémarré, tous les journaux qui ont été lus avant le crash mais qui n’ont pas été envoyés à leur destination sont réenvoyés. Il est possible que certains journaux soient dupliqués après un crash.
  • La livraison AtMostOnce signifie que l’expéditeur de journaux ne fait aucun effort pour récupérer les journaux perdus lors d’un accident. Ce mode donne un meilleur débit, mais peut entraîner une plus grande perte de log.
2
En spécifiant une configuration de compression, les données sont compressées avant qu’elles ne soient envoyées sur le réseau. Il est à noter que tous les types de sortie ne supportent pas la compression, et si le type de compression spécifié n’est pas pris en charge par la sortie, cela entraîne une erreur. Les valeurs possibles pour cette configuration ne sont pas pour aucune compression, gzip, snappy, zlib ou zstd. la compression lz4 est également disponible si vous utilisez une sortie Kafka. Consultez le tableau « Types de compression soutenus pour les sorties de réglage » pour plus d’informations.
3
Indique une limite pour la charge utile maximale d’une seule opération d’envoi à la sortie.
4
Indique une durée minimale d’attente entre les tentatives avant de réessayer la livraison après un échec. Cette valeur est une chaîne de caractères, et peut être spécifiée comme millisecondes (ms), secondes (s) ou minutes (m).
5
Indique une durée maximale d’attente entre les tentatives avant de réessayer la livraison après un échec. Cette valeur est une chaîne de caractères, et peut être spécifiée comme millisecondes (ms), secondes (s) ou minutes (m).
Expand
Tableau 9.9. Les types de compression pris en charge pour les sorties de réglage
Algorithme de compressionÀ propos de SplunkAmazon CloudwatchElasticsearch 8LokiStackApache KafkaHTTPLe syslogGoogle CloudLa surveillance Microsoft Azure

gzip

A) X

A) X

A) X

A) X

 

A) X

   

C’est un clin d’œil

 

A) X

 

A) X

A) X

A) X

   

le zlib

 

A) X

A) X

  

A) X

   

le zstd

 

A) X

  

A) X

A) X

   

lz4

    

A) X

    

9.4.4. Activer la détection d’exceptions multilignes
Copier lien

Active la détection d’erreurs multilignes des journaux de conteneurs.

Avertissement

L’activation de cette fonctionnalité pourrait avoir des répercussions sur les performances et peut nécessiter des ressources informatiques supplémentaires ou des solutions de journalisation alternatives.

Les analyseurs de journaux identifient souvent de manière incorrecte des lignes distinctes de la même exception que des exceptions distinctes. Cela conduit à des entrées de journal supplémentaires et une vue incomplète ou inexacte des informations tracées.

Exemple d’exception Java

java.lang.NullPointerException: Cannot invoke "String.toString()" because "<param1>" is null
    at testjava.Main.handle(Main.java:47)
    at testjava.Main.printMe(Main.java:19)
    at testjava.Main.main(Main.java:10)
Copy to Clipboard Toggle word wrap

  • Afin de permettre à l’enregistrement de détecter des exceptions multilignes et de les réassembler en une seule entrée de journal, assurez-vous que la ressource personnalisée ClusterLogForwarder (CR) contient un champ DétecterMultilineErrors, avec une valeur de true.

Exemple ClusterLogForwarder CR

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-app-logs
      inputRefs:
        - application
      outputRefs:
        - default
      detectMultilineErrors: true
Copy to Clipboard Toggle word wrap

9.4.4.1. Détails
Copier lien

Lorsque les messages de log apparaissent comme une séquence consécutive formant une trace de pile d’exception, ils sont combinés en un seul enregistrement de journal unifié. Le contenu du premier message journal est remplacé par le contenu concaténé de tous les champs de message de la séquence.

Expand
Tableau 9.10. Langues prises en charge par collectionneur
LangueFluentdLe vecteur

Java

✓

✓

JS

✓

✓

♪ Ruby ♪

✓

✓

À propos de Python

✓

✓

Golang

✓

✓

À PROPOS DE PHP

✓

✓

Dart

✓

✓

9.4.4.2. Résolution de problèmes
Copier lien

Lorsqu’elle est activée, la configuration du collecteur inclura une nouvelle section avec type:

Exemple de section de configuration vectorielle

[transforms.detect_exceptions_app-logs]
 type = "detect_exceptions"
 inputs = ["application"]
 languages = ["All"]
 group_by = ["kubernetes.namespace_name","kubernetes.pod_name","kubernetes.container_name"]
 expire_after_ms = 2000
 multiline_flush_interval_ms = 1000
Copy to Clipboard Toggle word wrap

Exemple de section de configuration fluide

<label @MULTILINE_APP_LOGS>
  <match kubernetes.**>
    @type detect_exceptions
    remove_tag_prefix 'kubernetes'
    message message
    force_line_breaks true
    multiline_flush_interval .2
  </match>
</label>
Copy to Clipboard Toggle word wrap

9.4.5. Les journaux de transfert vers Splunk
Copier lien

Il est possible d’envoyer les journaux vers le collecteur d’événements Splunk HTTP (HEC) en plus ou au lieu du service interne Red Hat OpenShift sur AWS log store.

Note

Cette fonctionnalité avec Fluentd n’est pas prise en charge.

Conditions préalables

  • L’opérateur de journalisation de Red Hat OpenShift 5.6 ou supérieur
  • Instance ClusterLogging avec vecteur spécifié comme collecteur
  • Base64 encodée jeton HEC Splunk

Procédure

  1. Créez un secret à l’aide de votre jeton Splunk HEC codé Base64. 

    $ oc -n openshift-logging create secret generic vector-splunk-secret --from-literal hecToken=<HEC_Token>
    Copy to Clipboard Toggle word wrap

  2. Créez ou modifiez la ressource personnalisée ClusterLogForwarder (CR) en utilisant le modèle ci-dessous: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
    - name: splunk-receiver
    4 
    
      secret:
        name: vector-splunk-secret
    5 
    
      type: splunk
    6 
    
      url: <http://your.splunk.hec.url:8088>
    7 
    
  pipelines:
    8 
    
    - inputRefs:
        - application
        - infrastructure
      name:
    9 
    
      outputRefs:
        - splunk-receiver
    10
    Copy to Clipboard Toggle word wrap
    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le nom du secret qui contient votre jeton HEC.
    6
    Indiquez le type de sortie comme splunk.
    7
    Indiquez l’URL (y compris le port) de votre Splunk HEC.
    8
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    9
    Facultatif : Spécifiez un nom pour le pipeline.
    10
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

9.4.6. Envoi des journaux sur HTTP
Copier lien

Les journaux de transfert sur HTTP sont pris en charge pour les collecteurs de journaux Fluentd et Vector. Afin d’activer, spécifiez http comme type de sortie dans la ressource personnalisée ClusterLogForwarder (CR).

Procédure

  • Créez ou modifiez le ClusterLogForwarder CR en utilisant le modèle ci-dessous:

    Exemple ClusterLogForwarder CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
    - name: httpout-app
      type: http
      url:
    4 
    
      http:
        headers:
    5 
    
          h1: v1
          h2: v2
        method: POST
      secret:
        name:
    6 
    
      tls:
        insecureSkipVerify:
    7 
    
  pipelines:
    - name:
      inputRefs:
        - application
      outputRefs:
        - httpout-app
    8
    Copy to Clipboard Toggle word wrap

    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Adresse de destination pour les journaux.
    5
    En-têtes supplémentaires à envoyer avec l’enregistrement du journal.
    6
    Le nom secret des informations d’identification de destination.
    7
    Les valeurs sont vraies ou fausses.
    8
    Cette valeur devrait être la même que le nom de sortie.

9.4.7. Envoi vers Azure Monitor Logs
Copier lien

Avec l’enregistrement 5.9 et ultérieur, vous pouvez transférer les journaux vers Azure Monitor Logs en plus ou à la place du log store par défaut. Cette fonctionnalité est fournie par l’évier Vector Azure Monitor Logs.

Conditions préalables

  • Il est familier avec la façon d’administrer et de créer une instance ClusterLogging de ressource personnalisée (CR).
  • Il est familier avec la façon d’administrer et de créer une instance ClusterLogForwarder CR.
  • Les spécifications ClusterLogForwarder CR sont bien comprises.
  • Familiarité de base avec les services Azure.
  • Il y a un compte Azure configuré pour l’accès Azure Portal ou Azure CLI.
  • Le fichier Azure Monitor Logs vous permet d’obtenir la clé de sécurité primaire ou secondaire.
  • C’est vous qui avez déterminé les types de journaux à transmettre.

Activer le transfert de journaux vers Azure Monitor Logs via l’API HTTP Data Collector:

Créez un secret avec votre clé partagée: 

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
  namespace: openshift-logging
type: Opaque
data:
  shared_key: <your_shared_key>
1
Copy to Clipboard Toggle word wrap
1
Doit contenir une clé primaire ou secondaire pour l’espace de travail Log Analytics faisant la demande.

Afin d’obtenir une clé partagée, vous pouvez utiliser cette commande dans Azure CLI: 

Get-AzOperationalInsightsWorkspaceSharedKey -ResourceGroupName "<resource_name>" -Name "<workspace_name>”
Copy to Clipboard Toggle word wrap

Créez ou modifiez votre ClusterLogForwarder CR en utilisant le modèle correspondant à votre sélection de journal.

Envoyer tous les journaux

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
1 

      logType: my_log_type
2 

    secret:
       name: my-secret
  pipelines:
  - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor
Copy to Clipboard Toggle word wrap

1
Identifiant unique pour l’espace de travail Log Analytics. Champ requis.
2
Azure enregistre le type de données soumises. Il ne peut contenir que des lettres, des chiffres et des accents (_), et ne peut pas dépasser 100 caractères.

Journaux d’applications et d’infrastructures

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor-app
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: application_log
1 

    secret:
      name: my-secret
  - name: azure-monitor-infra
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: infra_log #
    secret:
      name: my-secret
  pipelines:
    - name: app-pipeline
      inputRefs:
      - application
      outputRefs:
      - azure-monitor-app
    - name: infra-pipeline
      inputRefs:
      - infrastructure
      outputRefs:
      - azure-monitor-infra
Copy to Clipboard Toggle word wrap

1
Azure enregistre le type de données soumises. Il ne peut contenir que des lettres, des chiffres et des accents (_), et ne peut pas dépasser 100 caractères.

Des options de configuration avancées

apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogForwarder"
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
  - name: azure-monitor
    type: azureMonitor
    azureMonitor:
      customerId: my-customer-id
      logType: my_log_type
      azureResourceId: "/subscriptions/111111111"
1 

      host: "ods.opinsights.azure.com"
2 

    secret:
       name: my-secret
  pipelines:
   - name: app-pipeline
    inputRefs:
    - application
    outputRefs:
    - azure-monitor
Copy to Clipboard Toggle word wrap

1
ID de ressource de la ressource Azure auxquelles les données doivent être associées. Champ facultatif.
2
Hôte alternatif pour les régions Azure dédiées. Champ facultatif. La valeur par défaut est ods.opinsights.azure.com. La valeur par défaut pour Azure Government est ods.opinsights.azure.us.

Il est possible d’envoyer une copie des journaux de l’application de projets spécifiques à un agrégateur de journaux externe, en plus ou au lieu d’utiliser le log store interne. Il faut également configurer l’agrégateur de journal externe pour recevoir les données de journal de Red Hat OpenShift Service sur AWS.

Afin de configurer les journaux d’applications d’un projet, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec au moins une entrée d’un projet, des sorties optionnelles pour d’autres agrégateurs de journaux et des pipelines qui utilisent ces entrées et sorties.

Conditions préalables

  • Il faut avoir un serveur de journalisation configuré pour recevoir les données de journalisation à l’aide du protocole ou du format spécifié.

Procédure

  1. Créer ou modifier un fichier YAML qui définit le ClusterLogForwarder CR:

    Exemple ClusterLogForwarder CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  outputs:
   - name: fluentd-server-secure
    3 
    
     type: fluentdForward
    4 
    
     url: 'tls://fluentdserver.security.example.com:24224'
    5 
    
     secret:
    6 
    
        name: fluentd-secret
   - name: fluentd-server-insecure
     type: fluentdForward
     url: 'tcp://fluentdserver.home.example.com:24224'
  inputs:
    7 
    
   - name: my-app-logs
     application:
        namespaces:
        - my-project
    8 
    
  pipelines:
   - name: forward-to-fluentd-insecure
    9 
    
     inputRefs:
    10 
    
     - my-app-logs
     outputRefs:
    11 
    
     - fluentd-server-insecure
     labels:
       project: "my-project"
    12 
    
   - name: forward-to-fluentd-secure
    13 
    
     inputRefs:
     - application
    14 
    
     - audit
     - infrastructure
     outputRefs:
     - fluentd-server-secure
     - default
     labels:
       clusterId: "C1234"
    Copy to Clipboard Toggle word wrap

    1
    Le nom du ClusterLogForwarder CR doit être instance.
    2
    L’espace de noms du ClusterLogForwarder CR doit être ouvert-logging.
    3
    Le nom de la sortie.
    4
    Le type de sortie: recherche élastique, fluentdForward, syslog, ou kafka.
    5
    L’URL et le port de l’agrégateur de journal externe en tant qu’URL absolue valide. Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.
    6
    En utilisant un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit exister dans le projet openshift-logging et avoir des touches tls.crt, tls.key et ca-bundle.crt qui pointent vers les certificats qu’ils représentent.
    7
    La configuration d’une entrée pour filtrer les journaux des applications à partir des projets spécifiés.
    8
    En l’absence d’espace de noms, les journaux sont recueillis dans tous les espaces de noms.
    9
    La configuration du pipeline dirige les journaux d’une entrée nommée vers une sortie nommée. Dans cet exemple, un pipeline nommé forward-to-fluentd-insécurité enregistre des logs d’une entrée nommée my-app-logs à un produit nommé couramment serveur non sécurisé.
    10
    Liste des entrées.
    11
    Le nom de la sortie à utiliser.
    12
    Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.
    13
    Configuration pour qu’un pipeline envoie des journaux à d’autres agrégateurs de journaux.
    • Facultatif : Spécifiez un nom pour le pipeline.
    • Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    • Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
    • Facultatif : Spécifiez la sortie par défaut pour transférer les journaux vers le log store par défaut.
    • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.
    14
    Les journaux d’applications de tous les espaces de noms sont recueillis lors de l’utilisation de cette configuration.

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

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

En tant qu’administrateur de cluster, vous pouvez utiliser les étiquettes de pod Kubernetes pour recueillir des données de log à partir de pods spécifiques et les transmettre à un collecteur de journaux.

Imaginez que vous avez une application composée de pods fonctionnant aux côtés d’autres pods dans divers espaces de noms. Lorsque ces pods ont des étiquettes qui identifient l’application, vous pouvez collecter et afficher leurs données de journal à un collecteur de journaux spécifique.

Afin de spécifier les étiquettes de pod, vous utilisez une ou plusieurs paires de clés-valeur matchLabels. Lorsque vous spécifiez plusieurs paires de clés-valeur, les gousses doivent correspondre à toutes les paires pour être sélectionnées.

Procédure

  1. Créez ou modifiez un fichier YAML qui définit l’objet ClusterLogForwarder CR. Dans le fichier, spécifiez les étiquettes de pod en utilisant des sélecteurs simples basés sur l’égalité sous input[].name.application.selector.matchLabels, comme indiqué dans l’exemple suivant.

    Exemple de fichier ClusterLogForwarder CR YAML

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  pipelines:
    - inputRefs: [ myAppLogData ]
    3 
    
      outputRefs: [ default ]
    4 
    
  inputs:
    5 
    
    - name: myAppLogData
      application:
        selector:
          matchLabels:
    6 
    
            environment: production
            app: nginx
        namespaces:
    7 
    
        - app1
        - app2
  outputs:
    8 
    
    - <output_name>
    ...
    Copy to Clipboard Toggle word wrap

    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Indiquez une ou plusieurs valeurs séparées par des virgules à partir des entrées[].name.
    4
    Indiquez une ou plusieurs valeurs séparées par les virgules des sorties[].
    5
    Définissez une entrée unique[].nom pour chaque application qui a un ensemble unique d’étiquettes de pod.
    6
    Indiquez les paires clés-valeur d’étiquettes de pod dont vous souhaitez recueillir les données de journal. Il faut spécifier à la fois une clé et une valeur, pas seulement une clé. Afin d’être sélectionnés, les gousses doivent correspondre à toutes les paires clé-valeur.
    7
    Facultatif : Spécifiez un ou plusieurs espaces de noms.
    8
    Indiquez une ou plusieurs sorties pour transmettre vos données de journal.
  2. Facultatif: Pour limiter la collecte de données de journal à des espaces de noms spécifiques, utilisez les entrées[].name.application.namespaces, comme indiqué dans l’exemple précédent.

  3. Facultatif: Vous pouvez envoyer des données de log à partir d’applications supplémentaires qui ont des étiquettes de pod différentes vers le même pipeline.

    1. Dans chaque combinaison unique d’étiquettes de pod, créez une section d’entrées supplémentaires similaire à celle affichée.
    2. Actualisez les sélecteurs pour correspondre aux étiquettes de pod de cette application.

    3. Ajoutez la nouvelle valeur d’entrée[].name à inputRefs. À titre d’exemple: 

      - inputRefs: [ myAppLogData, myOtherAppLogData ]
      Copy to Clipboard Toggle word wrap

  4. Créer l’objet CR: 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

9.4.10. Aperçu du filtre d’audit API
Copier lien

Les serveurs API OpenShift génèrent des événements d’audit pour chaque appel API, en détaillant la demande, la réponse et l’identité du demandeur, ce qui conduit à de grands volumes de données. Le filtre API Audit utilise des règles pour permettre l’exclusion des événements non essentiels et la réduction de la taille des événements, facilitant ainsi une piste d’audit plus gérable. Les règles sont vérifiées dans l’ordre, vérifier les arrêts au premier match. La quantité de données incluses dans un événement est déterminée par la valeur du champ de niveau:

  • Aucun : L’événement est abandonné.
  • Les métadonnées de l’audit sont incluses, les organismes de demande et de réponse sont supprimés.
  • Demande : Les métadonnées d’audit et l’organisme de demande sont inclus, le corps de réponse est supprimé.
  • RequestResponse: Toutes les données sont incluses: métadonnées, corps de requête et corps de réponse. Le corps de réponse peut être très grand. À titre d’exemple, oc get pods -A génère un corps de réponse contenant la description YAML de chaque pod dans le cluster.
Note

Cette fonctionnalité ne peut être utilisée que si le collecteur vectoriel est configuré dans votre déploiement de journalisation.

Dans l’enregistrement 5.8 et ultérieur, la ressource personnalisée ClusterLogForwarder (CR) utilise le même format que la politique d’audit standard Kubernetes, tout en fournissant les fonctions supplémentaires suivantes:

Les wildcards
Les noms d’utilisateurs, de groupes, d’espaces de noms et de ressources peuvent avoir un caractère d’astérisque principal ou suivi *. À titre d’exemple, namespace openshift-\* correspond à openshift-apiserver ou openshift-authentication. La ressource \*/status correspond à Pod/status ou Déploiement/status.
Les règles par défaut

Les événements qui ne correspondent à aucune règle de la politique sont filtrés comme suit:

  • Les événements système en lecture seule tels que get, list, watch sont supprimés.
  • Les événements d’écriture de compte de service qui se produisent dans le même espace de noms que le compte de service sont supprimés.
  • Les autres événements sont transmis, sous réserve des limites de taux configurées.

Afin de désactiver ces valeurs par défaut, terminez votre liste de règles avec une règle qui n’a qu’un champ de niveau ou ajoutez une règle vide.

Omettre les codes de réponse
Liste des codes de statut entiers à omettre. Dans la réponse, vous pouvez supprimer les événements en fonction du code d’état HTTP en utilisant le champ OmitResponseCodes, une liste de code d’état HTTP pour lequel aucun événement n’est créé. La valeur par défaut est [404, 409, 422, 429]. Lorsque la valeur est une liste vide, [], alors aucun code d’état n’est omis.

La politique d’audit ClusterLogForwarder CR agit en plus du Red Hat OpenShift Service sur la politique d’audit AWS. Le filtre d’audit ClusterLogForwarder CR modifie ce que le collecteur de journaux avance et permet de filtrer par verbe, utilisateur, groupe, espace de noms ou ressource. Il est possible de créer plusieurs filtres pour envoyer différents résumés du même flux d’audit à différents endroits. À titre d’exemple, vous pouvez envoyer un flux détaillé au magasin de journal de cluster local et un flux moins détaillé vers un site distant.

Note

L’exemple fourni vise à illustrer l’éventail des règles possibles dans une politique d’audit et n’est pas une configuration recommandée.

Exemple de politique d’audit

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
    - name: my-pipeline
      inputRefs: audit
1 

      filterRefs: my-policy
2 

      outputRefs: default
  filters:
    - name: my-policy
      type: kubeAPIAudit
      kubeAPIAudit:
        # Don't generate audit events for all requests in RequestReceived stage.
        omitStages:
          - "RequestReceived"

        rules:
          # Log pod changes at RequestResponse level
          - level: RequestResponse
            resources:
            - group: ""
              resources: ["pods"]

          # Log "pods/log", "pods/status" at Metadata level
          - level: Metadata
            resources:
            - group: ""
              resources: ["pods/log", "pods/status"]

          # Don't log requests to a configmap called "controller-leader"
          - level: None
            resources:
            - group: ""
              resources: ["configmaps"]
              resourceNames: ["controller-leader"]

          # Don't log watch requests by the "system:kube-proxy" on endpoints or services
          - level: None
            users: ["system:kube-proxy"]
            verbs: ["watch"]
            resources:
            - group: "" # core API group
              resources: ["endpoints", "services"]

          # Don't log authenticated requests to certain non-resource URL paths.
          - level: None
            userGroups: ["system:authenticated"]
            nonResourceURLs:
            - "/api*" # Wildcard matching.
            - "/version"

          # Log the request body of configmap changes in kube-system.
          - level: Request
            resources:
            - group: "" # core API group
              resources: ["configmaps"]
            # This rule only applies to resources in the "kube-system" namespace.
            # The empty string "" can be used to select non-namespaced resources.
            namespaces: ["kube-system"]

          # Log configmap and secret changes in all other namespaces at the Metadata level.
          - level: Metadata
            resources:
            - group: "" # core API group
              resources: ["secrets", "configmaps"]

          # Log all other resources in core and extensions at the Request level.
          - level: Request
            resources:
            - group: "" # core API group
            - group: "extensions" # Version of group should NOT be included.

          # A catch-all rule to log all other requests at the Metadata level.
          - level: Metadata
Copy to Clipboard Toggle word wrap

1
Les types de journaux qui sont collectés. La valeur de ce champ peut être l’audit pour les journaux d’audit, les applications pour les journaux d’applications, l’infrastructure pour les journaux d’infrastructure ou une entrée nommée qui a été définie pour votre application.
2
Le nom de votre politique d’audit.

Les journaux peuvent être transférés vers un système d’enregistrement Loki externe en plus ou au lieu du log store par défaut.

Afin de configurer le transfert de journaux vers Loki, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec une sortie vers Loki, et un pipeline qui utilise la sortie. La sortie vers Loki peut utiliser la connexion HTTP (non sécurisée) ou HTTPS (sécurisé HTTP).

Conditions préalables

  • Il faut avoir un système d’enregistrement Loki en cours d’exécution à l’URL que vous spécifiez avec le champ url dans le CR.

Procédure

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
  - name: loki-insecure
    4 
    
    type: "loki"
    5 
    
    url: http://loki.insecure.com:3100
    6 
    
    loki:
      tenantKey: kubernetes.namespace_name
      labelKeys:
      - kubernetes.labels.foo
  - name: loki-secure
    7 
    
    type: "loki"
    url: https://loki.secure.com:3100
    secret:
      name: loki-secret
    8 
    
    loki:
      tenantKey: kubernetes.namespace_name
    9 
    
      labelKeys:
      - kubernetes.labels.foo
    10 
    
  pipelines:
  - name: application-logs
    11 
    
    inputRefs:
    12 
    
    - application
    - audit
    outputRefs:
    13 
    
    - loki-secure
    Copy to Clipboard Toggle word wrap
    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le type comme "loki".
    6
    Indiquez l’URL et le port du système Loki en tant qu’URL absolue valide. Il est possible d’utiliser le protocole http (non sécurisé) ou https (sécurisé HTTP). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP. Le port par défaut de Loki pour la communication HTTP(S) est 3100.
    7
    Dans le cas d’une connexion sécurisée, vous pouvez spécifier une URL https ou http que vous authentifiez en spécifiant un secret.
    8
    Dans le cas d’un préfixe https, spécifiez le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers les certificats qu’il représente. Autrement, pour les préfixes http et https, vous pouvez spécifier un secret qui contient un nom d’utilisateur et un mot de passe. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift. En savoir plus, voir « Exemple : Configurer un secret qui contient un nom d’utilisateur et un mot de passe ».
    9
    Facultatif : Spécifiez un champ clé de métadonnées pour générer des valeurs pour le champ TenantID dans Loki. À titre d’exemple, le paramètre tenantKey: kubernetes.namespace_name utilise les noms des espaces de noms Kubernetes comme valeurs pour les identifiants de locataire dans Loki. Afin de voir les autres champs d’enregistrement de journaux que vous pouvez spécifier, consultez le lien « Champs d’enregistrement de registre » dans la section suivante « Ressources supplémentaires ».
    10
    Facultatif: Spécifiez une liste de touches de champ de métadonnées pour remplacer les étiquettes Loki par défaut. Les noms d’étiquettes Loki doivent correspondre à l’expression régulière [a-zA-Z_:][a-zA-Z0-9_:]*. Les caractères illégaux dans les clés de métadonnées sont remplacés par _ pour former le nom de l’étiquette. Ainsi, la clé de métadonnées kubernetes.labels.foo devient le label Loki kubernetes_labels_foo. Dans le cas où vous ne définissez pas de baliseKeys, la valeur par défaut est : [log_type, kubernetes.namespace_name, kubernetes.pod_name, kubernetes_host]. Gardez l’ensemble d’étiquettes petit car Loki limite la taille et le nombre d’étiquettes autorisées. Consultez Configuring Loki, limit_config. Cependant, vous pouvez toujours interroger en fonction de n’importe quel champ d’enregistrement de journal à l’aide de filtres de requête.
    11
    Facultatif : Spécifiez un nom pour le pipeline.
    12
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    13
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
    Note

    Étant donné que Loki exige que les flux de journaux soient correctement commandés par horodatage, labelKeys inclut toujours l’ensemble d’étiquettes kubernetes_host, même si vous ne le spécifiez pas. Cette inclusion garantit que chaque flux provient d’un seul hôte, ce qui empêche les horodatages de devenir désordonnés en raison des différences d’horloge sur différents hôtes.

  2. Appliquez l’objet ClusterLogForwarder CR en exécutant la commande suivante: 

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

Les journaux peuvent être transférés vers une instance externe Elasticsearch en plus ou au lieu du log store interne. Il vous incombe de configurer l’agrégateur de journaux externe pour recevoir les données de log de Red Hat OpenShift Service sur AWS.

Afin de configurer le transfert de journaux vers une instance externe Elasticsearch, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec une sortie vers cette instance, et un pipeline qui utilise la sortie. La sortie externe Elasticsearch peut utiliser la connexion HTTP (non sécurisée) ou HTTPS (sécurisé HTTP).

Afin de transmettre les journaux à une instance externe et interne d’Elasticsearch, créez des sorties et des pipelines vers l’instance externe et un pipeline qui utilise la sortie par défaut pour transmettre les journaux à l’instance interne.

Note

Il n’est pas nécessaire de créer un ClusterLogForwarder CR si vous voulez seulement transférer les journaux vers une instance interne Elasticsearch.

Conditions préalables

  • Il faut avoir un serveur de journalisation configuré pour recevoir les données de journalisation à l’aide du protocole ou du format spécifié.

Procédure

  1. Créer ou modifier un fichier YAML qui définit le ClusterLogForwarder CR:

    Exemple ClusterLogForwarder CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
   - name: elasticsearch-example
    4 
    
     type: elasticsearch
    5 
    
     elasticsearch:
       version: 8
    6 
    
     url: http://elasticsearch.example.com:9200
    7 
    
     secret:
       name: es-secret
    8 
    
  pipelines:
   - name: application-logs
    9 
    
     inputRefs:
    10 
    
     - application
     - audit
     outputRefs:
     - elasticsearch-example
    11 
    
     - default
    12 
    
     labels:
       myLabel: "myValue"
    13 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le type de recherche élastique.
    6
    Indiquez la version Elasticsearch. Cela peut être 6, 7 ou 8.
    7
    Indiquez l’URL et le port de l’instance externe Elasticsearch comme URL absolue valide. Il est possible d’utiliser le protocole http (non sécurisé) ou https (sécurisé HTTP). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.
    8
    Dans le cas d’un préfixe https, spécifiez le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente. Autrement, pour les préfixes http et https, vous pouvez spécifier un secret qui contient un nom d’utilisateur et un mot de passe. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift. En savoir plus, voir « Exemple : Configurer un secret qui contient un nom d’utilisateur et un mot de passe ».
    9
    Facultatif : Spécifiez un nom pour le pipeline.
    10
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    11
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
    12
    Facultatif : Spécifiez la sortie par défaut pour envoyer les journaux à l’instance interne Elasticsearch.
    13
    Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

  2. Appliquer le ClusterLogForwarder CR: 

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

Exemple : Définir un secret contenant un nom d’utilisateur et un mot de passe

Il est possible d’utiliser un secret contenant un nom d’utilisateur et un mot de passe pour authentifier une connexion sécurisée à une instance externe Elasticsearch.

Ainsi, si vous ne pouvez pas utiliser les touches TLS (mTLS) mutuelles parce qu’un tiers exploite l’instance Elasticsearch, vous pouvez utiliser HTTP ou HTTPS et définir un secret contenant le nom d’utilisateur et le mot de passe.

  1. Créez un fichier Secret YAML similaire à l’exemple suivant. Les valeurs encodées base64 sont utilisées pour les champs nom d’utilisateur et mot de passe. Le type secret est opaque par défaut. 

    apiVersion: v1
kind: Secret
metadata:
  name: openshift-test-secret
data:
  username: <username>
  password: <password>
# ...
    Copy to Clipboard Toggle word wrap

  2. Créer le secret: 

    $ oc create secret -n openshift-logging openshift-test-secret.yaml
    Copy to Clipboard Toggle word wrap

  3. Indiquez le nom du secret dans le ClusterLogForwarder CR: 

    kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: elasticsearch
     type: "elasticsearch"
     url: https://elasticsearch.secure.com:9200
     secret:
        name: openshift-test-secret
# ...
    Copy to Clipboard Toggle word wrap
    Note

    Dans la valeur du champ url, le préfixe peut être http ou https.

  4. Appliquer l’objet CR: 

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

Il est possible d’utiliser le protocole Fluentd forward pour envoyer une copie de vos journaux à un agrégateur de journal externe configuré pour accepter le protocole au lieu du magasin de journal Elasticsearch par défaut ou en plus. Il vous incombe de configurer l’agrégateur de journaux externe pour recevoir les journaux de Red Hat OpenShift Service sur AWS.

Afin de configurer le transfert de journaux à l’aide du protocole avant, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec une ou plusieurs sorties vers les serveurs Fluentd, et des pipelines qui utilisent ces sorties. La sortie Fluentd peut utiliser une connexion TCP (non sécurisée) ou TLS (TCP sécurisé).

Conditions préalables

  • Il faut avoir un serveur de journalisation configuré pour recevoir les données de journalisation à l’aide du protocole ou du format spécifié.

Procédure

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  outputs:
   - name: fluentd-server-secure
    3 
    
     type: fluentdForward
    4 
    
     url: 'tls://fluentdserver.security.example.com:24224'
    5 
    
     secret:
    6 
    
        name: fluentd-secret
   - name: fluentd-server-insecure
     type: fluentdForward
     url: 'tcp://fluentdserver.home.example.com:24224'
  pipelines:
   - name: forward-to-fluentd-secure
    7 
    
     inputRefs:
    8 
    
     - application
     - audit
     outputRefs:
     - fluentd-server-secure
    9 
    
     - default
    10 
    
     labels:
       clusterId: "C1234"
    11 
    
   - name: forward-to-fluentd-insecure
    12 
    
     inputRefs:
     - infrastructure
     outputRefs:
     - fluentd-server-insecure
     labels:
       clusterId: "C1234"
    Copy to Clipboard Toggle word wrap
    1
    Le nom du ClusterLogForwarder CR doit être instance.
    2
    L’espace de noms du ClusterLogForwarder CR doit être ouvert-logging.
    3
    Indiquez un nom pour la sortie.
    4
    Indiquez le type fluentdForward.
    5
    Indiquez l’URL et le port de l’instance Fluentd externe comme URL absolue valide. Il est possible d’utiliser le protocole tcp (non sécurisé) ou tls (TCP sécurisé). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.
    6
    Lorsque vous utilisez un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit exister dans le projet openshift-logging et doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente.
    7
    Facultatif : Spécifiez un nom pour le pipeline.
    8
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    9
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
    10
    Facultatif : Spécifiez la sortie par défaut pour transmettre les journaux à l’instance interne Elasticsearch.
    11
    Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.
    12
    Facultatif: Configurez plusieurs sorties pour transmettre les journaux à d’autres agrégateurs de journaux externes de tout type pris en charge:
    • C’est un nom pour décrire le pipeline.
    • L’entréeRefs est le type de journal à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    • La sortieRefs est le nom de la sortie à utiliser.
    • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

  2. Créer l’objet CR: 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

Afin que Logstash puisse ingérer des données de log à partir de fluentd, vous devez activer la précision nanoseconde dans le fichier de configuration Logstash.

Procédure

  • Dans le fichier de configuration Logstash, définissez nanosecond_précision sur true.

Exemple de fichier de configuration Logstash

input { tcp { codec => fluent { nanosecond_precision => true } port => 24114 } }
filter { }
output { stdout { codec => rubydebug } }
Copy to Clipboard Toggle word wrap

9.4.14. Journaux de transfert à l’aide du protocole syslog
Copier lien

Il est possible d’utiliser le protocole syslog RFC3164 ou RFC5424 pour envoyer une copie de vos journaux à un agrégateur de journal externe configuré pour accepter le protocole au lieu du magasin de journal Elasticsearch par défaut ou en plus. Il vous incombe de configurer l’agrégateur de journal externe, tel qu’un serveur syslog, pour recevoir les journaux de Red Hat OpenShift Service sur AWS.

Afin de configurer le transfert de journaux à l’aide du protocole syslog, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec une ou plusieurs sorties vers les serveurs syslog, et des pipelines qui utilisent ces sorties. La sortie syslog peut utiliser une connexion UDP, TCP ou TLS.

Conditions préalables

  • Il faut avoir un serveur de journalisation configuré pour recevoir les données de journalisation à l’aide du protocole ou du format spécifié.

Procédure

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
   - name: rsyslog-east
    4 
    
     type: syslog
    5 
    
     syslog:
    6 
    
       facility: local0
       rfc: RFC3164
       payloadKey: message
       severity: informational
     url: 'tls://rsyslogserver.east.example.com:514'
    7 
    
     secret:
    8 
    
        name: syslog-secret
   - name: rsyslog-west
     type: syslog
     syslog:
      appName: myapp
      facility: user
      msgID: mymsg
      procID: myproc
      rfc: RFC5424
      severity: debug
     url: 'tcp://rsyslogserver.west.example.com:514'
  pipelines:
   - name: syslog-east
    9 
    
     inputRefs:
    10 
    
     - audit
     - application
     outputRefs:
    11 
    
     - rsyslog-east
     - default
    12 
    
     labels:
       secure: "true"
    13 
    
       syslog: "east"
   - name: syslog-west
    14 
    
     inputRefs:
     - infrastructure
     outputRefs:
     - rsyslog-west
     - default
     labels:
       syslog: "west"
    Copy to Clipboard Toggle word wrap
    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le type de syslog.
    6
    Facultatif: Spécifiez les paramètres de syslog, énumérés ci-dessous.
    7
    Indiquez l’URL et le port de l’instance syslog externe. Il est possible d’utiliser le protocole udp (non sécurisé), tcp (non sécurisé) ou tls (TCP sécurisé). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.
    8
    En utilisant un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift.
    9
    Facultatif : Spécifiez un nom pour le pipeline.
    10
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    11
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
    12
    Facultatif : Spécifiez la sortie par défaut pour transmettre les journaux à l’instance interne Elasticsearch.
    13
    Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux. Citez des valeurs comme "vrai" afin qu’elles soient reconnues comme des valeurs de chaîne, et non comme un booléen.
    14
    Facultatif: Configurez plusieurs sorties pour transmettre les journaux à d’autres agrégateurs de journaux externes de tout type pris en charge:
    • C’est un nom pour décrire le pipeline.
    • L’entréeRefs est le type de journal à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    • La sortieRefs est le nom de la sortie à utiliser.
    • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

  2. Créer l’objet CR: 

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

Il est possible d’ajouter des éléments namespace_name, pod_name et container_name au champ de message de l’enregistrement en ajoutant le champ AddLogSource à votre ressource personnalisée ClusterLogForwarder (CR). 

  spec:
    outputs:
    - name: syslogout
      syslog:
        addLogSource: true
        facility: user
        payloadKey: message
        rfc: RFC3164
        severity: debug
        tag: mytag
      type: syslog
      url: tls://syslog-receiver.openshift-logging.svc:24224
    pipelines:
    - inputRefs:
      - application
      name: test-app
      outputRefs:
      - syslogout
Copy to Clipboard Toggle word wrap
Note

Cette configuration est compatible avec les RFC3164 et RFC5424.

Exemple de sortie de message syslog sans AddLogSource

<15>1 2020-11-15T17:06:14+00:00 fluentd-9hkb4 mytag - - -  {"msgcontent"=>"Message Contents", "timestamp"=>"2020-11-15 17:06:09", "tag_key"=>"rec_tag", "index"=>56}
Copy to Clipboard Toggle word wrap

Exemple de sortie de message syslog avec AddLogSource

<15>1 2020-11-16T10:49:37+00:00 crc-j55b9-master-0 mytag - - -  namespace_name=clo-test-6327,pod_name=log-generator-ff9746c49-qxm7l,container_name=log-generator,message={"msgcontent":"My life is my message", "timestamp":"2020-11-16 10:49:36", "tag_key":"rec_tag", "index":76}
Copy to Clipboard Toggle word wrap

9.4.14.2. Les paramètres de syslog
Copier lien

Il est possible de configurer ce qui suit pour les sorties syslog. Consultez le syslog RFC3164 ou RFC5424 RFC pour plus d’informations.

  • facilité: L’installation de syslog. La valeur peut être un entier décimal ou un mot-clé insensible à la casse:

    • 0 ou kern pour les messages du noyau
    • 1 ou utilisateur pour les messages de niveau utilisateur, par défaut.
    • 2 ou courrier pour le système de courrier
    • 3 ou démon pour les démons système
    • 4 ou auth pour les messages de sécurité / d’authentification
    • 5 ou syslog pour les messages générés en interne par syslogd
    • 6 ou lpr pour le sous-système d’imprimante de ligne
    • 7 ou nouvelles pour le sous-système d’actualités réseau
    • 8 ou uucp pour le sous-système UUCP
    • 9 ou cron pour le démon d’horloge
    • 10 ou authpriv pour les messages d’authentification de sécurité
    • 11 ou ftp pour le démon FTP
    • 12 ou ntp pour le sous-système NTP
    • 13 ou sécurité pour le journal d’audit syslog
    • 14 ou console pour le journal d’alerte syslog
    • 15 ou solaris-cron pour le démon de planification
    • 16-23 ou local0 - local7 pour les installations d’utilisation locale

  • Facultatif: payloadKey: Le champ d’enregistrement à utiliser comme charge utile pour le message syslog.

    Note

    La configuration du paramètre PayloadKey empêche d’autres paramètres d’être transmis au syslog.

  • la RFC à utiliser pour l’envoi de journaux à l’aide de syslog. La valeur par défaut est RFC5424.

  • gravité: La sévérité du syslog à établir sur les enregistrements de syslog sortants. La valeur peut être un entier décimal ou un mot-clé insensible à la casse:

    • 0 ou urgence pour les messages indiquant que le système est inutilisable
    • 1 ou Alerte pour les messages indiquant les actions doivent être prises immédiatement
    • 2 ou critique pour les messages indiquant des conditions critiques
    • 3 ou Erreur pour les messages indiquant les conditions d’erreur
    • 4 ou avertissement pour les messages indiquant les conditions d’avertissement
    • 5 ou Avis pour les messages indiquant des conditions normales mais significatives
    • 6 ou Information pour les messages indiquant des messages d’information
    • 7 ou Debug pour les messages indiquant le niveau de débogage, la valeur par défaut
  • balise: Tag spécifie un champ d’enregistrement à utiliser comme balise sur le message syslog.
  • trimPrefix: Supprimer le préfixe spécifié de la balise.
9.4.14.3. Autres paramètres RFC5424 syslog
Copier lien

Les paramètres suivants s’appliquent à la RFC5424:

  • Appname: L’APP-NAME est une chaîne de texte libre qui identifie l’application qui a envoyé le journal. Doit être spécifié pour la RFC5424.
  • Le MSGID est une chaîne de texte libre qui identifie le type de message. Doit être spécifié pour la RFC5424.
  • le PROCID est une chaîne de texte libre. La modification de la valeur indique une discontinuité dans le rapport syslog. Doit être spécifié pour la RFC5424.

9.4.15. Envoi de journaux à un courtier Kafka
Copier lien

Les journaux peuvent être transférés à un courtier Kafka externe en plus ou à la place du log store par défaut.

Afin de configurer le transfert de journaux vers une instance Kafka externe, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec une sortie vers cette instance, et un pipeline qui utilise la sortie. Il est possible d’inclure un sujet Kafka spécifique dans la sortie ou d’utiliser la valeur par défaut. La sortie Kafka peut utiliser une connexion TCP (non sécurisée) ou TLS (TCP sécurisé).

Procédure

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
   - name: app-logs
    4 
    
     type: kafka
    5 
    
     url: tls://kafka.example.devlab.com:9093/app-topic
    6 
    
     secret:
       name: kafka-secret
    7 
    
   - name: infra-logs
     type: kafka
     url: tcp://kafka.devlab2.example.com:9093/infra-topic
    8 
    
   - name: audit-logs
     type: kafka
     url: tls://kafka.qelab.example.com:9093/audit-topic
     secret:
        name: kafka-secret-qe
  pipelines:
   - name: app-topic
    9 
    
     inputRefs:
    10 
    
     - application
     outputRefs:
    11 
    
     - app-logs
     labels:
       logType: "application"
    12 
    
   - name: infra-topic
    13 
    
     inputRefs:
     - infrastructure
     outputRefs:
     - infra-logs
     labels:
       logType: "infra"
   - name: audit-topic
     inputRefs:
     - audit
     outputRefs:
     - audit-logs
     labels:
       logType: "audit"
    Copy to Clipboard Toggle word wrap
    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le type kafka.
    6
    Indiquez l’URL et le port du courtier Kafka en tant qu’URL absolue valide, éventuellement avec un sujet spécifique. Il est possible d’utiliser le protocole tcp (non sécurisé) ou tls (TCP sécurisé). Lorsque le proxy à l’échelle du cluster utilisant l’annotation CIDR est activé, la sortie doit être un nom de serveur ou un FQDN, et non une adresse IP.
    7
    Lorsque vous utilisez un préfixe tls, vous devez spécifier le nom du secret requis par le point de terminaison pour la communication TLS. Le secret doit contenir une clé ca-bundle.crt qui pointe vers le certificat qu’il représente. Dans les implémentations héritées, le secret doit exister dans le projet d’exploitation en openshift.
    8
    Facultatif: Pour envoyer une sortie non sécurisée, utilisez un préfixe tcp devant l’URL. Également omettre la clé secrète et son nom de cette sortie.
    9
    Facultatif : Spécifiez un nom pour le pipeline.
    10
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    11
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.
    12
    Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.
    13
    Facultatif: Configurez plusieurs sorties pour transmettre les journaux à d’autres agrégateurs de journaux externes de tout type pris en charge:
    • C’est un nom pour décrire le pipeline.
    • L’entréeRefs est le type de journal à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    • La sortieRefs est le nom de la sortie à utiliser.
    • Facultatif: String. Il y a une ou plusieurs étiquettes à ajouter aux journaux.

  2. Facultatif: Pour transférer une seule sortie à plusieurs courtiers Kafka, spécifiez un éventail de courtiers Kafka comme indiqué dans l’exemple suivant: 

    # ...
spec:
  outputs:
  - name: app-logs
    type: kafka
    secret:
      name: kafka-secret-dev
    kafka:
    1 
    
      brokers:
    2 
    
        - tls://kafka-broker1.example.com:9093/
        - tls://kafka-broker2.example.com:9093/
      topic: app-topic
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    Indiquez une clé kafka qui a une clé de courtier et de sujet.
    2
    Faites appel à la clé des courtiers pour spécifier un éventail d’un ou plusieurs courtiers.
    3
    La clé de sujet permet de spécifier le sujet cible qui reçoit les journaux.

  3. Appliquez le ClusterLogForwarder CR en exécutant la commande suivante: 

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

9.4.16. Envoi de journaux vers Amazon CloudWatch
Copier lien

Les journaux peuvent être transmis à Amazon CloudWatch, un service de surveillance et de stockage log hébergé par Amazon Web Services (AWS). Les journaux peuvent être transférés vers CloudWatch en plus ou au lieu du log store par défaut.

Afin de configurer le transfert de journaux vers CloudWatch, vous devez créer une ressource personnalisée ClusterLogForwarder (CR) avec une sortie pour CloudWatch et un pipeline qui utilise la sortie.

Procédure

  1. Créez un fichier Secret YAML qui utilise les champs aws_access_key_id et aws_secret_access_key pour spécifier vos identifiants AWS codés base64. À titre d’exemple: 

    apiVersion: v1
kind: Secret
metadata:
  name: cw-secret
  namespace: openshift-logging
data:
  aws_access_key_id: QUtJQUlPU0ZPRE5ON0VYQU1QTEUK
  aws_secret_access_key: d0phbHJYVXRuRkVNSS9LN01ERU5HL2JQeFJmaUNZRVhBTVBMRUtFWQo=
    Copy to Clipboard Toggle word wrap

  2. Créez le secret. À titre d’exemple: 

    $ oc apply -f cw-secret.yaml
    Copy to Clipboard Toggle word wrap

  3. Créez ou modifiez un fichier YAML qui définit l’objet ClusterLogForwarder CR. Dans le fichier, spécifiez le nom du secret. À titre d’exemple: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
   - name: cw
    4 
    
     type: cloudwatch
    5 
    
     cloudwatch:
       groupBy: logType
    6 
    
       groupPrefix: <group prefix>
    7 
    
       region: us-east-2
    8 
    
     secret:
        name: cw-secret
    9 
    
  pipelines:
    - name: infra-logs
    10 
    
      inputRefs:
    11 
    
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw
    12
    Copy to Clipboard Toggle word wrap
    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le type de cloudwatch.
    6
    Facultatif: Spécifiez comment regrouper les journaux:
    • logType crée des groupes de journaux pour chaque type de journal.
    • namespaceName crée un groupe de journal pour chaque espace de noms d’application. Il crée également des groupes de journaux distincts pour l’infrastructure et les journaux d’audit.
    • namespaceUUID crée un nouveau groupe de journaux pour chaque espace de noms d’application UUID. Il crée également des groupes de journaux distincts pour l’infrastructure et les journaux d’audit.
    7
    Facultatif : Spécifiez une chaîne de caractères pour remplacer le préfixe par défaut d’infrastructureName dans les noms des groupes de journaux.
    8
    Indiquez la région AWS.
    9
    Indiquez le nom du secret qui contient vos identifiants AWS.
    10
    Facultatif : Spécifiez un nom pour le pipeline.
    11
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    12
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

  4. Créer l’objet CR: 

    $ oc create -f <file-name>.yaml
    Copy to Clipboard Toggle word wrap

Exemple : Utiliser ClusterLogForwarder avec Amazon CloudWatch

Ici, vous voyez un exemple de ressource personnalisée ClusterLogForwarder (CR) et les données de log qu’elle génère sur Amazon CloudWatch.

Imaginez que vous dirigez un cluster ROSA nommé mycluster. La commande suivante renvoie l’infrastructure du clusterName, que vous utiliserez pour composer des commandes aws plus tard: 

$ oc get Infrastructure/cluster -ojson | jq .status.infrastructureName
"mycluster-7977k"
Copy to Clipboard Toggle word wrap

Afin de générer des données de journal pour cet exemple, vous exécutez un pod de boîte de travail dans un espace de noms appelé application. Le pod busybox écrit un message à stdout toutes les trois secondes: 

$ oc run busybox --image=busybox -- sh -c 'while true; do echo "My life is my message"; sleep 3; done'
$ oc logs -f busybox
My life is my message
My life is my message
My life is my message
...
Copy to Clipboard Toggle word wrap

Consultez l’UUID de l’espace de noms de l’application où s’exécute le pod busybox: 

$ oc get ns/app -ojson | jq .metadata.uid
"794e1e1a-b9f5-4958-a190-e76a9b53d7bf"
Copy to Clipboard Toggle word wrap

Dans votre ressource personnalisée ClusterLogForwarder (CR), vous configurez les types d’infrastructure, d’audit et de journal des applications en tant qu’entrées dans le pipeline de tous les journaux. En outre, vous connectez ce pipeline à la sortie cw, qui transmet les journaux à une instance CloudWatch dans la région us-est-2: 

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: cw
     type: cloudwatch
     cloudwatch:
       groupBy: logType
       region: us-east-2
     secret:
        name: cw-secret
  pipelines:
    - name: all-logs
      inputRefs:
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw
Copy to Clipboard Toggle word wrap

Chaque région de CloudWatch contient trois niveaux d’objets:

  • groupe de journal

    • flux de journal

      • événement de log

Avec groupBy: logType dans le ClusterLogForwarding CR, les trois types de log dans l’entréeRefs produisent trois groupes de log dans Amazon Cloudwatch: 

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.application"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"
Copy to Clipboard Toggle word wrap

Chacun des groupes de journaux contient des flux de journaux: 

$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.application | jq .logStreams[].logStreamName
"kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log"
Copy to Clipboard Toggle word wrap 
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.audit | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.k8s-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.linux-audit.log"
"ip-10-0-131-228.us-east-2.compute.internal.openshift-audit.log"
...
Copy to Clipboard Toggle word wrap 
$ aws --output json logs describe-log-streams --log-group-name mycluster-7977k.infrastructure | jq .logStreams[].logStreamName
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-69f9fd9b58-zqzw5_openshift-oauth-apiserver_oauth-apiserver-453c5c4ee026fe20a6139ba6b1cdd1bed25989c905bf5ac5ca211b7cbb5c3d7b.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-ce51532df7d4e4d5f21c4f4be05f6575b93196336be0027067fd7d93d70f66a4.log"
"ip-10-0-131-228.us-east-2.compute.internal.kubernetes.var.log.containers.apiserver-797774f7c5-lftrx_openshift-apiserver_openshift-apiserver-check-endpoints-82a9096b5931b5c3b1d6dc4b66113252da4a6472c9fff48623baee761911a9ef.log"
...
Copy to Clipboard Toggle word wrap

Chaque flux de journal contient des événements de journal. Afin de voir un événement journal à partir du Pod de la boîte de données, vous spécifiez son flux de journal à partir du groupe de journal de l’application: 

$ aws logs get-log-events --log-group-name mycluster-7977k.application --log-stream-name kubernetes.var.log.containers.busybox_app_busybox-da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76.log
{
    "events": [
        {
            "timestamp": 1629422704178,
            "message": "{\"docker\":{\"container_id\":\"da085893053e20beddd6747acdbaf98e77c37718f85a7f6a4facf09ca195ad76\"},\"kubernetes\":{\"container_name\":\"busybox\",\"namespace_name\":\"app\",\"pod_name\":\"busybox\",\"container_image\":\"docker.io/library/busybox:latest\",\"container_image_id\":\"docker.io/library/busybox@sha256:0f354ec1728d9ff32edcd7d1b8bbdfc798277ad36120dc3dc683be44524c8b60\",\"pod_id\":\"870be234-90a3-4258-b73f-4f4d6e2777c7\",\"host\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"labels\":{\"run\":\"busybox\"},\"master_url\":\"https://kubernetes.default.svc\",\"namespace_id\":\"794e1e1a-b9f5-4958-a190-e76a9b53d7bf\",\"namespace_labels\":{\"kubernetes_io/metadata_name\":\"app\"}},\"message\":\"My life is my message\",\"level\":\"unknown\",\"hostname\":\"ip-10-0-216-3.us-east-2.compute.internal\",\"pipeline_metadata\":{\"collector\":{\"ipaddr4\":\"10.0.216.3\",\"inputname\":\"fluent-plugin-systemd\",\"name\":\"fluentd\",\"received_at\":\"2021-08-20T01:25:08.085760+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-20T01:25:04.178986+00:00\",\"viaq_index_name\":\"app-write\",\"viaq_msg_id\":\"NWRjZmUyMWQtZjgzNC00MjI4LTk3MjMtNTk3NmY3ZjU4NDk1\",\"log_type\":\"application\",\"time\":\"2021-08-20T01:25:04+00:00\"}",
            "ingestionTime": 1629422744016
        },
...
Copy to Clipboard Toggle word wrap

Exemple : Personnaliser le préfixe dans les noms de groupes de journaux

Dans les noms de groupe de journaux, vous pouvez remplacer le préfixe par défaut InfrastructureName, mycluster-7977k, par une chaîne arbitraire comme demo-group-prefix. Afin d’effectuer cette modification, vous mettez à jour le champ groupPrefix dans le ClusterLogForwarding CR: 

cloudwatch:
    groupBy: logType
    groupPrefix: demo-group-prefix
    region: us-east-2
Copy to Clipboard Toggle word wrap

La valeur de groupPrefix remplace le préfixe infrastructure par défautName: 

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"demo-group-prefix.application"
"demo-group-prefix.audit"
"demo-group-prefix.infrastructure"
Copy to Clipboard Toggle word wrap

Exemple: Nom des groupes de journaux après les noms de l’espace de noms de l’application

Dans chaque espace de noms d’applications de votre cluster, vous pouvez créer un groupe de journaux dans CloudWatch dont le nom est basé sur le nom de l’espace de noms de l’application.

Lorsque vous supprimez un objet d’espace de noms d’application et créez un nouvel objet portant le même nom, CloudWatch continue d’utiliser le même groupe de journaux qu’auparavant.

Lorsque vous considérez des objets d’espace de noms d’application successifs qui ont le même nom comme équivalents les uns aux autres, utilisez l’approche décrite dans cet exemple. Dans le cas contraire, si vous devez distinguer les groupes de journaux résultants les uns des autres, consultez la section suivante "Noming log groups for application namespace UUIDs" section à la place.

Afin de créer des groupes de journaux d’applications dont les noms sont basés sur les noms des espaces de noms de l’application, vous définissez la valeur du groupePar le champ namespaceName dans le ClusterLogForwarder CR: 

cloudwatch:
    groupBy: namespaceName
    region: us-east-2
Copy to Clipboard Toggle word wrap

Le groupe de configurationPar à namespaceName affecte uniquement le groupe de journal de l’application. Cela n’affecte pas les groupes d’audit et de journal de l’infrastructure.

Dans Amazon Cloudwatch, le nom de l’espace de noms apparaît à la fin de chaque nom de groupe de journal. Comme il y a un seul espace de noms d’application, "app", la sortie suivante montre un nouveau groupe de journaux mycluster-7977k.app au lieu de mycluster-7977k.application: 

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.app"
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"
Copy to Clipboard Toggle word wrap

Lorsque le cluster de cet exemple contenait plusieurs espaces de noms d’applications, la sortie afficherait plusieurs groupes de journaux, un pour chaque espace de noms.

Le champ groupBy affecte uniquement le groupe de journal des applications. Cela n’affecte pas les groupes d’audit et de journal de l’infrastructure.

Exemple: Nom des groupes de journaux après l’espace de noms de l’application UUIDs

Dans chaque espace de noms d’applications de votre cluster, vous pouvez créer un groupe de journaux dans CloudWatch dont le nom est basé sur l’UUID de l’espace de noms de l’application.

Lorsque vous supprimez un objet d’espace de noms d’application et créez un nouvel objet, CloudWatch crée un nouveau groupe de journaux.

Lorsque vous considérez des objets d’espace de noms d’application successifs avec le même nom comme différents les uns des autres, utilisez l’approche décrite dans cet exemple. Dans le cas contraire, voir la section « Exemple : Nom des groupes de journaux pour les noms d’espace de noms d’applications » à la place.

Afin de nommer les groupes de journaux après les UUIDs de l’espace de noms de l’application, vous définissez la valeur du groupePar le champ namespaceUUID dans le ClusterLogForwarder CR: 

cloudwatch:
    groupBy: namespaceUUID
    region: us-east-2
Copy to Clipboard Toggle word wrap

Dans Amazon Cloudwatch, l’UUID de namespace apparaît à la fin de chaque nom de groupe de journal. Comme il y a un seul espace de noms d’application, "app", la sortie suivante montre un nouveau groupe de journaux mycluster-7977k.794e1a-b9f5-4958-a190-e76a9b53d7bf au lieu de mycluster-7977k.application: 

$ aws --output json logs describe-log-groups | jq .logGroups[].logGroupName
"mycluster-7977k.794e1e1a-b9f5-4958-a190-e76a9b53d7bf" // uid of the "app" namespace
"mycluster-7977k.audit"
"mycluster-7977k.infrastructure"
Copy to Clipboard Toggle word wrap

Le champ groupBy affecte uniquement le groupe de journal des applications. Cela n’affecte pas les groupes d’audit et de journal de l’infrastructure.

Lorsque vous avez un rôle existant pour AWS, vous pouvez créer un secret pour AWS avec STS en utilisant la commande oc create secret -- from-littéral.

Procédure

  • Dans le CLI, entrez ce qui suit pour générer un secret pour AWS: 

    $ oc create secret generic cw-sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/my-role_with-permissions
    Copy to Clipboard Toggle word wrap

    Exemple secret

    apiVersion: v1
kind: Secret
metadata:
  namespace: openshift-logging
  name: my-secret-name
stringData:
  role_arn: arn:aws:iam::123456789012:role/my-role_with-permissions
    Copy to Clipboard Toggle word wrap

Dans le cas des clusters avec AWS Security Token Service (STS) activés, vous devez créer les rôles et les politiques AWS IAM qui permettent le transfert de journaux, et une ressource personnalisée ClusterLogForwarder (CR) avec une sortie pour CloudWatch.

Conditions préalables

  • Journalisation pour Red Hat OpenShift: 5.5 et versions ultérieures

Procédure

  1. Créer le compte AWS:

    1. Créez un fichier JSON de stratégie IAM avec le contenu suivant: 

      {
"Version": "2012-10-17",
"Statement": [
    {
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:DescribeLogGroups",
      "logs:DescribeLogStreams",
      "logs:PutLogEvents",
      "logs:PutRetentionPolicy"
    ],
    "Resource": "arn:aws:logs:*:*:*"
    }
  ]
}
      Copy to Clipboard Toggle word wrap

    2. Créez un fichier JSON de confiance IAM avec le contenu suivant: 

      {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<your_aws_account_id>:oidc-provider/<openshift_oidc_provider>"
      1 
      
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "<openshift_oidc_provider>:sub": "system:serviceaccount:openshift-logging:logcollector"
      2 
      
        }
      }
    }
  ]
}
      Copy to Clipboard Toggle word wrap
      1
      Indiquez votre identifiant de compte AWS et le point de terminaison du fournisseur OpenShift OIDC. Obtenez le point de terminaison en exécutant la commande suivante: 
      $ rosa describe cluster \
  -c $(oc get clusterversion -o jsonpath='{.items[].spec.clusterID}{"\n"}') \
  -o yaml | awk '/oidc_endpoint_url/ {print $2}' | cut -d '/' -f 3,4
      Copy to Clipboard Toggle word wrap
      2
      Indiquez à nouveau le point de terminaison OpenShift OIDC.

    3. Créer le rôle de l’IAM: 

      $ aws iam create-role
  --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
  --assume-role-policy-document file://<your_trust_file_name>.json \
  --query Role.Arn \
  --output text
      Copy to Clipboard Toggle word wrap

      Enregistrez la sortie. Dans les prochaines étapes, vous l’utiliserez.

    4. Créer la politique IAM: 

      $ aws iam create-policy \
--policy-name "RosaCloudWatch" \
--policy-document file:///<your_policy_file_name>.json \
--query Policy.Arn \
--output text
      Copy to Clipboard Toggle word wrap

      Enregistrez la sortie. Dans les prochaines étapes, vous l’utiliserez.

    5. Attacher la politique de l’IAM au rôle de l’IAM: 

      $ aws iam attach-role-policy \
 --role-name “<your_rosa_cluster_name>-RosaCloudWatch” \
 --policy-arn <policy_ARN>
      1
      Copy to Clipboard Toggle word wrap
      1
      Remplace policy_ARN par la sortie que vous avez enregistrée lors de la création de la stratégie.

  2. Créer un fichier Secret YAML pour le Red Hat OpenShift Logging Operator: 

    apiVersion: v1
kind: Secret
metadata:
  name: cloudwatch-credentials
  namespace: openshift-logging
stringData:
  credentials: |-
    [default]
    sts_regional_endpoints = regional
    role_arn: <role_ARN>
    1 
    
    web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token
    Copy to Clipboard Toggle word wrap
    1
    Il suffit de remplacer role_ARN par la sortie que vous avez enregistrée lors de la création du rôle.

  3. Créer le secret: 

    $ oc apply -f cloudwatch-credentials.yaml
    Copy to Clipboard Toggle word wrap

  4. Créer ou modifier une ressource personnalisée ClusterLogForwarder: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: <log_forwarder_name>
    1 
    
  namespace: <log_forwarder_namespace>
    2 
    
spec:
  serviceAccountName: <service_account_name>
    3 
    
  outputs:
   - name: cw
    4 
    
     type: cloudwatch
    5 
    
     cloudwatch:
       groupBy: logType
    6 
    
       groupPrefix: <group prefix>
    7 
    
       region: us-east-2
    8 
    
     secret:
        name: <your_secret_name>
    9 
    
  pipelines:
    - name: to-cloudwatch
    10 
    
      inputRefs:
    11 
    
        - infrastructure
        - audit
        - application
      outputRefs:
        - cw
    12
    Copy to Clipboard Toggle word wrap
    1
    Dans les implémentations antérieures, le nom CR doit être instance. Dans les implémentations de transbordeur de journaux multiples, vous pouvez utiliser n’importe quel nom.
    2
    Dans les implémentations héritées, l’espace de noms CR doit être ouvert-logging. Dans les implémentations de transfert de journaux multiples, vous pouvez utiliser n’importe quel espace de noms.
    3
    Le nom de votre compte de service. Le compte de service n’est requis que dans les implémentations de transbordeur de journaux multiples si l’expéditeur de journaux n’est pas déployé dans l’espace de noms openshift-logging.
    4
    Indiquez un nom pour la sortie.
    5
    Indiquez le type de cloudwatch.
    6
    Facultatif: Spécifiez comment regrouper les journaux:
    • logType crée des groupes de journaux pour chaque type de journal
    • namespaceName crée un groupe de journal pour chaque espace de noms d’application. Les journaux d’infrastructure et d’audit ne sont pas affectés, restant regroupés par logType.
    • namespaceUUID crée un nouveau groupe de journaux pour chaque espace de noms d’application UUID. Il crée également des groupes de journaux distincts pour l’infrastructure et les journaux d’audit.
    7
    Facultatif : Spécifiez une chaîne de caractères pour remplacer le préfixe par défaut d’infrastructureName dans les noms des groupes de journaux.
    8
    Indiquez la région AWS.
    9
    Indiquez le nom du secret que vous avez créé précédemment.
    10
    Facultatif : Spécifiez un nom pour le pipeline.
    11
    Indiquez les types de journaux à transmettre en utilisant le pipeline : application, infrastructure ou vérification.
    12
    Indiquez le nom de la sortie à utiliser lors de la transmission des journaux avec ce pipeline.

9.5. Configuration du collecteur de journalisation
Copier lien

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

9.6. Collecte et stockage des événements Kubernetes
Copier lien

Le Red Hat OpenShift Service sur AWS Event Router est un pod qui regarde les événements Kubernetes et les enregistre pour la collecte par la journalisation. Il faut déployer manuellement le routeur d’événements.

Le routeur de l’événement recueille les événements de tous les projets et les écrit à STDOUT. Le collecteur transmet ensuite ces événements au magasin défini dans la ressource personnalisée ClusterLogForwarder (CR).

Important

Le routeur d’événements ajoute une charge supplémentaire à Fluentd et peut avoir un impact sur le nombre d’autres messages de journal qui peuvent être traités.

Employez les étapes suivantes pour déployer le routeur d’événements dans votre cluster. Il faut toujours déployer le routeur d’événements dans le projet openshift-logging pour s’assurer qu’il recueille les événements de l’ensemble du cluster.

Note

L’image du routeur d’événement ne fait pas partie de l’opérateur de journalisation Red Hat OpenShift et doit être téléchargée séparément.

L’objet Modèle suivant crée le compte de service, le rôle de cluster et la liaison de rôle de cluster requis pour le routeur d’événements. Le modèle configure et déploie également le pod Event Router. Il est possible d’utiliser ce modèle sans apporter de modifications ou de modifier le modèle pour modifier les requêtes CPU et mémoire de l’objet de déploiement.

Conditions préalables

  • Il vous faut des autorisations appropriées pour créer des comptes de service et mettre à jour les liaisons de rôle de cluster. À titre d’exemple, vous pouvez exécuter le modèle suivant avec un utilisateur qui a le rôle de cluster-admin.
  • Le Red Hat OpenShift Logging Operator doit être installé.

Procédure

  1. Créer un modèle pour le routeur d’événements: 

    apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: eventrouter-template
  annotations:
    description: "A pod forwarding kubernetes events to OpenShift Logging stack."
    tags: "events,EFK,logging,cluster-logging"
objects:
  - kind: ServiceAccount
    1 
    
    apiVersion: v1
    metadata:
      name: eventrouter
      namespace: ${NAMESPACE}
  - kind: ClusterRole
    2 
    
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: event-reader
    rules:
    - apiGroups: [""]
      resources: ["events"]
      verbs: ["get", "watch", "list"]
  - kind: ClusterRoleBinding
    3 
    
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: event-reader-binding
    subjects:
    - kind: ServiceAccount
      name: eventrouter
      namespace: ${NAMESPACE}
    roleRef:
      kind: ClusterRole
      name: event-reader
  - kind: ConfigMap
    4 
    
    apiVersion: v1
    metadata:
      name: eventrouter
      namespace: ${NAMESPACE}
    data:
      config.json: |-
        {
          "sink": "stdout"
        }
  - kind: Deployment
    5 
    
    apiVersion: apps/v1
    metadata:
      name: eventrouter
      namespace: ${NAMESPACE}
      labels:
        component: "eventrouter"
        logging-infra: "eventrouter"
        provider: "openshift"
    spec:
      selector:
        matchLabels:
          component: "eventrouter"
          logging-infra: "eventrouter"
          provider: "openshift"
      replicas: 1
      template:
        metadata:
          labels:
            component: "eventrouter"
            logging-infra: "eventrouter"
            provider: "openshift"
          name: eventrouter
        spec:
          serviceAccount: eventrouter
          containers:
            - name: kube-eventrouter
              image: ${IMAGE}
              imagePullPolicy: IfNotPresent
              resources:
                requests:
                  cpu: ${CPU}
                  memory: ${MEMORY}
              volumeMounts:
              - name: config-volume
                mountPath: /etc/eventrouter
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop: ["ALL"]
          securityContext:
            runAsNonRoot: true
            seccompProfile:
              type: RuntimeDefault
          volumes:
          - name: config-volume
            configMap:
              name: eventrouter
parameters:
  - name: IMAGE
    6 
    
    displayName: Image
    value: "registry.redhat.io/openshift-logging/eventrouter-rhel9:v0.4"
  - name: CPU
    7 
    
    displayName: CPU
    value: "100m"
  - name: MEMORY
    8 
    
    displayName: Memory
    value: "128Mi"
  - name: NAMESPACE
    displayName: Namespace
    value: "openshift-logging"
    9
    Copy to Clipboard Toggle word wrap
    1
    Crée un compte de service dans le projet openshift-logging pour le routeur d’événements.
    2
    Crée un ClusterRole pour surveiller les événements dans le cluster.
    3
    Crée un ClusterRoleBinding pour lier le ClusterRole au compte de service.
    4
    Crée une carte de configuration dans le projet openshift-logging pour générer le fichier config.json requis.
    5
    Crée un déploiement dans le projet openshift-logging pour générer et configurer le pod Event Router.
    6
    Indique l’image, identifiée par une balise telle que v0.4.
    7
    Indique la quantité minimale de CPU à allouer à la pod de routeur d’événement. Défaut à 100m.
    8
    Indique la quantité minimale de mémoire à allouer à la pod de routeur d’événements. Défaut à 128Mi.
    9
    Spécifie le projet openshift-logging pour installer des objets dans.

  2. Utilisez la commande suivante pour traiter et appliquer le modèle: 

    $ oc process -f <templatefile> | oc apply -n openshift-logging -f -
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc process -f eventrouter.yaml | oc apply -n openshift-logging -f -
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    serviceaccount/eventrouter created
clusterrole.rbac.authorization.k8s.io/event-reader created
clusterrolebinding.rbac.authorization.k8s.io/event-reader-binding created
configmap/eventrouter created
deployment.apps/eventrouter created
    Copy to Clipboard Toggle word wrap

  3. De valider que le routeur d’événement installé dans le projet openshift-logging:

    1. Consultez le nouveau module de routeur d’événements: 

      $ oc get pods --selector  component=eventrouter -o name -n openshift-logging
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      pod/cluster-logging-eventrouter-d649f97c8-qvv8r
      Copy to Clipboard Toggle word wrap

    2. Consultez les événements recueillis par le routeur de l’événement: 

      $ oc logs <cluster_logging_eventrouter_pod> -n openshift-logging
      Copy to Clipboard Toggle word wrap

      À titre d’exemple: 

      $ oc logs cluster-logging-eventrouter-d649f97c8-qvv8r -n openshift-logging
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      {"verb":"ADDED","event":{"metadata":{"name":"openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","namespace":"openshift-service-catalog-removed","selfLink":"/api/v1/namespaces/openshift-service-catalog-removed/events/openshift-service-catalog-controller-manager-remover.1632d931e88fcd8f","uid":"787d7b26-3d2f-4017-b0b0-420db4ae62c0","resourceVersion":"21399","creationTimestamp":"2020-09-08T15:40:26Z"},"involvedObject":{"kind":"Job","namespace":"openshift-service-catalog-removed","name":"openshift-service-catalog-controller-manager-remover","uid":"fac9f479-4ad5-4a57-8adc-cb25d3d9cf8f","apiVersion":"batch/v1","resourceVersion":"21280"},"reason":"Completed","message":"Job completed","source":{"component":"job-controller"},"firstTimestamp":"2020-09-08T15:40:26Z","lastTimestamp":"2020-09-08T15:40:26Z","count":1,"type":"Normal"}}
      Copy to Clipboard Toggle word wrap

      Il est également possible d’utiliser Kibana pour afficher les événements en créant un modèle d’index à l’aide de l’indice Elasticsearch infra.

Chapitre 10. Journal de stockage
Copier lien

10.1. À propos du stockage des journaux
Copier lien

Il est possible d’utiliser un log Store interne Loki ou Elasticsearch sur votre cluster pour stocker les journaux, ou vous pouvez utiliser une ressource personnalisée ClusterLogForwarder (CR) pour transférer les journaux vers un magasin externe.

10.1.1. Log types de stockage
Copier lien

Loki est un système d’agrégation de log multi-locataires à l’échelle horizontale, hautement disponible, offert en tant que log store GA pour l’enregistrement de Red Hat OpenShift qui peut être visualisé avec l’interface d’observation OpenShift. La configuration Loki fournie par OpenShift Logging est un log store à court terme conçu pour permettre aux utilisateurs d’effectuer un dépannage rapide avec les journaux collectés. À cette fin, l’enregistrement de la configuration Red Hat OpenShift de Loki dispose d’un stockage à court terme et est optimisé pour les requêtes très récentes. Dans le cas d’un stockage ou d’une requête à long terme sur une longue période, les utilisateurs devraient chercher à loger des magasins externes à leur cluster.

Elasticsearch indexe les enregistrements de log entrants complètement pendant l’ingestion. Loki n’indexe que quelques étiquettes fixes lors de l’ingestion et reporte l’analyse plus complexe jusqu’à ce que les journaux aient été stockés. Cela signifie que Loki peut collecter des journaux plus rapidement.

10.1.1.1. À propos de la boutique de journal Elasticsearch
Copier lien

L’instance d’enregistrement Elasticsearch est optimisée et testée pour le stockage à court terme, environ sept jours. Lorsque vous souhaitez conserver vos journaux à plus long terme, il est recommandé de déplacer les données vers un système de stockage tiers.

Elasticsearch organise les données de log de Fluentd en datastores, ou indices, puis subdivise chaque index en plusieurs morceaux appelés shards, qu’il diffuse à travers un ensemble de nœuds Elasticsearch dans un cluster Elasticsearch. Il est possible de configurer Elasticsearch pour faire des copies des fragments, appelés répliques, qu’Elasticsearch diffuse également à travers les nœuds Elasticsearch. La ressource personnalisée ClusterLogging (CR) vous permet de spécifier comment les fragments sont reproduits pour fournir une redondance des données et une résilience à l’échec. Il est également possible de spécifier combien de temps les différents types de journaux sont conservés à l’aide d’une stratégie de rétention dans le ClusterLogging CR.

Note

Le nombre de fragments primaires pour les modèles d’index est égal au nombre de nœuds de données Elasticsearch.

Le Red Hat OpenShift Logging Operator et son compagnon OpenShift Elasticsearch Operator s’assurent que chaque nœud Elasticsearch est déployé à l’aide d’un déploiement unique qui inclut son propre volume de stockage. Au besoin, vous pouvez utiliser une ressource personnalisée ClusterLogging (CR) pour augmenter le nombre de nœuds Elasticsearch. Consultez la documentation Elasticsearch pour les considérations impliquées dans la configuration du stockage.

Note

L’environnement Elasticsearch hautement disponible nécessite au moins trois nœuds Elasticsearch, chacun sur un hôte différent.

Le contrôle d’accès basé sur les rôles (RBAC) appliqué sur les indices Elasticsearch permet l’accès contrôlé des journaux aux développeurs. Les administrateurs peuvent accéder à tous les journaux et les développeurs ne peuvent accéder qu’aux journaux de leurs projets.

10.1.2. Interroger les magasins de journaux
Copier lien

Il est possible d’interroger Loki en utilisant le langage de requête LogQL.

10.2. Installation du stockage des journaux
Copier lien

Il est possible d’utiliser OpenShift CLI (oc) ou Red Hat OpenShift Service sur la console web AWS pour déployer un log store sur votre Red Hat OpenShift Service sur le cluster AWS.

Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

10.2.1. Déploiement d’un log store Loki
Copier lien

Il est possible d’utiliser l’opérateur Loki pour déployer un log store interne sur votre Red Hat OpenShift Service sur AWS cluster. Après avoir installé l’opérateur Loki, vous devez configurer le stockage d’objets Loki en créant un secret et créer une ressource personnalisée LokiStack (CR).

10.2.1.1. Dimensionnement du déploiement de Loki
Copier lien

Le dimensionnement pour Loki suit le format de 1x.&lt;size&gt; où la valeur 1x est le nombre d’instances et &lt;size&gt; spécifie les capacités de performance.

Important

Il n’est pas possible de modifier le nombre 1x pour la taille du déploiement.

Expand
Tableau 10.1. Dimensionnement de Loki
 1x.demo1x.extra-petit1x.petit1x.médium

Le transfert de données

Démo utiliser uniquement

100 Go/jour

500 Go/jour

2 To/jour

Requêtes par seconde (QPS)

Démo utiliser uniquement

1-25 QPS à 200ms

25-50 QPS à 200ms

25-75 QPS à 200ms

Facteur de réplication

Aucune.

2

2

2

Demandes totales de CPU

Aucune.

14 vCPUs

34 vCPUs

54 vCPUs

Demandes CPU totales si vous utilisez la règle

Aucune.

16 vCPUs

42 vCPUs

70 vCPUs

Demandes totales de mémoire

Aucune.

31GI

67GI

139GI

Demandes totales de mémoire si vous utilisez la règle

Aucune.

35GI

83GI

171GI

Demandes totales de disque

40GI

430GI

430GI

590GI

Demandes totales de disque si l’utilisation de la règle

80GI

750GI

750GI

910GI

Afin d’installer et de configurer la connexion de votre Red Hat OpenShift Service sur le cluster AWS, un opérateur tel que Loki Operator pour le stockage des journaux doit être installé en premier. Cela peut être fait à partir de OperatorHub dans la console Web.

Conditions préalables

  • Accès à un magasin d’objets pris en charge (AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation).
  • Il y a des autorisations d’administrateur.
  • Accès au service Red Hat OpenShift sur la console web AWS.

Procédure

  1. Dans le Red Hat OpenShift Service sur AWS Web console Administrator perspective, allez à Opérateurs → OperatorHub.

  2. Entrez Loki Opérateur dans le champ Filtrer par mot-clé. Cliquez sur l’opérateur Loki dans la liste des opérateurs disponibles, puis cliquez sur Installer.

    Important

    L’opérateur Loki communautaire n’est pas soutenu par Red Hat.

  3. Choisissez stable ou stable-x.y comme canal de mise à jour.

    Note

    Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

    L’opérateur Loki doit être déployé dans l’espace de noms du groupe d’opérateur mondial openshift-operators-redhat, de sorte que le mode Installation et Namespace installé sont déjà sélectionnés. Lorsque cet espace de noms n’existe pas déjà, il est créé pour vous.

  4. Activez la surveillance des clusters recommandée par l’opérateur sur cet espace de noms.

    Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-operators-redhat.

  5. Dans le cas de l’approbation de mise à jour, sélectionnez Automatique, puis cliquez sur Installer.

    Lorsque la stratégie d’approbation de l’abonnement est définie sur Automatique, le processus de mise à jour démarre dès qu’une nouvelle version de l’opérateur est disponible dans le canal sélectionné. Lorsque la stratégie d’approbation est définie sur Manuel, vous devez approuver manuellement les mises à jour en attente.

  6. Installez l’opérateur de journalisation Red Hat OpenShift:

    1. Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → OperatorHub.
    2. Choisissez Red Hat OpenShift Logging dans la liste des opérateurs disponibles, puis cliquez sur Installer.
    3. Assurez-vous que l’espace de noms A spécifique sur le cluster est sélectionné sous Mode d’installation.
    4. Assurez-vous que l’espace de noms recommandé par l’opérateur est ouvert de connexion sous Namespace installé.

    5. Activer l’opérateur recommande la surveillance des clusters sur cet espace de noms.

      Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-logging.

    6. Choisissez stable-5.y comme canal de mise à jour.

    7. Choisissez une stratégie d’approbation.

      • La stratégie automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible.
      • La stratégie du Manuel exige qu’un utilisateur ayant les informations d’identification appropriées approuve la mise à jour de l’opérateur.
    8. Cliquez sur Install.
  7. Accédez à la page Opérateurs installés → Opérateurs installés. Cliquez sur l’onglet Toutes les instances.
  8. Dans la liste déroulante Créer une nouvelle liste déroulante, sélectionnez LokiStack.

  9. Choisissez la vue YAML, puis utilisez le modèle suivant pour créer un LokiStack CR:

    Exemple LokiStack CR

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  size: 1x.small
    3 
    
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3
    4 
    
      type: s3
    5 
    
      credentialMode:
    6 
    
  storageClassName: <storage_class_name>
    7 
    
  tenants:
    mode: openshift-logging
    8
    Copy to Clipboard Toggle word wrap

    1
    J’utilise le nom logging-loki.
    2
    Il faut spécifier l’espace de noms openshift-logging.
    3
    Indiquez la taille du déploiement. Dans l’enregistrement 5.8 et les versions ultérieures, les options de taille prises en charge pour les instances de production de Loki sont 1x.extra-petit, 1x.petit, ou 1x.medium.
    4
    Indiquez le nom de votre log store secret.
    5
    Indiquez le type de stockage correspondant.
    6
    Champ optionnel, journalisation 5.9 et ultérieure. Les valeurs configurées par l’utilisateur pris en charge sont les suivantes: statique est le mode d’authentification par défaut disponible pour tous les types de stockage d’objet pris en charge à l’aide d’informations d’identification stockées dans un jeton Secret. Dans ce mode, la configuration statique ne contient pas d’informations d’identification nécessaires au stockage d’objets. Au lieu de cela, ils sont générés pendant l’exécution à l’aide d’un service, ce qui permet des informations d’identification plus courtes et un contrôle beaucoup plus granulaire. Ce mode d’authentification n’est pas pris en charge pour tous les types de stockage d’objets. token-cco est la valeur par défaut lorsque Loki s’exécute en mode STS géré et utilise CCO sur les clusters STS/WIF.
    7
    Indiquez le nom d’une classe de stockage pour le stockage temporaire. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l’aide de la commande oc get storageclasses.
    8
    LokiStack par défaut s’exécute en mode multi-locataires, qui ne peut pas être modifié. Il y a un locataire pour chaque type de journal : audit, infrastructure et journaux d’applications. Cela permet le contrôle d’accès pour les utilisateurs individuels et les groupes d’utilisateurs à différents flux de journaux.
    Important

    Il n’est pas possible de modifier le nombre 1x pour la taille du déploiement.

  10. Cliquez sur Create.

  11. Créer une instance OpenShift Logging:

    1. Basculez à la page Administration → Définitions de ressources personnalisées.
    2. Dans la page Définitions de ressources personnalisées, cliquez sur ClusterLogging.
    3. Dans la page Détails de la définition des ressources personnalisées, sélectionnez Afficher les instances dans le menu Actions.

    4. Dans la page ClusterLoggings, cliquez sur Créer ClusterLogging.

      Il vous faudra peut-être actualiser la page pour charger les données.

    5. Dans le champ YAML, remplacer le code par ce qui suit: 

      apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
      1 
      
  namespace: openshift-logging
      2 
      
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    retentionPolicy:
      application:
        maxAge: 7d
      audit:
        maxAge: 7d
      infra:
        maxAge: 7d
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15

  managementState: Managed
      Copy to Clipboard Toggle word wrap
      1
      Le nom doit être instance.
      2
      L’espace de noms doit être ouvert-logging.

La vérification

  1. Allez à Opérateurs → Opérateurs installés.
  2. Assurez-vous que le projet openshift-logging est sélectionné.
  3. Dans la colonne État, vérifiez que vous voyez des cocheries vertes avec InstallSucceeded et le texte à jour.
Note

L’opérateur peut afficher un état d’échec avant la fin de l’installation. Lorsque l’opérateur installe avec un message InstallSucceeded, actualisez la page.

Afin de configurer le stockage d’objets Loki, vous devez créer un secret. Créez un secret en utilisant le service Red Hat OpenShift sur la console web AWS.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Accès au service Red Hat OpenShift sur la console web AWS.
  • J’ai installé l’opérateur Loki.

Procédure

  1. Allez à Charges de travail → Secrets dans la perspective de l’administrateur du Red Hat OpenShift Service sur la console web AWS.
  2. Dans la liste déroulante Créer, sélectionnez À partir de YAML.

  3. Créez un secret qui utilise les champs access_key_id et access_key_secret pour spécifier vos identifiants et les champs seau, point de terminaison et région pour définir l’emplacement de stockage d’objets. AWS est utilisé dans l’exemple suivant:

    Exemple d’objet secret

    apiVersion: v1
kind: Secret
metadata:
  name: logging-loki-s3
  namespace: openshift-logging
stringData:
  access_key_id: AKIAIOSFODNN7EXAMPLE
  access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
  bucketnames: s3-bucket-name
  endpoint: https://s3.eu-central-1.amazonaws.com
  region: eu-central-1
    Copy to Clipboard Toggle word wrap

10.2.1.4. Fédération d’identité de la charge de travail
Copier lien

La fédération d’identité de charge de travail permet l’authentification des magasins de journaux basés sur le cloud à l’aide de jetons de courte durée.

Conditions préalables

  • Le Red Hat OpenShift Service sur AWS 4.14 et versions ultérieures
  • Journalisation 5.9 et ultérieure

Procédure

  • Lorsque vous utilisez le service Red Hat OpenShift sur la console web AWS pour installer l’opérateur Loki, les clusters qui utilisent des jetons de courte durée sont automatiquement détectés. Il vous est demandé de créer des rôles et de fournir les données nécessaires à l’opérateur Loki pour créer un objet CredentialsRequest, qui peuple un secret.
  • Lorsque vous utilisez l’OpenShift CLI (oc) pour installer l’opérateur Loki, vous devez créer manuellement un objet d’abonnement en utilisant le modèle approprié pour votre fournisseur de stockage, comme indiqué dans les exemples suivants. Cette stratégie d’authentification n’est prise en charge que pour les fournisseurs de stockage indiqués.

Abonnement à l’échantillon Azure

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-5.9"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
      - name: CLIENTID
        value: <your_client_id>
      - name: TENANTID
        value: <your_tenant_id>
      - name: SUBSCRIPTIONID
        value: <your_subscription_id>
      - name: REGION
        value: <your_region>
Copy to Clipboard Toggle word wrap

Abonnement à l’échantillon AWS

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
spec:
  channel: "stable-5.9"
  installPlanApproval: Manual
  name: loki-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  config:
    env:
    - name: ROLEARN
      value: <role_ARN>
Copy to Clipboard Toggle word wrap

Il est possible de créer une ressource personnalisée LokiStack (CR) en utilisant le service Red Hat OpenShift sur la console web AWS.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Accès au service Red Hat OpenShift sur la console web AWS.
  • J’ai installé l’opérateur Loki.

Procédure

  1. Accédez à la page Opérateurs installés → Opérateurs installés. Cliquez sur l’onglet Toutes les instances.
  2. Dans la liste déroulante Créer une nouvelle liste déroulante, sélectionnez LokiStack.

  3. Choisissez la vue YAML, puis utilisez le modèle suivant pour créer un LokiStack CR: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
    1 
    
  namespace: openshift-logging
spec:
  size: 1x.small
    2 
    
  storage:
    schemas:
      - effectiveDate: '2023-10-15'
        version: v13
    secret:
      name: logging-loki-s3
    3 
    
      type: s3
    4 
    
      credentialMode:
    5 
    
  storageClassName: <storage_class_name>
    6 
    
  tenants:
    mode: openshift-logging
    Copy to Clipboard Toggle word wrap
    1
    J’utilise le nom logging-loki.
    2
    Indiquez la taille du déploiement. Dans l’enregistrement 5.8 et les versions ultérieures, les options de taille prises en charge pour les instances de production de Loki sont 1x.extra-petit, 1x.petit, ou 1x.medium.
    3
    Indiquez le secret utilisé pour votre stockage de journal.
    4
    Indiquez le type de stockage correspondant.
    5
    Champ optionnel, journalisation 5.9 et ultérieure. Les valeurs configurées par l’utilisateur pris en charge sont les suivantes: statique est le mode d’authentification par défaut disponible pour tous les types de stockage d’objet pris en charge à l’aide d’informations d’identification stockées dans un Secret. jetons pour les jetons de courte durée récupérés à partir d’une source d’identification. Dans ce mode, la configuration statique ne contient pas d’informations d’identification nécessaires au stockage d’objets. Au lieu de cela, ils sont générés pendant l’exécution à l’aide d’un service, ce qui permet des informations d’identification plus courtes et un contrôle beaucoup plus granulaire. Ce mode d’authentification n’est pas pris en charge pour tous les types de stockage d’objets. le token-cco est la valeur par défaut lorsque Loki s’exécute en mode STS géré et utilise CCO sur les clusters STS/WIF.
    6
    Entrez le nom d’une classe de stockage pour le stockage temporaire. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l’aide de la commande oc get storageclasses.

Afin d’installer et de configurer la connexion de votre Red Hat OpenShift Service sur le cluster AWS, un opérateur tel que Loki Operator pour le stockage des journaux doit être installé en premier. Cela peut être fait à partir du service Red Hat OpenShift sur AWS CLI.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Installation de l’OpenShift CLI (oc).
  • Accès à un magasin d’objets pris en charge. AWS S3, Google Cloud Storage, Azure, Swift, Minio ou OpenShift Data Foundation.
Note

Le canal stable ne fournit que des mises à jour de la version la plus récente de l’enregistrement. Afin de continuer à recevoir des mises à jour pour les versions antérieures, vous devez changer votre canal d’abonnement en stable-x.y, où x.y représente la version majeure et mineure de la journalisation que vous avez installée. À titre d’exemple, stable-5.7.

  1. Créer un objet Namespace pour Loki Operator:

    Exemple d’objet Namespace

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-operators-redhat
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true"
    2
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat. Afin d’éviter d’éventuels conflits avec les métriques, vous devez configurer la pile Prometheus Cluster Monitoring pour gratter les métriques de l’espace de noms openshift-operators-redhat et non de l’espace de noms openshift-operators. L’espace de noms openshift-operators peut contenir des opérateurs communautaires, qui ne sont pas fiables et pourraient publier une métrique avec le même nom qu’un service OpenShift Red Hat sur la métrique AWS, ce qui provoquerait des conflits.
    2
    La valeur de chaîne qui spécifie l’étiquette comme indiqué pour s’assurer que la surveillance du cluster gratte l’espace de noms openshift-operators-redhat.

  2. Appliquez l’objet Namespace en exécutant la commande suivante: 

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

  3. Créer un objet d’abonnement pour Loki Operator:

    Exemple d’objet d’abonnement

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: loki-operator
  namespace: openshift-operators-redhat
    1 
    
spec:
  channel: stable
    2 
    
  name: loki-operator
  source: redhat-operators
    3 
    
  sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat.
    2
    Indiquez stable, ou stable-5.&lt;y&gt; comme canal.
    3
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également appelé cluster déconnecté, spécifiez le nom de l’objet CatalogSource que vous avez créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM).

  4. Appliquer l’objet Abonnement en exécutant la commande suivante: 

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

  5. Créer un objet d’espace de noms pour l’opérateur de journalisation OpenShift Red Hat:

    Exemple d’objet namespace

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-logging: "true"
    openshift.io/cluster-monitoring: "true"
    2
    Copy to Clipboard Toggle word wrap

    1
    L’opérateur de journalisation OpenShift de Red Hat n’est déployable que dans l’espace de noms openshift-logging.
    2
    La valeur de chaîne qui spécifie l’étiquette comme indiqué pour s’assurer que la surveillance du cluster gratte l’espace de noms openshift-operators-redhat.

  6. Appliquez l’objet namespace en exécutant la commande suivante: 

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

  7. Créer un objet OperatorGroup

    Exemple d’objet OperatorGroup

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
    1 
    
spec:
  targetNamespaces:
  - openshift-logging
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-logging.

  8. Appliquez l’objet OperatorGroup en exécutant la commande suivante: 

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

  9. Créer un objet d’abonnement: 

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
    1 
    
spec:
  channel: stable
    2 
    
  name: cluster-logging
  source: redhat-operators
    3 
    
  sourceNamespace: openshift-marketplace
    Copy to Clipboard Toggle word wrap
    1
    Il faut spécifier l’espace de noms openshift-logging.
    2
    Indiquez stable, ou stable-5.&lt;y&gt; comme canal.
    3
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également appelé cluster déconnecté, spécifiez le nom de l’objet CatalogSource que vous avez créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM).

  10. Appliquer l’objet Abonnement en exécutant la commande suivante: 

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

  11. Créer un LokiStack CR:

    Exemple LokiStack CR

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  size: 1x.small
    3 
    
  storage:
    schemas:
    - version: v13
      effectiveDate: "<yyyy>-<mm>-<dd>"
    secret:
      name: logging-loki-s3
    4 
    
      type: s3
    5 
    
      credentialMode:
    6 
    
  storageClassName: <storage_class_name>
    7 
    
  tenants:
    mode: openshift-logging
    8
    Copy to Clipboard Toggle word wrap

    1
    J’utilise le nom logging-loki.
    2
    Il faut spécifier l’espace de noms openshift-logging.
    3
    Indiquez la taille du déploiement. Dans l’enregistrement 5.8 et les versions ultérieures, les options de taille prises en charge pour les instances de production de Loki sont 1x.extra-petit, 1x.petit, ou 1x.medium.
    4
    Indiquez le nom de votre log store secret.
    5
    Indiquez le type de stockage correspondant.
    6
    Champ optionnel, journalisation 5.9 et ultérieure. Les valeurs configurées par l’utilisateur pris en charge sont les suivantes: statique est le mode d’authentification par défaut disponible pour tous les types de stockage d’objet pris en charge à l’aide d’informations d’identification stockées dans un Secret. jetons pour les jetons de courte durée récupérés à partir d’une source d’identification. Dans ce mode, la configuration statique ne contient pas d’informations d’identification nécessaires au stockage d’objets. Au lieu de cela, ils sont générés pendant l’exécution à l’aide d’un service, ce qui permet des informations d’identification plus courtes et un contrôle beaucoup plus granulaire. Ce mode d’authentification n’est pas pris en charge pour tous les types de stockage d’objets. le token-cco est la valeur par défaut lorsque Loki s’exécute en mode STS géré et utilise CCO sur les clusters STS/WIF.
    7
    Indiquez le nom d’une classe de stockage pour le stockage temporaire. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l’aide de la commande oc get storageclasses.
    8
    LokiStack par défaut s’exécute en mode multi-locataires, qui ne peut pas être modifié. Il y a un locataire pour chaque type de journal : audit, infrastructure et journaux d’applications. Cela permet le contrôle d’accès pour les utilisateurs individuels et les groupes d’utilisateurs à différents flux de journaux.

  12. Appliquez l’objet LokiStack CR en exécutant la commande suivante: 

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

  13. Créer un objet ClusterLogging CR:

    Exemple ClusterLogging objet CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
    1 
    
  namespace: openshift-logging
    2 
    
spec:
  collection:
    type: vector
  logStore:
    lokistack:
      name: logging-loki
    retentionPolicy:
      application:
        maxAge: 7d
      audit:
        maxAge: 7d
      infra:
        maxAge: 7d
    type: lokistack
  visualization:
    type: ocp-console
    ocpConsole:
      logsLimit: 15
  managementState: Managed
    Copy to Clipboard Toggle word wrap

    1
    Le nom doit être instance.
    2
    L’espace de noms doit être ouvert-logging.

  14. Appliquez l’objet ClusterLogging CR en exécutant la commande suivante: 

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

  15. Contrôlez l’installation en exécutant la commande suivante: 

    $ oc get pods -n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    $ oc get pods -n openshift-logging
NAME                                               READY   STATUS    RESTARTS   AGE
cluster-logging-operator-fb7f7cf69-8jsbq           1/1     Running   0          98m
collector-222js                                    2/2     Running   0          18m
collector-g9ddv                                    2/2     Running   0          18m
collector-hfqq8                                    2/2     Running   0          18m
collector-sphwg                                    2/2     Running   0          18m
collector-vv7zn                                    2/2     Running   0          18m
collector-wk5zz                                    2/2     Running   0          18m
logging-view-plugin-6f76fbb78f-n2n4n               1/1     Running   0          18m
lokistack-sample-compactor-0                       1/1     Running   0          42m
lokistack-sample-distributor-7d7688bcb9-dvcj8      1/1     Running   0          42m
lokistack-sample-gateway-5f6c75f879-bl7k9          2/2     Running   0          42m
lokistack-sample-gateway-5f6c75f879-xhq98          2/2     Running   0          42m
lokistack-sample-index-gateway-0                   1/1     Running   0          42m
lokistack-sample-ingester-0                        1/1     Running   0          42m
lokistack-sample-querier-6b7b56bccc-2v9q4          1/1     Running   0          42m
lokistack-sample-query-frontend-84fb57c578-gq2f7   1/1     Running   0          42m
    Copy to Clipboard Toggle word wrap

Afin de configurer le stockage d’objets Loki, vous devez créer un secret. Il est possible de le faire en utilisant l’OpenShift CLI (oc).

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).

Procédure

  • Créez un secret dans le répertoire qui contient votre certificat et vos fichiers clés en exécutant la commande suivante: 

    $ oc create secret generic -n openshift-logging <your_secret_name> \
 --from-file=tls.key=<your_key_file>
 --from-file=tls.crt=<your_crt_file>
 --from-file=ca-bundle.crt=<your_bundle_file>
 --from-literal=username=<your_username>
 --from-literal=password=<your_password>
    Copy to Clipboard Toggle word wrap
Note

Employez des secrets génériques ou opaques pour obtenir de meilleurs résultats.

La vérification

  • Assurez-vous qu’un secret a été créé en exécutant la commande suivante: 

    $ oc get secrets
    Copy to Clipboard Toggle word wrap

Il est possible de créer une ressource personnalisée LokiStack (CR) à l’aide de l’OpenShift CLI (oc).

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).

Procédure

  1. Créer un LokiStack CR:

Exemple LokiStack CR

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
1 

  namespace: openshift-logging
spec:
  size: 1x.small
2 

  storage:
    schemas:
      - effectiveDate: '2023-10-15'
        version: v13
    secret:
      name: logging-loki-s3
3 

      type: s3
4 

      credentialMode:
5 

  storageClassName: <storage_class_name>
6 

  tenants:
    mode: openshift-logging
Copy to Clipboard Toggle word wrap

1
J’utilise le nom logging-loki.
2
Indiquez la taille du déploiement. Dans l’enregistrement 5.8 et les versions ultérieures, les options de taille prises en charge pour les instances de production de Loki sont 1x.extra-petit, 1x.petit, ou 1x.medium.
3
Indiquez le secret utilisé pour votre stockage de journal.
4
Indiquez le type de stockage correspondant.
5
Champ optionnel, journalisation 5.9 et ultérieure. Les valeurs configurées par l’utilisateur pris en charge sont les suivantes: statique est le mode d’authentification par défaut disponible pour tous les types de stockage d’objet pris en charge à l’aide d’informations d’identification stockées dans un Secret. jetons pour les jetons de courte durée récupérés à partir d’une source d’identification. Dans ce mode, la configuration statique ne contient pas d’informations d’identification nécessaires au stockage d’objets. Au lieu de cela, ils sont générés pendant l’exécution à l’aide d’un service, ce qui permet des informations d’identification plus courtes et un contrôle beaucoup plus granulaire. Ce mode d’authentification n’est pas pris en charge pour tous les types de stockage d’objets. le token-cco est la valeur par défaut lorsque Loki s’exécute en mode STS géré et utilise CCO sur les clusters STS/WIF.
6
Entrez le nom d’une classe de stockage pour le stockage temporaire. Afin d’obtenir des performances optimales, spécifiez une classe de stockage qui alloue le stockage en bloc. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l’aide de la commande oc get storageclasses.
  1. Appliquez le LokiStack CR en exécutant la commande suivante:

La vérification

  • Contrôlez l’installation en listant les pods dans le projet openshift-logging en exécutant la commande suivante et en observant la sortie: 

    $ oc get pods -n openshift-logging
    Copy to Clipboard Toggle word wrap

    Confirmez que vous voyez plusieurs pods pour les composants de l’enregistrement, similaire à la liste suivante:

    Exemple de sortie

    NAME                                           READY   STATUS    RESTARTS   AGE
cluster-logging-operator-78fddc697-mnl82       1/1     Running   0          14m
collector-6cglq                                2/2     Running   0          45s
collector-8r664                                2/2     Running   0          45s
collector-8z7px                                2/2     Running   0          45s
collector-pdxl9                                2/2     Running   0          45s
collector-tc9dx                                2/2     Running   0          45s
collector-xkd76                                2/2     Running   0          45s
logging-loki-compactor-0                       1/1     Running   0          8m2s
logging-loki-distributor-b85b7d9fd-25j9g       1/1     Running   0          8m2s
logging-loki-distributor-b85b7d9fd-xwjs6       1/1     Running   0          8m2s
logging-loki-gateway-7bb86fd855-hjhl4          2/2     Running   0          8m2s
logging-loki-gateway-7bb86fd855-qjtlb          2/2     Running   0          8m2s
logging-loki-index-gateway-0                   1/1     Running   0          8m2s
logging-loki-index-gateway-1                   1/1     Running   0          7m29s
logging-loki-ingester-0                        1/1     Running   0          8m2s
logging-loki-ingester-1                        1/1     Running   0          6m46s
logging-loki-querier-f5cf9cb87-9fdjd           1/1     Running   0          8m2s
logging-loki-querier-f5cf9cb87-fp9v5           1/1     Running   0          8m2s
logging-loki-query-frontend-58c579fcb7-lfvbc   1/1     Running   0          8m2s
logging-loki-query-frontend-58c579fcb7-tjf9k   1/1     Running   0          8m2s
logging-view-plugin-79448d8df6-ckgmx           1/1     Running   0          46s
    Copy to Clipboard Toggle word wrap

10.2.2. Espace de stockage d’objets Loki
Copier lien

L’opérateur Loki prend en charge AWS S3, ainsi que d’autres magasins d’objets compatibles S3 tels que Minio et OpenShift Data Foundation. Azure, GCS et Swift sont également pris en charge.

La nomenclature recommandée pour le stockage Loki est logging-loki-&lt;your_storage_provider&gt;.

Le tableau suivant montre les valeurs de type dans la ressource personnalisée LokiStack (CR) pour chaque fournisseur de stockage. Consultez la section sur votre fournisseur de stockage pour plus d’informations.

Expand
Tableau 10.2. Le type secret de référence rapide
Fournisseur de stockageLa valeur de type secret

AWS

a) S3

Azure

Azure

Google Cloud

GCS

À propos de Minio

a) S3

Fondation de données OpenShift

a) S3

C’est rapide

C’est rapide

10.2.2.1. Le stockage AWS
Copier lien

Conditions préalables

  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).
  • « vous avez créé un seau sur AWS.
  • Il a créé une politique AWS IAM et un utilisateur IAM.

Procédure

  • Créez un secret de stockage d’objet avec le nom logging-loki-aws en exécutant la commande suivante: 

    $ oc create secret generic logging-loki-aws \
  --from-literal=bucketnames="<bucket_name>" \
  --from-literal=endpoint="<aws_bucket_endpoint>" \
  --from-literal=access_key_id="<aws_access_key_id>" \
  --from-literal=access_key_secret="<aws_access_key_secret>" \
  --from-literal=region="<aws_region_of_your_bucket>"
    Copy to Clipboard Toggle word wrap
10.2.2.1.1. Le stockage AWS pour les clusters activés STS
Copier lien

Dans le cas où votre cluster est activé STS, Cloud Credential Operator (CCO) prend en charge l’authentification à court terme à l’aide de jetons AWS.

Il est possible de créer manuellement le secret de stockage d’objets Loki en exécutant la commande suivante: 

$ oc -n openshift-logging create secret generic "logging-loki-aws" \
--from-literal=bucketnames="<s3_bucket_name>" \
--from-literal=region="<bucket_region>" \
--from-literal=audience="<oidc_audience>"
1
Copy to Clipboard Toggle word wrap
1
Annotation optionnelle, valeur par défaut est openshift.
10.2.2.2. Le stockage Azure
Copier lien

Conditions préalables

  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).
  • « vous avez créé un seau sur Azure.

Procédure

  • Créez un secret de stockage d’objet avec le nom logging-loki-azure en exécutant la commande suivante: 

    $ oc create secret generic logging-loki-azure \
  --from-literal=container="<azure_container_name>" \
  --from-literal=environment="<azure_environment>" \
    1 
    
  --from-literal=account_name="<azure_account_name>" \
  --from-literal=account_key="<azure_account_key>"
    Copy to Clipboard Toggle word wrap
    1
    Les valeurs d’environnement prises en charge sont AzureGlobal, AzureChinaCloud, Azure GermanCloud ou AzureUSGovernment.

Dans le cas où votre cluster est activé Microsoft Entra Workload ID, l’opérateur d’identification en nuage (CCO) prend en charge l’authentification à court terme à l’aide de l’ID de charge de travail.

Il est possible de créer manuellement le secret de stockage d’objets Loki en exécutant la commande suivante: 

$ oc -n openshift-logging create secret generic logging-loki-azure \
--from-literal=environment="<azure_environment>" \
--from-literal=account_name="<storage_account_name>" \
--from-literal=container="<container_name>"
Copy to Clipboard Toggle word wrap
10.2.2.3. Google Cloud Platform stockage
Copier lien

Conditions préalables

  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).
  • C’est sur Google Cloud Platform (GCP) que vous avez créé un projet.
  • « vous avez créé un seau dans le même projet.
  • Dans le même projet, vous avez créé un compte de service pour l’authentification GCP.

Procédure

  1. Copiez les informations d’identification de compte de service reçues de GCP dans un fichier appelé key.json.

  2. Créez un secret de stockage d’objet avec le nom logging-loki-gcs en exécutant la commande suivante: 

    $ oc create secret generic logging-loki-gcs \
  --from-literal=bucketname="<bucket_name>" \
  --from-file=key.json="<path/to/key.json>"
    Copy to Clipboard Toggle word wrap
10.2.2.4. Espace de stockage Minio
Copier lien

Conditions préalables

  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).
  • Il y a Minio déployé sur votre cluster.
  • C’est toi qui as créé un seau sur Minio.

Procédure

  • Créez un secret de stockage d’objet avec le nom logging-loki-minio en exécutant la commande suivante: 

    $ oc create secret generic logging-loki-minio \
  --from-literal=bucketnames="<bucket_name>" \
  --from-literal=endpoint="<minio_bucket_endpoint>" \
  --from-literal=access_key_id="<minio_access_key_id>" \
  --from-literal=access_key_secret="<minio_access_key_secret>"
    Copy to Clipboard Toggle word wrap
10.2.2.5. Stockage OpenShift Data Foundation
Copier lien

Conditions préalables

  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).
  • « vous avez déployé OpenShift Data Foundation.
  • Configuration de votre cluster OpenShift Data Foundation pour le stockage d’objets.

Procédure

  1. Créez une ressource personnalisée ObjectBucketClaim dans l’espace de noms openshift-logging: 

    apiVersion: objectbucket.io/v1alpha1
kind: ObjectBucketClaim
metadata:
  name: loki-bucket-odf
  namespace: openshift-logging
spec:
  generateBucketName: loki-bucket-odf
  storageClassName: openshift-storage.noobaa.io
    Copy to Clipboard Toggle word wrap

  2. Bénéficiez des propriétés du seau à partir de l’objet ConfigMap associé en exécutant la commande suivante: 

    BUCKET_HOST=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_HOST}')
BUCKET_NAME=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_NAME}')
BUCKET_PORT=$(oc get -n openshift-logging configmap loki-bucket-odf -o jsonpath='{.data.BUCKET_PORT}')
    Copy to Clipboard Toggle word wrap

  3. Bénéficiez de la clé d’accès au seau à partir du secret associé en exécutant la commande suivante: 

    ACCESS_KEY_ID=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_ACCESS_KEY_ID}' | base64 -d)
SECRET_ACCESS_KEY=$(oc get -n openshift-logging secret loki-bucket-odf -o jsonpath='{.data.AWS_SECRET_ACCESS_KEY}' | base64 -d)
    Copy to Clipboard Toggle word wrap

  4. Créez un secret de stockage d’objet avec le nom logging-loki-odf en exécutant la commande suivante: 

    $ oc create -n openshift-logging secret generic logging-loki-odf \
--from-literal=access_key_id="<access_key_id>" \
--from-literal=access_key_secret="<secret_access_key>" \
--from-literal=bucketnames="<bucket_name>" \
--from-literal=endpoint="https://<bucket_host>:<bucket_port>"
    Copy to Clipboard Toggle word wrap
10.2.2.6. Le stockage rapide
Copier lien

Conditions préalables

  • J’ai installé l’opérateur Loki.
  • Installation de l’OpenShift CLI (oc).
  • C’est toi qui as créé un seau sur Swift.

Procédure

  • Créez un secret de stockage d’objet avec le nom logging-loki-swift en exécutant la commande suivante: 

    $ oc create secret generic logging-loki-swift \
  --from-literal=auth_url="<swift_auth_url>" \
  --from-literal=username="<swift_usernameclaim>" \
  --from-literal=user_domain_name="<swift_user_domain_name>" \
  --from-literal=user_domain_id="<swift_user_domain_id>" \
  --from-literal=user_id="<swift_user_id>" \
  --from-literal=password="<swift_password>" \
  --from-literal=domain_id="<swift_domain_id>" \
  --from-literal=domain_name="<swift_domain_name>" \
  --from-literal=container_name="<swift_container_name>"
    Copy to Clipboard Toggle word wrap

  • En option, vous pouvez fournir des données spécifiques au projet, une région ou les deux en exécutant la commande suivante: 

    $ oc create secret generic logging-loki-swift \
  --from-literal=auth_url="<swift_auth_url>" \
  --from-literal=username="<swift_usernameclaim>" \
  --from-literal=user_domain_name="<swift_user_domain_name>" \
  --from-literal=user_domain_id="<swift_user_domain_id>" \
  --from-literal=user_id="<swift_user_id>" \
  --from-literal=password="<swift_password>" \
  --from-literal=domain_id="<swift_domain_id>" \
  --from-literal=domain_name="<swift_domain_name>" \
  --from-literal=container_name="<swift_container_name>" \
  --from-literal=project_id="<swift_project_id>" \
  --from-literal=project_name="<swift_project_name>" \
  --from-literal=project_domain_id="<swift_project_domain_id>" \
  --from-literal=project_domain_name="<swift_project_domain_name>" \
  --from-literal=region="<swift_region>"
    Copy to Clipboard Toggle word wrap

10.2.3. Déploiement d’un log store Elasticsearch
Copier lien

L’opérateur Elasticsearch d’OpenShift vous permet de déployer une boutique de journal Elasticsearch interne sur votre Red Hat OpenShift Service sur AWS cluster.

Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

10.2.3.1. Considérations de stockage pour Elasticsearch
Copier lien

Il faut un volume persistant pour chaque configuration de déploiement Elasticsearch. Avec Red Hat OpenShift Service sur AWS, cela est réalisé à l’aide de revendications de volume persistantes (PVC).

Note

Lorsque vous utilisez un volume local pour le stockage persistant, n’utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: bloc dans l’objet LocalVolume. Elasticsearch ne peut pas utiliser les volumes de blocs bruts.

L’opérateur OpenShift Elasticsearch nomme les PVC en utilisant le nom de ressource Elasticsearch.

Fluentd expédie tous les journaux de journal systemd et /var/log/containers/*.log à Elasticsearch.

Elasticsearch nécessite une mémoire suffisante pour effectuer de grandes opérations de fusion. « si elle n’a pas assez de mémoire, elle devient insensible. Afin d’éviter ce problème, évaluez la quantité de données de journal d’application dont vous avez besoin et allouez environ le double de la capacité de stockage gratuite.

Lorsque la capacité de stockage est pleine de 85%, Elasticsearch cesse d’attribuer de nouvelles données au nœud. À 90%, Elasticsearch tente de déplacer des fragments existants de ce nœud vers d’autres nœuds si possible. Cependant, si les nœuds ont une capacité libre inférieure à 85 %, Elasticsearch rejette effectivement la création de nouveaux indices et devient RED.

Note

Ces valeurs de filigrane basses et élevées sont des valeurs par défaut Elasticsearch dans la version actuelle. Ces valeurs par défaut peuvent être modifiées. Bien que les alertes utilisent les mêmes valeurs par défaut, vous ne pouvez pas modifier ces valeurs dans les alertes.

L’opérateur OpenShift Elasticsearch crée et gère le cluster Elasticsearch utilisé par OpenShift Logging.

Conditions préalables

  • Elasticsearch est une application à forte intensité de mémoire. Chaque nœud Elasticsearch a besoin d’au moins 16 Go de mémoire pour les requêtes et les limites de mémoire, à moins que vous n’en spécifiiez autrement dans la ressource personnalisée ClusterLogging.

    L’ensemble initial de Red Hat OpenShift Service sur les nœuds AWS pourrait ne pas être assez grand pour prendre en charge le cluster Elasticsearch. Il faut ajouter des nœuds supplémentaires au service Red Hat OpenShift sur AWS pour fonctionner avec la mémoire recommandée ou supérieure, jusqu’à un maximum de 64 Go pour chaque nœud Elasticsearch.

    Les nœuds Elasticsearch peuvent fonctionner avec un réglage de mémoire inférieur, bien que cela ne soit pas recommandé pour les environnements de production.

  • Assurez-vous que vous avez le stockage persistant nécessaire pour Elasticsearch. A noter que chaque nœud Elasticsearch nécessite son propre volume de stockage.

    Note

    Lorsque vous utilisez un volume local pour le stockage persistant, n’utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: bloc dans l’objet LocalVolume. Elasticsearch ne peut pas utiliser les volumes de blocs bruts.

Procédure

  1. Dans le Red Hat OpenShift Service sur la console web AWS, cliquez sur Opérateurs → OperatorHub.
  2. Cliquez sur OpenShift Elasticsearch Operator dans la liste des opérateurs disponibles, et cliquez sur Installer.
  3. Assurez-vous que tous les espaces de noms du cluster sont sélectionnés sous le mode Installation.

  4. Assurez-vous que l’openshift-operators-redhat est sélectionné sous la rubrique Installed Namespace.

    Il faut spécifier l’espace de noms openshift-operators-redhat. L’espace de noms openshift-operators peut contenir des opérateurs communautaires, qui ne sont pas fiables et pourraient publier une métrique avec le même nom que Red Hat OpenShift Service sur la métrique AWS, ce qui provoquerait des conflits.

  5. Activer la surveillance des clusters recommandé par l’opérateur sur cet espace de noms.

    Cette option définit l’étiquette openshift.io/cluster-monitoring: "vrai" étiquette dans l’objet Namespace. Il faut sélectionner cette option pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-operators-redhat.

  6. Choisissez stable-5.x comme canal de mise à jour.

  7. Choisissez une stratégie d’approbation de mise à jour:

    • La stratégie automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible.
    • La stratégie du Manuel exige qu’un utilisateur ayant les informations d’identification appropriées approuve la mise à jour de l’opérateur.
  8. Cliquez sur Install.

La vérification

  1. Assurez-vous que l’opérateur OpenShift Elasticsearch est installé en passant à la page Opérateurs installés.
  2. Assurez-vous que l’opérateur OpenShift Elasticsearch est répertorié dans tous les projets ayant un statut de Succès.

Il est possible d’utiliser OpenShift CLI (oc) pour installer l’opérateur OpenShift Elasticsearch.

Conditions préalables

  • Assurez-vous que vous avez le stockage persistant nécessaire pour Elasticsearch. A noter que chaque nœud Elasticsearch nécessite son propre volume de stockage.

    Note

    Lorsque vous utilisez un volume local pour le stockage persistant, n’utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: bloc dans l’objet LocalVolume. Elasticsearch ne peut pas utiliser les volumes de blocs bruts.

    Elasticsearch est une application à forte intensité de mémoire. Le service Red Hat OpenShift sur AWS installe par défaut trois nœuds Elasticsearch avec des requêtes de mémoire et des limites de 16 Go. Cet ensemble initial de trois Red Hat OpenShift Service sur les nœuds AWS pourrait ne pas avoir assez de mémoire pour exécuter Elasticsearch dans votre cluster. Lorsque vous rencontrez des problèmes de mémoire liés à Elasticsearch, ajoutez plus de nœuds Elasticsearch à votre cluster plutôt que d’augmenter la mémoire sur les nœuds existants.

  • Il y a des autorisations d’administrateur.
  • L’OpenShift CLI (oc) a été installé.

Procédure

  1. Créer un objet Namespace comme fichier YAML: 

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-operators-redhat
    1 
    
  annotations:
    openshift.io/node-selector: ""
  labels:
    openshift.io/cluster-monitoring: "true"
    2
    Copy to Clipboard Toggle word wrap
    1
    Il faut spécifier l’espace de noms openshift-operators-redhat. Afin d’éviter d’éventuels conflits avec les métriques, configurez la pile Prometheus Cluster Monitoring pour gratter les métriques de l’espace de noms openshift-operators-redhat et non de l’espace de noms openshift-operators. L’espace de noms openshift-operators peut contenir des opérateurs communautaires, qui ne sont pas fiables et pourraient publier une métrique avec le même nom qu’une métrique ROSA, ce qui provoquerait des conflits.
    2
    La corde. Il faut spécifier cette étiquette comme indiqué pour s’assurer que la surveillance des clusters gratte l’espace de noms openshift-operators-redhat.

  2. Appliquez l’objet Namespace en exécutant la commande suivante: 

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

  3. Créer un objet OperatorGroup en tant que fichier YAML: 

    apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-operators-redhat
  namespace: openshift-operators-redhat
    1 
    
spec: {}
    Copy to Clipboard Toggle word wrap
    1
    Il faut spécifier l’espace de noms openshift-operators-redhat.

  4. Appliquez l’objet OperatorGroup en exécutant la commande suivante: 

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

  5. Créer un objet d’abonnement pour souscrire l’espace de noms à l’opérateur OpenShift Elasticsearch:

    Exemple d’abonnement

    apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: elasticsearch-operator
  namespace: openshift-operators-redhat
    1 
    
spec:
  channel: stable-x.y
    2 
    
  installPlanApproval: Automatic
    3 
    
  source: redhat-operators
    4 
    
  sourceNamespace: openshift-marketplace
  name: elasticsearch-operator
    Copy to Clipboard Toggle word wrap

    1
    Il faut spécifier l’espace de noms openshift-operators-redhat.
    2
    Indiquez stable, ou stable-x.y comme canal. Consultez la note suivante.
    3
    Automatique permet au gestionnaire de cycle de vie de l’opérateur (OLM) de mettre à jour automatiquement l’opérateur lorsqu’une nouvelle version est disponible. Le manuel exige qu’un utilisateur avec les informations d’identification appropriées approuve la mise à jour de l’opérateur.
    4
    Indiquez les redhat-operators. Lorsque votre Red Hat OpenShift Service sur AWS cluster est installé sur un réseau restreint, également connu sous le nom de cluster déconnecté, spécifiez le nom de l’objet CatalogSource créé lorsque vous avez configuré le gestionnaire de cycle de vie de l’opérateur (OLM).
    Note

    La spécification stable installe la version actuelle de la dernière version stable. En utilisant stable avec installPlanApproval: "Automatique" met automatiquement à niveau vos opérateurs vers la dernière version majeure et mineure stable.

    La spécification stable-x.y installe la version mineure actuelle d’une version majeure spécifique. En utilisant stable-x.y avec installPlanApproval: "Automatic" met automatiquement à niveau vos Opérateurs vers la dernière version mineure stable dans la version principale.

  6. Appliquer l’abonnement en exécutant la commande suivante: 

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

    L’opérateur OpenShift Elasticsearch est installé dans l’espace de noms openshift-operators-redhat et copié sur chaque projet du cluster.

La vérification

  1. Exécutez la commande suivante: 

    $ oc get csv -n --all-namespaces
    Copy to Clipboard Toggle word wrap

  2. Consultez la sortie et confirmez que les pods pour l’opérateur OpenShift Elasticsearch existent dans chaque espace de noms

    Exemple de sortie

    NAMESPACE                                          NAME                            DISPLAY                            VERSION          REPLACES                        PHASE
default                                            elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
kube-node-lease                                    elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
kube-public                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
kube-system                                        elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
non-destructive-test                               elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
openshift-apiserver-operator                       elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
openshift-apiserver                                elasticsearch-operator.v5.8.1   OpenShift Elasticsearch Operator   5.8.1            elasticsearch-operator.v5.8.0   Succeeded
...
    Copy to Clipboard Toggle word wrap

10.2.4. Configuration du stockage des journaux
Copier lien

Il est possible de configurer le type de stockage de journal utilisé par votre journal en modifiant la ressource personnalisée ClusterLogging (CR).

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 et un log store interne sont soit le LokiStack, soit Elasticsearch.
  • C’est vous qui avez créé un ClusterLogging CR.
Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

Procédure

  1. ClusterLogging CR logStore Spécification:

    Exemple de ClusterLogging CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  logStore:
    type: <log_store_type>
    1 
    
    elasticsearch:
    2 
    
      nodeCount: <integer>
      resources: {}
      storage: {}
      redundancyPolicy: <redundancy_type>
    3 
    
    lokistack:
    4 
    
      name: {}
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indiquez le type de log store. Cela peut être soit le lokistack ou la recherche élastique.
    2
    Des options de configuration optionnelles pour la boutique de journal Elasticsearch.
    3
    Indiquez le type de redondance. Cette valeur peut être ZeroRedundancy, SingleRedundancy, MultipleRedundancy ou FullRedundancy.
    4
    Configuration optionnelle pour LokiStack.

    Exemple ClusterLogging CR pour spécifier LokiStack comme log store

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-loki
# ...
    Copy to Clipboard Toggle word wrap

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

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

10.3. Configuration du log store LokiStack
Copier lien

Dans la documentation de journalisation, LokiStack fait référence à la combinaison prise en charge de la journalisation de Loki et de proxy Web avec Red Hat OpenShift Service sur l’intégration d’authentification AWS. Le proxy de LokiStack utilise Red Hat OpenShift Service sur l’authentification AWS pour appliquer la multi-tenance. Loki se réfère au log store comme étant soit le composant individuel, soit un magasin externe.

Important

La requête de journaux d’applications pour plusieurs espaces de noms en tant qu’utilisateur cluster-admin, où la somme totale des caractères de tous les espaces de noms dans le cluster est supérieure à 5120, entraîne l’erreur Parse erreur: taille d’entrée trop longue (XXXX &gt; 5120). Afin de mieux contrôler l’accès aux connexions dans LokiStack, faites de l’utilisateur cluster-admin un membre du groupe cluster-admin. Lorsque le groupe cluster-admin n’existe pas, créez-le et ajoutez-y les utilisateurs souhaités.

La procédure suivante permet de créer un nouveau groupe pour les utilisateurs disposant d’autorisations cluster-admin.

Procédure

  1. Entrez la commande suivante pour créer un nouveau groupe: 

    $ oc adm groups new cluster-admin
    Copy to Clipboard Toggle word wrap

  2. Entrez la commande suivante pour ajouter l’utilisateur souhaité au groupe cluster-admin: 

    $ oc adm groups add-users cluster-admin <username>
    Copy to Clipboard Toggle word wrap

  3. Entrez la commande suivante pour ajouter le rôle utilisateur cluster-admin au groupe: 

    $ oc adm policy add-cluster-role-to-group cluster-admin cluster-admin
    Copy to Clipboard Toggle word wrap

Dans la version de journalisation 5.8 et les versions plus récentes, lorsqu’un Red Hat OpenShift Service sur AWS cluster est redémarré, l’ingestion LokiStack et le chemin de requête continuent à fonctionner dans les ressources CPU et mémoire disponibles pour le nœud. Cela signifie qu’il n’y a pas de temps d’arrêt pour le LokiStack pendant Red Hat OpenShift Service sur les mises à jour du cluster AWS. Ce comportement est atteint en utilisant les ressources PodDisruptionBudget. L’opérateur Loki fournit les ressources de PodDisruptionBudget pour Loki, qui déterminent le nombre minimum de gousses qui doivent être disponibles par composant pour assurer des opérations normales dans certaines conditions.

10.3.3. Configurer Loki pour tolérer l’échec du nœud
Copier lien

Dans la journalisation 5.8 et les versions ultérieures, l’opérateur Loki prend en charge le réglage des règles anti-affinité de pod pour demander que les pods du même composant soient programmés sur différents nœuds disponibles dans le cluster.

Affinité est une propriété de pods qui contrôle les nœuds sur lesquels ils préfèrent être programmés. L’anti-affinité est une propriété de gousses qui empêche une gousse d’être programmée sur un nœud.

Dans Red Hat OpenShift Service sur AWS, l’affinité de pod et la pod anti-affinité vous permettent de limiter les nœuds que votre pod est éligible pour être programmé sur la base des étiquettes de valeur clé sur d’autres gousses.

L’opérateur définit les règles par défaut, podAntiAffinity préférées pour tous les composants Loki, qui comprend le compacteur, le distributeur, la passerelle, indexGateway, ingester, querier, queryFrontend et les composants de règle.

Il est possible de remplacer les paramètres podAntiAffinity préférés pour les composants Loki en configurant les paramètres requis dans le champ requisDuringSchedulingIgnoredDuringExecution:

Exemple de paramètres utilisateur pour le composant ingester

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    ingester:
      podAntiAffinity:
      # ...
        requiredDuringSchedulingIgnoredDuringExecution:
1 

        - labelSelector:
            matchLabels:
2 

              app.kubernetes.io/component: ingester
          topologyKey: kubernetes.io/hostname
# ...
Copy to Clipboard Toggle word wrap

1
La strophe pour définir une règle requise.
2
La paire clé-valeur (étiquette) qui doit être assortie pour appliquer la règle.

10.3.4. La réplication de données conscientes de zone
Copier lien

Dans l’enregistrement 5.8 et les versions ultérieures, l’opérateur Loki offre une prise en charge de la réplication des données conscientes de la zone grâce à des contraintes de propagation de la topologie des pod. L’activation de cette fonctionnalité améliore la fiabilité et les protections contre la perte de log en cas de défaillance d’une seule zone. Lors de la configuration de la taille de déploiement comme 1x.extra.petit, 1x.petit, ou 1x.medium, le champ réplication.factor est automatiquement réglé sur 2.

Afin d’assurer une réplication appropriée, vous devez avoir au moins autant de zones de disponibilité que le facteur de réplication le spécifie. Bien qu’il soit possible d’avoir plus de zones de disponibilité que le facteur de réplication, avoir moins de zones peut conduire à des échecs d’écriture. Chaque zone doit accueillir un nombre égal d’instances pour un fonctionnement optimal.

Exemple LokiStack CR avec réplication de zone activée

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
 name: logging-loki
 namespace: openshift-logging
spec:
 replicationFactor: 2
1 

 replication:
   factor: 2
2 

   zones:
   -  maxSkew: 1
3 

      topologyKey: topology.kubernetes.io/zone
4
Copy to Clipboard Toggle word wrap

1
Champ déprécié, les valeurs saisies sont écrasées par réplication.factor.
2
Cette valeur est automatiquement définie lorsque la taille du déploiement est sélectionnée lors de la configuration.
3
La différence maximale de nombre de pods entre deux domaines de topologie. La valeur par défaut est 1, et vous ne pouvez pas spécifier une valeur de 0.
4
Définit des zones sous la forme d’une clé de topologie qui correspond à une étiquette de nœud.

Dans Red Hat OpenShift Service sur AWS, une défaillance de zone se produit lorsque des ressources de zone de disponibilité spécifiques deviennent inaccessibles. Les zones de disponibilité sont des zones isolées du centre de données d’un fournisseur de cloud, visant à améliorer la redondance et la tolérance aux pannes. Lorsque votre Red Hat OpenShift Service sur AWS cluster n’est pas configuré pour gérer cela, une défaillance de zone peut entraîner une perte de service ou de données.

Les pods Loki font partie d’un StatefulSet, et ils sont livrés avec des revendications de volume persistants (PVC) fournies par un objet StorageClass. Chaque gousse Loki et ses PVC résident dans la même zone. Lorsqu’une défaillance de zone se produit dans un cluster, le contrôleur StatefulSet tente automatiquement de récupérer les pods affectés dans la zone défaillante.

Avertissement

La procédure suivante supprimera les PVC dans la zone défaillante et toutes les données qui y sont contenues. Afin d’éviter toute perte de données, le champ de facteur de réplication du LokiStack CR doit toujours être réglé à une valeur supérieure à 1 pour s’assurer que Loki réplique.

Conditions préalables

  • Journalisation de la version 5.8 ou ultérieure.
  • Assurez-vous que votre LokiStack CR a un facteur de réplication supérieur à 1.
  • La défaillance de la zone détectée par le plan de contrôle, et les nœuds dans la zone défaillante sont marqués par l’intégration du fournisseur de cloud.

Le contrôleur StatefulSet tente automatiquement de rééchelonner les pods dans une zone défaillante. Étant donné que les PVC associés sont également dans la zone défaillante, le rééchelonnement automatique vers une zone différente ne fonctionne pas. Il faut supprimer manuellement les PVC dans la zone défaillante pour permettre une recréation réussie de l’étatique Loki Pod et de son PVC approvisionné dans la nouvelle zone.

Procédure

  1. Énumérez les pods dans l’état en attente en exécutant la commande suivante: 

    oc get pods --field-selector status.phase==Pending -n openshift-logging
    Copy to Clipboard Toggle word wrap

    Exemple oc get pods sortie

    NAME                           READY   STATUS    RESTARTS   AGE
    1 
    
logging-loki-index-gateway-1   0/1     Pending   0          17m
logging-loki-ingester-1        0/1     Pending   0          16m
logging-loki-ruler-1           0/1     Pending   0          16m
    Copy to Clipboard Toggle word wrap

    1
    Ces gousses sont en attente parce que leurs PVC correspondants sont dans la zone défaillante.

  2. Énumérez les PVC en attente d’état en exécutant la commande suivante: 

    oc get pvc -o=json -n openshift-logging | jq '.items[] | select(.status.phase == "Pending") | .metadata.name' -r
    Copy to Clipboard Toggle word wrap

    Exemple oc obtenir la sortie pvc

    storage-logging-loki-index-gateway-1
storage-logging-loki-ingester-1
wal-logging-loki-ingester-1
storage-logging-loki-ruler-1
wal-logging-loki-ruler-1
    Copy to Clipboard Toggle word wrap

  3. Effacer le(s) PVC(s) pour un pod en exécutant la commande suivante: 

    oc delete pvc __<pvc_name>__  -n openshift-logging
    Copy to Clipboard Toggle word wrap

  4. Ensuite, supprimez le(s) pod(s) en exécutant la commande suivante: 

    oc delete pod __<pod_name>__  -n openshift-logging
    Copy to Clipboard Toggle word wrap

Lorsque ces objets ont été supprimés avec succès, ils doivent être automatiquement reprogrammés dans une zone disponible.

10.3.4.1.1. Dépannage PVC dans un état de terminaison
Copier lien

Les PVC peuvent être suspendus à l’état de terminaison sans être supprimés, si les finalisateurs de métadonnées PVC sont réglés sur kubernetes.io/pv-protection. Le retrait des finalisateurs devrait permettre aux PVC de supprimer avec succès.

  1. Enlevez le finalisateur pour chaque PVC en exécutant la commande ci-dessous, puis réessayez la suppression. 

    oc patch pvc __<pvc_name>__ -p '{"metadata":{"finalizers":null}}' -n openshift-logging
    Copy to Clipboard Toggle word wrap

10.3.5. Accès grainé fin pour les bûches Loki
Copier lien

Dans l’enregistrement 5.8 et plus tard, l’opérateur de journalisation Red Hat OpenShift n’accorde pas à tous les utilisateurs l’accès aux journaux par défaut. En tant qu’administrateur, vous devez configurer l’accès de vos utilisateurs à moins que l’opérateur n’ait été mis à niveau et que des configurations antérieures ne soient en place. En fonction de votre configuration et de votre besoin, vous pouvez configurer l’accès au grain fin aux logs en utilisant les éléments suivants:

  • Groupe de politiques à grande échelle
  • Domaines d’application de l’espace de noms
  • Création de groupes d’administrateurs personnalisés

En tant qu’administrateur, vous devez créer les liaisons de rôle et les liaisons de rôle de cluster appropriées à votre déploiement. Le Red Hat OpenShift Logging Operator fournit les rôles de cluster suivants:

  • cluster-logging-application-view autorise la lecture des journaux des applications.
  • cluster-logging-infrastructure-view donne l’autorisation de lire les journaux d’infrastructure.
  • cluster-logging-audit-view donne l’autorisation de lire les journaux d’audit.

Lorsque vous avez mis à niveau à partir d’une version précédente, un cluster supplémentaire logging-application-logs-lecteur de rôle et la liaison de rôle de cluster associé logging-all-authenticated-application-logs-lecteur fournit une rétrocompatibilité, permettant à tout utilisateur authentifié d’accéder à la lecture dans leurs espaces de noms.

Note

Les utilisateurs ayant accès par namespace doivent fournir un espace de noms lors de l’interrogation des journaux des applications.

10.3.5.1. Accès large en cluster
Copier lien

Les ressources de liaison des rôles de cluster référencent les rôles de cluster, et définissent les autorisations de cluster large.

Exemple ClusterRoleBinding

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: logging-all-application-logs-reader
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
1 

subjects:
2 

- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io
Copy to Clipboard Toggle word wrap

1
D’autres ClusterRoles sont cluster-logging-infrastructure-view, et cluster-logging-audit-view.
2
Indique les utilisateurs ou les groupes auxquels s’applique cet objet.
10.3.5.2. Accès espacement de nom
Copier lien

Les ressources RoleBinding peuvent être utilisées avec les objets ClusterRole pour définir l’espace de noms pour lequel un utilisateur ou un groupe a accès aux journaux.

Exemple de rôleBinding

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: allow-read-logs
  namespace: log-test-0
1 

roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-logging-application-view
subjects:
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: testuser-0
Copy to Clipboard Toggle word wrap

1
Indique l’espace de noms auquel s’applique le RoleBinding.
10.3.5.3. Accès au groupe administrateur personnalisé
Copier lien

Lorsque vous avez un déploiement important avec plusieurs utilisateurs qui nécessitent des autorisations plus larges, vous pouvez créer un groupe personnalisé à l’aide du champ adminGroup. Les utilisateurs qui sont membres de tout groupe spécifié dans le champ adminGroups du LokiStack CR sont considérés comme des administrateurs.

Les utilisateurs administrateurs ont accès à tous les journaux d’applications dans tous les espaces de noms, s’ils reçoivent également le rôle cluster-logging-application-view.

Exemple LokiStack CR

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  tenants:
    mode: openshift-logging
1 

    openshift:
      adminGroups:
2 

      - cluster-admin
      - custom-admin-group
3
Copy to Clipboard Toggle word wrap

1
Les groupes d’administrateurs personnalisés ne sont disponibles que dans ce mode.
2
Entrer une valeur de liste vide [] pour ce champ désactive les groupes d’administrateurs.
3
Remplace les groupes par défaut (système:cluster-admins, cluster-admin, dédié-admin)

10.3.7. Dépannage des erreurs de limite de taux Loki
Copier lien

Lorsque l’API Log Forwarder transmet un grand bloc de messages qui dépasse la limite de taux à Loki, Loki génère des erreurs de limite de débit (429).

Ces erreurs peuvent se produire pendant le fonctionnement normal. À titre d’exemple, lors de l’ajout de la journalisation à un cluster qui possède déjà certains journaux, des erreurs de limite de taux peuvent se produire pendant que la journalisation tente d’ingérer toutes les entrées de journal existantes. Dans ce cas, si le taux d’ajout de nouveaux journaux est inférieur à la limite de taux totale, les données historiques sont finalement ingérées, et les erreurs de limite de taux sont résolues sans nécessiter l’intervention de l’utilisateur.

Dans les cas où les erreurs de limite de taux continuent de se produire, vous pouvez résoudre le problème en modifiant la ressource personnalisée LokiStack (CR).

Important

Le LokiStack CR n’est pas disponible sur Grafana-hosted Loki. Cette rubrique ne s’applique pas aux serveurs Loki hébergés par Grafana.

Les conditions

  • L’API Log Forwarder est configurée pour transférer les journaux vers Loki.

  • Le système envoie un bloc de messages de plus de 2 Mo à Loki. À titre d’exemple: 

    "values":[["1630410392689800468","{\"kind\":\"Event\",\"apiVersion\":\
.......
......
......
......
\"received_at\":\"2021-08-31T11:46:32.800278+00:00\",\"version\":\"1.7.4 1.6.0\"}},\"@timestamp\":\"2021-08-31T11:46:32.799692+00:00\",\"viaq_index_name\":\"audit-write\",\"viaq_msg_id\":\"MzFjYjJkZjItNjY0MC00YWU4LWIwMTEtNGNmM2E5ZmViMGU4\",\"log_type\":\"audit\"}"]]}]}
    Copy to Clipboard Toggle word wrap

  • Après avoir entré les journaux oc -n openshift-logging -l component=collector, les journaux collecteurs de votre cluster affichent une ligne contenant l’un des messages d’erreur suivants: 

    429 Too Many Requests Ingestion rate limit exceeded
    Copy to Clipboard Toggle word wrap

    Exemple de message d’erreur vectoriel

    2023-08-25T16:08:49.301780Z  WARN sink{component_kind="sink" component_id=default_loki_infra component_type=loki component_name=default_loki_infra}: vector::sinks::util::retries: Retrying after error. error=Server responded with an error: 429 Too Many Requests internal_log_rate_limit=true
    Copy to Clipboard Toggle word wrap

    Exemple de message d’erreur Fluentd

    2023-08-30 14:52:15 +0000 [warn]: [default_loki_infra] failed to flush the buffer. retry_times=2 next_retry_time=2023-08-30 14:52:19 +0000 chunk="604251225bf5378ed1567231a1c03b8b" error_class=Fluent::Plugin::LokiOutput::LogPostError error="429 Too Many Requests Ingestion rate limit exceeded for user infrastructure (limit: 4194304 bytes/sec) while attempting to ingest '4082' lines totaling '7820025' bytes, reduce log volume or contact your Loki administrator to see if the limit can be increased\n"
    Copy to Clipboard Toggle word wrap

    L’erreur est également visible à l’extrémité de réception. À titre d’exemple, dans la pod LokiStack ingester:

    Exemple de message d’erreur Loki ingester

    level=warn ts=2023-08-30T14:57:34.155592243Z caller=grpc_logging.go:43 duration=1.434942ms method=/logproto.Pusher/Push err="rpc error: code = Code(429) desc = entry with timestamp 2023-08-30 14:57:32.012778399 +0000 UTC ignored, reason: 'Per stream rate limit exceeded (limit: 3MB/sec) while attempting to ingest for stream
    Copy to Clipboard Toggle word wrap

Procédure

  • Actualisez les champs ingestionBurstSize et ingestionRate dans le LokiStack CR: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
  limits:
    global:
      ingestion:
        ingestionBurstSize: 16
    1 
    
        ingestionRate: 8
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    Le champ ingestionBurstSize définit la taille maximale de l’échantillon par distributeur en MB. Cette valeur est une limite dure. Définissez cette valeur sur au moins la taille maximale des logs attendue dans une seule requête push. Les demandes uniques qui sont plus grandes que la valeur d’ingestionBurstSize ne sont pas autorisées.
    2
    Le champ ingestionRate est une limite molle sur la quantité maximale d’échantillons ingérés par seconde en MB. Les erreurs de limite de taux se produisent si le taux de logs dépasse la limite, mais le collecteur retries en envoyant les journaux. Aussi longtemps que la moyenne totale est inférieure à la limite, le système récupère et les erreurs sont résolues sans intervention de l’utilisateur.

Dans un cluster OpenShift, les administrateurs utilisent généralement une plage de réseau IP non privée. En conséquence, la configuration de la liste de membres LokiStack échoue parce que, par défaut, elle utilise uniquement des réseaux IP privés.

En tant qu’administrateur, vous pouvez sélectionner le réseau pod pour la configuration de la liste de membres. Il est possible de modifier le LokiStack CR pour utiliser le podIP dans la spécification hashRing. Afin de configurer le LokiStack CR, utilisez la commande suivante: 

$ oc patch LokiStack logging-loki -n openshift-logging  --type=merge -p '{"spec": {"hashRing":{"memberlist":{"instanceAddrType":"podIP","type": "memberlist"}}}}'
Copy to Clipboard Toggle word wrap

Exemple LokiStack pour inclure podIP

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  hashRing:
    type: memberlist
    memberlist:
      instanceAddrType: podIP
# ...
Copy to Clipboard Toggle word wrap

10.4. Configuration du log store Elasticsearch
Copier lien

Elasticsearch 6 vous permet de stocker et d’organiser les données de log.

Il est possible d’apporter des modifications à votre log store, y compris:

  • Entreposage pour votre cluster Elasticsearch
  • La réplication partagée entre les nœuds de données dans le cluster, de la réplication complète à l’absence de réplication
  • Accès externe aux données Elasticsearch

10.4.1. Configuration du stockage des journaux
Copier lien

Il est possible de configurer le type de stockage de journal utilisé par votre journal en modifiant la ressource personnalisée ClusterLogging (CR).

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 et un log store interne sont soit le LokiStack, soit Elasticsearch.
  • C’est vous qui avez créé un ClusterLogging CR.
Note

La version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.

Procédure

  1. ClusterLogging CR logStore Spécification:

    Exemple de ClusterLogging CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  logStore:
    type: <log_store_type>
    1 
    
    elasticsearch:
    2 
    
      nodeCount: <integer>
      resources: {}
      storage: {}
      redundancyPolicy: <redundancy_type>
    3 
    
    lokistack:
    4 
    
      name: {}
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indiquez le type de log store. Cela peut être soit le lokistack ou la recherche élastique.
    2
    Des options de configuration optionnelles pour la boutique de journal Elasticsearch.
    3
    Indiquez le type de redondance. Cette valeur peut être ZeroRedundancy, SingleRedundancy, MultipleRedundancy ou FullRedundancy.
    4
    Configuration optionnelle pour LokiStack.

    Exemple ClusterLogging CR pour spécifier LokiStack comme log store

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  managementState: Managed
  logStore:
    type: lokistack
    lokistack:
      name: logging-loki
# ...
    Copy to Clipboard Toggle word wrap

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

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

10.4.2. Envoi des journaux d’audit au log store
Copier lien

Dans un déploiement de journalisation, les journaux de conteneurs et d’infrastructures sont transférés au log store interne défini dans la ressource personnalisée ClusterLogging (CR) par défaut.

Les journaux d’audit ne sont pas transmis au log store interne par défaut, car cela ne fournit pas de stockage sécurisé. Il vous incombe de vous assurer que le système vers lequel vous transmettez les journaux d’audit est conforme à vos réglementations organisationnelles et gouvernementales et qu’il est correctement sécurisé.

Lorsque cette configuration par défaut répond à vos besoins, vous n’avez pas besoin de configurer un ClusterLogForwarder CR. En cas d’existence d’un ClusterLogForwarder CR, les journaux ne sont pas transmis au log store interne à moins qu’un pipeline ne soit défini qui contient la sortie par défaut.

Procédure

D’utiliser l’API Log Forward pour transmettre les journaux d’audit à l’instance interne Elasticsearch:

  1. Créer ou modifier un fichier YAML qui définit l’objet ClusterLogForwarder CR:

    • Créez un CR pour envoyer tous les types de journaux à l’instance interne Elasticsearch. Il est possible d’utiliser l’exemple suivant sans apporter de modifications: 

      apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  pipelines:
      1 
      
  - name: all-to-default
    inputRefs:
    - infrastructure
    - application
    - audit
    outputRefs:
    - default
      Copy to Clipboard Toggle word wrap
      1
      Le pipeline définit le type de logs à transmettre à l’aide de la sortie spécifiée. La sortie par défaut transmet les journaux à l’instance interne Elasticsearch.
      Note

      Dans le pipeline, vous devez spécifier les trois types de logs : application, infrastructure et audit. Dans le cas où vous ne spécifiez pas un type de journal, ces journaux ne sont pas stockés et seront perdus.

    • Lorsque vous avez un ClusterLogForwarder CR existant, ajoutez un pipeline à la sortie par défaut pour les journaux d’audit. Il n’est pas nécessaire de définir la sortie par défaut. À titre d’exemple: 

      apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
   - name: elasticsearch-insecure
     type: "elasticsearch"
     url: http://elasticsearch-insecure.messaging.svc.cluster.local
     insecure: true
   - name: elasticsearch-secure
     type: "elasticsearch"
     url: https://elasticsearch-secure.messaging.svc.cluster.local
     secret:
       name: es-audit
   - name: secureforward-offcluster
     type: "fluentdForward"
     url: https://secureforward.offcluster.com:24224
     secret:
       name: secureforward
  pipelines:
   - name: container-logs
     inputRefs:
     - application
     outputRefs:
     - secureforward-offcluster
   - name: infra-logs
     inputRefs:
     - infrastructure
     outputRefs:
     - elasticsearch-insecure
   - name: audit-logs
     inputRefs:
     - audit
     outputRefs:
     - elasticsearch-secure
     - default
      1
      Copy to Clipboard Toggle word wrap
      1
      Ce pipeline envoie les journaux d’audit à l’instance interne Elasticsearch en plus d’une instance externe.

10.4.3. Configuration du temps de rétention du journal
Copier lien

Il est possible de configurer une stratégie de rétention qui spécifie combien de temps le magasin de journal Elasticsearch par défaut conserve des indices pour chacune des trois sources de journaux : journaux d’infrastructures, journaux d’applications et journaux d’audit.

Afin de configurer la stratégie de rétention, vous définissez un paramètre maxAge pour chaque source de journal de la ressource personnalisée ClusterLogging (CR). Le CR applique ces valeurs au calendrier de roulement Elasticsearch, qui détermine quand Elasticsearch supprime les indices reportés.

Elasticsearch roule sur un index, en déplaçant l’index actuel et en créant un nouvel index, lorsqu’un index correspond à l’une des conditions suivantes:

  • L’indice est plus ancien que la valeur rollover.maxAge dans le CR Elasticsearch.
  • La taille de l’indice est supérieure à 40 Go × le nombre de fragments primaires.
  • Le nombre de doc index est supérieur à 40960 KB × le nombre de fragments primaires.

Elasticsearch supprime les indices en fonction de la stratégie de rétention que vous configurez. Lorsque vous ne créez pas de stratégie de rétention pour les sources de journaux, les journaux sont supprimés après sept jours par défaut.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift et l’opérateur OpenShift Elasticsearch doivent être installés.

Procédure

Configurer le temps de rétention du journal:

  1. Modifiez le ClusterLogging CR pour ajouter ou modifier le paramètre de rétentionPolicy: 

    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
...
spec:
  managementState: "Managed"
  logStore:
    type: "elasticsearch"
    retentionPolicy:
    1 
    
      application:
        maxAge: 1d
      infra:
        maxAge: 7d
      audit:
        maxAge: 7d
    elasticsearch:
      nodeCount: 3
...
    Copy to Clipboard Toggle word wrap
    1
    Indiquez l’heure à laquelle Elasticsearch doit conserver chaque source de journal. Entrez un entier et une désignation de temps: semaines (w), heures (h/H), minutes(m) et secondes(s). A titre d’exemple, 1d pour une journée. Les journaux plus anciens que le maxAge sont supprimés. Les journaux sont conservés par défaut pendant sept jours.

  2. Il est possible de vérifier les paramètres de la ressource personnalisée Elasticsearch (CR).

    À titre d’exemple, le Red Hat OpenShift Logging Operator a mis à jour la version suivante d’Elasticsearch CR pour configurer une politique de rétention qui inclut des paramètres permettant de renverser les indices actifs pour les journaux d’infrastructure toutes les huit heures et les indices enroulés sont supprimés sept jours après le roulement. Le service OpenShift Red Hat sur AWS vérifie toutes les 15 minutes pour déterminer si les indices doivent être reportés. 

    apiVersion: "logging.openshift.io/v1"
kind: "Elasticsearch"
metadata:
  name: "elasticsearch"
spec:
...
  indexManagement:
    policies:
    1 
    
      - name: infra-policy
        phases:
          delete:
            minAge: 7d
    2 
    
          hot:
            actions:
              rollover:
                maxAge: 8h
    3 
    
        pollInterval: 15m
    4 
    
...
    Copy to Clipboard Toggle word wrap
    1
    Dans chaque source de journal, la stratégie de rétention indique quand supprimer et retourner les journaux pour cette source.
    2
    Lorsque Red Hat OpenShift Service sur AWS supprime les indices laminés. Ce paramètre est le maxAge que vous définissez dans le ClusterLogging CR.
    3
    L’âge de l’index pour Red Hat OpenShift Service sur AWS à prendre en compte lors du roulement sur les indices. Cette valeur est déterminée à partir du maxAge que vous définissez dans le ClusterLogging CR.
    4
    Lorsque Red Hat OpenShift Service sur AWS vérifie si les indices doivent être reportés. Ce paramètre est le paramètre par défaut et ne peut pas être modifié.
    Note

    La modification du CR Elasticsearch n’est pas prise en charge. Les modifications apportées aux politiques de conservation doivent être apportées dans le ClusterLogging CR.

    L’opérateur OpenShift Elasticsearch déploie une tâche cron pour déplacer les indices de chaque mappage à l’aide de la stratégie définie, programmée à l’aide du pollInterval. 

    $ oc get cronjob
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    NAME                     SCHEDULE       SUSPEND   ACTIVE   LAST SCHEDULE   AGE
elasticsearch-im-app     */15 * * * *   False     0        <none>          4s
elasticsearch-im-audit   */15 * * * *   False     0        <none>          4s
elasticsearch-im-infra   */15 * * * *   False     0        <none>          4s
    Copy to Clipboard Toggle word wrap

Chaque spécification de composant permet d’ajuster à la fois le CPU et les demandes de mémoire. Il ne faut pas avoir à ajuster manuellement ces valeurs car l’opérateur OpenShift Elasticsearch définit des valeurs suffisantes pour votre environnement.

Note

Dans les clusters à grande échelle, la limite de mémoire par défaut pour le conteneur proxy Elasticsearch pourrait ne pas être suffisante, ce qui rend le conteneur proxy OOMKilled. Lorsque vous rencontrez ce problème, augmentez les demandes de mémoire et les limites pour le proxy Elasticsearch.

Chaque nœud Elasticsearch peut fonctionner avec un réglage de mémoire inférieur, mais cela n’est pas recommandé pour les déploiements de production. En production, vous ne devriez pas avoir moins que le 16Gi par défaut alloué à chaque pod. De préférence, vous devriez allouer autant que possible, jusqu’à 64Gi par dose.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

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 
    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
....
spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
    1 
    
        resources:
          limits:
    2 
    
            memory: "32Gi"
          requests:
    3 
    
            cpu: "1"
            memory: "16Gi"
        proxy:
    4 
    
          resources:
            limits:
              memory: 100Mi
            requests:
              memory: 100Mi
    Copy to Clipboard Toggle word wrap
    1
    Indiquez les requêtes CPU et mémoire pour Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut qui devraient être suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 16Gi pour la requête mémoire et 1 pour la requête CPU.
    2
    La quantité maximale de ressources qu’un pod peut utiliser.
    3
    Les ressources minimales requises pour planifier un pod.
    4
    Indiquez les requêtes CPU et mémoire pour le proxy Elasticsearch au besoin. Lorsque vous laissez ces valeurs vides, l’opérateur OpenShift Elasticsearch définit des valeurs par défaut suffisantes pour la plupart des déploiements. Les valeurs par défaut sont 256Mi pour la requête mémoire et 100m pour la requête CPU.

Lors de l’ajustement de la quantité de mémoire Elasticsearch, la même valeur doit être utilisée pour les requêtes et les limites.

À titre d’exemple: 

      resources:
        limits:
1 

          memory: "32Gi"
        requests:
2 

          cpu: "8"
          memory: "32Gi"
Copy to Clipboard Toggle word wrap
1
Le montant maximal de la ressource.
2
Le montant minimum requis.

Kubernetes adhère généralement à la configuration du nœud et ne permet pas à Elasticsearch d’utiliser les limites spécifiées. La définition de la même valeur pour les requêtes et les limites garantit qu’Elasticsearch peut utiliser la mémoire que vous voulez, en supposant que le nœud dispose de la mémoire disponible.

Il est possible de définir comment les fragments Elasticsearch sont reproduits sur les nœuds de données du cluster.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. É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"

....

spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      redundancyPolicy: "SingleRedundancy"
    1
    Copy to Clipboard Toggle word wrap
    1
    Indiquez une politique de redondance pour les fragments. Le changement est appliqué lors de la sauvegarde des changements.
    • FullRedundancy. Elasticsearch réplique complètement les fragments primaires de chaque index à chaque nœud de données. Cela offre la sécurité la plus élevée, mais au coût de la plus grande quantité de disque requise et des performances les plus pauvres.
    • De multiplesRedundancy. Elasticsearch reproduit complètement les fragments primaires de chaque index à la moitié des nœuds de données. Cela offre un bon compromis entre la sécurité et la performance.
    • Le singleRedundancy. Elasticsearch fait une copie des fragments primaires pour chaque index. Les journaux sont toujours disponibles et récupérables tant qu’il existe au moins deux nœuds de données. De meilleures performances que MultipleRedundancy, lorsque vous utilisez 5 nœuds ou plus. Il est impossible d’appliquer cette politique sur les déploiements d’un nœud Elasticsearch unique.
    • Le ZeroRedundancy. Elasticsearch ne fait pas de copies des fragments primaires. Les journaux peuvent être indisponibles ou perdus en cas de panne ou d’échec d’un nœud. Lorsque vous êtes plus préoccupé par les performances que par la sécurité, utilisez ce mode ou avez mis en œuvre votre propre stratégie de sauvegarde/restauration de disque/PVC.
Note

Le nombre de fragments primaires pour les modèles d’index est égal au nombre de nœuds de données Elasticsearch.

10.4.6. Évoluant vers le bas des pods Elasticsearch
Copier lien

La réduction du nombre de pods Elasticsearch dans votre cluster peut entraîner une perte de données ou une dégradation des performances d’Elasticsearch.

Lorsque vous baissez, vous devriez réduire d’une dose à la fois et permettre au cluster de rééquilibrer les éclats et les répliques. Après le retour de l’état de santé Elasticsearch au vert, vous pouvez réduire par une autre dose.

Note

Lorsque votre cluster Elasticsearch est défini sur ZeroRedundancy, vous ne devriez pas réduire vos pods Elasticsearch.

10.4.7. Configuration du stockage persistant pour le log store
Copier lien

Elasticsearch nécessite un stockage persistant. Le stockage est rapide, plus la performance Elasticsearch est rapide.

Avertissement

L’utilisation du stockage NFS comme volume ou volume persistant (ou via un NAS tel que Gluster) n’est pas prise en charge pour le stockage Elasticsearch, car Lucene s’appuie sur le comportement du système de fichiers que NFS ne fournit pas. La corruption des données et d’autres problèmes peuvent survenir.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Éditez le ClusterLogging CR pour spécifier que chaque nœud de données dans le cluster est lié à une revendication de volume persistant. 

    apiVersion: "logging.openshift.io/v1"
kind: "ClusterLogging"
metadata:
  name: "instance"
# ...
spec:
  logStore:
    type: "elasticsearch"
    elasticsearch:
      nodeCount: 3
      storage:
        storageClassName: "gp2"
        size: "200G"
    Copy to Clipboard Toggle word wrap

Cet exemple spécifie chaque nœud de données dans le cluster est lié à une revendication de volume persistant qui demande le stockage "200G" d’AWS General Purpose SSD (gp2).

Note

Lorsque vous utilisez un volume local pour le stockage persistant, n’utilisez pas de volume de bloc brut, qui est décrit avec volumeMode: bloc dans l’objet LocalVolume. Elasticsearch ne peut pas utiliser les volumes de blocs bruts.

10.4.8. Configuration du log store pour le stockage emptyDir
Copier lien

Il est possible d’utiliser emptyDir avec votre log store, ce qui crée un déploiement éphémère dans lequel toutes les données d’un pod sont perdues lors du redémarrage.

Note

Lorsque vous utilisez emptyDir, si le stockage du journal est redémarré ou redéployé, vous perdrez des données.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

  1. Éditez le ClusterLogging CR pour spécifier emptyDir: 

     spec:
    logStore:
      type: "elasticsearch"
      elasticsearch:
        nodeCount: 3
        storage: {}
    Copy to Clipboard Toggle word wrap

Effectuez un redémarrage roulant lorsque vous modifiez la carte de configuration de la recherche élastique ou l’une des configurations de déploiement élastiquesearch-*.

En outre, un redémarrage roulant est recommandé si les nœuds sur lesquels fonctionne un pod Elasticsearch nécessitent un redémarrage.

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.

Procédure

Effectuer un redémarrage du cluster roulant:

  1. Changement au projet openshift-logging: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Les noms des pods Elasticsearch: 

    $ oc get pods -l component=elasticsearch
    Copy to Clipboard Toggle word wrap

  3. Faites baisser les pods de collecteurs afin qu’ils arrêtent d’envoyer de nouveaux journaux à Elasticsearch: 

    $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "false"}}}}}'
    Copy to Clipboard Toggle word wrap

  4. Effectuez une flush synchronisée en utilisant le service OpenShift Red Hat sur AWS es_util pour s’assurer qu’il n’y a pas d’opérations en attente d’être écrites sur le disque avant d’arrêter: 

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_flush/synced" -XPOST
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc exec -c elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6  -c elasticsearch -- es_util --query="_flush/synced" -XPOST
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {"_shards":{"total":4,"successful":4,"failed":0},".security":{"total":2,"successful":2,"failed":0},".kibana_1":{"total":2,"successful":2,"failed":0}}
    Copy to Clipboard Toggle word wrap

  5. Évitez l’équilibrage shard lorsque vous faites tomber délibérément les nœuds à l’aide du service OpenShift Red Hat sur AWS es_util: 

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "primaries" } }'
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"primaries"}}}},"transient":
    Copy to Clipboard Toggle word wrap

  6. Après la commande est terminée, pour chaque déploiement que vous avez pour un cluster ES:

    1. Le service OpenShift de Red Hat sur AWS Elasticsearch bloque les déploiements sur leurs nœuds. À l’aide de la commande suivante pour autoriser les déploiements et permettre au pod de récupérer les modifications: 

      $ oc rollout resume deployment/<deployment-name>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple: 

      $ oc rollout resume deployment/elasticsearch-cdm-0-1
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      deployment.extensions/elasticsearch-cdm-0-1 resumed
      Copy to Clipboard Toggle word wrap

      Il y a un nouveau pod. Après que la gousse a un conteneur prêt, vous pouvez passer au prochain déploiement. 

      $ oc get pods -l component=elasticsearch-
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      NAME                                            READY   STATUS    RESTARTS   AGE
elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6k    2/2     Running   0          22h
elasticsearch-cdm-5ceex6ts-2-f799564cb-l9mj7    2/2     Running   0          22h
elasticsearch-cdm-5ceex6ts-3-585968dc68-k7kjr   2/2     Running   0          22h
      Copy to Clipboard Toggle word wrap

    2. Après que les déploiements soient terminés, réinitialisez le pod pour refuser les déploiements: 

      $ oc rollout pause deployment/<deployment-name>
      Copy to Clipboard Toggle word wrap

      À titre d’exemple: 

      $ oc rollout pause deployment/elasticsearch-cdm-0-1
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      deployment.extensions/elasticsearch-cdm-0-1 paused
      Copy to Clipboard Toggle word wrap

    3. Assurez-vous que le cluster Elasticsearch est dans un état vert ou jaune: 

      $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      Copy to Clipboard Toggle word wrap
      Note

      Lorsque vous avez effectué un déploiement sur le pod Elasticsearch que vous avez utilisé dans les commandes précédentes, le pod n’existe plus et vous avez besoin d’un nouveau nom de pod ici.

      À titre d’exemple: 

      $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query=_cluster/health?pretty=true
      Copy to Clipboard Toggle word wrap 
      {
  "cluster_name" : "elasticsearch",
  "status" : "yellow",
      1 
      
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 8,
  "active_shards" : 16,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 1,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}
      Copy to Clipboard Toggle word wrap
      1
      Assurez-vous que cette valeur de paramètre est verte ou jaune avant de procéder.
  7. Lorsque vous avez modifié la carte de configuration Elasticsearch, répétez ces étapes pour chaque pod Elasticsearch.

  8. Après que tous les déploiements pour le cluster aient été déployés, réactivez l’équilibrage en dur: 

    $ oc exec <any_es_pod_in_the_cluster> -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'
    Copy to Clipboard Toggle word wrap

    À titre d’exemple: 

    $ oc exec elasticsearch-cdm-5ceex6ts-1-dcd6c4c7c-jpw6 -c elasticsearch -- es_util --query="_cluster/settings" -XPUT -d '{ "persistent": { "cluster.routing.allocation.enable" : "all" } }'
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    {
  "acknowledged" : true,
  "persistent" : { },
  "transient" : {
    "cluster" : {
      "routing" : {
        "allocation" : {
          "enable" : "all"
        }
      }
    }
  }
}
    Copy to Clipboard Toggle word wrap

  9. Augmentez les pods de collecteurs afin qu’ils envoient de nouveaux journaux à Elasticsearch. 

    $ oc -n openshift-logging patch daemonset/collector -p '{"spec":{"template":{"spec":{"nodeSelector":{"logging-infra-collector": "true"}}}}}'
    Copy to Clipboard Toggle word wrap

10.4.10. Exposer le service de log store comme itinéraire
Copier lien

Le log store déployé avec l’enregistrement n’est pas accessible depuis l’extérieur du cluster de journalisation. Il est possible d’activer un itinéraire avec terminaison de recryptage pour un accès externe au service log store pour les outils qui accèdent à ses données.

En externe, vous pouvez accéder au log store en créant un itinéraire recrypté, votre Red Hat OpenShift Service sur le jeton AWS et le certificat CA installé. Ensuite, accédez à un nœud qui héberge le service log store avec une requête cURL qui contient:

  • L’autorisation: Porteur ${token}
  • La route Elasticsearch recrypte et une demande d’API Elasticsearch.

En interne, vous pouvez accéder au service de log store à l’aide du cluster de log store IP, que vous pouvez obtenir en utilisant l’une des commandes suivantes: 

$ oc get service elasticsearch -o jsonpath={.spec.clusterIP} -n openshift-logging
Copy to Clipboard Toggle word wrap

Exemple de sortie

172.30.183.229
Copy to Clipboard Toggle word wrap 

$ oc get service elasticsearch -n openshift-logging
Copy to Clipboard Toggle word wrap

Exemple de sortie

NAME            TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGE
elasticsearch   ClusterIP   172.30.183.229   <none>        9200/TCP   22h
Copy to Clipboard Toggle word wrap

Il est possible de vérifier l’adresse IP du cluster avec une commande similaire à ce qui suit: 

$ oc exec elasticsearch-cdm-oplnhinv-1-5746475887-fj2f8 -n openshift-logging -- curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://172.30.183.229:9200/_cat/health"
Copy to Clipboard Toggle word wrap

Exemple de sortie

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100    29  100    29    0     0    108      0 --:--:-- --:--:-- --:--:--   108
Copy to Clipboard Toggle word wrap

Conditions préalables

  • Les opérateurs Red Hat OpenShift Logging et Elasticsearch doivent être installés.
  • Il faut avoir accès au projet pour pouvoir accéder aux journaux.

Procédure

Exposer le log store à l’extérieur:

  1. Changement au projet openshift-logging: 

    $ oc project openshift-logging
    Copy to Clipboard Toggle word wrap

  2. Extrayez le certificat CA du log store et écrivez dans le fichier admin-ca: 

    $ oc extract secret/elasticsearch --to=. --keys=admin-ca
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    admin-ca
    Copy to Clipboard Toggle word wrap

  3. Créez l’itinéraire pour le service log store en tant que fichier YAML:

    1. Créez un fichier YAML avec ce qui suit: 

      apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: elasticsearch
  namespace: openshift-logging
spec:
  host:
  to:
    kind: Service
    name: elasticsearch
  tls:
    termination: reencrypt
    destinationCACertificate: |
      1
      Copy to Clipboard Toggle word wrap
      1
      Ajoutez le log store CA certifcate ou utilisez la commande dans l’étape suivante. Il n’est pas nécessaire de définir les paramètres spec.tls.key, spec.tls.certificate et spec.tls.caCertificate requis par certains itinéraires recryptés.

    2. Exécutez la commande suivante pour ajouter le certificat CA log store à l’itinéraire YAML que vous avez créé à l’étape précédente: 

      $ cat ./admin-ca | sed -e "s/^/      /" >> <file-name>.yaml
      Copy to Clipboard Toggle word wrap

    3. Créer l’itinéraire: 

      $ oc create -f <file-name>.yaml
      Copy to Clipboard Toggle word wrap

      Exemple de sortie

      route.route.openshift.io/elasticsearch created
      Copy to Clipboard Toggle word wrap

  4. Assurez-vous que le service Elasticsearch est exposé:

    1. Bénéficiez du jeton de ce compte de service pour être utilisé dans la demande: 

      $ token=$(oc whoami -t)
      Copy to Clipboard Toggle word wrap

    2. Définissez l’itinéraire de recherche élastique que vous avez créé en tant que variable d’environnement. 

      $ routeES=`oc get route elasticsearch -o jsonpath={.spec.host}`
      Copy to Clipboard Toggle word wrap

    3. Afin de vérifier que l’itinéraire a été créé avec succès, exécutez la commande suivante qui accède à Elasticsearch à travers la route exposée: 

      curl -tlsv1.2 --insecure -H "Authorization: Bearer ${token}" "https://${routeES}"
      Copy to Clipboard Toggle word wrap

      La réponse semble similaire à ce qui suit:

      Exemple de sortie

      {
  "name" : "elasticsearch-cdm-i40ktba0-1",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "0eY-tJzcR3KOdpgeMJo-MQ",
  "version" : {
  "number" : "6.8.1",
  "build_flavor" : "oss",
  "build_type" : "zip",
  "build_hash" : "Unknown",
  "build_date" : "Unknown",
  "build_snapshot" : true,
  "lucene_version" : "7.7.0",
  "minimum_wire_compatibility_version" : "5.6.0",
  "minimum_index_compatibility_version" : "5.0.0"
},
  "<tagline>" : "<for search>"
}
      Copy to Clipboard Toggle word wrap

En tant qu’administrateur, dans le cas rare que vous transmettiez des journaux vers un magasin de journal tiers et que vous n’utilisiez pas le log store 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 log store Elasticsearch par défaut, vous pouvez supprimer les composants de visualisation internes Elasticsearch logStore et Kibana de la ressource personnalisée ClusterLogging (CR). La suppression de ces composants est facultative, mais permet d’économiser des ressources.

Conditions préalables

  • Assurez-vous que votre transmetteur de journaux n’envoie pas de données de journal au cluster interne Elasticsearch par défaut. Inspectez le fichier ClusterLogForwarder CR YAML que vous avez utilisé pour configurer le transfert de journaux. Assurez-vous qu’il n’a pas d’élément outputRefs qui spécifie par défaut. À titre d’exemple: 

    outputRefs:
- default
    Copy to Clipboard Toggle word wrap
Avertissement

Imaginez que le ClusterLogForwarder CR transmet les données de log vers le cluster Elasticsearch interne, et vous supprimez le composant logStore du ClusterLogging CR. 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. Éditer la ressource personnalisée ClusterLogging (CR) dans le projet openshift-logging: 

    $ oc edit ClusterLogging instance
    Copy to Clipboard Toggle word wrap
  2. En cas de présence, retirez les strophes logStore et visualisation du ClusterLogging CR.

  3. Conserver la strophe de collection du ClusterLogging CR. 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:
    type: "fluentd"
    fluentd: {}
    Copy to Clipboard Toggle word wrap

  4. Assurez-vous que les pods de collecteur sont redéployés: 

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

Chapitre 11. Alertes de journalisation
Copier lien

11.1. Alertes de journalisation par défaut
Copier lien

Les alertes de journalisation sont installées dans le cadre de l’installation Red Hat OpenShift Logging Operator. Les alertes dépendent des métriques exportées par la collecte de journaux et les backends de stockage de journaux. Ces métriques sont activées si vous avez sélectionné l’option Activer la surveillance de cluster recommandée par l’opérateur sur cet espace de noms lors de l’installation de l’opérateur de journalisation Red Hat OpenShift.

Les alertes de journalisation par défaut sont envoyées au service Red Hat OpenShift sur la pile de surveillance AWS Alertmanager dans l’espace de noms de surveillance openshift, à moins que vous n’ayez désactivé l’instance Alertmanager locale.

L’interface utilisateur d’alerte est accessible via la perspective Développeur du Red Hat OpenShift Service sur la console web AWS.

  • Du point de vue de l’administrateur, allez à Observer → Alerter. Les trois pages principales de l’interface utilisateur d’alerte dans cette perspective sont les pages de règles d’alerte, de silence et d’alerte.
  • Du point de vue Développeur, allez à Observer et allez à l’onglet Alertes.
  • Choisissez le projet pour lequel vous souhaitez gérer les alertes dans la liste Projet:

Dans cette perspective, les alertes, les silences et les règles d’alerte sont tous gérés à partir de l’onglet Alertes. Les résultats affichés dans l’onglet Alertes sont spécifiques au projet sélectionné.

Note

Dans la perspective Développeur, vous pouvez sélectionner à partir du service Core Red Hat OpenShift sur AWS et les projets définis par l’utilisateur auxquels vous avez accès dans la liste Projet: &lt;project_name&gt;. Cependant, les alertes, les silences et les règles d’alerte relatives au service Core Red Hat OpenShift sur les projets AWS ne sont pas affichés si vous n’êtes pas connecté en tant qu’administrateur de cluster.

11.1.3. Alerte de collecteur de journalisation
Copier lien

Dans l’enregistrement des versions 5.8 et ultérieures, les alertes suivantes sont générées par l’opérateur de journalisation Red Hat OpenShift. Ces alertes sont affichées dans le service OpenShift Red Hat sur la console web AWS.

Expand
Alerte NomLe messageDescriptionLa sévérité

CollectorNodeDown

Le Prometheus n’a pas pu gratter le composant du collecteur de noms/pod pendant plus de 10 m.

Le collecteur ne peut pas être gratté.

Critique

CollectorHighErrorRate

la valeur % des enregistrements a entraîné une erreur par composant collecteur d’espace de noms/pod.

les erreurs de composant de collecteur de noms/pods sont élevées.

Critique

CollectorVeryHighErrorRate

la valeur % des enregistrements a entraîné une erreur par composant collecteur d’espace de noms/pod.

les erreurs de composant de collecteur de noms/pods sont très élevées.

Critique

11.1.4. Alertes de collecteur de vecteurs
Copier lien

Dans l’enregistrement des versions 5.7 et ultérieures, les alertes suivantes sont générées par le collecteur de vecteurs. Ces alertes sont affichées dans le service OpenShift Red Hat sur la console web AWS.

Expand
Tableau 11.1. Alertes de collecteur de vecteurs
AlerteLe messageDescriptionLa sévérité

CollectorHighErrorRate

&lt;value&gt; des enregistrements ont entraîné une erreur par vecteur &lt;instance&gt;.

Le nombre d’erreurs de sortie vectorielles est élevé, par défaut plus de 10 au cours des 15 minutes précédentes.

Avertissement

CollectorNodeDown

Le Prométhée n’a pas pu gratter le vecteur &lt;instance&gt; pendant plus de 10m.

Le vecteur rapporte que Prometheus ne pouvait pas gratter une instance vectorielle spécifique.

Critique

CollectorVeryHighErrorRate

&lt;value&gt; des enregistrements ont entraîné une erreur par vecteur &lt;instance&gt;.

Le nombre d’erreurs de composants vectoriels est très élevé, par défaut plus de 25 au cours des 15 minutes précédentes.

Critique

FluentdQueueLength Augmentation

Au cours de la dernière 1h, la longueur de file d’attente du tampon a constamment augmenté de plus de 1. La valeur actuelle est &lt;valeur&gt;.

Fluentd rapporte que la taille de la file d’attente augmente.

Avertissement

11.1.5. Alertes Fluentd collector
Copier lien

Les alertes suivantes sont générées par l’ancien collecteur de journaux Fluentd. Ces alertes sont affichées dans le service OpenShift Red Hat sur la console web AWS.

Expand
Tableau 11.2. Alertes Fluentd collector
AlerteLe messageDescriptionLa sévérité

FluentDHighErrorRate

&lt;valeur&gt; des enregistrements ont entraîné une erreur par fluentd &lt;instance&gt;.

Le nombre d’erreurs de sortie FluentD est élevé, par défaut plus de 10 au cours des 15 minutes précédentes.

Avertissement

FluentdNodeDown

Le Prométhée ne pouvait pas gratter couramment &lt;instance&gt; pendant plus de 10m.

Fluentd signale que Prometheus ne pouvait pas gratter une instance Fluentd spécifique.

Critique

FluentdQueueLength Augmentation

Au cours de la dernière 1h, la longueur de file d’attente du tampon a constamment augmenté de plus de 1. La valeur actuelle est &lt;valeur&gt;.

Fluentd rapporte que la taille de la file d’attente augmente.

Avertissement

FluentDVeryHighErrorRate

&lt;valeur&gt; des enregistrements ont entraîné une erreur par fluentd &lt;instance&gt;.

Le nombre d’erreurs de sortie FluentD est très élevé, par défaut plus de 25 au cours des 15 minutes précédentes.

Critique

11.1.6. Elasticsearch règles d’alerte
Copier lien

Ces règles d’alerte sont affichées dans le Service OpenShift Red Hat sur la console web AWS.

Expand
Tableau 11.3. Les règles d’alerte
AlerteDescriptionLa sévérité

ElasticsearchClusterNotHealthy

L’état de santé du cluster a été RED depuis au moins 2 minutes. Le cluster n’accepte pas les écrits, les éclats peuvent manquer, ou le nœud maître n’a pas encore été élu.

Critique

ElasticsearchClusterNotHealthy

L’état de santé du cluster a été YELLOW pendant au moins 20 minutes. Certaines répliques de fragments ne sont pas allouées.

Avertissement

ElasticsearchDiskSpaceRunningLow

Le cluster devrait être hors de l’espace disque dans les 6 prochaines heures.

Critique

ElasticsearchHighFileDescriptorUsage

Le cluster devrait être sorti des descripteurs de fichiers dans l’heure suivante.

Avertissement

ElasticsearchJVMHeapUseHigh

L’utilisation de JVM Heap sur le nœud spécifié est élevée.

Alerte

ElasticsearchNodeDiskWatermarkReached

Le nœud spécifié a atteint le filigrane bas en raison d’un faible espace disque libre. Les fragments ne peuvent plus être attribués à ce nœud. Il faut envisager d’ajouter plus d’espace disque au nœud.

Infos

ElasticsearchNodeDiskWatermarkReached

Le nœud spécifié a atteint le filigrane élevé en raison d’un faible espace disque libre. Certains fragments seront réaffectés à différents nœuds si possible. Assurez-vous que plus d’espace disque est ajouté au nœud ou déposez les anciens indices alloués à ce nœud.

Avertissement

ElasticsearchNodeDiskWatermarkReached

Le nœud spécifié a frappé le filigrane d’inondation en raison d’un faible espace disque libre. Chaque index qui a un fragment alloué sur ce nœud est appliqué un bloc en lecture seule. Le bloc d’index doit être libéré manuellement lorsque l’utilisation du disque tombe sous le filigrane élevé.

Critique

ElasticsearchJVMHeapUseHigh

L’utilisation de JVM Heap sur le nœud spécifié est trop élevée.

Alerte

ElasticsearchWriteRequestsRejectionJumps

Elasticsearch connaît une augmentation des rejets d’écriture sur le nœud spécifié. Ce nœud pourrait ne pas suivre la vitesse d’indexation.

Avertissement

AggregatedLoggingSystemCPUHigh

Le CPU utilisé par le système sur le nœud spécifié est trop élevé.

Alerte

ElasticsearchProcessCPUHigh

Le CPU utilisé par Elasticsearch sur le nœud spécifié est trop élevé.

Alerte

11.2. Alertes de journalisation personnalisées
Copier lien

Dans l’enregistrement des versions 5.7 et ultérieures, les utilisateurs peuvent configurer le déploiement LokiStack pour produire des alertes personnalisées et des métriques enregistrées. Lorsque vous souhaitez utiliser des règles d’alerte et d’enregistrement personnalisées, vous devez activer le composant règle LokiStack.

Les alertes basées sur les logs LokiStack et les métriques enregistrées sont déclenchées en fournissant des expressions LogQL au composant règle. L’opérateur Loki gère une règle optimisée pour la taille LokiStack sélectionnée, qui peut être 1x.extra-petit, 1x.petit, ou 1x.medium.

Afin de fournir ces expressions, vous devez créer une ressource personnalisée AlertingRule (CR) contenant des règles d’alerte compatibles Prometheus, ou une RecordingRule CR contenant des règles d’enregistrement compatibles Prometheus.

Les administrateurs peuvent configurer des alertes logées ou des métriques enregistrées pour les locataires d’applications, d’audits ou d’infrastructures. Les utilisateurs sans autorisation d’administrateur peuvent configurer des alertes log-based ou des métriques enregistrées pour les locataires des applications auxquelles ils ont accès.

Les alertes d’application, d’audit et d’infrastructure sont envoyées par défaut au service Red Hat OpenShift sur la pile de surveillance AWS Alertmanager dans l’espace de noms de surveillance openshift, sauf si vous avez désactivé l’instance Alertmanager locale. Lorsque le gestionnaire d’alerte qui est utilisé pour surveiller les projets définis par l’utilisateur dans l’espace de noms de surveillance de la charge de travail openshift-user est activé, des alertes d’application sont envoyées au gestionnaire d’alerte dans cet espace de noms par défaut.

11.2.1. Configuration de la règle
Copier lien

Lorsque le composant de règle LokiStack est activé, les utilisateurs peuvent définir un groupe d’expressions LogQL qui déclenchent des alertes de journalisation ou des métriques enregistrées.

Les administrateurs peuvent activer la règle en modifiant la ressource personnalisée LokiStack (CR).

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift et l’opérateur Loki ont été installés.
  • « vous avez créé un LokiStack CR.
  • Il y a des autorisations d’administrateur.

Procédure

  • Activer la règle en s’assurant que le LokiStack CR contient la configuration spec ci-dessous: 

    apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: <name>
  namespace: <namespace>
spec:
# ...
  rules:
    enabled: true
    1 
    
    selector:
      matchLabels:
        openshift.io/<label_name>: "true"
    2 
    
    namespaceSelector:
      matchLabels:
        openshift.io/<label_name>: "true"
    3
    Copy to Clipboard Toggle word wrap
    1
    Activez les règles d’alerte et d’enregistrement Loki dans votre cluster.
    2
    Ajoutez une étiquette personnalisée qui peut être ajoutée aux espaces de noms où vous souhaitez activer l’utilisation des alertes et des métriques de journalisation.
    3
    Ajoutez une étiquette personnalisée qui peut être ajoutée aux espaces de noms où vous souhaitez activer l’utilisation des alertes et des métriques de journalisation.

11.2.2. Autoriser les règles LokiStack Autorisations RBAC
Copier lien

Les administrateurs peuvent permettre aux utilisateurs de créer et de gérer leurs propres règles d’alerte et d’enregistrement en liant les rôles de cluster aux noms d’utilisateurs. Les rôles de cluster sont définis comme des objets ClusterRole qui contiennent les autorisations nécessaires de contrôle d’accès basé sur les rôles (RBAC) pour les utilisateurs.

Dans l’enregistrement 5.8 et plus tard, les rôles de cluster suivants pour les règles d’alerte et d’enregistrement sont disponibles pour LokiStack:

Expand
Le nom de la règleDescription

alertingrules.loki.grafana.com-v1-admin

Les utilisateurs ayant ce rôle ont un accès administratif pour gérer les règles d’alerte. Ce rôle de cluster accorde des autorisations pour créer, lire, mettre à jour, supprimer, répertorier et regarder les ressources AlertingRule au sein du groupe API loki.grafana.com/v1.

alertingrules.loki.grafana.com-v1-crdview

Les utilisateurs ayant ce rôle peuvent afficher les définitions des définitions de ressources personnalisées (CRD) liées aux ressources AlertingRule dans le groupe API loki.grafana.com/v1, mais n’ont pas d’autorisations pour modifier ou gérer ces ressources.

alertingrules.loki.grafana.com-v1-edit

Les utilisateurs ayant ce rôle ont la permission de créer, de mettre à jour et de supprimer les ressources AlertingRule.

alertingrules.loki.grafana.com-v1-view

Les utilisateurs avec ce rôle peuvent lire les ressources AlertingRule dans le groupe API loki.grafana.com/v1. Ils peuvent inspecter les configurations, les étiquettes et les annotations pour les règles d’alerte existantes, mais ne peuvent y apporter aucune modification.

recordingrules.loki.grafana.com-v1-admin

Les utilisateurs ayant ce rôle ont un accès administratif pour gérer les règles d’enregistrement. Ce rôle de cluster accorde des autorisations pour créer, lire, mettre à jour, supprimer, répertorier et regarder les ressources RecordingRule au sein du groupe API loki.grafana.com/v1.

recordingrules.loki.grafana.com-v1-crdview

Les utilisateurs avec ce rôle peuvent afficher les définitions de Définitions de Ressources Personnalisées (CRD) liées aux ressources RecordingRule dans le groupe API loki.grafana.com/v1, mais n’ont pas d’autorisations pour modifier ou gérer ces ressources.

recordingrules.loki.grafana.com-v1-edit

Les utilisateurs ayant ce rôle ont la permission de créer, de mettre à jour et de supprimer les ressources RecordingRule.

recordingrules.loki.grafana.com-v1-view

Les utilisateurs avec ce rôle peuvent lire les ressources RecordingRule dans le groupe API loki.grafana.com/v1. Ils peuvent inspecter les configurations, les étiquettes et les annotations pour les règles d’alerte existantes, mais ne peuvent y apporter aucune modification.

11.2.2.1. Exemples
Copier lien

Afin d’appliquer des rôles de cluster pour un utilisateur, vous devez lier un rôle de cluster existant à un nom d’utilisateur spécifique.

Les rôles de cluster peuvent être définis en cluster ou en espace de noms, en fonction du type de liaison de rôle que vous utilisez. Lorsqu’un objet RoleBinding est utilisé, comme lors de l’utilisation de la commande add-role-to-user de la stratégie adm oc, le rôle de cluster ne s’applique qu’à l’espace de noms spécifié. Lorsqu’un objet ClusterRoleBinding est utilisé, comme lors de l’utilisation de la commande add-cluster-role-to-user de la stratégie adm oc, le rôle de cluster s’applique à tous les espaces de noms du cluster.

La commande d’exemple suivante donne à l’utilisateur spécifié des autorisations de création, de lecture, de mise à jour et de suppression (CRUD) pour les règles d’alerte dans un espace de noms spécifique dans le cluster:

Exemple de commande de liaison de rôle de cluster pour alerter les autorisations CRUD de règle dans un espace de noms spécifique

$ oc adm policy add-role-to-user alertingrules.loki.grafana.com-v1-admin -n <namespace> <username>
Copy to Clipboard Toggle word wrap

La commande suivante donne les autorisations d’administrateur d’utilisateur spécifiées pour les règles d’alerte dans tous les espaces de noms:

Exemple de commande de liaison de rôle de cluster pour les autorisations d’administrateur

$ oc adm policy add-cluster-role-to-user alertingrules.loki.grafana.com-v1-admin <username>
Copy to Clipboard Toggle word wrap

La règle d’alerte CR contient un ensemble de spécifications et de définitions de validation webhook pour déclarer des groupes de règles d’alerte pour une seule instance LokiStack. En outre, la définition de validation webhook prend en charge les conditions de validation des règles:

  • Lorsqu’une règle d’alerte CR inclut une période d’intervalle invalide, il s’agit d’une règle d’alerte invalide
  • Lorsqu’une règle d’alerte CR inclut une période invalide, il s’agit d’une règle d’alerte invalide.
  • Dans le cas où une règle d’alerte CR inclut une expr de LogQL invalide, il s’agit d’une règle d’alerte invalide.
  • Lorsqu’une règle d’alerte CR inclut deux groupes portant le même nom, il s’agit d’une règle d’alerte invalide.
  • Dans le cas où aucun des éléments ci-dessus ne s’applique, une règle d’alerte est considérée comme valide.
Expand
Le type de locataireEspaces de noms valides pour AlertingRule CRs

application

 

audit

journalisation OpenShift

l’infrastructure

d’OpenShift-/*, kube-/\*, par défaut

Conditions préalables

  • L’opérateur de journalisation de Red Hat OpenShift 5.7 et versions ultérieures
  • Le Red Hat OpenShift Service sur AWS 4.13 et versions ultérieures

Procédure

  1. Créer une ressource personnalisée AlertingRule (CR):

    Exemple d’infrastructure AlertingRule CR

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: loki-operator-alerts
    namespace: openshift-operators-redhat
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "infrastructure"
    3 
    
    groups:
      - name: LokiOperatorHighReconciliationError
        rules:
          - alert: HighPercentageError
            expr: |
    4 
    
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"} |= "error" [1m])) by (job)
                /
              sum(rate({kubernetes_namespace_name="openshift-operators-redhat", kubernetes_pod_name=~"loki-operator-controller-manager.*"}[1m])) by (job)
                > 0.01
            for: 10s
            labels:
              severity: critical
    5 
    
            annotations:
              summary: High Loki Operator Reconciliation Errors
    6 
    
              description: High Loki Operator Reconciliation Errors
    7
    Copy to Clipboard Toggle word wrap

    1
    L’espace de noms où cette AlertingRule CR est créée doit avoir une étiquette correspondant à la définition LokiStack spec.rules.namespaceSelector.
    2
    Le bloc d’étiquettes doit correspondre à la définition de LokiStack spec.rules.selector.
    3
    AlertingRule CRs pour les locataires de l’infrastructure sont uniquement pris en charge dans les espaces de noms openshift-*, kube-\* ou par défaut.
    4
    La valeur de kubernetes_namespace_name: doit correspondre à la valeur de métadonnées.namespace.
    5
    La valeur de ce champ obligatoire doit être critique, mise en garde ou info.
    6
    Ce champ est obligatoire.
    7
    Ce champ est obligatoire.

    Exemple d’application AlertingRule CR

      apiVersion: loki.grafana.com/v1
  kind: AlertingRule
  metadata:
    name: app-user-workload
    namespace: app-ns
    1 
    
    labels:
    2 
    
      openshift.io/<label_name>: "true"
  spec:
    tenantID: "application"
    groups:
      - name: AppUserWorkloadHighError
        rules:
          - alert:
            expr: |
    3 
    
            sum(rate({kubernetes_namespace_name="app-ns", kubernetes_pod_name=~"podName.*"} |= "error" [1m])) by (job)
            for: 10s
            labels:
              severity: critical
    4 
    
            annotations:
              summary:
    5 
    
              description:
    6
    Copy to Clipboard Toggle word wrap

    1
    L’espace de noms où cette AlertingRule CR est créée doit avoir une étiquette correspondant à la définition LokiStack spec.rules.namespaceSelector.
    2
    Le bloc d’étiquettes doit correspondre à la définition de LokiStack spec.rules.selector.
    3
    La valeur de kubernetes_namespace_name: doit correspondre à la valeur de métadonnées.namespace.
    4
    La valeur de ce champ obligatoire doit être critique, mise en garde ou info.
    5
    La valeur de ce champ obligatoire est un résumé de la règle.
    6
    La valeur de ce champ obligatoire est une description détaillée de la règle.

  2. Appliquer la règle d’alerte CR: 

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

Chapitre 12. Accord de performance et de fiabilité
Copier lien

12.1. Les mécanismes de contrôle du flux
Copier lien

Lorsque les journaux sont produits plus rapidement qu’ils ne peuvent être collectés, il peut être difficile de prédire ou de contrôler le volume des logs envoyés à une sortie. Le fait de ne pas pouvoir prédire ou contrôler le volume des journaux envoyés à une sortie peut entraîner la perte de logs. En cas de panne du système et les tampons de log sont accumulés sans contrôle de l’utilisateur, cela peut également entraîner de longs temps de récupération et une latence élevée lorsque la connexion est restaurée.

En tant qu’administrateur, vous pouvez limiter les taux de journalisation en configurant des mécanismes de contrôle de flux pour votre journalisation.

12.1.1. Avantages des mécanismes de contrôle du débit
Copier lien

  • Le coût et le volume de l’exploitation forestière peuvent être prédits plus précisément à l’avance.
  • Les conteneurs bruyants ne peuvent pas produire un trafic journal non lié qui noie d’autres conteneurs.
  • Ignorer les journaux de faible valeur réduit la charge sur l’infrastructure d’exploitation forestière.
  • Les journaux à haute valeur peuvent être préférés aux journaux de faible valeur en attribuant des limites de taux plus élevées.

12.1.2. Configuration des limites de taux
Copier lien

Les limites de taux sont configurées par collecteur, ce qui signifie que le taux maximum de collecte de journaux est le nombre d’instances de collecte multipliée par la limite de taux.

Étant donné que les journaux sont recueillis à partir du système de fichiers de chaque nœud, un collecteur est déployé sur chaque nœud de cluster. Ainsi, dans un groupe de 3 nœuds, avec une limite maximale de 10 enregistrements par seconde par collecteur, le taux maximal de collecte des logs est de 30 enregistrements par seconde.

Étant donné que la taille exacte d’octets d’un enregistrement tel qu’écrit à une sortie peut varier en raison de transformations, différents encodages ou d’autres facteurs, les limites de taux sont fixées en nombre d’enregistrements au lieu d’octets.

Configurez les limites de taux dans la ressource personnalisée ClusterLogForwarder (CR) de deux manières:

Limite de taux de production
Limitez le taux de logs sortants aux sorties sélectionnées, par exemple, pour correspondre à la capacité de réseau ou de stockage d’une sortie. La limite de taux de sortie contrôle le taux agrégé par sortie.
Limite de taux d’entrée
Limiter le taux de collecte des logs par conteneur pour les conteneurs sélectionnés.

Il est possible de limiter le taux de logs sortants à une sortie spécifiée en configurant la ressource personnalisée ClusterLogForwarder (CR).

Conditions préalables

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

Procédure

  1. Ajoutez une valeur limite maxRecordsPerSecond au ClusterLogForwarder CR pour une sortie spécifiée.

    L’exemple suivant montre comment configurer une limite de débit de sortie par collecteur pour une sortie de courtier Kafka nommée kafka-exemple:

    Exemple ClusterLogForwarder CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  outputs:
    - name: kafka-example
    1 
    
      type: kafka
    2 
    
      limit:
        maxRecordsPerSecond: 1000000
    3 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le nom de sortie.
    2
    Le type de sortie.
    3
    La limite de débit de sortie du journal. Cette valeur définit la quantité maximale de logs qui peuvent être envoyées au courtier Kafka par seconde. Cette valeur n’est pas définie par défaut. Le comportement par défaut est le meilleur effort, et les enregistrements sont supprimés si l’expéditeur de journal ne peut pas suivre. Dans le cas où cette valeur est 0, aucun journal n’est transmis.

  2. Appliquer le ClusterLogForwarder CR:

    Commande d’exemple

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

Il est possible de limiter le taux de logs entrants qui sont collectés en configurant la ressource personnalisée ClusterLogForwarder (CR). Il est possible de fixer des limites d’entrée sur une base par conteneur ou par espace.

Conditions préalables

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

Procédure

  1. Ajoutez une valeur limite maxRecordsPerSecond au ClusterLogForwarder CR pour une entrée spécifiée.

    Les exemples suivants montrent comment configurer les limites de débit d’entrée pour différents scénarios:

    Exemple ClusterLogForwarder CR qui fixe une limite par conteneur pour les conteneurs avec certaines étiquettes

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  inputs:
    - name: <input_name>
    1 
    
      application:
        selector:
          matchLabels: { example: label }
    2 
    
        containerLimit:
          maxRecordsPerSecond: 0
    3 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le nom d’entrée.
    2
    Liste des étiquettes. Lorsque ces étiquettes correspondent aux étiquettes apposées sur un pod, la limite par conteneur spécifiée dans le champ maxRecordsPerSecond est appliquée à ces conteneurs.
    3
    Configure la limite de taux. Définir le champ maxRecordsPerSecond sur 0 signifie qu’aucun journal n’est collecté pour le conteneur. Définir le champ maxRecordsPerSecond sur une autre valeur signifie qu’un maximum de ce nombre d’enregistrements par seconde est collecté pour le conteneur.

    Exemple ClusterLogForwarder CR qui fixe une limite par conteneur pour les conteneurs dans certains espaces de noms

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
# ...
  inputs:
    - name: <input_name>
    1 
    
      application:
        namespaces: [ example-ns-1, example-ns-2 ]
    2 
    
        containerLimit:
          maxRecordsPerSecond: 10
    3 
    
    - name: <input_name>
      application:
        namespaces: [ test ]
        containerLimit:
          maxRecordsPerSecond: 1000
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le nom d’entrée.
    2
    Liste des espaces de noms. La limite par conteneur spécifiée dans le champ maxRecordsPerSecond est appliquée à tous les conteneurs dans les espaces de noms listés.
    3
    Configure la limite de taux. Définir le champ maxRecordsPerSecond à 10 signifie qu’un maximum de 10 enregistrements par seconde sont collectés pour chaque conteneur dans les espaces de noms énumérés.

  2. Appliquer le ClusterLogForwarder CR:

    Commande d’exemple

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

12.2. Filtrage des journaux par contenu
Copier lien

La collecte de tous les journaux à partir d’un cluster peut produire une grande quantité de données, ce qui peut être coûteux pour le transport et le stockage.

Il est possible de réduire le volume de vos données de log en filtrant les données à faible priorité qui n’ont pas besoin d’être stockées. L’enregistrement fournit des filtres de contenu que vous pouvez utiliser pour réduire le volume des données de log.

Note

Les filtres de contenu sont distincts des sélecteurs d’entrée. les sélecteurs d’entrée sélectionnent ou ignorent des flux de journaux entiers basés sur les métadonnées source. Les filtres de contenu modifient les flux de journaux pour supprimer et modifier les enregistrements en fonction du contenu de l’enregistrement.

Le volume des données de log peut être réduit en utilisant l’une des méthodes suivantes:

Lorsque le filtre de chute est configuré, le collecteur de journaux évalue les flux de journaux en fonction des filtres avant le transfert. Le collecteur dépose les enregistrements de journal indésirables qui correspondent à la configuration spécifiée.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • Il y a des autorisations d’administrateur.
  • Création d’une ressource personnalisée ClusterLogForwarder (CR).

Procédure

  1. Ajoutez une configuration pour un filtre à la spécification des filtres dans le ClusterLogForwarder CR.

    L’exemple suivant montre comment configurer le ClusterLogForwarder CR pour laisser tomber les enregistrements de journaux basés sur des expressions régulières:

    Exemple ClusterLogForwarder CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: <filter_name>
    type: drop
    1 
    
    drop:
    2 
    
    - test:
    3 
    
      - field: .kubernetes.labels."foo-bar/baz"
    4 
    
        matches: .+
    5 
    
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
    6 
    
  pipelines:
  - name: <pipeline_name>
    7 
    
    filterRefs: ["<filter_name>"]
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indique le type de filtre. Le filtre de chute dépose les enregistrements de journal qui correspondent à la configuration du filtre.
    2
    Indique les options de configuration pour l’application du filtre de chute.
    3
    Indique la configuration des tests utilisés pour évaluer si un enregistrement de journal est supprimé.
    • Lorsque toutes les conditions spécifiées pour un essai sont vraies, le test passe et l’enregistrement du journal est supprimé.
    • Lorsque plusieurs tests sont spécifiés pour la configuration du filtre de chute, si l’un des tests passe, l’enregistrement est supprimé.
    • En cas d’erreur d’évaluation d’une condition, par exemple, le champ est absent de l’enregistrement journal en cours d’évaluation, cette condition évalue à false.
    4
    Indique un chemin de champ délimité par point, qui est un chemin vers un champ dans l’enregistrement de journal. Le chemin peut contenir des caractères alpha-numériques et des accents (a-zA-Z0-9_), par exemple, .kubernetes.namespace_name. Lorsque les segments contiennent des caractères en dehors de cette plage, le segment doit être en guillemets, par exemple, .kubernetes.labels.foo.bar-bar/baz. Il est possible d’inclure plusieurs chemins de champ dans une configuration de test unique, mais ils doivent tous être évalués à true pour que le test passe et que le filtre de chute soit appliqué.
    5
    Indique une expression régulière. Lorsque les enregistrements de journaux correspondent à cette expression régulière, ils sont supprimés. Il est possible de définir soit les correspondances, soit la condition Matches pour un seul chemin de champ, mais pas les deux.
    6
    Indique une expression régulière. Lorsque les enregistrements de journaux ne correspondent pas à cette expression régulière, ils sont supprimés. Il est possible de définir soit les correspondances, soit la condition Matches pour un seul chemin de champ, mais pas les deux.
    7
    Indique le pipeline auquel le filtre de goutte est appliqué.

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

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

Exemples supplémentaires

L’exemple supplémentaire suivant montre comment vous pouvez configurer le filtre de chute pour ne conserver que des enregistrements de journal de priorité plus élevés: 

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: important
    type: drop
    drop:
      test:
      - field: .message
        notMatches: "(?i)critical|error"
      - field: .level
        matches: "info|warning"
# ...
Copy to Clipboard Toggle word wrap

En plus d’inclure plusieurs chemins de champ dans une configuration de test unique, vous pouvez également inclure des tests supplémentaires qui sont traités comme des vérifications OU. Dans l’exemple suivant, les enregistrements sont supprimés si l’une ou l’autre configuration de test évalue à true. Cependant, pour la deuxième configuration d’essai, les deux spécifications de champ doivent être vraies pour qu’elles soient évaluées à true: 

apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: important
    type: drop
    drop:
      test:
      - field: .kubernetes.namespace_name
        matches: "^open"
      test:
      - field: .log_type
        matches: "application"
      - field: .kubernetes.pod_name
        notMatches: "my-pod"
# ...
Copy to Clipboard Toggle word wrap

Lorsque le filtre tailleur est configuré, le collecteur de journaux évalue les flux de journaux en fonction des filtres avant le transfert. Le collecteur prune log enregistre en supprimant les champs de faible valeur tels que les annotations de pod.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • Il y a des autorisations d’administrateur.
  • Création d’une ressource personnalisée ClusterLogForwarder (CR).

Procédure

  1. Ajoutez une configuration pour un filtre à la spécification de prune dans le ClusterLogForwarder CR.

    L’exemple suivant montre comment configurer le ClusterLogForwarder CR pour tailler les enregistrements de journal en fonction des chemins de champ:

    Important

    Dans le cas où les deux sont spécifiés, les enregistrements sont taillés en fonction du tableau notIn d’abord, ce qui prime sur le tableau dans le tableau. Après que les enregistrements ont été élagués en utilisant le tableau notIn, ils sont ensuite élagués en utilisant le tableau dans le tableau.

    Exemple ClusterLogForwarder CR

    apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
# ...
spec:
  filters:
  - name: <filter_name>
    type: prune
    1 
    
    prune:
    2 
    
      in: [.kubernetes.annotations, .kubernetes.namespace_id]
    3 
    
      notIn: [.kubernetes,.log_type,.message,."@timestamp"]
    4 
    
  pipelines:
  - name: <pipeline_name>
    5 
    
    filterRefs: ["<filter_name>"]
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indiquez le type de filtre. Le filtre prunes enregistre les enregistrements par champs configurés.
    2
    Spécifiez les options de configuration pour l’application du filtre de pruneaux. Les champs in et notIn sont spécifiés comme des tableaux de chemins de champ délimités par points, qui sont des chemins vers des champs dans les enregistrements de log. Ces chemins peuvent contenir des caractères alpha-numériques et des accents (a-zA-Z0-9_), par exemple, .kubernetes.namespace_name. Lorsque les segments contiennent des caractères en dehors de cette plage, le segment doit être en guillemets, par exemple, .kubernetes.labels.foo.bar-bar/baz.
    3
    Facultatif : Tous les champs spécifiés dans ce tableau sont supprimés de l’enregistrement de journal.
    4
    Facultatif : Tous les champs qui ne sont pas spécifiés dans ce tableau sont supprimés de l’enregistrement de journal.
    5
    Indiquez le pipeline auquel le filtre de prune est appliqué.

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

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

12.3. Filtrage des journaux par métadonnées
Copier lien

Il est possible de filtrer les journaux dans le ClusterLogForwarder CR pour sélectionner ou ignorer tout un flux journal basé sur les métadonnées à l’aide du sélecteur d’entrée. En tant qu’administrateur ou développeur, vous pouvez inclure ou exclure la collection de journaux pour réduire la mémoire et la charge CPU sur le collecteur.

Important

Cette fonctionnalité ne peut être utilisée que si le collecteur vectoriel est configuré dans votre déploiement de journalisation.

Note

le filtrage spec d’entrée est différent du filtrage de contenu. les sélecteurs d’entrée sélectionnent ou ignorent des flux de journaux entiers basés sur les métadonnées source. Les filtres de contenu modifient les flux de journaux pour supprimer et modifier les enregistrements en fonction du contenu de l’enregistrement.

Il est possible d’inclure ou d’exclure les journaux de l’application en fonction de l’espace de noms et du nom du conteneur à l’aide du sélecteur d’entrée.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • Il y a des autorisations d’administrateur.
  • Création d’une ressource personnalisée ClusterLogForwarder (CR).

Procédure

  1. Ajoutez une configuration pour inclure ou exclure les noms d’espace de noms et de conteneurs dans le ClusterLogForwarder CR.

    L’exemple suivant montre comment configurer le ClusterLogForwarder CR pour inclure ou exclure les espaces de noms et les noms de conteneurs:

    Exemple ClusterLogForwarder CR

    apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
# ...
spec:
  inputs:
    - name: mylogs
      application:
        includes:
          - namespace: "my-project"
    1 
    
            container: "my-container"
    2 
    
        excludes:
          - container: "other-container*"
    3 
    
            namespace: "other-namespace"
    4 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indique que les journaux ne sont recueillis qu’à partir de ces espaces de noms.
    2
    Indique que les journaux ne sont recueillis qu’à partir de ces conteneurs.
    3
    Indique le modèle des espaces de noms à ignorer lors de la collecte des journaux.
    4
    Indique l’ensemble des conteneurs à ignorer lors de la collecte des journaux.

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

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

L’option d’exclusion a préséance sur les inclus.

Il est possible d’inclure les journaux des applications en fonction des expressions d’étiquette ou d’une clé d’étiquette correspondante et de ses valeurs à l’aide du sélecteur d’entrée.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • Il y a des autorisations d’administrateur.
  • Création d’une ressource personnalisée ClusterLogForwarder (CR).

Procédure

  1. Ajoutez une configuration pour un filtre à la spécification d’entrée dans le ClusterLogForwarder CR.

    L’exemple suivant montre comment configurer le ClusterLogForwarder CR pour inclure des journaux basés sur des expressions d’étiquettes ou des clés/valeurs d’étiquettes assorties:

    Exemple ClusterLogForwarder CR

    apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
# ...
spec:
  inputs:
    - name: mylogs
      application:
        selector:
          matchExpressions:
          - key: env
    1 
    
            operator: In
    2 
    
            values: [“prod”, “qa”]
    3 
    
          - key: zone
            operator: NotIn
            values: [“east”, “west”]
          matchLabels:
    4 
    
            app: one
            name: app1
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indique la clé d’étiquette pour correspondre.
    2
    Indique l’opérateur. Les valeurs valides incluent: In, NotIn, Exist et NeesNotExist.
    3
    Indique un tableau de valeurs de chaîne. Lorsque la valeur de l’opérateur est soit existante, soit DoesNotExist, le tableau de valeur doit être vide.
    4
    Indique une clé exacte ou un mappage de valeur.

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

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

Il est possible de définir la liste des sources d’audit et d’infrastructure pour collecter les journaux à l’aide du sélecteur d’entrée.

Conditions préalables

  • L’opérateur de journalisation Red Hat OpenShift a été installé.
  • Il y a des autorisations d’administrateur.
  • Création d’une ressource personnalisée ClusterLogForwarder (CR).

Procédure

  1. Ajoutez une configuration pour définir les sources d’audit et d’infrastructure dans ClusterLogForwarder CR.

    L’exemple suivant montre comment configurer le ClusterLogForwarder CR pour définir les sources d’aduit et d’infrastructure:

    Exemple ClusterLogForwarder CR

    apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
# ...
spec:
  inputs:
    - name: mylogs1
      infrastructure:
        sources:
    1 
    
          - node
    - name: mylogs2
      audit:
        sources:
    2 
    
          - kubeAPI
          - openshiftAPI
          - ovn
# ...
    Copy to Clipboard Toggle word wrap

    1
    Indique la liste des sources d’infrastructure à collecter. Les sources valides comprennent:
    • journal de journal du nœud
    • conteneur: Logs des charges de travail déployées dans les espaces de noms
    2
    Indique la liste des sources d’audit à collecter. Les sources valides comprennent:
    • kubeAPI: Logs des serveurs de l’API Kubernetes
    • API openshift: Logs à partir des serveurs de l’API OpenShift
    • audité : Logs d’un service audité de nœuds
    • ovn: Logs à partir d’un service de réseau virtuel ouvert

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

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

Chapitre 13. Calendrier des ressources
Copier lien

Le sélecteur de nœuds spécifie une carte des paires de clés/valeurs qui sont définies à l’aide d’étiquettes personnalisées sur les nœuds et les sélecteurs spécifiés dans les pods.

Afin que la gousse puisse fonctionner sur un nœud, la gousse doit avoir le même sélecteur de nœud clé/valeur que l’étiquette sur le nœud.

13.1.1. À propos des sélecteurs de nœuds
Copier lien

Il est possible d’utiliser des sélecteurs de nœuds sur les gousses et les étiquettes sur les nœuds pour contrôler l’endroit où la gousse est programmée. Avec les sélecteurs de nœuds, Red Hat OpenShift Service sur AWS programme les pods sur les nœuds qui contiennent des étiquettes correspondantes.

Il est possible d’utiliser un sélecteur de nœuds pour placer des pods spécifiques sur des nœuds spécifiques, des sélecteurs de nœuds à l’échelle du cluster pour placer de nouveaux pods sur des nœuds spécifiques n’importe où dans le cluster, et des sélecteurs de nœuds de projet pour placer de nouveaux pods dans un projet sur des nœuds spécifiques.

En tant qu’administrateur de cluster, par exemple, vous pouvez créer une infrastructure où les développeurs d’applications peuvent déployer des pods uniquement sur les nœuds les plus proches de leur emplacement géographique en incluant un sélecteur de nœuds dans chaque pod qu’ils créent. Dans cet exemple, le cluster se compose de cinq centres de données répartis dans deux régions. Aux États-Unis, étiquetez les nœuds comme nous-est, nous-central, ou nous-ouest. Dans la région Asie-Pacifique (APAC), étiqueter les nœuds comme apac-est ou apac-west. Les développeurs peuvent ajouter un sélecteur de nœuds aux gousses qu’ils créent pour s’assurer que les gousses sont programmées sur ces nœuds.

La pod n’est pas programmée si l’objet Pod contient un sélecteur de nœuds, mais le nœud a une étiquette correspondante.

Important

Lorsque vous utilisez les sélecteurs de nœuds et l’affinité des nœuds dans la même configuration, les règles suivantes contrôlent le placement des pod sur les nœuds:

  • Lorsque vous configurez à la fois nodeSelector et nodeAffinity, les deux conditions doivent être remplies pour que la gousse soit programmée sur un nœud candidat.
  • Lorsque vous spécifiez plusieurs nodeSelectorTerms associés aux types nodeAffinity, le pod peut être programmé sur un nœud si l’un des nodeSelectorTerms est satisfait.
  • Lorsque vous spécifiez plusieurs correspondancesExpressions associées à nodeSelectorTerms, le pod ne peut être programmé sur un nœud que si toutes les correspondancesExpressions sont satisfaites.
Les sélecteurs de nœuds sur des gousses et nœuds spécifiques

Il est possible de contrôler quel nœud est programmé en utilisant des sélecteurs de nœuds et des étiquettes.

Afin d’utiliser des sélecteurs de nœuds et des étiquettes, d’abord étiqueter le nœud pour éviter que les gousses ne soient décalées, puis ajouter le sélecteur de nœud à la gousse.

Note

Il n’est pas possible d’ajouter un sélecteur de nœuds directement à un pod existant. Il faut étiqueter l’objet qui contrôle la pod, comme la configuration de déploiement.

À titre d’exemple, l’objet Node suivant a la région:

Échantillon d’objet Node avec une étiquette

kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-131-14.ec2.internal
  selfLink: /api/v1/nodes/ip-10-0-131-14.ec2.internal
  uid: 7bc2580a-8b8e-11e9-8e01-021ab4174c74
  resourceVersion: '478704'
  creationTimestamp: '2019-06-10T14:46:08Z'
  labels:
    kubernetes.io/os: linux
    topology.kubernetes.io/zone: us-east-1a
    node.openshift.io/os_version: '4.5'
    node-role.kubernetes.io/worker: ''
    topology.kubernetes.io/region: us-east-1
    node.openshift.io/os_id: rhcos
    node.kubernetes.io/instance-type: m4.large
    kubernetes.io/hostname: ip-10-0-131-14
    kubernetes.io/arch: amd64
    region: east
1 

    type: user-node
#...
Copy to Clipboard Toggle word wrap

1
Étiquettes pour correspondre au sélecteur de nœud de pod.

A pod a le type: user-node,région: sélecteur de nœud est:

Échantillon d’objet Pod avec sélecteurs de nœuds

apiVersion: v1
kind: Pod
metadata:
  name: s1
#...
spec:
  nodeSelector:
1 

    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

1
Les sélecteurs de nœuds correspondent à l’étiquette du nœud. Le nœud doit avoir une étiquette pour chaque sélecteur de nœud.

Lorsque vous créez le pod à l’aide de l’exemple pod spec, il peut être programmé sur le nœud d’exemple.

Les sélecteurs par défaut de nœuds à l’échelle du cluster

Avec les sélecteurs de nœuds larges par défaut, lorsque vous créez un pod dans ce cluster, Red Hat OpenShift Service sur AWS ajoute les sélecteurs de nœuds par défaut au pod et programme le pod sur les nœuds avec des étiquettes correspondantes.

À titre d’exemple, l’objet Scheduler suivant a la région par défaut de cluster=Est et type=node-utilisateur sélecteur:

Exemple d’opérateur de programmeur de ressources personnalisées

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
#...
spec:
  defaultNodeSelector: type=user-node,region=east
#...
Copy to Clipboard Toggle word wrap

Dans ce cluster, un nœud a le type= user-node,region=East Labels:

Exemple d’objet Node

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
#...
  labels:
    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

Exemple Pod objet avec un sélecteur de nœud

apiVersion: v1
kind: Pod
metadata:
  name: s1
#...
spec:
  nodeSelector:
    region: east
#...
Copy to Clipboard Toggle word wrap

Lorsque vous créez le pod à l’aide de l’exemple pod spec dans le cluster d’exemples, le pod est créé avec le sélecteur de nœud de cluster-large et est programmé sur le nœud étiqueté:

Exemple de pod list avec la gousse sur le nœud étiqueté

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>
Copy to Clipboard Toggle word wrap

Note

Lorsque le projet où vous créez le pod a un sélecteur de nœud de projet, ce sélecteur prend la préférence sur un sélecteur de nœuds à l’échelle du cluster. Le pod n’est pas créé ou programmé si le pod n’a pas le sélecteur de nœud de projet.

Les sélecteurs de nœuds de projet

Avec les sélecteurs de nœuds de projet, lorsque vous créez un pod dans ce projet, Red Hat OpenShift Service sur AWS ajoute les sélecteurs de nœuds au pod et programme les pods sur un nœud avec des étiquettes correspondantes. Lorsqu’il existe un sélecteur de nœuds par défaut à l’échelle du cluster, un sélecteur de nœud de projet prend la préférence.

À titre d’exemple, le projet suivant a le sélecteur de nœud région=Est:

Exemple d’objet Namespace

apiVersion: v1
kind: Namespace
metadata:
  name: east-region
  annotations:
    openshift.io/node-selector: "region=east"
#...
Copy to Clipboard Toggle word wrap

Le nœud suivant a le type=nœud utilisateur,région=est étiquettes:

Exemple d’objet Node

apiVersion: v1
kind: Node
metadata:
  name: ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4
#...
  labels:
    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

Lorsque vous créez le pod à l’aide de l’exemple pod spec dans ce projet d’exemple, le pod est créé avec les sélecteurs de nœud de projet et est programmé sur le nœud étiqueté:

Exemple d’objet Pod

apiVersion: v1
kind: Pod
metadata:
  namespace: east-region
#...
spec:
  nodeSelector:
    region: east
    type: user-node
#...
Copy to Clipboard Toggle word wrap

Exemple de pod list avec la gousse sur le nœud étiqueté

NAME     READY   STATUS    RESTARTS   AGE   IP           NODE                                       NOMINATED NODE   READINESS GATES
pod-s1   1/1     Running   0          20s   10.131.2.6   ci-ln-qg1il3k-f76d1-hlmhl-worker-b-df2s4   <none>           <none>
Copy to Clipboard Toggle word wrap

Dans le projet, un pod n’est pas créé ou programmé si le pod contient différents sélecteurs de nœuds. À titre d’exemple, si vous déployez la pod suivante dans le projet d’exemple, il n’est pas créé:

Exemple d’objet Pod avec un sélecteur de nœud invalide

apiVersion: v1
kind: Pod
metadata:
  name: west-region
#...
spec:
  nodeSelector:
    region: west
#...
Copy to Clipboard Toggle word wrap

13.1.2. Loki Pod placement
Copier lien

Il est possible de contrôler les nœuds sur lesquels les pods Loki s’exécutent et d’empêcher d’autres charges de travail d’utiliser ces nœuds, en utilisant des tolérances ou des sélecteurs de nœuds sur les pods.

Avec la ressource personnalisée LokiStack (CR) vous pouvez appliquer des tolérances aux pods de log store et appliquer des taintes à un nœud avec la spécification du nœud. La tainte sur un nœud est une paire key:value qui ordonne au nœud de repousser toutes les gousses qui ne permettent pas la tainte. En utilisant une paire clé:valeur spécifique qui n’est pas sur d’autres gousses garantit que seuls les pods de log store peuvent fonctionner sur ce nœud.

Exemple LokiStack avec sélecteurs de nœuds

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
1 

      nodeSelector:
        node-role.kubernetes.io/infra: ""
2 

    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...
Copy to Clipboard Toggle word wrap

1
Indique le type de pod de composant qui s’applique au sélecteur de nœud.
2
Indique les pods qui sont déplacés vers des nœuds contenant l’étiquette définie.

Dans la configuration de l’exemple précédent, tous les pods Loki sont déplacés vers des nœuds contenant l’étiquette node-role.kubernetes.io/infra: "".

Exemple LokiStack CR avec sélecteurs de nœuds et tolérances

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...
Copy to Clipboard Toggle word wrap

Afin de configurer les champs nodeSelector et tolerations du LokiStack (CR), vous pouvez utiliser la commande oc explicative pour afficher la description et les champs d’une ressource particulière: 

$ oc explain lokistack.spec.template
Copy to Clipboard Toggle word wrap

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...
Copy to Clipboard Toggle word wrap

Afin d’obtenir des informations plus détaillées, vous pouvez ajouter un champ spécifique: 

$ oc explain lokistack.spec.template.compactor
Copy to Clipboard Toggle word wrap

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...
Copy to Clipboard Toggle word wrap

Les administrateurs peuvent modifier les ressources ou la planification du collecteur en créant une ressource personnalisée ClusterLogging (CR) qui se trouve dans le même espace de noms et a le même nom que le ClusterLogForwarder CR qu’il prend en charge.

Les strophes applicables au ClusterLogging CR lors de l’utilisation de plusieurs transmetteurs de journaux dans un déploiement sont l’état de gestion et la collecte. Les autres strophes sont ignorées.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • La version 5.8 ou plus récente de Red Hat OpenShift Logging Operator a été installée.
  • ClusterLogForwarder CR a créé un ClusterLogForwarder CR.

Procédure

  1. Créez un ClusterLogging CR qui prend en charge votre ClusterLogForwarder CR existant:

    Exemple ClusterLogging CR YAML

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name:  <name>
    1 
    
  namespace: <namespace>
    2 
    
spec:
  managementState: "Managed"
  collection:
    type: "vector"
    tolerations:
    - key: "logging"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 1Gi
    nodeSelector:
      collector: needed
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le nom doit être le même nom que le ClusterLogForwarder CR.
    2
    L’espace de noms doit être le même espace de noms que le ClusterLogForwarder CR.

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

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

13.1.4. Affichage des pods de collecteurs de journalisation
Copier lien

Il est possible d’afficher les pods de collecteurs de journalisation et les nœuds correspondants sur lesquels ils sont en cours d’exécution.

Procédure

  • Exécutez la commande suivante dans un projet pour afficher les pods de collecte de journalisation et leurs détails: 

    $ oc get pods --selector component=collector -o wide -n <project_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

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

Les taintes et les tolérances permettent au nœud de contrôler quels pods doivent (ou ne devraient pas) être programmés sur eux.

13.2.1. Comprendre les taintes et les tolérances
Copier lien

La tainte permet à un nœud de refuser la programmation d’une gousse à moins que cette gousse n’ait une tolérance correspondante.

Appliquez des taintes à un nœud via la spécification Node (NodeSpec) et appliquez des tolérances à un pod via la spécification Pod (PodSpec). Lorsque vous appliquez une tainte sur un nœud, le programmeur ne peut pas placer une gousse sur ce nœud à moins que la gousse ne puisse tolérer la tainte.

Exemple taint dans une spécification de nœud

apiVersion: v1
kind: Node
metadata:
  name: my-node
#...
spec:
  taints:
  - effect: NoExecute
    key: key1
    value: value1
#...
Copy to Clipboard Toggle word wrap

Exemple de tolérance dans un Pod spec

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
#...
spec:
  tolerations:
  - key: "key1"
    operator: "Equal"
    value: "value1"
    effect: "NoExecute"
    tolerationSeconds: 3600
#...
Copy to Clipboard Toggle word wrap

Les taintes et les tolérances se composent d’une clé, d’une valeur et d’un effet.

Expand
Tableau 13.1. Composants de tainte et de tolérance
Le paramètreDescription

la clé

La clé est n’importe quelle chaîne, jusqu’à 253 caractères. La clé doit commencer par une lettre ou un nombre, et peut contenir des lettres, des chiffres, des traits d’union, des points et des accents.

la valeur

La valeur est n’importe quelle chaîne, jusqu’à 63 caractères. La valeur doit commencer par une lettre ou un nombre, et peut contenir des lettres, des chiffres, des traits d’union, des points et des accents.

effet

L’effet est l’un des suivants:

Expand

Calendrier [1]

  • Les nouvelles gousses qui ne correspondent pas à la tainte ne sont pas programmées sur ce nœud.
  • Des gousses existantes sur le nœud restent.

La préférenceNoSchedule

  • De nouvelles gousses qui ne correspondent pas à la tainte peuvent être programmées sur ce nœud, mais le planificateur essaie de ne pas le faire.
  • Des gousses existantes sur le nœud restent.

Le noexecute

  • Les nouvelles gousses qui ne correspondent pas à la tainte ne peuvent pas être programmées sur ce nœud.
  • Les gousses existantes sur le nœud qui n’ont pas de tolérance correspondante sont supprimées.

exploitant

Expand

Égale

Les paramètres clé/valeur/effet doivent correspondre. C’est la valeur par défaut.

Existe

Les paramètres clés/effets doivent correspondre. Il faut laisser un paramètre de valeur vierge, qui correspond à n’importe quel paramètre.

  1. Lorsque vous ajoutez un taint NoSchedule à un nœud de plan de contrôle, le nœud doit avoir le node-role.kubernetes.io/master=:NoSchedule taint, qui est ajouté par défaut.

    À titre d’exemple: 

    apiVersion: v1
kind: Node
metadata:
  annotations:
    machine.openshift.io/machine: openshift-machine-api/ci-ln-62s7gtb-f76d1-v8jxv-master-0
    machineconfiguration.openshift.io/currentConfig: rendered-master-cdc1ab7da414629332cc4c3926e6e59c
  name: my-node
#...
spec:
  taints:
  - effect: NoSchedule
    key: node-role.kubernetes.io/master
#...
    Copy to Clipboard Toggle word wrap

A tolérance correspond à une tainte:

  • Lorsque le paramètre de l’opérateur est défini sur Equal:

    • les paramètres clés sont les mêmes;
    • les paramètres de valeur sont les mêmes;
    • les paramètres d’effet sont les mêmes.

  • Lorsque le paramètre opérateur est défini sur Exist:

    • les paramètres clés sont les mêmes;
    • les paramètres d’effet sont les mêmes.

Les taintes suivantes sont intégrées dans Red Hat OpenShift Service sur AWS:

  • node.kubernetes.io/not-ready: Le nœud n’est pas prêt. Cela correspond à la condition du nœud Ready=False.
  • node.kubernetes.io/unreachable: Le nœud est inaccessible à partir du contrôleur du nœud. Cela correspond à la condition du nœud Ready=Inknown.
  • node.kubernetes.io/Memory-pression: Le nœud a des problèmes de pression de mémoire. Cela correspond à la condition du nœud MemoryPressure=True.
  • node.kubernetes.io/disk-pression: Le nœud a des problèmes de pression du disque. Cela correspond à la condition du nœud DiskPressure=True.
  • node.kubernetes.io/network-indisponible: Le réseau de nœuds n’est pas disponible.
  • node.kubernetes.io/Unschedulable: Le nœud est imprévu.
  • node.cloudprovider.kubernetes.io/non initialisé: Lorsque le contrôleur de nœud est démarré avec un fournisseur de cloud externe, cette tainte est définie sur un nœud pour le marquer comme inutilisable. Après qu’un contrôleur du cloud-controller-manager initialise ce nœud, le kubelet enlève cette tainte.

  • node.kubernetes.io/pid-pression: Le nœud a une pression pid. Cela correspond à la condition du nœud PIDPressure=True.

    Important

    Le service Red Hat OpenShift sur AWS ne définit pas d’éviction pid.available par défaut.

13.2.2. Loki Pod placement
Copier lien

Il est possible de contrôler les nœuds sur lesquels les pods Loki s’exécutent et d’empêcher d’autres charges de travail d’utiliser ces nœuds, en utilisant des tolérances ou des sélecteurs de nœuds sur les pods.

Avec la ressource personnalisée LokiStack (CR) vous pouvez appliquer des tolérances aux pods de log store et appliquer des taintes à un nœud avec la spécification du nœud. La tainte sur un nœud est une paire key:value qui ordonne au nœud de repousser toutes les gousses qui ne permettent pas la tainte. En utilisant une paire clé:valeur spécifique qui n’est pas sur d’autres gousses garantit que seuls les pods de log store peuvent fonctionner sur ce nœud.

Exemple LokiStack avec sélecteurs de nœuds

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
1 

      nodeSelector:
        node-role.kubernetes.io/infra: ""
2 

    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
# ...
Copy to Clipboard Toggle word wrap

1
Indique le type de pod de composant qui s’applique au sélecteur de nœud.
2
Indique les pods qui sont déplacés vers des nœuds contenant l’étiquette définie.

Dans la configuration de l’exemple précédent, tous les pods Loki sont déplacés vers des nœuds contenant l’étiquette node-role.kubernetes.io/infra: "".

Exemple LokiStack CR avec sélecteurs de nœuds et tolérances

apiVersion: loki.grafana.com/v1
kind: LokiStack
metadata:
  name: logging-loki
  namespace: openshift-logging
spec:
# ...
  template:
    compactor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    distributor:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    indexGateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ingester:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    querier:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    queryFrontend:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    ruler:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
    gateway:
      nodeSelector:
        node-role.kubernetes.io/infra: ""
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        value: reserved
      - effect: NoExecute
        key: node-role.kubernetes.io/infra
        value: reserved
# ...
Copy to Clipboard Toggle word wrap

Afin de configurer les champs nodeSelector et tolerations du LokiStack (CR), vous pouvez utiliser la commande oc explicative pour afficher la description et les champs d’une ressource particulière: 

$ oc explain lokistack.spec.template
Copy to Clipboard Toggle word wrap

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: template <Object>

DESCRIPTION:
     Template defines the resource/limits/tolerations/nodeselectors per
     component

FIELDS:
   compactor	<Object>
     Compactor defines the compaction component spec.

   distributor	<Object>
     Distributor defines the distributor component spec.
...
Copy to Clipboard Toggle word wrap

Afin d’obtenir des informations plus détaillées, vous pouvez ajouter un champ spécifique: 

$ oc explain lokistack.spec.template.compactor
Copy to Clipboard Toggle word wrap

Exemple de sortie

KIND:     LokiStack
VERSION:  loki.grafana.com/v1

RESOURCE: compactor <Object>

DESCRIPTION:
     Compactor defines the compaction component spec.

FIELDS:
   nodeSelector	<map[string]string>
     NodeSelector defines the labels required by a node to schedule the
     component onto it.
...
Copy to Clipboard Toggle word wrap

Les pods collector de journaux par défaut ont la configuration de tolérance suivante: 

apiVersion: v1
kind: Pod
metadata:
  name: collector-example
  namespace: openshift-logging
spec:
# ...
  collection:
    type: vector
    tolerations:
    - effect: NoSchedule
      key: node-role.kubernetes.io/master
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/disk-pressure
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/not-ready
      operator: Exists
    - effect: NoExecute
      key: node.kubernetes.io/unreachable
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/memory-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/pid-pressure
      operator: Exists
    - effect: NoSchedule
      key: node.kubernetes.io/unschedulable
      operator: Exists
# ...
Copy to Clipboard Toggle word wrap

Conditions préalables

  • Le Red Hat OpenShift Logging Operator et OpenShift CLI (oc) ont été installés.

Procédure

  1. Ajoutez un taint à un nœud où vous voulez enregistrer des pods collector pour programmer les pods de collecte de journalisation en exécutant la commande suivante: 

    $ oc adm taint nodes <node_name> <key>=<value>:<effect>
    Copy to Clipboard Toggle word wrap

    Commande d’exemple

    $ oc adm taint nodes node1 collector=node:NoExecute
    Copy to Clipboard Toggle word wrap

    Cet exemple place une tainte sur node1 qui a le collecteur de clés, le nœud de valeur et l’effet taint NoExecute. Il faut utiliser l’effet NoExecute taint. Le programme noexecute uniquement les pods qui correspondent à la tainte et supprime les pods existants qui ne correspondent pas.

  2. Éditer la strophe de collection de la ressource personnalisée ClusterLogging (CR) pour configurer une tolérance pour les pods de collecte de journalisation: 

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
# ...
spec:
# ...
  collection:
    type: vector
    tolerations:
    - key: collector
    1 
    
      operator: Exists
    2 
    
      effect: NoExecute
    3 
    
      tolerationSeconds: 6000
    4 
    
    resources:
      limits:
        memory: 2Gi
      requests:
        cpu: 100m
        memory: 1Gi
# ...
    Copy to Clipboard Toggle word wrap
    1
    Indiquez la clé que vous avez ajoutée au nœud.
    2
    Indiquez l’opérateur existant pour exiger que les paramètres clés/valeur/effet correspondent.
    3
    Indiquez l’effet NoExecute.
    4
    En option, spécifiez le paramètre de toléranceSeconds pour définir combien de temps un pod peut rester lié à un nœud avant d’être expulsé.

Cette tolérance correspond à la tainte créée par la commande oc adm taint. La gousse avec cette tolérance peut être programmée sur le nœud1.

Les administrateurs peuvent modifier les ressources ou la planification du collecteur en créant une ressource personnalisée ClusterLogging (CR) qui se trouve dans le même espace de noms et a le même nom que le ClusterLogForwarder CR qu’il prend en charge.

Les strophes applicables au ClusterLogging CR lors de l’utilisation de plusieurs transmetteurs de journaux dans un déploiement sont l’état de gestion et la collecte. Les autres strophes sont ignorées.

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • La version 5.8 ou plus récente de Red Hat OpenShift Logging Operator a été installée.
  • ClusterLogForwarder CR a créé un ClusterLogForwarder CR.

Procédure

  1. Créez un ClusterLogging CR qui prend en charge votre ClusterLogForwarder CR existant:

    Exemple ClusterLogging CR YAML

    apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name:  <name>
    1 
    
  namespace: <namespace>
    2 
    
spec:
  managementState: "Managed"
  collection:
    type: "vector"
    tolerations:
    - key: "logging"
      operator: "Exists"
      effect: "NoExecute"
      tolerationSeconds: 6000
    resources:
      limits:
        memory: 1Gi
      requests:
        cpu: 100m
        memory: 1Gi
    nodeSelector:
      collector: needed
# ...
    Copy to Clipboard Toggle word wrap

    1
    Le nom doit être le même nom que le ClusterLogForwarder CR.
    2
    L’espace de noms doit être le même espace de noms que le ClusterLogForwarder CR.

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

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

13.2.5. Affichage des pods de collecteurs de journalisation
Copier lien

Il est possible d’afficher les pods de collecteurs de journalisation et les nœuds correspondants sur lesquels ils sont en cours d’exécution.

Procédure

  • Exécutez la commande suivante dans un projet pour afficher les pods de collecte de journalisation et leurs détails: 

    $ oc get pods --selector component=collector -o wide -n <project_name>
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

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

Chapitre 14. Désinstaller Logging
Copier lien

Il est possible de supprimer l’enregistrement de votre Red Hat OpenShift Service sur le cluster AWS en supprimant les opérateurs installés et les ressources personnalisées (CR) associées.

14.1. Désinstallation de la journalisation
Copier lien

Il est possible d’arrêter d’agréger les journaux en supprimant le Red Hat OpenShift Logging Operator et la ressource personnalisée ClusterLogging (CR).

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Accès à la perspective administrateur du service Red Hat OpenShift sur la console web AWS.

Procédure

  1. Allez à la page Administration → Définitions de ressources personnalisées, puis cliquez sur ClusterLogging.
  2. Dans la page Détails de la définition des ressources personnalisées, cliquez sur Instances.
  3. Cliquez sur le menu Options à côté de l’instance, puis cliquez sur Supprimer ClusterLogging.
  4. Accédez à la page Administration → Définitions de ressources personnalisées.

  5. Cliquez sur le menu Options à côté de ClusterLogging, puis sélectionnez Supprimer la définition des ressources personnalisées.

    Avertissement

    La suppression du ClusterLogging CR ne supprime pas les revendications de volume persistants (PVC). Afin de supprimer les PVC restants, les volumes persistants (PV) et les données associées, vous devez prendre d’autres mesures. La libération ou la suppression des PVC peut supprimer les PV et causer la perte de données.

  6. Lorsque vous avez créé un ClusterLogForwarder CR, cliquez sur le menu Options à côté de ClusterLogForwarder, puis cliquez sur Supprimer la définition de ressource personnalisée.
  7. Accédez à la page Opérateurs installés → Opérateurs installés.
  8. Cliquez sur le menu Options à côté de l’opérateur de journalisation Red Hat OpenShift, puis cliquez sur Désinstaller l’opérateur.

  9. Facultatif: Supprimer le projet openshift-logging.

    Avertissement

    La suppression du projet openshift-logging supprime tout dans cet espace de noms, y compris toute revendication de volume persistant (PVC). Dans le cas où vous souhaitez conserver les données de journalisation, ne supprimez pas le projet openshift-logging.

    1. Allez à la page Accueil → Projets.
    2. Cliquez sur le menu Options à côté du projet openshift-logging, puis cliquez sur Supprimer le projet.
    3. Confirmez la suppression en tapant openshift-logging dans la boîte de dialogue, puis cliquez sur Supprimer.

14.2. Suppression des PVCs d’exploitation forestière
Copier lien

Afin de conserver les revendications de volume persistantes (PVC) pour la réutilisation avec d’autres gousses, conservez les étiquettes ou les noms de PVC dont vous avez besoin pour récupérer les PVC. Lorsque vous ne voulez pas conserver les PVC, vous pouvez les supprimer. Lorsque vous souhaitez récupérer de l’espace de stockage, vous pouvez également supprimer les volumes persistants (PV).

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Accès à la perspective administrateur du service Red Hat OpenShift sur la console web AWS.

Procédure

  1. Allez à la page Stockage → Réclamations de volume persistant.
  2. Cliquez sur le menu Options à côté de chaque PVC et sélectionnez Supprimer la revendication de volume persistant.

14.3. Désinstallation de Loki
Copier lien

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Accès à la perspective administrateur du service Red Hat OpenShift sur la console web AWS.
  • Lorsque vous n’avez pas déjà supprimé le Red Hat OpenShift Logging Operator et les ressources connexes, vous avez supprimé les références à LokiStack de la ressource personnalisée ClusterLogging.

Procédure

  1. Allez à la page Administration → Définitions de ressources personnalisées, puis cliquez sur LokiStack.
  2. Dans la page Détails de la définition des ressources personnalisées, cliquez sur Instances.
  3. Cliquez sur le menu Options à côté de l’instance, puis cliquez sur Supprimer LokiStack.
  4. Accédez à la page Administration → Définitions de ressources personnalisées.
  5. Cliquez sur le menu Options à côté de LokiStack, puis sélectionnez Supprimer la définition des ressources personnalisées.
  6. Effacer le secret de stockage de l’objet.
  7. Accédez à la page Opérateurs installés → Opérateurs installés.
  8. Cliquez sur le menu Options à côté de l’opérateur Loki, puis cliquez sur Désinstaller l’opérateur.

  9. Facultatif: Supprimer le projet openshift-operators-redhat.

    Important

    Il ne faut pas supprimer le projet openshift-operators-redhat si d’autres opérateurs mondiaux sont installés dans cet espace de noms.

    1. Allez à la page Accueil → Projets.
    2. Cliquez sur le menu Options à côté du projet openshift-operators-redhat, puis cliquez sur Supprimer le projet.
    3. Confirmez la suppression en tapant openshift-operators-redhat dans la boîte de dialogue, puis cliquez sur Supprimer.

14.4. Désinstaller Elasticsearch
Copier lien

Conditions préalables

  • Il y a des autorisations d’administrateur.
  • Accès à la perspective administrateur du service Red Hat OpenShift sur la console web AWS.
  • Lorsque vous n’avez pas déjà supprimé le Red Hat OpenShift Logging Operator et les ressources connexes, vous devez supprimer les références à Elasticsearch de la ressource personnalisée ClusterLogging.

Procédure

  1. Allez à la page Administration → Définitions de ressources personnalisées, puis cliquez sur Elasticsearch.
  2. Dans la page Détails de la définition des ressources personnalisées, cliquez sur Instances.
  3. Cliquez sur le menu Options à côté de l’instance, puis cliquez sur Supprimer Elasticsearch.
  4. Accédez à la page Administration → Définitions de ressources personnalisées.
  5. Cliquez sur le menu Options à côté d’Elasticsearch et sélectionnez Supprimer la définition de ressources personnalisées.
  6. Effacer le secret de stockage de l’objet.
  7. Accédez à la page Opérateurs installés → Opérateurs installés.
  8. Cliquez sur le menu Options à côté de l’opérateur OpenShift Elasticsearch, puis cliquez sur Désinstaller l’opérateur.

  9. Facultatif: Supprimer le projet openshift-operators-redhat.

    Important

    Il ne faut pas supprimer le projet openshift-operators-redhat si d’autres opérateurs mondiaux sont installés dans cet espace de noms.

    1. Allez à la page Accueil → Projets.
    2. Cliquez sur le menu Options à côté du projet openshift-operators-redhat, puis cliquez sur Supprimer le projet.
    3. Confirmez la suppression en tapant openshift-operators-redhat dans la boîte de dialogue, puis cliquez sur Supprimer.

Les administrateurs de clusters peuvent supprimer les opérateurs installés d’un espace de noms sélectionné en utilisant le CLI.

Conditions préalables

  • Grâce à un compte doté d’autorisations d’administration dédiées, vous avez accès à un service Red Hat OpenShift sur AWS.
  • L’OpenShift CLI (oc) est installé sur votre poste de travail.

Procédure

  1. Assurez-vous que la dernière version de l’opérateur souscrit (par exemple, l’opérateur sans serveur) est identifiée dans le champ CSV actuel. 

    $ oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

      currentCSV: serverless-operator.v1.28.0
    Copy to Clipboard Toggle word wrap

  2. Effacer l’abonnement (par exemple, l’opérateur sans serveur): 

    $ oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    subscription.operators.coreos.com "serverless-operator" deleted
    Copy to Clipboard Toggle word wrap

  3. Effacer le CSV pour l’opérateur dans l’espace de noms cible en utilisant la valeur actuelleCSV de l’étape précédente: 

    $ oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless
    Copy to Clipboard Toggle word wrap

    Exemple de sortie

    clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" deleted
    Copy to Clipboard Toggle word wrap

Chapitre 15. Champs d’enregistrement de journaux
Copier lien

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.

Le type de données

le texte

Exemple de valeur

HEUREUX

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.

Le type de données

groupe de travail

Exemple de valeur

carte[message:démarrage d’un travailleur fluide pid=21631 ppid=21618 travailleur=0 pid:21631 ppid:21618 travailleur:0]

@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 type de données

date

Exemple de valeur

2015-01-24 14:06:05.071000000 Z

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.

Le type de données

le mot-clé

ipaddr4

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

Le type de données

IP

ipaddr6

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

Le type de données

IP

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:

  • 0 = Emerg, le système est inutilisable.
  • 1 = alerte, l’action doit être prise immédiatement.
  • 2 = conditions critiques.
  • 3 = erreur, conditions d’erreur.
  • 4 = avertissement, conditions d’avertissement.
  • 5 = remarque, condition normale mais significative.
  • 6 = info, information.
  • 7 = débogage, messages de niveau débogage.

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

  • 8 = trace, les messages de niveau de trace, qui sont plus verbeux que les messages de débogue.
  • 9 = inconnu, lorsque le système d’enregistrement obtient une valeur, il ne reconnaît pas.

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 type de données

le mot-clé

Exemple de valeur

infos

le PID

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

Le type de données

le mot-clé

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.

Le type de données

le mot-clé

Chapitre 16. étiquettes
Copier lien

En option. Liste définie par l’opérateur des balises placées sur chaque journal par le collecteur ou le normalisateur. La charge utile peut être une chaîne avec des jetons de chaîne délimités dans l’espace ou une liste JSON de jetons de chaîne.

Le type de données

le texte

fichier

Le chemin vers le fichier journal à partir duquel le collecteur lit cette entrée de journal. Il s’agit normalement d’un chemin dans le système de fichiers /var/log d’un nœud de cluster.

Le type de données

le texte

compensation

La valeur de compensation. Il peut représenter des octets au début de la ligne de journal dans le fichier (zéro ou un seul) ou des numéros de ligne de journal (zéro ou un seul), tant que les valeurs augmentent strictement monotonement dans le contexte d’un seul fichier journal. Les valeurs sont autorisées à envelopper, représentant une nouvelle version du fichier journal (rotation).

Le type de données

long

Chapitre 17. Kubernetes
Copier lien

L’espace de noms pour les métadonnées spécifiques à Kubernetes

Le type de données

groupe de travail

17.1. Kubernetes.pod_name
Copier lien

Le nom du pod

Le type de données

le mot-clé

17.2. Kubernetes.pod_id
Copier lien

L’identifiant Kubernetes du pod

Le type de données

le mot-clé

17.3. Kubernetes.namespace_name
Copier lien

Le nom de l’espace de noms dans Kubernetes

Le type de données

le mot-clé

17.4. Kubernetes.namespace_id
Copier lien

L’ID de l’espace de noms dans Kubernetes

Le type de données

le mot-clé

17.5. Kubernetes.host
Copier lien

Le nom du nœud Kubernetes

Le type de données

le mot-clé

17.6. Kubernetes.container_name
Copier lien

Le nom du conteneur dans Kubernetes

Le type de données

le mot-clé

17.7. Kubernetes.annotations
Copier lien

Annotations associées à l’objet Kubernetes

Le type de données

groupe de travail

17.8. Kubernetes.labels
Copier lien

Étiquettes présentes sur le Pod original de Kubernetes

Le type de données

groupe de travail

17.9. Kubernetes.event
Copier lien

L’événement Kubernetes obtenu à partir de l’API principale de Kubernetes. Cette description d’événement suit vaguement le type Event in Event v1 core.

Le type de données

groupe de travail

17.9.1. Kubernetes.event.verb
Copier lien

Le type d’événement, ADDED, MODIFIED, ou DELETED

Le type de données

le mot-clé

Exemple de valeur

AJOUTÉ

17.9.2. Kubernetes.event.metadata
Copier lien

Informations relatives à l’emplacement et à l’heure de la création de l’événement

Le type de données

groupe de travail

17.9.2.1. Kubernetes.event.metadata.name
Copier lien

Le nom de l’objet qui a déclenché la création de l’événement

Le type de données

le mot-clé

Exemple de valeur

Java-mainclass-1.14d888a4cfc24890

17.9.2.2. Kubernetes.event.metadata.namespace
Copier lien

Le nom de l’espace de noms où l’événement a eu lieu à l’origine. A noter qu’il diffère de kubernetes.namespace_name, qui est l’espace de noms où l’application eventrouter est déployée.

Le type de données

le mot-clé

Exemple de valeur

défaut par défaut

17.9.2.4. Kubernetes.event.metadata.uid
Copier lien

L’identifiant unique de l’événement

Le type de données

le mot-clé

Exemple de valeur

d828ac69-7b58-11e7-9cf5-5254002f560c

17.9.2.5. Kubernetes.event.metadata.resourceVersion
Copier lien

Chaîne qui identifie la version interne du serveur de l’événement. Les clients peuvent utiliser cette chaîne pour déterminer quand les objets ont changé.

Le type de données

entier

Exemple de valeur

311987

17.9.3. Kubernetes.event.impliquéObjet
Copier lien

L’objet de l’événement.

Le type de données

groupe de travail

17.9.3.1. Kubernetes.event.impliquéObject.kind
Copier lien

Le type d’objet

Le type de données

le mot-clé

Exemple de valeur

Contrôleur de réplication

17.9.3.2. Kubernetes.event.inimpllvedObject.namespace
Copier lien

Le nom de l’espace de noms de l’objet impliqué. Il peut être différent de kubernetes.namespace_name, qui est l’espace de noms où l’application eventrouter est déployée.

Le type de données

le mot-clé

Exemple de valeur

défaut par défaut

17.9.3.3. Kubernetes.event.involvedObject.name
Copier lien

Le nom de l’objet qui a déclenché l’événement

Le type de données

le mot-clé

Exemple de valeur

Java-mainclass-1

17.9.3.4. Kubernetes.event.involvedObject.uid
Copier lien

L’identifiant unique de l’objet

Le type de données

le mot-clé

Exemple de valeur

e6bff941-76a8-11e7-8193-5254002f560c

17.9.3.5. Kubernetes.event.impliquéObject.apiVersion
Copier lien

La version de kubernetes master API

Le type de données

le mot-clé

Exemple de valeur

à propos de v1

17.9.3.6. Kubernetes.event.involvedObject.resourceVersion
Copier lien

Chaîne qui identifie la version interne du serveur de la pod qui a déclenché l’événement. Les clients peuvent utiliser cette chaîne pour déterminer quand les objets ont changé.

Le type de données

le mot-clé

Exemple de valeur

308882

17.9.4. Kubernetes.event.reason
Copier lien

Chaîne courte compréhensible par la machine qui donne la raison de générer cet événement

Le type de données

le mot-clé

Exemple de valeur

Création réussie

17.9.5. Kubernetes.event.source_component
Copier lien

Le composant qui a rapporté cet événement

Le type de données

le mot-clé

Exemple de valeur

contrôleur de réplication

17.9.6. Kubernetes.event.firstTimestamp
Copier lien

L’heure à laquelle l’événement a été enregistré pour la première fois

Le type de données

date

Exemple de valeur

2017-08-07 10:11:57.000000000 Z

17.9.7. Kubernetes.event.count
Copier lien

Le nombre de fois que cet événement s’est produit

Le type de données

entier

Exemple de valeur

1

17.9.8. Kubernetes.event.type
Copier lien

Le type d’événement, Normal ou Avertissement. De nouveaux types pourraient être ajoutés à l’avenir.

Le type de données

le mot-clé

Exemple de valeur

La normale

Chapitre 18. À propos de OpenShift
Copier lien

L’espace de noms pour openshift-logging métadonnées spécifiques

Le type de données

groupe de travail

18.1. bienvenue sur OpenShift.labels
Copier lien

Étiquettes ajoutées par la configuration Cluster Log Forwarder

Le type de données

groupe de travail

Chapitre 19. API référence
Copier lien

19.1. 5.6 référence de l’API de journalisation
Copier lien

19.1.1. Enregistrement de la référence de l’API 5.6
Copier lien

19.1.1.1. ClusterLogForwarder
Copier lien

ClusterLogForwarder est une API pour configurer les journaux de transfert.

Configurez le transfert en spécifiant une liste de pipelines, qui passent d’un ensemble d’entrées nommées à un ensemble de sorties nommées.

Il existe des noms d’entrée intégrés pour les catégories de journaux communes, et vous pouvez définir des entrées personnalisées pour effectuer un filtrage supplémentaire.

Il existe un nom de sortie intégré pour le log store openshift par défaut, mais vous pouvez définir vos propres sorties avec une URL et d’autres informations de connexion pour transférer les journaux vers d’autres magasins ou processeurs, à l’intérieur ou à l’extérieur du cluster.

Consultez la documentation sur les champs API pour plus de détails.

Expand
La propriétéLe typeDescription

les spécifications

l’objet

Caractéristiques du comportement souhaité de ClusterLogForwarder

status

l’objet

État du ClusterLogForwarder

19.1.1.1.1. .spec
Copier lien
19.1.1.1.1.1. Description
Copier lien

ClusterLogForwarderSpec définit comment les journaux doivent être transférés vers des cibles distantes.

19.1.1.1.1.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

entrées

le tableau

(facultatif) Les entrées sont nommées filtres pour les messages de journal à transmettre.

défectuosités de sortie

l’objet

(facultatif) DEPRECATED OutputDefaults spécifient explicitement la configuration de l’expéditeur pour le magasin par défaut.

extrants

le tableau

(facultatif) Les sorties sont nommées destinations pour les messages journaux.

gazoducs

le tableau

Les pipelines transmettent les messages sélectionnés par un ensemble d’entrées à un ensemble de sorties.

19.1.1.1.2. .spec.inputs[]
Copier lien
19.1.1.1.2.1. Description
Copier lien

InputSpec définit un sélecteur de messages journaux.

19.1.1.1.2.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

application

l’objet

(facultatif) L’application, si elle est présente, active un ensemble nommé de journaux d’applications qui

le nom

chaîne de caractères

Le nom utilisé pour faire référence à l’entrée d’un pipeline.

19.1.1.1.3. .spec.inputs[].application
Copier lien
19.1.1.1.3.1. Description
Copier lien

Le sélecteur de journal de l’application. Dans le sélecteur, toutes les conditions doivent être remplies (logique ET) pour sélectionner les journaux.

19.1.1.1.3.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

espaces de noms

le tableau

(facultatif) Namespaces à partir desquels collecter les journaux des applications.

le sélecteur

l’objet

(facultatif) Sélecteur pour les logs des pods avec les étiquettes correspondantes.

19.1.1.1.4. .spec.inputs[].application.namespaces[]
Copier lien
19.1.1.1.4.1. Description
Copier lien
19.1.1.1.4.1.1. Le type
Copier lien
  • le tableau
19.1.1.1.5. .spec.inputs[].application.selector
Copier lien
19.1.1.1.5.1. Description
Copier lien

Le sélecteur d’étiquette est une requête d’étiquette sur un ensemble de ressources.

19.1.1.1.5.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

les Laboratoires de match

l’objet

(facultatif) MatchLabels est une carte des paires {key,value}. * un seul {clé, valeur} dans le matchLabels

19.1.1.1.6. .spec.inputs[].application.selector.matchLabels
Copier lien
19.1.1.1.6.1. Description
Copier lien
19.1.1.1.6.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.7. .spec.outputDefaults
Copier lien
19.1.1.1.7.1. Description
Copier lien
19.1.1.1.7.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Elasticsearch

l’objet

(facultatif) Elasticsearch OutputSpec valeurs par défaut

19.1.1.1.8. .spec.outputDefaults.elasticsearch
Copier lien
19.1.1.1.8.1. Description
Copier lien

ElasticsearchStructuredSpec est lié aux changements de log structurés pour déterminer l’indice de recherche élastique

19.1.1.1.8.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

enableStructuredContainerLogs

bool

(facultatif) EnableStructuredContainerLogs permet aux logs structurés multiconteneurs de permettre

à propos de StructureTypeKey

chaîne de caractères

(facultatif) StructuredTypeKey spécifie la clé de métadonnées à utiliser comme nom de l’index de recherche élastique

la structureTypeName

chaîne de caractères

(facultatif) StructuredTypeName spécifie le nom du schéma de recherche élastique

19.1.1.1.9. .spec.outputs[]
Copier lien
19.1.1.1.9.1. Description
Copier lien

La sortie définit une destination pour les messages journaux.

19.1.1.1.9.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

le syslog

l’objet

(facultatif)

FluentdForward

l’objet

(facultatif)

Elasticsearch

l’objet

(facultatif)

Kafka

l’objet

(facultatif)

CloudWatch

l’objet

(facultatif)

Loki

l’objet

(facultatif)

GoogleCloudLogging

l’objet

(facultatif)

à propos de Splunk

l’objet

(facultatif)

le nom

chaîne de caractères

Le nom utilisé pour faire référence à la sortie d’un pipeline.

le secret

l’objet

(facultatif) Secret pour l’authentification.

le TLS

l’objet

Le TLS contient des paramètres pour le contrôle des options sur les connexions client TLS.

le type

chaîne de caractères

Le type de plugin de sortie.

l’URL

chaîne de caractères

(facultatif) URL pour envoyer des enregistrements de journal à.

19.1.1.1.10. .spec.outputs[].secret
Copier lien
19.1.1.1.10.1. Description
Copier lien

OutputSecretSpec est une référence secrète contenant seulement un nom, pas d’espace de noms.

19.1.1.1.10.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le nom

chaîne de caractères

Le nom d’un secret dans l’espace de noms configuré pour les secrets d’expéditeur de journaux.

19.1.1.1.11. .spec.outputs[].tls
Copier lien
19.1.1.1.11.1. Description
Copier lien

La sortieTLSSpec contient des options pour les connexions TLS qui sont agnostiques au type de sortie.

19.1.1.1.11.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

insecureSkipVerify

bool

Lorsque InsecureSkipVerify est vrai, le client TLS sera configuré pour ignorer les erreurs avec les certificats.

19.1.1.1.12. .spec.pipelines[]
Copier lien
19.1.1.1.12.1. Description
Copier lien

Les PipelinesSpec lient un ensemble d’entrées à un ensemble de sorties.

19.1.1.1.12.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

détecterMultilineErrors

bool

(facultatif) DetectMultilineErrors permet la détection d’erreurs multilignes des journaux de conteneurs

entréeRefs

le tableau

InputRefs répertorie les noms (input.name) des entrées de ce pipeline.

étiquettes

l’objet

(facultatif) Les étiquettes s’appliquent aux enregistrements de log qui passent par ce pipeline.

le nom

chaîne de caractères

(facultatif) Le nom est facultatif, mais doit être unique dans la liste des pipelines s’il est fourni.

la sortieRefs

le tableau

Les OutputRefs répertorient les noms (output.name) des sorties de ce pipeline.

analysez

chaîne de caractères

(facultatif) Parse permet l’analyse des entrées de journal dans des journaux structurés

19.1.1.1.13. .spec.pipelines[].inputRefs[]
Copier lien
19.1.1.1.13.1. Description
Copier lien
19.1.1.1.13.1.1. Le type
Copier lien
  • le tableau
19.1.1.1.14. .spec.pipelines[].labels
Copier lien
19.1.1.1.14.1. Description
Copier lien
19.1.1.1.14.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.15. .spec.pipelines[].outputRefs[]
Copier lien
19.1.1.1.15.1. Description
Copier lien
19.1.1.1.15.1.1. Le type
Copier lien
  • le tableau
19.1.1.1.16. .status
Copier lien
19.1.1.1.16.1. Description
Copier lien

ClusterLogForwarderStatus définit l’état observé de ClusterLogForwarder

19.1.1.1.16.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

les conditions

l’objet

Conditions de l’expéditeur journalier.

entrées

Les conditions

Entrées mappe le nom d’entrée à l’état de l’entrée.

extrants

Les conditions

Les sorties cartographient le nom de sortie à l’état de la sortie.

gazoducs

Les conditions

Les pipelines indiquent le nom du pipeline à l’état du pipeline.

19.1.1.1.17. .status.conditions
Copier lien
19.1.1.1.17.1. Description
Copier lien
19.1.1.1.17.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.18. .status.inputs
Copier lien
19.1.1.1.18.1. Description
Copier lien
19.1.1.1.18.1.1. Le type
Copier lien
  • Les conditions
19.1.1.1.19. .status.outputs
Copier lien
19.1.1.1.19.1. Description
Copier lien
19.1.1.1.19.1.1. Le type
Copier lien
  • Les conditions
19.1.1.1.20. .status.pipelines
Copier lien
19.1.1.1.20.1. Description
Copier lien
19.1.1.1.20.1.1. Le type
Copier lien
  • Conditions ==ClusterLogging Une instance Red Hat OpenShift Logging. ClusterLogging est le schéma de l’API clusterloggings
Expand
La propriétéLe typeDescription

les spécifications

l’objet

Caractéristiques du comportement souhaité de ClusterLogging

status

l’objet

Le statut définit l’état observé de ClusterLogging

19.1.1.1.21. .spec
Copier lien
19.1.1.1.21.1. Description
Copier lien

ClusterLoggingSpec définit l’état souhaité de ClusterLogging

19.1.1.1.21.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

la collection

l’objet

Cahier des charges du composant Collection pour le cluster

curation

l’objet

(DEPRÉGÉ) (facultatif) Déprécié. Spécification du composant Curation pour le cluster

expéditeur

l’objet

(DEPRÉGÉ) (facultatif) Déprécié. Caractéristiques pour le composant Forwarder pour le cluster

Logstore

l’objet

(facultatif) Spécification du composant Log Storage pour le cluster

État de gestion

chaîne de caractères

(facultatif) Indicateur si la ressource est « gérée » ou « non gérée » par l’opérateur

la visualisation

l’objet

(facultatif) Spécification du composant Visualisation pour le cluster

19.1.1.1.22. .spec.collection
Copier lien
19.1.1.1.22.1. Description
Copier lien

Il s’agit de la structure qui contiendra des informations pertinentes pour la collecte de log et d’événements

19.1.1.1.22.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

les ressources

l’objet

(facultatif) Les ressources nécessaires pour le collecteur

le nodeSelector

l’objet

(facultatif) Définir quels nœuds les Pods sont programmés.

les tolérances

le tableau

(facultatif) Définir les tolérances que les Pods accepteront

Fluentd

l’objet

(facultatif) Fluentd représente la configuration pour les transmetteurs de type fluentd.

journaux de bord

l’objet

(DEPRÉGÉ) (facultatif) Déprécié. Cahier des charges de la collection de journaux pour le cluster

le type

chaîne de caractères

(facultatif) Le type de collection de journaux à configurer

19.1.1.1.23. .spec.collection.fluentd
Copier lien
19.1.1.1.23.1. Description
Copier lien

FluentdForwarderSpec représente la configuration pour les transiteurs de type fluentd.

19.1.1.1.23.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le tampon

l’objet

 

INFILE

l’objet

 
19.1.1.1.24. .spec.collection.fluentd.buffer
Copier lien
19.1.1.1.24.1. Description
Copier lien

FluentdBufferSpec représente un sous-ensemble de paramètres tampons fluides pour régler la configuration tampon pour toutes les sorties fluides. Il prend en charge un sous-ensemble de paramètres pour configurer le dimensionnement de tampon et de file d’attente, les opérations de rinçage et de réessayer.

Les paramètres généraux se réfèrent à: https://docs.fluentd.org/configuration/buffer-section#buffering-parameters

Les paramètres de flush se réfèrent à: https://docs.fluentd.org/configuration/buffer-section#flushing-parameters

Les paramètres de réessayer se réfèrent à: https://docs.fluentd.org/configuration/buffer-section#retries-parameters

19.1.1.1.24.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

chunkLimitSize

chaîne de caractères

(facultatif) ChunkLimitSize représente la taille maximale de chaque morceau. Les événements seront

flushInterval

chaîne de caractères

(facultatif) FlushInterval représente la durée d’attente entre deux chasses consécutives

FlushMode

chaîne de caractères

(facultatif) FlushMode représente le mode du fil de rinçage pour écrire des morceaux. Le mode

flushThreadCount

int

(facultatif) FlushThreadCount reprend le nombre de threads utilisés par le tampon fluide

action de débordement

chaîne de caractères

(facultatif) OverflowAction représente l’action du plugin tampon fluide pour

à propos de RetryMaxInterval

chaîne de caractères

(facultatif) RetryMaxInterval représente l’intervalle de temps maximal pour le recul exponentiel

à propos de RetryTimeout

chaîne de caractères

(facultatif) RetryTimeout représente l’intervalle de temps maximum pour tenter les retries avant d’abandonner

le RetryType

chaîne de caractères

(facultatif) RetryType représente le type d’opérations de récupération. Les opérations de chasse peuvent

à propos de RetryWait

chaîne de caractères

(facultatif) RetryWait représente la durée de temps entre deux retries consécutives à la chasse

la taille totaleLimitSize

chaîne de caractères

(facultatif) TotalLimitSize représente le seuil d’espace de nœud autorisé par fluentd

19.1.1.1.25. .spec.collection.fluentd.inFile
Copier lien
19.1.1.1.25.1. Description
Copier lien

FluentdInFileSpec représente un sous-ensemble de paramètres de plugin en queue fluides pour régler la configuration de toutes les entrées fluides en queue.

Les paramètres généraux se réfèrent à: https://docs.fluentd.org/input/tail#parameters

19.1.1.1.25.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

lectureLinesLimit

int

(facultatif) ReadLinesLimit représente le nombre de lignes à lire avec chaque opération d’E/S

19.1.1.1.26. .spec.collection.logs
Copier lien
19.1.1.1.26.1. Description
Copier lien
19.1.1.1.26.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Fluentd

l’objet

Caractéristiques du composant Fluentd Log Collection

le type

chaîne de caractères

Le type de Log Collection à configurer

19.1.1.1.27. .spec.collection.logs.fluentd
Copier lien
19.1.1.1.27.1. Description
Copier lien

CollectorSpec est Spécification pour définir la programmation et les ressources pour un collectionneur

19.1.1.1.27.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le nodeSelector

l’objet

(facultatif) Définir quels nœuds les Pods sont programmés.

les ressources

l’objet

(facultatif) Les ressources nécessaires pour le collecteur

les tolérances

le tableau

(facultatif) Définir les tolérances que les Pods accepteront

19.1.1.1.28. .spec.collection.logs.fluentd.nodeSelector
Copier lien
19.1.1.1.28.1. Description
Copier lien
19.1.1.1.28.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.29. .spec.collection.logs.fluentd.resources
Copier lien
19.1.1.1.29.1. Description
Copier lien
19.1.1.1.29.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

limites

l’objet

(facultatif) Les limites décrivent la quantité maximale de ressources de calcul autorisées.

demandes

l’objet

(facultatif) Demandes décrit le montant minimum de ressources de calcul nécessaires.

19.1.1.1.30. .spec.collection.logs.fluentd.resources.limits
Copier lien
19.1.1.1.30.1. Description
Copier lien
19.1.1.1.30.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.31. .spec.collection.logs.fluentd.resources.requests
Copier lien
19.1.1.1.31.1. Description
Copier lien
19.1.1.1.31.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.32. .spec.collection.logs.fluentd.tolerations[]
Copier lien
19.1.1.1.32.1. Description
Copier lien
19.1.1.1.32.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

effet

chaîne de caractères

(facultatif) Effet indique l’effet taint à correspondre. Vide signifie correspondre à tous les effets de tainte.

la clé

chaîne de caractères

(facultatif) La clé est la clé tainte à laquelle la tolérance s’applique. Vide signifie correspondre à toutes les touches taintes.

exploitant

chaîne de caractères

(facultatif) L’opérateur représente la relation d’une clé avec la valeur.

la toléranceDeuxièmes

int

(facultatif) TolérationSeconds représente la période de temps que la tolérance (qui doit être

la valeur

chaîne de caractères

(facultatif) La valeur est la valeur tainte à laquelle la tolérance correspond.

19.1.1.1.33.1. Description
Copier lien
19.1.1.1.33.1.1. Le type
Copier lien
  • int
19.1.1.1.34. .spec.curation
Copier lien
19.1.1.1.34.1. Description
Copier lien

Il s’agit de la structure qui contiendra des informations pertinentes pour Log curation (Curator)

19.1.1.1.34.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

commissaire

l’objet

La spécification de curation à configurer

le type

chaîne de caractères

Le type de curation à configurer

19.1.1.1.35. .spec.curation.curator
Copier lien
19.1.1.1.35.1. Description
Copier lien
19.1.1.1.35.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le nodeSelector

l’objet

Définissez les nœuds sur lesquels les Pods sont programmés.

les ressources

l’objet

(facultatif) Les besoins en ressources pour le conservateur

calendrier

chaîne de caractères

L’horaire cron que le poste de conservateur est exécuté. Défaut à "30 3 * * *"

les tolérances

le tableau

 
19.1.1.1.36. .spec.curation.curator.nodeSelector
Copier lien
19.1.1.1.36.1. Description
Copier lien
19.1.1.1.36.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.37. .spec.curation.curator.resources
Copier lien
19.1.1.1.37.1. Description
Copier lien
19.1.1.1.37.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

limites

l’objet

(facultatif) Les limites décrivent la quantité maximale de ressources de calcul autorisées.

demandes

l’objet

(facultatif) Demandes décrit le montant minimum de ressources de calcul nécessaires.

19.1.1.1.38. .spec.curation.curator.resources.limits
Copier lien
19.1.1.1.38.1. Description
Copier lien
19.1.1.1.38.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.39. .spec.curation.curator.resources.requests
Copier lien
19.1.1.1.39.1. Description
Copier lien
19.1.1.1.39.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.40. .spec.curation.curator.tolerations[]
Copier lien
19.1.1.1.40.1. Description
Copier lien
19.1.1.1.40.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

effet

chaîne de caractères

(facultatif) Effet indique l’effet taint à correspondre. Vide signifie correspondre à tous les effets de tainte.

la clé

chaîne de caractères

(facultatif) La clé est la clé tainte à laquelle la tolérance s’applique. Vide signifie correspondre à toutes les touches taintes.

exploitant

chaîne de caractères

(facultatif) L’opérateur représente la relation d’une clé avec la valeur.

la toléranceDeuxièmes

int

(facultatif) TolérationSeconds représente la période de temps que la tolérance (qui doit être

la valeur

chaîne de caractères

(facultatif) La valeur est la valeur tainte à laquelle la tolérance correspond.

19.1.1.1.41.1. Description
Copier lien
19.1.1.1.41.1.1. Le type
Copier lien
  • int
19.1.1.1.42. .spec.forwarder
Copier lien
19.1.1.1.42.1. Description
Copier lien

ForwarderSpec contient des paramètres globaux de réglage pour des implémentations spécifiques de l’expéditeur. Ce champ n’est pas requis pour une utilisation générale, il permet un réglage des performances par les utilisateurs familiers avec la technologie de transit sous-jacente. Actuellement pris en charge: fluentd.

19.1.1.1.42.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Fluentd

l’objet

 
19.1.1.1.43. .spec.forwarder.fluentd
Copier lien
19.1.1.1.43.1. Description
Copier lien

FluentdForwarderSpec représente la configuration pour les transiteurs de type fluentd.

19.1.1.1.43.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le tampon

l’objet

 

INFILE

l’objet

 
19.1.1.1.44. .spec.forwarder.fluentd.buffer
Copier lien
19.1.1.1.44.1. Description
Copier lien

FluentdBufferSpec représente un sous-ensemble de paramètres tampons fluides pour régler la configuration tampon pour toutes les sorties fluides. Il prend en charge un sous-ensemble de paramètres pour configurer le dimensionnement de tampon et de file d’attente, les opérations de rinçage et de réessayer.

Les paramètres généraux se réfèrent à: https://docs.fluentd.org/configuration/buffer-section#buffering-parameters

Les paramètres de flush se réfèrent à: https://docs.fluentd.org/configuration/buffer-section#flushing-parameters

Les paramètres de réessayer se réfèrent à: https://docs.fluentd.org/configuration/buffer-section#retries-parameters

19.1.1.1.44.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

chunkLimitSize

chaîne de caractères

(facultatif) ChunkLimitSize représente la taille maximale de chaque morceau. Les événements seront

flushInterval

chaîne de caractères

(facultatif) FlushInterval représente la durée d’attente entre deux chasses consécutives

FlushMode

chaîne de caractères

(facultatif) FlushMode représente le mode du fil de rinçage pour écrire des morceaux. Le mode

flushThreadCount

int

(facultatif) FlushThreadCount reprend le nombre de threads utilisés par le tampon fluide

action de débordement

chaîne de caractères

(facultatif) OverflowAction représente l’action du plugin tampon fluide pour

à propos de RetryMaxInterval

chaîne de caractères

(facultatif) RetryMaxInterval représente l’intervalle de temps maximal pour le recul exponentiel

à propos de RetryTimeout

chaîne de caractères

(facultatif) RetryTimeout représente l’intervalle de temps maximum pour tenter les retries avant d’abandonner

le RetryType

chaîne de caractères

(facultatif) RetryType représente le type d’opérations de récupération. Les opérations de chasse peuvent

à propos de RetryWait

chaîne de caractères

(facultatif) RetryWait représente la durée de temps entre deux retries consécutives à la chasse

la taille totaleLimitSize

chaîne de caractères

(facultatif) TotalLimitSize représente le seuil d’espace de nœud autorisé par fluentd

19.1.1.1.45. .spec.forwarder.fluentd.inFile
Copier lien
19.1.1.1.45.1. Description
Copier lien

FluentdInFileSpec représente un sous-ensemble de paramètres de plugin en queue fluides pour régler la configuration de toutes les entrées fluides en queue.

Les paramètres généraux se réfèrent à: https://docs.fluentd.org/input/tail#parameters

19.1.1.1.45.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

lectureLinesLimit

int

(facultatif) ReadLinesLimit représente le nombre de lignes à lire avec chaque opération d’E/S

19.1.1.1.46. .spec.logStore
Copier lien
19.1.1.1.46.1. Description
Copier lien

Le LogStoreSpec contient des informations sur la façon dont les journaux sont stockés.

19.1.1.1.46.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Elasticsearch

l’objet

Caractéristiques du composant Elasticsearch Log Store

lokistack

l’objet

LokiStack contient des informations sur lesquelles LokiStack doit être utilisé pour le stockage de log si Type est réglé sur LogStoreTypeLokiStack.

la politique de rétention

l’objet

(facultatif) La politique de conservation définit l’âge maximum d’un indice après lequel il doit être supprimé

le type

chaîne de caractères

Le type de stockage journal à configurer. L’opérateur prend actuellement en charge l’utilisation d’ElasticSearch

19.1.1.1.47. .spec.logStore.elasticsearch
Copier lien
19.1.1.1.47.1. Description
Copier lien
19.1.1.1.47.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

à propos de NodeCount

int

Le nombre de nœuds à déployer pour Elasticsearch

le nodeSelector

l’objet

Définissez les nœuds sur lesquels les Pods sont programmés.

le proxy

l’objet

Cahier des charges du composant Proxy Elasticsearch

la politique de redondance

chaîne de caractères

(facultatif)

les ressources

l’objet

(facultatif) Les ressources nécessaires pour Elasticsearch

le stockage

l’objet

(facultatif) La spécification de stockage pour les nœuds de données Elasticsearch

les tolérances

le tableau

 
19.1.1.1.48. .spec.logStore.elasticsearch.nodeSelector
Copier lien
19.1.1.1.48.1. Description
Copier lien
19.1.1.1.48.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.49. .spec.logStore.elasticsearch.proxy
Copier lien
19.1.1.1.49.1. Description
Copier lien
19.1.1.1.49.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

les ressources

l’objet

 
19.1.1.1.50. .spec.logStore.elasticsearch.proxy.resources
Copier lien
19.1.1.1.50.1. Description
Copier lien
19.1.1.1.50.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

limites

l’objet

(facultatif) Les limites décrivent la quantité maximale de ressources de calcul autorisées.

demandes

l’objet

(facultatif) Demandes décrit le montant minimum de ressources de calcul nécessaires.

19.1.1.1.51.1. Description
Copier lien
19.1.1.1.51.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.52.1. Description
Copier lien
19.1.1.1.52.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.53. .spec.logStore.elasticsearch.resources
Copier lien
19.1.1.1.53.1. Description
Copier lien
19.1.1.1.53.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

limites

l’objet

(facultatif) Les limites décrivent la quantité maximale de ressources de calcul autorisées.

demandes

l’objet

(facultatif) Demandes décrit le montant minimum de ressources de calcul nécessaires.

19.1.1.1.54. .spec.logStore.elasticsearch.resources.limits
Copier lien
19.1.1.1.54.1. Description
Copier lien
19.1.1.1.54.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.55. .spec.logStore.elasticsearch.resources.requests
Copier lien
19.1.1.1.55.1. Description
Copier lien
19.1.1.1.55.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.56. .spec.logStore.elasticsearch.storage
Copier lien
19.1.1.1.56.1. Description
Copier lien
19.1.1.1.56.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

la taille

l’objet

La capacité de stockage maximale pour le nœud à disposition.

classe de stockageName

chaîne de caractères

(facultatif) Le nom de la classe de stockage à utiliser pour créer le PVC du nœud.

19.1.1.1.57. .spec.logStore.elasticsearch.storage.size
Copier lien
19.1.1.1.57.1. Description
Copier lien
19.1.1.1.57.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Format

chaîne de caractères

Changer le format à volonté. Consultez le commentaire pour Canonicalize pour

d)

l’objet

d est la quantité sous forme inf.Dec si d.Dec != nil

J’ai

int

I est la quantité sous forme int64 mise à l’échelle, si d.Dec ==

a) S

chaîne de caractères

est la valeur générée de cette quantité pour éviter le recalcul

19.1.1.1.58. .spec.logStore.elasticsearch.storage.size.d
Copier lien
19.1.1.1.58.1. Description
Copier lien
19.1.1.1.58.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Déc.

l’objet

 
19.1.1.1.59. .spec.logStore.elasticsearch.storage.size.d.Dec
Copier lien
19.1.1.1.59.1. Description
Copier lien
19.1.1.1.59.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

échelle

int

 

à l’échelle

l’objet

 
19.1.1.1.60.1. Description
Copier lien
19.1.1.1.60.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

ABS

Le mot

le signe

♪ neg ♪

bool

 
19.1.1.1.61.1. Description
Copier lien
19.1.1.1.61.1.1. Le type
Copier lien
  • Le mot
19.1.1.1.62. .spec.logStore.elasticsearch.storage.size.i
Copier lien
19.1.1.1.62.1. Description
Copier lien
19.1.1.1.62.1.1. Le type
Copier lien
  • int
Expand
La propriétéLe typeDescription

échelle

int

 

la valeur

int

 
19.1.1.1.63. .spec.logStore.elasticsearch.tolerations[]
Copier lien
19.1.1.1.63.1. Description
Copier lien
19.1.1.1.63.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

effet

chaîne de caractères

(facultatif) Effet indique l’effet taint à correspondre. Vide signifie correspondre à tous les effets de tainte.

la clé

chaîne de caractères

(facultatif) La clé est la clé tainte à laquelle la tolérance s’applique. Vide signifie correspondre à toutes les touches taintes.

exploitant

chaîne de caractères

(facultatif) L’opérateur représente la relation d’une clé avec la valeur.

la toléranceDeuxièmes

int

(facultatif) TolérationSeconds représente la période de temps que la tolérance (qui doit être

la valeur

chaîne de caractères

(facultatif) La valeur est la valeur tainte à laquelle la tolérance correspond.

19.1.1.1.64.1. Description
Copier lien
19.1.1.1.64.1.1. Le type
Copier lien
  • int
19.1.1.1.65. .spec.logStore.lokistack
Copier lien
19.1.1.1.65.1. Description
Copier lien

LokiStackStoreSpec est utilisé pour configurer l’enregistrement des clusters pour utiliser un LokiStack comme stockage de journalisation. Il pointe vers un LokiStack existant dans le même espace de noms.

19.1.1.1.65.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le nom

chaîne de caractères

Le nom de la ressource LokiStack.

19.1.1.1.66. .spec.logStore.retentionPolicy
Copier lien
19.1.1.1.66.1. Description
Copier lien
19.1.1.1.66.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

application

l’objet

 

audit

l’objet

 

infra

l’objet

 
19.1.1.1.67. .spec.logStore.retentionPolicy.application
Copier lien
19.1.1.1.67.1. Description
Copier lien
19.1.1.1.67.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

DiskThresholdPercent

int

(facultatif) Le pourcentage seuil d’utilisation du disque ES qui, lorsqu’il est atteint, devrait être supprimé (p. ex. 75)

Le maxage

chaîne de caractères

(facultatif)

espace de nomsSpec

le tableau

(facultatif) La spécification par espace de noms pour supprimer des documents plus anciens qu’un âge minimum donné

espace de PruneNamespacesInterval

chaîne de caractères

(facultatif) À quelle fréquence exécuter un nouvel emploi de prune-namespaces

19.1.1.1.68.1. Description
Copier lien
19.1.1.1.68.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

le minage

chaîne de caractères

(facultatif) Supprimer les enregistrements correspondant aux espaces de noms qui sont plus anciens que ce MinAge (par exemple 1d)

espace de noms

chaîne de caractères

Cible Namespace pour supprimer les journaux plus anciens que MinAge (par défaut à 7d)

19.1.1.1.69. .spec.logStore.retentionPolicy.audit
Copier lien
19.1.1.1.69.1. Description
Copier lien
19.1.1.1.69.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

DiskThresholdPercent

int

(facultatif) Le pourcentage seuil d’utilisation du disque ES qui, lorsqu’il est atteint, devrait être supprimé (p. ex. 75)

Le maxage

chaîne de caractères

(facultatif)

espace de nomsSpec

le tableau

(facultatif) La spécification par espace de noms pour supprimer des documents plus anciens qu’un âge minimum donné

espace de PruneNamespacesInterval

chaîne de caractères

(facultatif) À quelle fréquence exécuter un nouvel emploi de prune-namespaces

19.1.1.1.70.1. Description
Copier lien
19.1.1.1.70.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

le minage

chaîne de caractères

(facultatif) Supprimer les enregistrements correspondant aux espaces de noms qui sont plus anciens que ce MinAge (par exemple 1d)

espace de noms

chaîne de caractères

Cible Namespace pour supprimer les journaux plus anciens que MinAge (par défaut à 7d)

19.1.1.1.71. .spec.logStore.retentionPolicy.infra
Copier lien
19.1.1.1.71.1. Description
Copier lien
19.1.1.1.71.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

DiskThresholdPercent

int

(facultatif) Le pourcentage seuil d’utilisation du disque ES qui, lorsqu’il est atteint, devrait être supprimé (p. ex. 75)

Le maxage

chaîne de caractères

(facultatif)

espace de nomsSpec

le tableau

(facultatif) La spécification par espace de noms pour supprimer des documents plus anciens qu’un âge minimum donné

espace de PruneNamespacesInterval

chaîne de caractères

(facultatif) À quelle fréquence exécuter un nouvel emploi de prune-namespaces

19.1.1.1.72.1. Description
Copier lien
19.1.1.1.72.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

le minage

chaîne de caractères

(facultatif) Supprimer les enregistrements correspondant aux espaces de noms qui sont plus anciens que ce MinAge (par exemple 1d)

espace de noms

chaîne de caractères

Cible Namespace pour supprimer les journaux plus anciens que MinAge (par défaut à 7d)

19.1.1.1.73. .spec.visualisation
Copier lien
19.1.1.1.73.1. Description
Copier lien

Il s’agit de la structure qui contiendra des informations pertinentes à la visualisation de Log (Kibana)

19.1.1.1.73.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

Kibana

l’objet

Caractéristiques du composant de visualisation Kibana

le type

chaîne de caractères

Le type de visualisation à configurer

19.1.1.1.74. .spec.visualization.kibana
Copier lien
19.1.1.1.74.1. Description
Copier lien
19.1.1.1.74.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

le nodeSelector

l’objet

Définissez les nœuds sur lesquels les Pods sont programmés.

le proxy

l’objet

Caractéristiques du composant Proxy Kibana

les répliques

int

Le nombre d’instances à déployer pour un déploiement de Kibana

les ressources

l’objet

(facultatif) Les ressources nécessaires pour Kibana

les tolérances

le tableau

 
19.1.1.1.75. .spec.visualization.kibana.nodeSelector
Copier lien
19.1.1.1.75.1. Description
Copier lien
19.1.1.1.75.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.76. .spec.visualization.kibana.proxy
Copier lien
19.1.1.1.76.1. Description
Copier lien
19.1.1.1.76.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

les ressources

l’objet

 
19.1.1.1.77. .spec.visualization.kibana.proxy.ressources
Copier lien
19.1.1.1.77.1. Description
Copier lien
19.1.1.1.77.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

limites

l’objet

(facultatif) Les limites décrivent la quantité maximale de ressources de calcul autorisées.

demandes

l’objet

(facultatif) Demandes décrit le montant minimum de ressources de calcul nécessaires.

19.1.1.1.78. .spec.visualization.kibana.proxy.resources.limits
Copier lien
19.1.1.1.78.1. Description
Copier lien
19.1.1.1.78.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.79.1. Description
Copier lien
19.1.1.1.79.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.80. .spec.visualization.kibana.replicas
Copier lien
19.1.1.1.80.1. Description
Copier lien
19.1.1.1.80.1.1. Le type
Copier lien
  • int
19.1.1.1.81. .spec.visualization.kibana.ressources
Copier lien
19.1.1.1.81.1. Description
Copier lien
19.1.1.1.81.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

limites

l’objet

(facultatif) Les limites décrivent la quantité maximale de ressources de calcul autorisées.

demandes

l’objet

(facultatif) Demandes décrit le montant minimum de ressources de calcul nécessaires.

19.1.1.1.82. .spec.visualization.kibana.resources.limits
Copier lien
19.1.1.1.82.1. Description
Copier lien
19.1.1.1.82.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.83. .spec.visualization.kibana.resources.requests
Copier lien
19.1.1.1.83.1. Description
Copier lien
19.1.1.1.83.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.84. .spec.visualization.kibana.tolerations[]
Copier lien
19.1.1.1.84.1. Description
Copier lien
19.1.1.1.84.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

effet

chaîne de caractères

(facultatif) Effet indique l’effet taint à correspondre. Vide signifie correspondre à tous les effets de tainte.

la clé

chaîne de caractères

(facultatif) La clé est la clé tainte à laquelle la tolérance s’applique. Vide signifie correspondre à toutes les touches taintes.

exploitant

chaîne de caractères

(facultatif) L’opérateur représente la relation d’une clé avec la valeur.

la toléranceDeuxièmes

int

(facultatif) TolérationSeconds représente la période de temps que la tolérance (qui doit être

la valeur

chaîne de caractères

(facultatif) La valeur est la valeur tainte à laquelle la tolérance correspond.

19.1.1.1.85.1. Description
Copier lien
19.1.1.1.85.1.1. Le type
Copier lien
  • int
19.1.1.1.86. .status
Copier lien
19.1.1.1.86.1. Description
Copier lien

ClusterLoggingStatus définit l’état observé de ClusterLogging

19.1.1.1.86.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

la collection

l’objet

(facultatif)

les conditions

l’objet

(facultatif)

curation

l’objet

(facultatif)

Logstore

l’objet

(facultatif)

la visualisation

l’objet

(facultatif)

19.1.1.1.87. .status.collection
Copier lien
19.1.1.1.87.1. Description
Copier lien
19.1.1.1.87.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

journaux de bord

l’objet

(facultatif)

19.1.1.1.88. .status.collection.logs
Copier lien
19.1.1.1.88.1. Description
Copier lien
19.1.1.1.88.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

fluentdStatus

l’objet

(facultatif)

19.1.1.1.89. .status.collection.logs.fluentdStatus
Copier lien
19.1.1.1.89.1. Description
Copier lien
19.1.1.1.89.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

clusterCondition

l’objet

(facultatif)

DaemonSet

chaîne de caractères

(facultatif)

les nœuds

l’objet

(facultatif)

les gousses

chaîne de caractères

(facultatif)

19.1.1.1.90.1. Description
Copier lien

la génération de crds d’opérateur-sdk n’autorise pas la carte de coupe, doit utiliser un type nommé.

19.1.1.1.90.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.91. .status.collection.logs.fluentdStatus.nodes
Copier lien
19.1.1.1.91.1. Description
Copier lien
19.1.1.1.91.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.92. .status.conditions
Copier lien
19.1.1.1.92.1. Description
Copier lien
19.1.1.1.92.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.93. .status.curation
Copier lien
19.1.1.1.93.1. Description
Copier lien
19.1.1.1.93.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

CurservatorStatus

le tableau

(facultatif)

19.1.1.1.94. .status.curation.curatorStatus[]
Copier lien
19.1.1.1.94.1. Description
Copier lien
19.1.1.1.94.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

clusterCondition

l’objet

(facultatif)

Cronjobs

chaîne de caractères

(facultatif)

horaires

chaîne de caractères

(facultatif)

B) Suspension

bool

(facultatif)

19.1.1.1.95. .status.curation.curatorStatus[].clusterCondition
Copier lien
19.1.1.1.95.1. Description
Copier lien

la génération de crds d’opérateur-sdk n’autorise pas la carte de coupe, doit utiliser un type nommé.

19.1.1.1.95.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.96. .status.logStore
Copier lien
19.1.1.1.96.1. Description
Copier lien
19.1.1.1.96.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

ElastiquesearchStatus

le tableau

(facultatif)

19.1.1.1.97. .status.logStore.elasticsearchStatus[]
Copier lien
19.1.1.1.97.1. Description
Copier lien
19.1.1.1.97.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

cluster

l’objet

(facultatif)

clusterConditions

l’objet

(facultatif)

clusterHealth

chaîne de caractères

(facultatif)

ClusterName

chaîne de caractères

(facultatif)

déploiements

le tableau

(facultatif)

conditions de node

l’objet

(facultatif)

à propos de NodeCount

int

(facultatif)

les gousses

l’objet

(facultatif)

ensembles de répliques

le tableau

(facultatif)

AllocationShardAllocationEnabled

chaîne de caractères

(facultatif)

État des ensembles

le tableau

(facultatif)

19.1.1.1.98. .status.logStore.elasticsearchStatus[].cluster
Copier lien
19.1.1.1.98.1. Description
Copier lien
19.1.1.1.98.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

activePrimaryShards

int

Le nombre de partages primaires actifs pour le cluster Elasticsearch

activeShards

int

Le nombre de Shards actifs pour le cluster Elasticsearch

initialisationShards

int

Le nombre de partages initiaux pour le cluster Elasticsearch

à propos de numDataNodes

int

Le nombre de nœuds de données pour le cluster Elasticsearch

les numNodes

int

Le nombre de nœuds pour le cluster Elasticsearch

dossiers en attente

int

 

déménagement deShards

int

Le nombre de partages de relocalisation pour le cluster Elasticsearch

status

chaîne de caractères

L’état actuel du cluster Elasticsearch

desShards non assignés

int

Le nombre de partages non attribués pour le cluster Elasticsearch

19.1.1.1.99.1. Description
Copier lien
19.1.1.1.99.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.100.1. Description
Copier lien
19.1.1.1.100.1.1. Le type
Copier lien
  • le tableau
19.1.1.1.101.1. Description
Copier lien
19.1.1.1.101.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.102. .status.logStore.elasticsearchStatus[].pods
Copier lien
19.1.1.1.102.1. Description
Copier lien
19.1.1.1.102.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.103.1. Description
Copier lien
19.1.1.1.103.1.1. Le type
Copier lien
  • le tableau
19.1.1.1.104.1. Description
Copier lien
19.1.1.1.104.1.1. Le type
Copier lien
  • le tableau
19.1.1.1.105. .status.visualisation
Copier lien
19.1.1.1.105.1. Description
Copier lien
19.1.1.1.105.1.1. Le type
Copier lien
  • l’objet
Expand
La propriétéLe typeDescription

kibanaStatus

le tableau

(facultatif)

19.1.1.1.106. .status.visualization.kibanaStatus[]
Copier lien
19.1.1.1.106.1. Description
Copier lien
19.1.1.1.106.1.1. Le type
Copier lien
  • le tableau
Expand
La propriétéLe typeDescription

clusterCondition

l’objet

(facultatif)

déploiement

chaîne de caractères

(facultatif)

les gousses

chaîne de caractères

(facultatif) Le statut de chacun des pods Kibana pour le composant Visualisation

ensembles de répliques

le tableau

(facultatif)

les répliques

int

(facultatif)

19.1.1.1.107.1. Description
Copier lien
19.1.1.1.107.1.1. Le type
Copier lien
  • l’objet
19.1.1.1.108.1. Description
Copier lien
19.1.1.1.108.1.1. Le type
Copier lien
  • le tableau

Chapitre 20. Glossaire
Copier lien

Ce glossaire définit des termes communs qui sont utilisés dans la documentation de journalisation.

Annotation
Il est possible d’utiliser des annotations pour joindre des métadonnées à des objets.
L’opérateur de journalisation de Red Hat OpenShift
Le Red Hat OpenShift Logging Operator fournit un ensemble d’API pour contrôler la collecte et la transmission des journaux d’application, d’infrastructure et d’audit.
Les ressources personnalisées (CR)
A CR est une extension de l’API Kubernetes. Afin de configurer l’enregistrement et le transfert de journaux, vous pouvez personnaliser les ressources personnalisées ClusterLogging et ClusterLogForwarder.
Routeur d’événements
Le routeur d’événements est un pod qui regarde Red Hat OpenShift Service sur les événements AWS. Il collecte les journaux en utilisant l’enregistrement.
Fluentd
Fluentd est un collectionneur de journaux qui réside sur chaque service Red Hat OpenShift sur le nœud AWS. Il rassemble les journaux d’applications, d’infrastructures et d’audits et les transmet à différents extrants.
Collecte des ordures
La collecte des ordures est le processus de nettoyage des ressources en cluster, telles que les conteneurs terminés et les images qui ne sont pas référencées par les pods en cours d’exécution.
Elasticsearch
Elasticsearch est un moteur de recherche et d’analyse distribué. Le service OpenShift Red Hat sur AWS utilise Elasticsearch comme log store par défaut pour l’enregistrement.
L’opérateur OpenShift Elasticsearch
L’opérateur OpenShift Elasticsearch est utilisé pour exécuter un cluster Elasticsearch sur Red Hat OpenShift Service sur AWS. L’opérateur OpenShift Elasticsearch fournit un libre-service pour les opérations de cluster Elasticsearch et est utilisé par la journalisation.
Indexation
L’indexation est une technique de structure de données qui est utilisée pour localiser et accéder rapidement aux données. L’indexation optimise les performances en minimisant la quantité d’accès au disque nécessaire lors du traitement d’une requête.
Enregistrement de JSON
L’API Log Forwarding vous permet d’analyser les logs JSON dans un objet structuré et de les transmettre à Elasticsearch ou à tout autre système tiers pris en charge par l’API Log Forwarding.
Kibana
Kibana est une interface de console basée sur un navigateur pour interroger, découvrir et visualiser vos données Elasticsearch à travers des histogrammes, des graphiques linéaires et des graphiques à tartes.
Kubernetes serveur API
Kubernetes API serveur valide et configure les données pour les objets API.
Étiquettes
Les étiquettes sont des paires clé-valeur que vous pouvez utiliser pour organiser et sélectionner des sous-ensembles d’objets, tels qu’un pod.
L’exploitation forestière
Avec l’enregistrement, vous pouvez agréger les journaux d’applications, d’infrastructures et d’audits tout au long de votre cluster. De plus, vous pouvez les stocker dans un log store par défaut, les transférer vers des systèmes tiers, interroger et visualiser les journaux stockés dans le log store par défaut.
Collecteur d’enregistrement
Le collecteur d’enregistrement recueille les journaux du cluster, les formate et les transmet au log store ou aux systèmes tiers.
Log Store
Le log store est utilisé pour stocker des journaux agrégés. Il est possible d’utiliser un log store interne ou de transférer des journaux vers des logs externes.
Journal visualiseur
Le visualiseur de journal est le composant de l’interface utilisateur (UI) que vous pouvez utiliser pour afficher des informations telles que des journaux, des graphiques, des graphiques et d’autres métriques.
Le nœud
Le nœud est une machine de travail dans le Red Hat OpenShift Service sur AWS cluster. Le nœud est soit une machine virtuelle (VM) soit une machine physique.
Opérateurs
Les opérateurs sont la méthode préférée d’emballage, de déploiement et de gestion d’une application Kubernetes dans un service Red Hat OpenShift sur AWS cluster. L’opérateur utilise les connaissances opérationnelles humaines et l’encode dans un logiciel qui est emballé et partagé avec les clients.
La pod
La gousse est la plus petite unité logique de Kubernetes. La gousse se compose d’un ou de plusieurs conteneurs et fonctionne sur un nœud ouvrier.
Contrôle d’accès basé sur le rôle (RBAC)
Le RBAC est un contrôle de sécurité clé pour s’assurer que les utilisateurs de clusters et les charges de travail n’ont accès qu’aux ressources nécessaires à l’exécution de leurs rôles.
Des éclats
Elasticsearch organise les données de log de Fluentd en datastores, ou indices, puis subdivise chaque index en plusieurs morceaux appelés shards.
La tainte
Les taintes s’assurent que les gousses sont programmées sur les nœuds appropriés. Il est possible d’appliquer une ou plusieurs taintes sur un nœud.
La tolérance
Il est possible d’appliquer des tolérances aux pods. Les tolérances permettent au planificateur de programmer des pods avec des taintes correspondantes.
Console Web
Interface utilisateur (UI) pour gérer Red Hat OpenShift Service sur AWS. La console Web pour Red Hat OpenShift Service sur AWS se trouve à https://console.redhat.com/openshift.

Legal Notice
Copier lien

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

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