Chapitre 2. Enregistrement 5.6

2.1. Notes de version sur la journalisation 5.6

Note

Le sous-système de journalisation pour Red Hat OpenShift est fourni en tant que composant installable, avec un cycle de publication distinct de celui de la plateforme principale OpenShift Container Platform. La politique de cycle de vie de Red Hat OpenShift Container Platform décrit la compatibilité des versions.

Note

Le canal stable ne fournit des mises à jour que pour la version la plus récente du logiciel d'exploitation. Pour continuer à recevoir les mises à jour des versions antérieures, vous devez changer votre canal d'abonnement pour stable-X, où X est la version de l'exploitation que vous avez installée.

2.1.1. Journalisation 5.6.4

Cette version inclut la version 5.6.4 de la correction des bugs de journalisation d'OpenShift.

2.1.1.1. Bug fixes

Avant cette mise à jour, lorsque LokiStack était déployé comme magasin de logs, les logs générés par les pods Loki étaient collectés et envoyés à LokiStack. Avec cette mise à jour, les logs générés par Loki sont exclus de la collecte et ne seront pas stockés.(LOG-3280)
Avant cette mise à jour, lorsque l'éditeur de requêtes de la page Logs de l'OpenShift Web Console était vide, les menus déroulants ne s'affichaient pas. Avec cette mise à jour, si une requête vide est tentée, un message d'erreur s'affiche et les menus déroulants se remplissent maintenant comme prévu.(LOG-3454)
Avant cette mise à jour, lorsque l'option tls.insecureSkipVerify était définie sur true, l'opérateur de journalisation de cluster générait une configuration incorrecte. En conséquence, l'opérateur n'envoyait pas de données à Elasticsearch lorsqu'il tentait d'ignorer la validation du certificat. Avec cette mise à jour, le Cluster Logging Operator génère une configuration TLS correcte même lorsque tls.insecureSkipVerify est activé. Par conséquent, les données peuvent être envoyées avec succès à Elasticsearch même lorsque l'on tente d'ignorer la validation du certificat.(LOG-3475)
Avant cette mise à jour, lorsque l'analyse structurée était activée et que les messages étaient transmis à plusieurs destinations, ils n'étaient pas copiés en profondeur. Par conséquent, certains des journaux reçus incluaient le message structuré, tandis que d'autres ne le faisaient pas. Avec cette mise à jour, la génération de configuration a été modifiée pour copier en profondeur les messages avant l'analyse JSON. Par conséquent, tous les messages reçus contiennent désormais des messages structurés, même lorsqu'ils sont transmis à plusieurs destinations.(LOG-3640)
Avant cette mise à jour, si le champ collection contenait {}, l'opérateur pouvait se bloquer. Avec cette mise à jour, l'opérateur ignorera cette valeur, ce qui lui permettra de continuer à fonctionner sans interruption.(LOG-3733)
Avant cette mise à jour, l'attribut nodeSelector pour le composant Gateway de LokiStack n'avait aucun effet. Avec cette mise à jour, l'attribut nodeSelector fonctionne comme prévu.(LOG-3783)
Avant cette mise à jour, la configuration statique de la liste des membres de LokiStack reposait uniquement sur des réseaux IP privés. Par conséquent, lorsque le réseau de pods du cluster OpenShift Container Platform était configuré avec une plage d'IP publique, les pods LokiStack se bloquaient. Avec cette mise à jour, l'administrateur de LokiStack a maintenant la possibilité d'utiliser le réseau de pods pour la configuration de la liste des membres. Cela résout le problème et empêche les pods LokiStack d'entrer dans un état de crashloop lorsque le réseau de pods du cluster OpenShift Container Platform est configuré avec une plage d'IP publique.(LOG-3814)
Avant cette mise à jour, si le champ tls.insecureSkipVerify était défini sur true, l'opérateur de journalisation de cluster générait une configuration incorrecte. Par conséquent, l'opérateur n'envoyait pas de données à Elasticsearch lorsqu'il tentait d'ignorer la validation du certificat. Avec cette mise à jour, l'opérateur génère une configuration TLS correcte même lorsque tls.insecureSkipVerify est activé. Par conséquent, les données peuvent être envoyées avec succès à Elasticsearch même lorsque l'on tente d'ignorer la validation du certificat.(LOG-3838)
Avant cette mise à jour, si le Cluster Logging Operator (CLO) était installé sans l'Elasticsearch Operator, le pod CLO affichait en permanence un message d'erreur lié à la suppression d'Elasticsearch. Avec cette mise à jour, le CLO effectue désormais des vérifications supplémentaires avant d'afficher des messages d'erreur. Par conséquent, les messages d'erreur liés à la suppression d'Elasticsearch ne sont plus affichés en l'absence de l'opérateur Elasticsearch.(LOG-3763)

2.1.1.2. CVE

2.1.2. Journalisation 5.6.3

Cette version inclut la version 5.6.3 de la correction des bugs de journalisation d'OpenShift.

2.1.2.1. Bug fixes

Avant cette mise à jour, l'opérateur stockait les informations relatives au secret du locataire de la passerelle dans une carte de configuration. Avec cette mise à jour, l'opérateur stocke ces informations dans un secret.(LOG-3717)
Avant cette mise à jour, le collecteur Fluentd ne capturait pas les événements de connexion OAuth stockés dans /var/log/auth-server/audit.log. Avec cette mise à jour, Fluentd capture ces événements de connexion OAuth, ce qui résout le problème.(LOG-3729)

2.1.2.2. CVE

2.1.3. Journalisation 5.6.2

Cette version inclut la version 5.6.2 de la correction des bugs de journalisation d'OpenShift.

2.1.3.1. Bug fixes

Avant cette mise à jour, le collecteur ne définissait pas correctement les champs level en fonction de la priorité des journaux systemd. Avec cette mise à jour, les champs level sont définis correctement.(LOG-3429)
Avant cette mise à jour, l'Opérateur générait incorrectement des avertissements d'incompatibilité sur OpenShift Container Platform 4.12 ou plus récent. Avec cette mise à jour, la valeur de la version max OpenShift Container Platform de l'Opérateur a été corrigée, ce qui résout le problème.(LOG-3584)
Avant cette mise à jour, la création d'une ressource personnalisée (CR) ClusterLogForwarder avec une valeur de sortie de default ne générait aucune erreur. Avec cette mise à jour, un avertissement d'erreur indiquant que cette valeur n'est pas valide est généré de manière appropriée.(LOG-3437)
Avant cette mise à jour, lorsque la ressource personnalisée (CR) ClusterLogForwarder avait plusieurs pipelines configurés avec une sortie définie comme default, les pods collecteurs redémarraient. Avec cette mise à jour, la logique de validation des sorties a été corrigée, ce qui résout le problème.(LOG-3559)
Avant cette mise à jour, les pods collecteurs redémarraient après avoir été créés. Avec cette mise à jour, le collecteur déployé ne redémarre pas de lui-même.(LOG-3608)
Avant cette mise à jour, les versions des correctifs supprimaient les versions précédentes des opérateurs du catalogue. Cela rendait l'installation des anciennes versions impossible. Cette mise à jour modifie les configurations des paquets de sorte que les versions précédentes de la même version mineure restent dans le catalogue.(LOG-3635)

2.1.3.2. CVE

2.1.4. Journalisation 5.6.1

Cette version inclut la version 5.6.1 de la correction des bugs de journalisation d'OpenShift.

2.1.4.1. Bug fixes

Avant cette mise à jour, le compacteur signalait des erreurs de certificat TLS lors des communications avec l'interrogateur lorsque la rétention était active. Avec cette mise à jour, le compacteur et l'interrogateur ne communiquent plus de manière erronée via HTTP.(LOG-3494)
Avant cette mise à jour, l'opérateur Loki ne réessayait pas de définir l'état de LokiStack CR, ce qui entraînait des informations d'état périmées. Avec cette mise à jour, l'opérateur réessaie de mettre à jour les informations d'état en cas de conflit.(LOG-3496)
Avant cette mise à jour, le serveur Webhook de l'opérateur Loki provoquait des erreurs TLS lorsque l'opérateur kube-apiserver-operator vérifiait la validité du webhook. Avec cette mise à jour, l'ICP du webhook de l'opérateur Loki est gérée par le gestionnaire du cycle de vie de l'opérateur (OLM), ce qui résout le problème.(LOG-3510)
Avant cette mise à jour, le LokiStack Gateway Labels Enforcer générait des erreurs d'analyse pour les requêtes LogQL valides lors de l'utilisation de filtres d'étiquettes combinés avec des expressions booléennes. Avec cette mise à jour, l'implémentation LogQL de LokiStack prend en charge les filtres d'étiquettes avec des expressions booléennes et résout le problème.(LOG-3441),(LOG-3397)
Avant cette mise à jour, les enregistrements écrits dans Elasticsearch échouaient si plusieurs clés d'étiquettes avaient le même préfixe et si certaines clés comportaient des points. Avec cette mise à jour, les traits de soulignement remplacent les points dans les clés d'étiquettes, ce qui résout le problème.(LOG-3463)
Avant cette mise à jour, l'opérateur Red Hat OpenShift Logging n'était pas disponible pour les clusters OpenShift Container Platform 4.10 en raison d'une incompatibilité entre la console OpenShift Container Platform et le plugin logging-view. Avec cette mise à jour, le plugin est correctement intégré à la console d'administration d'OpenShift Container Platform 4.10.(LOG-3447)
Avant cette mise à jour, la réconciliation de la ressource personnalisée ClusterLogForwarder signalait de manière incorrecte un état dégradé des pipelines qui font référence au logstore par défaut. Avec cette mise à jour, le pipeline est validé correctement.(LOG-3477)

2.1.4.2. CVE

2.1.5. Journalisation 5.6.0

Cette version inclut la version 5.6 d'OpenShift Logging.

2.1.5.1. Avis de dépréciation

Dans la version 5.6 de Logging, Fluentd est obsolète et il est prévu de le supprimer dans une prochaine version. Red Hat fournira des corrections de bogues et une assistance pour cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne recevra plus d'améliorations et sera supprimée. Comme alternative à Fluentd, vous pouvez utiliser Vector.

2.1.5.2. Améliorations

Avec cette mise à jour, la journalisation est conforme aux politiques cryptographiques à l'échelle du cluster d'OpenShift Container Platform.(LOG-895)
Avec cette mise à jour, vous pouvez déclarer des politiques de rétention par locataire, par flux et globales via la ressource personnalisée LokiStack, classées par ordre de priorité.(LOG-2695)
Avec cette mise à jour, Splunk est une option de sortie disponible pour le transfert de logs.(LOG-2913)
Avec cette mise à jour, Vector remplace Fluentd comme collecteur par défaut.(LOG-2222)
Avec cette mise à jour, le rôle Developer peut accéder aux journaux de charge de travail par projet auxquels ils sont affectés dans le plugin Log Console sur les clusters exécutant OpenShift Container Platform 4.11 et plus.(LOG-3388)
Avec cette mise à jour, les logs de n'importe quelle source contiennent un champ openshift.cluster_id, l'identifiant unique du cluster dans lequel l'Opérateur est déployé. Vous pouvez visualiser la valeur de clusterID à l'aide de la commande ci-dessous.(LOG-2715)

$ oc get clusterversion/version -o jsonpath='{.spec.clusterID}{"\n"}'

2.1.5.3. Problèmes connus

Avant cette mise à jour, Elasticsearch rejetait les journaux si plusieurs clés de label avaient le même préfixe et si certaines clés incluaient le caractère .. Cette mise à jour corrige la limitation d'Elasticsearch en remplaçant . dans les clés d'étiquettes par _. Pour contourner ce problème, supprimez les étiquettes qui provoquent des erreurs ou ajoutez un espace de noms à l'étiquette.(LOG-3463)

2.1.5.4. Bug fixes

Avant cette mise à jour, si vous supprimiez la ressource personnalisée Kibana, la console web de OpenShift Container Platform continuait à afficher un lien vers Kibana. Avec cette mise à jour, la suppression de la ressource personnalisée Kibana supprime également ce lien.(LOG-2993)
Avant cette mise à jour, un utilisateur n'était pas en mesure de voir les journaux d'application des espaces de noms auxquels il avait accès. Avec cette mise à jour, l'opérateur Loki crée automatiquement un rôle de cluster et un lien de rôle de cluster permettant aux utilisateurs de lire les journaux d'application.(LOG-3072)
Avant cette mise à jour, l'opérateur supprimait toutes les sorties personnalisées définies dans la ressource personnalisée ClusterLogForwarder lorsqu'il utilisait LokiStack comme stockage de logs par défaut. Avec cette mise à jour, l'opérateur fusionne les sorties personnalisées avec les sorties par défaut lors du traitement de la ressource personnalisée ClusterLogForwarder.(LOG-3090)
Avant cette mise à jour, la clé de l'autorité de certification était utilisée comme nom de volume pour le montage de l'autorité de certification dans Loki, ce qui provoquait des états d'erreur lorsque la clé de l'autorité de certification comprenait des caractères non conformes, tels que des points. Avec cette mise à jour, le nom de volume est normalisé à une chaîne interne, ce qui résout le problème.(LOG-3331)
Avant cette mise à jour, une valeur par défaut définie dans la définition des ressources personnalisées de LokiStack entraînait l'impossibilité de créer une instance de LokiStack sans ReplicationFactor de 1. Avec cette mise à jour, l'opérateur définit la valeur réelle de la taille utilisée.(LOG-3296)
Avant cette mise à jour, Vector analysait le champ message lorsque l'analyse JSON était activée sans définir les valeurs structuredTypeKey ou structuredTypeName. Avec cette mise à jour, une valeur est requise pour structuredTypeKey ou structuredTypeName lors de l'écriture de journaux structurés dans Elasticsearch.(LOG-3195)
Avant cette mise à jour, le composant de création de secret de l'Elasticsearch Operator modifiait constamment les secrets internes. Avec cette mise à jour, le secret existant est correctement géré.(LOG-3161)
Avant cette mise à jour, l'opérateur pouvait entrer dans une boucle de suppression et de recréation du daemonset du collecteur pendant que les déploiements Elasticsearch ou Kibana changeaient d'état. Avec cette mise à jour, une correction dans la gestion de l'état de l'opérateur résout le problème.(LOG-3157)
Avant cette mise à jour, Kibana avait un délai d'expiration du cookie OAuth fixe 24h, ce qui entraînait des erreurs 401 dans Kibana chaque fois que le champ accessTokenInactivityTimeout était défini sur une valeur inférieure à 24h. Avec cette mise à jour, le délai d'expiration du cookie OAuth de Kibana se synchronise sur le champ accessTokenInactivityTimeout, avec une valeur par défaut de 24h.(LOG-3129)
Avant cette mise à jour, le modèle général des opérateurs pour le rapprochement des ressources consistait à essayer de créer un objet avant d'essayer de l'obtenir ou de le mettre à jour, ce qui entraînait des réponses HTTP 409 constantes après la création. Avec cette mise à jour, les opérateurs tentent d'abord de récupérer un objet et ne le créent ou ne le mettent à jour que s'il est manquant ou différent de ce qui a été spécifié.(LOG-2919)
Avant cette mise à jour, les champs .level et`.structure.level` de Fluentd pouvaient contenir des valeurs différentes. Avec cette mise à jour, les valeurs sont les mêmes pour chaque champ.(LOG-2819)
Avant cette mise à jour, l'opérateur n'attendait pas que le groupe d'autorités de certification de confiance soit peuplé et déployait le collecteur une deuxième fois une fois le groupe mis à jour. Avec cette mise à jour, l'opérateur attend brièvement de voir si le groupe a été peuplé avant de poursuivre le déploiement du collecteur.(LOG-2789)
Avant cette mise à jour, les informations de télémétrie d'enregistrement apparaissaient deux fois lors de l'examen des métriques. Avec cette mise à jour, les informations de télémétrie s'affichent comme prévu.(LOG-2315)
Avant cette mise à jour, les logs de Fluentd pod contenaient un message d'avertissement après avoir activé l'ajout de l'analyse JSON. Avec cette mise à jour, ce message d'avertissement n'apparaît plus.(LOG-1806)
Avant cette mise à jour, le script must-gather ne s'exécutait pas car oc a besoin d'un dossier avec des droits d'écriture pour construire son cache. Avec cette mise à jour, oc a les droits d'écriture sur un dossier et le script must-gather s'exécute correctement.(LOG-3446)
Avant cette mise à jour, le SCC du collecteur de journaux pouvait être remplacé par d'autres SCC sur le cluster, rendant le collecteur inutilisable. Cette mise à jour définit la priorité du SCC du collecteur de journaux de manière à ce qu'il soit prioritaire sur les autres.(LOG-3235)
Avant cette mise à jour, il manquait à Vector le champ sequence, qui a été ajouté à fluentd pour pallier le manque de précision des nanosecondes. Avec cette mise à jour, le champ openshift.sequence a été ajouté aux journaux d'événements.(LOG-3106)