Chapitre 1. Notes de mise à jour pour la journalisation
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.
1.1. Journalisation 5.6.4
Cette version inclut la version 5.6.4 de la correction des bugs de journalisation d'OpenShift.
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 surtrue, 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 lorsquetls.insecureSkipVerifyest 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
collectioncontenait{}, 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
nodeSelectorpour le composant Gateway de LokiStack n'avait aucun effet. Avec cette mise à jour, l'attributnodeSelectorfonctionne 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 surtrue, 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 lorsquetls.insecureSkipVerifyest 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)
