SupportConsoleDéveloppeursCommencer un essaiContact

1.56. OpenShift Logging 5.2.0

Cette version inclut RHBA-2021:3393 OpenShift Logging Bug Fix Release 5.2.0

1.56.1. Nouvelles fonctionnalités et améliorations

  • Avec cette mise à jour, vous pouvez transférer les données des journaux vers Amazon CloudWatch, qui assure la surveillance des applications et de l'infrastructure. Pour plus d'informations, voir Transférer les journaux vers Amazon CloudWatch.(LOG-1173)
  • Avec cette mise à jour, vous pouvez transférer les données des journaux vers Loki, un système d'agrégation de journaux multitenant, évolutif horizontalement et hautement disponible. Pour plus d'informations, voir Transférer les journaux vers Loki.(LOG-684)
  • Avec cette mise à jour, si vous utilisez le protocole de transfert Fluentd pour transférer des données de journal sur une connexion cryptée TLS, vous pouvez désormais utiliser un fichier de clé privée cryptée par mot de passe et spécifier la phrase de passe dans la configuration du Cluster Log Forwarder. Pour plus d'informations, voir Transférer des logs en utilisant le protocole Fluentd forward.(LOG-1525)
  • Cette amélioration vous permet d'utiliser un nom d'utilisateur et un mot de passe pour authentifier une connexion de transfert de protocole vers une instance Elasticsearch externe. Par exemple, si vous ne pouvez pas utiliser TLS mutuel (mTLS) 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. Pour plus d'informations, voir Transférer les logs vers une instance Elasticsearch externe.(LOG-1022)
  • Avec cette mise à jour, vous pouvez collecter les logs d'audit de la politique réseau OVN pour les transmettre à un serveur de journalisation.(LOG-1526)

  • Par défaut, le modèle de données introduit dans OpenShift Container Platform 4.5 donnait aux logs de différents espaces de noms un index unique en commun. Ce changement rendait plus difficile de voir quels espaces de noms produisaient le plus de logs.

    La version actuelle ajoute des métriques d'espace de noms au tableau de bord Logging dans la console OpenShift Container Platform. Avec ces métriques, vous pouvez voir quels espaces de noms produisent des logs et combien de logs chaque espace de noms produit pour un timestamp donné.

    Pour voir ces métriques, ouvrez la perspective Administrator dans la console web d'OpenShift Container Platform, et naviguez vers Observe Dashboards Logging/Elasticsearch...(LOG-1680)

  • La version actuelle, OpenShift Logging 5.2, permet deux nouvelles mesures : Pour un timestamp ou une durée donnée, vous pouvez voir le total des logs produits ou enregistrés par des conteneurs individuels, et le total des logs collectés par le collecteur. Ces mesures sont étiquetées par espace de noms, pod et nom de conteneur afin que vous puissiez voir combien de journaux chaque espace de noms et pod collecte et produit.(LOG-1213)

1.56.2. Bug fixes

  • Avant cette mise à jour, lorsque l'OpenShift Elasticsearch Operator créait des cronjobs de gestion d'index, il ajoutait la variable d'environnement POLICY_MAPPING deux fois, ce qui amenait l'apiserver à signaler la duplication. Cette mise à jour corrige le problème de sorte que la variable d'environnement POLICY_MAPPING n'est définie qu'une seule fois par cronjob, et qu'il n'y a pas de duplication signalée par l'apiserver.(LOG-1130)
  • Avant cette mise à jour, la suspension d'un cluster Elasticsearch à zéro nœud ne suspendait pas les cronjobs de gestion d'index, ce qui mettait ces cronjobs en backoff maximum. Ensuite, après la suspension du cluster Elasticsearch, ces cronjobs restaient interrompus en raison de l'atteinte du délai maximal. Cette mise à jour résout le problème en suspendant les cronjobs et le cluster.(LOG-1268)
  • Avant cette mise à jour, dans le tableau de bord Logging de la console OpenShift Container Platform, la liste des 10 premiers conteneurs produisant des logs ne comportait pas l'étiquette "chart namespace" et fournissait un nom de métrique incorrect, fluentd_input_status_total_bytes_logged. Avec cette mise à jour, le graphique affiche l'étiquette de l'espace de noms et le nom correct de la métrique, log_logged_bytes_total.(LOG-1271)
  • Avant cette mise à jour, si un cronjob de gestion d'index se terminait par une erreur, il ne signalait pas le code de sortie de l'erreur : à la place, son statut était "complete." Cette mise à jour résout le problème en signalant les codes de sortie d'erreur des cronjobs de gestion d'index qui se terminent par des erreurs.(LOG-1273)
  • Le site priorityclasses.v1beta1.scheduling.k8s.io a été supprimé dans la version 1.22 et remplacé par priorityclasses.v1.scheduling.k8s.io (v1beta1 a été remplacé par v1). Avant cette mise à jour, des alertes APIRemovedInNextReleaseInUse étaient générées pour priorityclasses car v1beta1 était toujours présent. Cette mise à jour résout le problème en remplaçant v1beta1 par v1. L'alerte n'est plus générée.(LOG-1385)
  • Auparavant, l'OpenShift Elasticsearch Operator et le Red Hat OpenShift Logging Operator ne disposaient pas de l'annotation requise pour apparaître dans la liste des opérateurs pouvant s'exécuter dans un environnement déconnecté de la console web d'OpenShift Container Platform. Cette mise à jour ajoute l'annotation operators.openshift.io/infrastructure-features: '["Disconnected"]' à ces deux opérateurs afin qu'ils apparaissent dans la liste des opérateurs qui s'exécutent dans des environnements déconnectés.(LOG-1420)
  • Avant cette mise à jour, les pods Red Hat OpenShift Logging Operator étaient planifiés sur des cœurs de CPU qui étaient réservés aux charges de travail des clients sur des clusters à nœud unique aux performances optimisées. Avec cette mise à jour, les pods de l'opérateur de journalisation de cluster sont planifiés sur les cœurs de CPU corrects.(LOG-1440)
  • Avant cette mise à jour, certaines entrées de journal contenaient des octets UTF-8 non reconnus, ce qui amenait Elasticsearch à rejeter les messages et à bloquer l'ensemble de la charge utile mise en mémoire tampon. Avec cette mise à jour, les charges utiles rejetées abandonnent les entrées de journal invalides et soumettent à nouveau les entrées restantes pour résoudre le problème.(LOG-1499)
  • Avant cette mise à jour, le pod kibana-proxy entrait parfois dans l'état CrashLoopBackoff et enregistrait le message suivant : Invalid configuration: cookie_secret must be 16, 24, or 32 bytes to create an AES cipher when pass_access_token == true or cookie_refresh != 0, but is 29 bytes. Le nombre exact d'octets peut varier. Avec cette mise à jour, la génération du secret de session Kibana a été corrigée, et le pod kibana-proxy n'entre plus dans l'état CrashLoopBackoff à cause de cette erreur.(LOG-1446)
  • Avant cette mise à jour, le plugin AWS CloudWatch Fluentd consignait ses appels API AWS dans le journal Fluentd à tous les niveaux de journal, ce qui consommait des ressources de nœuds OpenShift Container Platform supplémentaires. Avec cette mise à jour, le plugin AWS CloudWatch Fluentd enregistre les appels API AWS uniquement aux niveaux de journalisation "debug" et "trace". Ainsi, au niveau de journalisation par défaut "warn", Fluentd ne consomme pas de ressources de nœuds supplémentaires.(LOG-1071)
  • Avant cette mise à jour, le plugin de sécurité Elasticsearch OpenDistro provoquait l'échec des migrations d'index utilisateur. Cette mise à jour résout le problème en fournissant une version plus récente du plugin. Désormais, les migrations d'index se déroulent sans erreur.(LOG-1276)
  • Avant cette mise à jour, dans le tableau de bord Logging de la console OpenShift Container Platform, la liste des 10 premiers conteneurs produisant des logs manquait de points de données. Cette mise à jour résout le problème et le tableau de bord affiche tous les points de données.(LOG-1353)
  • Avant cette mise à jour, si vous ajustiez les performances du log forwarder Fluentd en ajustant les valeurs chunkLimitSize et totalLimitSize, le message Setting queued_chunks_limit_size for each buffer to indiquait des valeurs trop faibles. La mise à jour actuelle corrige ce problème de sorte que ce message signale les valeurs correctes.(LOG-1411)
  • Avant cette mise à jour, le plugin de sécurité Kibana OpenDistro provoquait l'échec des migrations d'index d'utilisateurs. Cette mise à jour résout le problème en fournissant une version plus récente du plugin. Désormais, les migrations d'index se déroulent sans erreur.(LOG-1558)
  • Avant cette mise à jour, l'utilisation d'un filtre d'entrée d'espace de noms empêchait les journaux de cet espace de noms d'apparaître dans d'autres entrées. Avec cette mise à jour, les journaux sont envoyés à toutes les entrées qui peuvent les accepter.(LOG-1570)
  • Avant cette mise à jour, un fichier de licence manquant pour la dépendance viaq/logerr provoquait l'abandon des scanners de licence sans succès. Avec cette mise à jour, la dépendance viaq/logerr est sous licence Apache 2.0 et les scanners de licence s'exécutent avec succès.(LOG-1590)
  • Avant cette mise à jour, une étiquette de brassage incorrecte pour curator5 dans le pipeline de construction de elasticsearch-operator-bundle provoquait l'extraction d'une image épinglée à un SHA1 factice. Avec cette mise à jour, le pipeline de construction utilise la référence logging-curator5-rhel8 pour curator5, ce qui permet aux cronjobs de gestion d'index d'extraire la bonne image de registry.redhat.io.(LOG-1624)
  • Avant cette mise à jour, un problème avec les permissions de ServiceAccount provoquait des erreurs telles que no permissions for [indices:admin/aliases/get]. Avec cette mise à jour, une correction des permissions résout le problème.(LOG-1657)
  • Avant cette mise à jour, la définition de ressource personnalisée (CRD) pour l'opérateur de journalisation Red Hat OpenShift manquait le type de sortie Loki, ce qui entraînait le rejet de l'objet de ressource personnalisée ClusterLogForwarder par le contrôleur d'admission. Avec cette mise à jour, le CRD inclut Loki comme type de sortie afin que les administrateurs puissent configurer ClusterLogForwarder pour envoyer les journaux à un serveur Loki.(LOG-1683)
  • Avant cette mise à jour, OpenShift Elasticsearch Operator reconciliation of the ServiceAccounts écrasait les champs appartenant à des tiers et contenant des secrets. Ce problème provoquait des pics de mémoire et de CPU en raison de la recréation fréquente des secrets. Cette mise à jour résout le problème. Désormais, l'OpenShift Elasticsearch Operator n'écrase plus les champs appartenant à des tiers.(LOG-1714)
  • Avant cette mise à jour, dans la définition de la ressource personnalisée (CR) ClusterLogging, si vous avez spécifié une valeur flush_interval mais n'avez pas défini flush_mode à interval, l'opérateur de journalisation Red Hat OpenShift a généré une configuration Fluentd. Cependant, le collecteur Fluentd a généré une erreur lors de l'exécution. Avec cette mise à jour, Red Hat OpenShift Logging Operator valide la définition ClusterLogging CR et génère la configuration Fluentd uniquement si les deux champs sont spécifiés.(LOG-1723)

1.56.3. Problèmes connus

  • Si vous transférez des logs vers un serveur Elasticsearch externe et que vous modifiez ensuite une valeur configurée dans le secret du pipeline, comme le nom d'utilisateur et le mot de passe, le forwarder Fluentd charge le nouveau secret mais utilise l'ancienne valeur pour se connecter à un serveur Elasticsearch externe. Ce problème se produit parce que l'opérateur de journalisation de Red Hat OpenShift ne surveille pas actuellement les secrets pour les changements de contenu.(LOG-1652)

    Comme solution de contournement, si vous changez le secret, vous pouvez forcer les pods Fluentd à se redéployer en entrant : 

    $ oc delete pod -l component=collector

1.56.4. Fonctionnalités obsolètes et supprimées

Certaines fonctionnalités disponibles dans les versions précédentes sont devenues obsolètes ou ont été supprimées.

Les fonctionnalités dépréciées sont toujours incluses dans OpenShift Logging et continuent d'être prises en charge ; cependant, elles seront supprimées dans une prochaine version de ce produit et ne sont pas recommandées pour les nouveaux déploiements.

1.56.5. Le transfert des journaux à l'aide des anciennes méthodes Fluentd et syslog a été supprimé

Depuis OpenShift Container Platform 4.6 jusqu'à aujourd'hui, l'envoi de logs en utilisant les méthodes suivantes a été déprécié et sera supprimé dans une prochaine version :

  • Transférer les journaux à l'aide de l'ancienne méthode Fluentd
  • Transférer les journaux à l'aide de la méthode syslog traditionnelle

Utilisez plutôt les méthodes non traditionnelles suivantes :

1.56.6. CVE

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.

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

© 2024 Red Hat, Inc.