Chapitre 1. Libération des notes

1.1. Journalisation 5,9

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

Cette version inclut OpenShift Logging Bug Fix Release 5.9.3

1.1.1.1. Correction des bugs

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

1.1.2. Enregistrement de l’enregistrement 5.9.2

Cette version inclut OpenShift Logging Bug Fix Release 5.9.2

1.1.2.1. Correction des bugs

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

1.1.3. Journalisation 5.9.1

Cette version inclut OpenShift Logging Bug Fix Release 5.9.1

1.1.3.1. Améliorations

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

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

Il n’y a pas de VEC.

1.1.4. Journalisation 5.9.0

Cette version inclut OpenShift Logging Bug Fix Release 5.9.0

1.1.4.1. Avis de renvoi

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

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

1.1.4.3.1. Collection de journaux

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

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

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

Aucun.

1.1.4.6. CVEs

Retour au début