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 libération distinct du noyau OpenShift Dedicated. 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. Enregistrement 5,9.7

Cette version inclut OpenShift Logging Bug Fix Release 5.9.7.

1.1.1.1. Corrections de bogues

  • Avant cette mise à jour, le paramètre clusterlogforwarder.spec.outputs.http.timeout n’était pas appliqué à la configuration Fluentd lorsque Fluentd a été utilisé comme type de collecteur, ce qui entraîne une mauvaise configuration des timeouts HTTP. Avec cette mise à jour, le paramètre clusterlogforwarder.spec.outputs.http.timeout est maintenant correctement appliqué, assurant que Fluentd honore le délai spécifié et gère les connexions HTTP en fonction de la configuration de l’utilisateur. (LOG-6125)
  • Avant cette mise à jour, la section TLS a été ajoutée sans vérifier le schéma d’URL de courtier, entraînant des erreurs de connexion SSL si les URL ne commencaient pas par tls. Avec cette mise à jour, la section TLS n’est maintenant ajoutée que si les URL du courtier commencent par tls, empêchant ainsi les erreurs de connexion SSL. (LOG-6041)

1.1.1.2. CVEs

Note

Afin d’obtenir des informations détaillées sur les cotes de sécurité de Red Hat, examinez les cotes de gravité.

1.1.2. Enregistrement 5,9.6

Cette version inclut OpenShift Logging Bug Fix Release 5.9.6.

1.1.2.1. Corrections de bogues

  • Avant cette mise à jour, le déploiement du collecteur ignorait les changements secrets, ce qui faisait que les récepteurs rejettent les journaux. Avec cette mise à jour, le système déploie un nouveau pod lorsqu’il y a un changement de valeur secrète, assurant que le collecteur recharge les secrets mis à jour. (LOG-5525)
  • Avant cette mise à jour, le vecteur ne pouvait pas analyser correctement les valeurs du champ qui incluaient un signe d’un seul dollar ($). Avec cette mise à jour, les valeurs de champ avec un signe d’un seul dollar sont automatiquement changées en deux signes dollars ($$), assurant une analyse appropriée par le vecteur. (LOG-5602)
  • Avant cette mise à jour, le filtre de chute ne pouvait pas gérer les valeurs non-string (par exemple, .responseStatus.code: 403). Avec cette mise à jour, le filtre de chute fonctionne maintenant correctement avec ces valeurs. (LOG-5815)
  • Avant cette mise à jour, le collecteur utilisait les paramètres par défaut pour collecter les journaux d’audit, sans gérer le backload des récepteurs de sortie. Avec cette mise à jour, le processus de collecte des journaux d’audit a été amélioré afin de mieux gérer la gestion des fichiers et l’efficacité de la lecture des journaux. (LOG-5866)
  • Avant cette mise à jour, l’outil must-collectther a échoué sur les clusters avec des architectures non-AMD64 telles que Azure Resource Manager (ARM) ou PowerPC. Avec cette mise à jour, l’outil détecte maintenant l’architecture du cluster au moment de l’exécution et utilise des chemins et des dépendances indépendants de l’architecture. La détection permet à la collecte incontournable de fonctionner en douceur sur des plates-formes comme ARM et PowerPC. (LOG-5997)
  • Avant cette mise à jour, le niveau de journal était défini à l’aide d’un mélange de mots clés structurés et non structurés qui n’étaient pas clairs. Avec cette mise à jour, le niveau de journal suit un ordre clair et documenté, en commençant par des mots clés structurés. (LOG-6016)
  • Avant cette mise à jour, plusieurs pipelines sans nom écrivant à la sortie par défaut dans le ClusterLogForwarder ont causé une erreur de validation en raison des noms générés automatiquement dupliqués. Avec cette mise à jour, les noms de pipelines sont maintenant générés sans doublons. (LOG-6033)
  • Avant cette mise à jour, les pods collector n’avaient pas l’annotation PreferredScheduling. Avec cette mise à jour, l’annotation PreferredScheduling est ajoutée au collecteur daemonset. (LOG-6023)

1.1.2.2. CVEs

1.1.3. Enregistrement 5,9.5

Cette version inclut OpenShift Logging Bug Fix Release 5.9.5

1.1.3.1. Correction des bugs

  • Avant cette mise à jour, des conditions dupliquées dans le statut de ressource LokiStack ont conduit à des métriques invalides de l’opérateur Loki. Avec cette mise à jour, l’opérateur supprime les conditions du double de l’état. (LOG-5855)
  • Avant cette mise à jour, l’opérateur Loki n’a pas déclenché d’alertes lorsqu’il a abandonné les événements de journal en raison de défaillances de validation. Avec cette mise à jour, l’opérateur Loki inclut une nouvelle définition d’alerte qui déclenche une alerte si Loki abandonne les événements de journal en raison de défaillances de validation. (LOG-5895)
  • Avant cette mise à jour, l’opérateur Loki a remplacé les annotations utilisateur sur la ressource LokiStack Route, faisant tomber les personnalisations. Avec cette mise à jour, l’opérateur Loki n’écrase plus les annotations de Route, ce qui résout le problème. (LOG-5945)

1.1.3.2. CVEs

Aucun.

1.1.4. Journalisation 5.9.4

Cette version inclut OpenShift Logging Bug Fix Release 5.9.4

1.1.4.1. Correction des bugs

  • Avant cette mise à jour, une configuration de timeout mal formatée a causé le crash du plugin OCP. Avec cette mise à jour, une validation empêche le crash et informe l’utilisateur de la configuration incorrecte. (LOG-5373)
  • Avant cette mise à jour, les charges de travail avec des étiquettes contenant - ont causé une erreur dans le collecteur lors de la normalisation des entrées de journal. Avec cette mise à jour, le changement de configuration garantit que le collecteur utilise la syntaxe correcte. (LOG-5524)
  • Avant cette mise à jour, un problème empêchait de sélectionner des pods qui n’existaient plus, même s’ils avaient généré des journaux. Avec cette mise à jour, ce problème a été corrigé, permettant la sélection de ces pods. (LOG-5697)
  • Avant cette mise à jour, l’opérateur Loki se bloquerait si la spécification CredentialRequest était enregistrée dans un environnement sans l’opérateur cloud-credentials-operator. Avec cette mise à jour, la spécification CredentialRequest ne s’inscrit que dans des environnements qui sont activés par l’opérateur cloud-credentials-operator. (LOG-5701)
  • Avant cette mise à jour, l’opérateur de journalisation a regardé et traité toutes les cartes de configuration à travers le cluster. Avec cette mise à jour, le contrôleur de tableau de bord ne regarde que la carte de configuration du tableau de bord de journalisation. (LOG-5702)
  • Avant cette mise à jour, le ClusterLogForwarder a introduit un espace supplémentaire dans la charge utile du message qui ne respectait pas la spécification RFC3164. Avec cette mise à jour, l’espace supplémentaire a été supprimé, fixant le problème. (LOG-5707)
  • Avant cette mise à jour, la suppression de l’ensemencement pour grafana-dashboard-cluster-logement dans le cadre de (LOG-5308) a brisé de nouveaux déploiements greenfield sans tableau de bord. Avec cette mise à jour, l’opérateur d’enregistrement ensemencé le tableau de bord au début et continue de le mettre à jour pour les changements. (LOG-5747)
  • Avant cette mise à jour, LokiStack manquait une route pour l’API Volume causant l’erreur suivante : 404 introuvables. Avec cette mise à jour, LokiStack expose l’API Volume, résolvant le problème. (LOG-5749)

1.1.4.2. CVEs

CVE-2024-24790

1.1.5. Journalisation 5.9.3

Cette version inclut OpenShift Logging Bug Fix Release 5.9.3

1.1.5.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.5.2. CVEs

1.1.6. Enregistrement de l’enregistrement 5.9.2

Cette version inclut OpenShift Logging Bug Fix Release 5.9.2

1.1.6.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.6.2. CVEs

1.1.7. Journalisation 5.9.1

Cette version inclut OpenShift Logging Bug Fix Release 5.9.1

1.1.7.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.7.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.7.3. CVEs

Il n’y a pas de VEC.

1.1.8. Journalisation 5.9.0

Cette version inclut OpenShift Logging Bug Fix Release 5.9.0

1.1.8.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.8.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 d’OpenShift Dedicated. 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.8.3. Améliorations

1.1.8.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.8.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 store pour STS activé OpenShift Dedicated 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.8.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.8.5. Les problèmes connus

Aucun.

1.1.8.6. CVEs

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