Enregistrement

Plate-forme de conteneurs OpenShift 4.12

Notes d'installation, d'utilisation et de mise à jour d'OpenShift Logging

Red Hat OpenShift Documentation Team

Résumé

Ce document fournit des instructions pour l'installation, la configuration et l'utilisation d'OpenShift Logging, qui regroupe les logs pour une gamme de services OpenShift Container Platform.

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 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)

1.1.2. CVE

1.2. Journalisation 5.6.3

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

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)

1.2.2. CVE

1.3. Journalisation 5.6.2

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

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)

1.3.2. CVE

1.4. Journalisation 5.6.1

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

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)

1.4.2. CVE

1.5. Enregistrement 5.6

Cette version inclut la version 5.6 d'OpenShift Logging.

1.5.1. Avis de dépréciation

Dans Logging 5.6, 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.

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"}'

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)

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)

1.5.5. CVE

1.6. Journalisation 5.5.10

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

1.6.1. Bug fixes

  • Avant cette mise à jour, le plugin logging view de l'OpenShift Web Console n'affichait qu'un texte d'erreur lorsque la LokiStack n'était pas joignable. Après cette mise à jour, le plugin affiche un message d'erreur approprié avec des détails sur la façon de réparer la LokiStack inaccessible.(LOG-2874)

1.6.2. CVE

1.7. Journalisation 5.5.9

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

1.7.1. Bug fixes

  • Avant cette mise à jour, un problème avec le collecteur Fluentd faisait qu'il ne capturait pas les événements de connexion OAuth stockés dans /var/log/auth-server/audit.log. Cela conduisait à une collecte incomplète des événements de connexion du service OAuth. Avec cette mise à jour, le collecteur Fluentd résout maintenant ce problème en capturant tous les événements de connexion du service OAuth, y compris ceux stockés dans /var/log/auth-server/audit.log, comme prévu.(LOG-3730)
  • 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 journaux reçus contiennent désormais des messages structurés, même lorsqu'ils sont transmis à plusieurs destinations.(LOG-3767)

1.7.2. CVE

1.8. Journalisation 5.5.8

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

1.8.1. Bug fixes

  • Avant cette mise à jour, le champ priority était absent des journaux systemd en raison d'une erreur dans la manière dont le collecteur définissait les champs level. Avec cette mise à jour, ces champs sont définis correctement, ce qui résout le problème.(LOG-3630)

1.8.2. CVE

1.9. Journalisation 5.5.7

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

1.9.1. Bug fixes

  • 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-3534)
  • Avant cette mise à jour, la ressource personnalisée (CR) ClusterLogForwarder ne transmettait pas les informations d'identification TLS pour la sortie syslog à Fluentd, ce qui entraînait des erreurs lors de la transmission. Avec cette mise à jour, les informations d'identification sont correctement transmises à Fluentd, ce qui résout le problème.(LOG-3533)

1.9.2. CVE

CVE-2021-46848CVE-2022-3821CVE-2022-35737CVE-2022-42010CVE-2022-42011CVE-2022-42012CVE-2022-42898CVE-2022-43680

1.10. Journalisation 5.5.6

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

1.10.1. Bug fixes

  • Avant cette mise à jour, le contrôleur d'admission Pod Security a ajouté le label podSecurityLabelSync = true à l'espace de noms openshift-logging. Les étiquettes de sécurité que nous avions spécifiées étaient donc écrasées et les pods Collector ne démarraient pas. Avec cette mise à jour, l'étiquette podSecurityLabelSync = false préserve les étiquettes de sécurité. Les pods du collecteur se déploient comme prévu.(LOG-3340)
  • Avant cette mise à jour, l'opérateur installait le plugin d'affichage de la console, même s'il n'était pas activé sur le cluster. Cela provoquait le plantage de l'opérateur. Avec cette mise à jour, si un compte pour un cluster n'a pas la vue console activée, l'Opérateur fonctionne normalement et n'installe pas la vue console.(LOG-3407)
  • Avant cette mise à jour, une correction antérieure visant à prendre en charge une régression dans laquelle le statut du déploiement d'Elasticsearch n'était pas mis à jour entraînait un plantage de l'opérateur à moins que le site Red Hat Elasticsearch Operator ne soit déployé. Avec cette mise à jour, cette correction a été annulée de sorte que l'opérateur est maintenant stable mais réintroduit le problème précédent lié à l'état rapporté.(LOG-3428)
  • Avant cette mise à jour, l'Opérateur Loki ne déployait qu'une seule réplique de la passerelle LokiStack quelle que soit la taille de la pile choisie. Avec cette mise à jour, le nombre de répliques est correctement configuré en fonction de la taille choisie.(LOG-3478)
  • 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-3341)
  • Avant cette mise à jour, le plugin logging view contenait une fonctionnalité incompatible avec certaines versions d'OpenShift Container Platform. Avec cette mise à jour, la version correcte du plugin résout le problème.(LOG-3467)
  • Avant cette mise à jour, la réconciliation de la ressource personnalisée ClusterLogForwarder signalait de manière incorrecte un état dégradé d'un ou de plusieurs pipelines, ce qui entraînait le redémarrage des pods collecteurs toutes les 8 à 10 secondes. Avec cette mise à jour, la réconciliation de la ressource personnalisée ClusterLogForwarder se déroule correctement, ce qui résout le problème.(LOG-3469)
  • Avant cette modification, la spécification du champ outputDefaults de la ressource personnalisée ClusterLogForwarder appliquait les paramètres à chaque type de sortie Elasticsearch déclaré. Ce changement corrige le comportement pour correspondre à la spécification d'amélioration où le paramètre s'applique spécifiquement au magasin Elasticsearch géré par défaut.(LOG-3342)
  • Avant cette mise à jour, le script must-gather de l'OpenShift CLI (oc) ne se terminait pas car l'OpenShift CLI (oc) a besoin d'un dossier avec des droits d'écriture pour construire son cache. Avec cette mise à jour, l'OpenShift CLI (oc) a des droits d'écriture sur un dossier, et le script must-gather se termine avec succès.(LOG-3472)
  • Avant cette mise à jour, le serveur webhook de Loki Operator provoquait des erreurs TLS. Avec cette mise à jour, l'ICP du webhook de Loki Operator est gérée par la gestion dynamique du webhook de Operator Lifecycle Manager, ce qui résout le problème.(LOG-3511)

1.10.2. CVE

1.11. Journalisation 5.5.5

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

1.11.1. Bug fixes

  • 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-3305)
  • 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-3284)
  • Avant cette mise à jour, l'alerte FluentdQueueLengthIncreasing pouvait ne pas se déclencher en cas de problème de cardinalité avec l'ensemble des étiquettes renvoyées par cette expression d'alerte. Cette mise à jour réduit les étiquettes pour n'inclure que celles nécessaires à l'alerte.(LOG-3226)
  • Avant cette mise à jour, Loki n'avait pas de support pour atteindre un stockage externe dans un cluster déconnecté. Avec cette mise à jour, les variables d'environnement proxy et les bundles d'autorité de certification proxy sont inclus dans l'image du conteneur pour prendre en charge ces connexions.(LOG-2860)
  • Avant cette mise à jour, les utilisateurs de la console web d'OpenShift Container Platform ne pouvaient pas choisir l'objet ConfigMap qui inclut le certificat CA pour Loki, ce qui faisait que les pods fonctionnaient sans le CA. Avec cette mise à jour, les utilisateurs de la console web peuvent sélectionner la carte de configuration, ce qui résout le problème.(LOG-3310)
  • 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 erreurs lorsque la clé de l'autorité de certification comportait 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-3332)

1.11.2. CVE

1.12. Journalisation 5.5.4

Cette version inclut la version 5.5.4 de la correction des bogues de journalisation d'OpenShift (RHSA-2022:7434).

1.12.1. Bug fixes

  • Avant cette mise à jour, une erreur dans l'analyseur de requêtes du plugin logging view entraînait la disparition de certaines parties de la requête de logs si celle-ci contenait des parenthèses curly {}. Cela rendait les requêtes invalides, ce qui entraînait le renvoi d'erreurs pour des requêtes valides. Avec cette mise à jour, l'analyseur traite correctement ces requêtes.(LOG-3042)
  • 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 du statut de l'opérateur résout le problème.(LOG-3049)
  • Avant cette mise à jour, aucune alerte n'était mise en œuvre pour prendre en charge l'implémentation du collecteur Vector. Cette modification ajoute des alertes Vector et déploie des alertes distinctes, en fonction de l'implémentation du collecteur choisie.(LOG-3127)
  • 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-3138)
  • Avant cette mise à jour, une refonte des scripts de journalisation must-gather a supprimé l'emplacement prévu pour les artefacts. Cette mise à jour annule ce changement pour écrire les artefacts dans le dossier /must-gather.(LOG-3213)
  • Avant cette mise à jour, sur certains clusters, l'exportateur Prometheus se liait à IPv4 au lieu d'IPv6. Après cette mise à jour, Fluentd détecte la version IP et se lie à 0.0.0.0 pour IPv4 ou [::] pour IPv6.(LOG-3162)

1.12.2. CVE

1.13. Journalisation 5.5.3

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

1.13.1. Bug fixes

  • Avant cette mise à jour, les entrées de journal comportant des messages structurés incluaient le champ du message original, ce qui augmentait la taille de l'entrée. Cette mise à jour supprime le champ de message pour les journaux structurés afin de réduire la taille de l'entrée.(LOG-2759)
  • Avant cette mise à jour, la configuration du collecteur excluait les journaux des pods collector, default-log-store, et visualization, mais n'était pas en mesure d'exclure les journaux archivés dans un fichier .gz. Avec cette mise à jour, les journaux archivés stockés dans les fichiers .gz des pods collector, default-log-store et visualization sont également exclus.(LOG-2844)
  • Avant cette mise à jour, lorsque des requêtes vers un pod indisponible étaient envoyées via la passerelle, aucune alerte ne prévenait de l'interruption. Avec cette mise à jour, des alertes individuelles seront générées si la passerelle a des problèmes pour terminer une requête d'écriture ou de lecture.(LOG-2884)
  • Avant cette mise à jour, les métadonnées de pods pouvaient être modifiées par des plugins fluents car les valeurs passaient par le pipeline par référence. Cette mise à jour assure que chaque message de log reçoit une copie des métadonnées du pod afin que chaque message soit traité indépendamment.(LOG-3046)
  • Avant cette mise à jour, la sélection de la gravité unknown dans la vue des journaux de la console OpenShift excluait les journaux avec une valeur level=unknown. Avec cette mise à jour, les journaux sans niveau et avec des valeurs level=unknown sont visibles lors du filtrage par gravité unknown.(LOG-3062)
  • Avant cette mise à jour, les enregistrements de logs envoyés à Elasticsearch avaient un champ supplémentaire nommé write-index qui contenait le nom de l'index vers lequel les logs devaient être envoyés. Ce champ ne fait pas partie du modèle de données. Après cette mise à jour, ce champ n'est plus envoyé.(LOG-3075)
  • Avec l'introduction du nouveau contrôleur d'admission à la sécurité des pods intégré, les pods qui ne sont pas configurés conformément aux normes de sécurité définies globalement ou au niveau de l'espace de noms ne peuvent pas être exécutés. Avec cette mise à jour, l'opérateur et les collecteurs permettent une exécution privilégiée et s'exécutent sans avertissement ni erreur d'audit de sécurité.(LOG-3077)
  • 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-3095)

1.13.2. CVE

1.14. Journalisation 5.5.2

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

1.14.1. Bug fixes

  • Avant cette mise à jour, les règles d'alerte pour le collecteur Fluentd n'adhéraient pas aux directives de style de surveillance de OpenShift Container Platform. Cette mise à jour modifie ces alertes pour inclure l'étiquette de l'espace de noms, ce qui résout le problème.(LOG-1823)
  • Avant cette mise à jour, le script de basculement de la gestion des index ne parvenait pas à générer un nouveau nom d'index lorsque le nom de l'index comportait plus d'un trait d'union. Avec cette mise à jour, les noms d'index sont générés correctement.(LOG-2644)
  • Avant cette mise à jour, la route Kibana définissait une valeur caCertificate sans qu'un certificat soit présent. Avec cette mise à jour, aucune valeur caCertificate n'est définie.(LOG-2661)
  • Avant cette mise à jour, un changement dans les dépendances du collecteur provoquait l'émission d'un message d'avertissement pour les paramètres non utilisés. Avec cette mise à jour, la suppression des paramètres de configuration inutilisés résout le problème.(LOG-2859)
  • Avant cette mise à jour, les pods créés pour les déploiements créés par l'opérateur Loki étaient planifiés par erreur sur des nœuds avec des systèmes d'exploitation non-Linux, si de tels nœuds étaient disponibles dans le cluster dans lequel l'opérateur s'exécutait. Avec cette mise à jour, l'opérateur attache un sélecteur de nœud supplémentaire aux définitions de pods qui permet uniquement de planifier les pods sur des nœuds basés sur Linux.(LOG-2895)
  • Avant cette mise à jour, la vue Logs de la console OpenShift ne filtrait pas les logs par gravité en raison d'un problème d'analyseur LogQL dans la passerelle LokiStack. Avec cette mise à jour, un correctif d'analyseur résout le problème et la vue Logs de la console OpenShift peut filtrer par gravité.(LOG-2908)
  • Avant cette mise à jour, une refonte des plugins du collecteur Fluentd a supprimé le champ timestamp pour les événements. Cette mise à jour rétablit le champ timestamp, qui provient de l'heure de réception de l'événement.(LOG-2923)
  • Avant cette mise à jour, l'absence d'un champ level dans les journaux d'audit provoquait une erreur dans les journaux vectoriels. Avec cette mise à jour, l'ajout d'un champ level dans l'enregistrement du journal d'audit résout le problème.(LOG-2961)
  • 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-3053)
  • Avant cette mise à jour, chaque travail de basculement créait des index vides lorsque la ressource personnalisée ClusterLogForwarder avait une analyse JSON définie. Avec cette mise à jour, les nouveaux index ne sont pas vides(LOG-3063)
  • Avant cette mise à jour, lorsque l'utilisateur supprimait la LokiStack après une mise à jour vers Loki Operator 5.5, les ressources créées à l'origine par Loki Operator 5.4 étaient conservées. Avec cette mise à jour, les références propriétaires des ressources pointent vers la LokiStack 5.5.(LOG-2945)
  • 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-2918)
  • Avant cette mise à jour, les utilisateurs ayant des privilèges d'administrateur de cluster n'étaient pas en mesure de visualiser correctement les journaux d'infrastructure et d'audit à l'aide de la console de journalisation. Avec cette mise à jour, le contrôle des autorisations a été étendu pour reconnaître également les utilisateurs des groupes cluster-admin et dedicated-admin en tant qu'administrateurs.(LOG-2970)

1.14.2. CVE

1.15. Journalisation 5.5.1

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

1.15.1. Améliorations

  • Cette amélioration ajoute un onglet Aggregated Logs à la page Pod Details de la console web d'OpenShift Container Platform lorsque le plugin Logging Console est utilisé. Cette amélioration n'est disponible que sur OpenShift Container Platform 4.10 et plus.(LOG-2647)
  • Cette amélioration ajoute Google Cloud Logging comme option de sortie pour la redirection des journaux.(LOG-1482)

1.15.2. Bug fixes

  • Avant cette mise à jour, l'opérateur ne s'assurait pas que le module était prêt, ce qui entraînait un état inopérant du cluster lors d'un redémarrage. Avec cette mise à jour, l'opérateur marque les nouveaux pods comme étant prêts avant de passer à un nouveau pod lors d'un redémarrage, ce qui résout le problème.(LOG-2745)
  • Avant cette mise à jour, Fluentd ne reconnaissait parfois pas que la plateforme Kubernetes effectuait une rotation du fichier de log et ne lisait plus les messages de log. Cette mise à jour corrige cela en définissant le paramètre de configuration suggéré par l'équipe de développement en amont.(LOG-2995)
  • Avant cette mise à jour, l'ajout de la détection des erreurs multilignes entraînait une modification du routage interne et l'acheminement des enregistrements vers la mauvaise destination. Avec cette mise à jour, le routage interne est correct.(LOG-2801)
  • Avant cette mise à jour, la modification de l'intervalle de rafraîchissement de la console web d'OpenShift Container Platform créait une erreur lorsque le champ Query était vide. Avec cette mise à jour, la modification de l'intervalle n'est pas une option disponible lorsque le champ Query est vide.(LOG-2917)

1.15.3. CVE

1.16. Enregistrement 5.5

Les avis suivants sont disponibles pour Logging 5.5:Release 5.5

1.16.1. Améliorations

  • Avec cette mise à jour, vous pouvez transférer des logs structurés provenant de différents conteneurs au sein d'un même pod vers différents index. Pour utiliser cette fonctionnalité, vous devez configurer le pipeline avec le support multi-conteneurs et annoter les pods.(LOG-1296)
Important

Le formatage JSON des journaux varie selon les applications. La création d'un trop grand nombre d'index ayant un impact sur les performances, limitez l'utilisation de cette fonctionnalité à la création d'index pour les journaux dont les formats JSON sont incompatibles. Utilisez des requêtes pour séparer les journaux provenant de différents espaces de noms ou d'applications dont les formats JSON sont compatibles.

  • Avec cette mise à jour, vous pouvez filtrer les journaux avec des sorties Elasticsearch en utilisant les étiquettes communes Kubernetes, app.kubernetes.io/component, app.kubernetes.io/managed-by, app.kubernetes.io/part-of, et app.kubernetes.io/version. Les types de sorties non Elasticsearch peuvent utiliser toutes les étiquettes incluses dans kubernetes.labels.(LOG-2388)
  • Avec cette mise à jour, les clusters avec AWS Security Token Service (STS) activé peuvent utiliser l'authentification STS pour transmettre les journaux à Amazon CloudWatch.(LOG-1976)
  • Avec cette mise à jour, l'opérateur "Loki Operator" et le collecteur vectoriel passent de l'aperçu technique à la disponibilité générale. La parité complète des fonctionnalités avec les versions précédentes est en attente, et certaines API restent en avant-première technique. Voir la section Logging with the LokiStack pour plus de détails.

1.16.2. Bug fixes

  • Avant cette mise à jour, les clusters configurés pour transmettre les journaux à Amazon CloudWatch écrivaient les fichiers journaux rejetés dans le stockage temporaire, ce qui entraînait une instabilité du cluster au fil du temps. Avec cette mise à jour, la sauvegarde de morceaux pour toutes les options de stockage a été désactivée, ce qui résout le problème.(LOG-2746)
  • Avant cette mise à jour, l'Opérateur utilisait des versions de certaines API qui sont obsolètes et dont la suppression est prévue dans les prochaines versions d'OpenShift Container Platform. Cette mise à jour déplace les dépendances vers les versions d'API prises en charge.(LOG-2656)

Avant cette mise à jour, l'Opérateur utilisait des versions de certaines API qui sont obsolètes et dont la suppression est prévue dans les prochaines versions d'OpenShift Container Platform. Cette mise à jour déplace les dépendances vers les versions d'API prises en charge.(LOG-2656)

  • Avant cette mise à jour, plusieurs pipelines ClusterLogForwarder configurés pour la détection d'erreurs multilignes provoquaient l'entrée du collecteur dans l'état d'erreur crashloopbackoff. Cette mise à jour corrige le problème où plusieurs sections de configuration avaient le même identifiant unique.(LOG-2241)
  • Avant cette mise à jour, le collecteur ne pouvait pas enregistrer les symboles non UTF-8 dans les journaux de stockage Elasticsearch. Avec cette mise à jour, le collecteur encode les symboles non UTF-8, ce qui résout le problème.(LOG-2203)
  • Avant cette mise à jour, les caractères non latins s'affichaient de manière incorrecte dans Kibana. Avec cette mise à jour, Kibana affiche correctement tous les symboles UTF-8 valides.(LOG-2784)

1.16.3. CVE

1.17. Journalisation 5.4.11

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

1.17.1. Bug fixes

1.17.2. CVE

1.18. Journalisation 5.4.10

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

1.18.1. Bug fixes

Aucun.

1.18.2. CVE

1.19. Journalisation 5.4.9

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

1.19.1. Bug fixes

  • Avant cette mise à jour, le collecteur Fluentd avertissait des paramètres de configuration non utilisés. Cette mise à jour supprime ces paramètres de configuration et leurs messages d'avertissement.(LOG-3074)
  • 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-3306)

1.19.2. CVE

1.20. Journalisation 5.4.8

Cette version inclut la version 5.4.8 de la correction des bogues de journalisation d'OpenShift (RHSA-2022:7435).

1.20.1. Bug fixes

Aucun.

1.20.2. CVE

1.21. Journalisation 5.4.6

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

1.21.1. Bug fixes

  • Avant cette mise à jour, Fluentd ne reconnaissait parfois pas que la plateforme Kubernetes effectuait une rotation du fichier de log et ne lisait plus les messages de log. Cette mise à jour corrige cela en définissant le paramètre de configuration suggéré par l'équipe de développement en amont.(LOG-2792)
  • Avant cette mise à jour, chaque travail de basculement créait des index vides lorsque la ressource personnalisée ClusterLogForwarder avait une définition de l'analyse JSON. Avec cette mise à jour, les nouveaux index ne sont pas vides(LOG-2823)
  • 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-3054)

1.21.2. CVE

1.22. Journalisation 5.4.5

Cette version inclut la version 5.4.5 de la correction des bogues de journalisation d'OpenShift, RHSA-2022:6183.

1.22.1. Bug fixes

  • Avant cette mise à jour, l'opérateur ne s'assurait pas que le module était prêt, ce qui entraînait un état inopérant du cluster lors d'un redémarrage. Avec cette mise à jour, l'opérateur marque les nouveaux pods comme étant prêts avant de passer à un nouveau pod lors d'un redémarrage, ce qui résout le problème.(LOG-2881)
  • Avant cette mise à jour, l'ajout de la détection des erreurs multilignes entraînait une modification du routage interne et l'acheminement des enregistrements vers la mauvaise destination. Avec cette mise à jour, le routage interne est correct.(LOG-2946)
  • Avant cette mise à jour, l'opérateur ne pouvait pas décoder les réponses JSON relatives aux paramètres d'index avec une valeur booléenne citée, ce qui entraînait une erreur. Avec cette mise à jour, l'opérateur peut décoder correctement cette réponse JSON.(LOG-3009)
  • Avant cette mise à jour, les modèles d'index Elasticsearch définissaient les champs des étiquettes avec les mauvais types. Cette modification met à jour ces modèles pour qu'ils correspondent aux types attendus transmis par le collecteur de logs.(LOG-2972)

1.22.2. CVE

1.23. Journalisation 5.4.4

Cette version inclut la version 5.4.4 de RHBA-2022:5907-OpenShift Logging Bug Fix.

1.23.1. Bug fixes

  • Avant cette mise à jour, les caractères non latins s'affichaient de manière incorrecte dans Elasticsearch. Avec cette mise à jour, Elasticsearch affiche correctement tous les symboles UTF-8 valides.(LOG-2794)
  • Avant cette mise à jour, les caractères non-latins s'affichaient incorrectement dans Fluentd. Avec cette mise à jour, Fluentd affiche correctement tous les symboles UTF-8 valides.(LOG-2657)
  • Avant cette mise à jour, le serveur de métriques pour le collecteur tentait de se lier à l'adresse en utilisant une valeur exposée par une valeur d'environnement. Ce changement modifie la configuration pour se lier à n'importe quelle interface disponible.(LOG-2821)
  • Avant cette mise à jour, l'opérateur cluster-logging s'appuyait sur le cluster pour créer un secret. Ce comportement du cluster a changé dans OpenShift Container Platform 4.11, ce qui a entraîné l'échec des déploiements de journalisation. Avec cette mise à jour, l'opérateur cluster-logging résout le problème en créant le secret si nécessaire.(LOG-2840)

1.23.2. CVE

1.24. Journalisation 5.4.3

Cette version inclut la version 5.4.3 de la correction des bogues de journalisation d'OpenShift (RHSA-2022:5556).

1.24.1. Avis de dépréciation d'Elasticsearch Operator

Dans le sous-système de journalisation 5.4.3, l'opérateur Elasticsearch 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. Au lieu d'utiliser l'opérateur Elasticsearch pour gérer le stockage des journaux par défaut, vous pouvez utiliser l'opérateur Loki.

1.24.2. Bug fixes

  • Avant cette mise à jour, le tableau de bord OpenShift Logging Dashboard affichait le nombre de shards primaires actifs au lieu de tous les shards actifs. Avec cette mise à jour, le tableau de bord affiche tous les shards actifs.(LOG-2781)
  • Avant cette mise à jour, un bogue dans une bibliothèque utilisée par elasticsearch-operator contenait une vulnérabilité d'attaque par déni de service. Avec cette mise à jour, la bibliothèque a été mise à jour vers une version qui ne contient pas cette vulnérabilité.(LOG-2816)
  • Avant cette mise à jour, lors de la configuration de Vector pour transmettre les journaux à Loki, il n'était pas possible de définir un jeton de support personnalisé ou d'utiliser le jeton par défaut si Loki avait activé TLS. Avec cette mise à jour, Vector peut transmettre les journaux à Loki en utilisant des jetons avec TLS activé.(LOG-2786
  • Avant cette mise à jour, l'opérateur ElasticSearch omettait la propriété referencePolicy de la ressource personnalisée ImageStream lors de la sélection d'une image oauth-proxy. Cette omission entraînait l'échec du déploiement de Kibana dans certains environnements. Avec cette mise à jour, l'utilisation de referencePolicy résout le problème et l'opérateur peut déployer Kibana avec succès.(LOG-2791)
  • Avant cette mise à jour, les règles d'alerte pour la ressource personnalisée ClusterLogForwarder ne prenaient pas en compte les sorties multiples. Cette mise à jour résout le problème.(LOG-2640)
  • Avant cette mise à jour, les clusters configurés pour transmettre les journaux à Amazon CloudWatch écrivaient les fichiers journaux rejetés dans le stockage temporaire, ce qui entraînait une instabilité du cluster au fil du temps. Avec cette mise à jour, la sauvegarde de chunk pour CloudWatch a été désactivée, ce qui résout le problème.(LOG-2768)

1.24.3. CVE

1.25. Journalisation 5.4.2

Cette version inclut RHBA-2022:4874-OpenShift Logging Bug Fix Release 5.4.2

1.25.1. Bug fixes

  • Avant cette mise à jour, l'édition de la configuration du collecteur à l'aide de oc edit était difficile en raison de l'utilisation incohérente des espaces blancs. Cette modification introduit une logique de normalisation et de formatage de la configuration avant toute mise à jour par l'opérateur afin qu'elle soit facile à éditer à l'aide de oc edit.(LOG-2319)
  • Avant cette mise à jour, l'alerte FluentdNodeDown ne pouvait pas fournir les étiquettes d'instance dans la section du message de manière appropriée. Cette mise à jour résout le problème en corrigeant la règle d'alerte pour fournir des étiquettes d'instance dans les cas d'échecs partiels de l'instance.(LOG-2607)
  • Avant cette mise à jour, plusieurs niveaux d'enregistrement, tels que "critique", qui étaient documentés comme étant pris en charge par le produit ne l'étaient pas. Cette mise à jour corrige l'anomalie de sorte que les niveaux de journalisation documentés sont maintenant pris en charge par le produit.(LOG-2033)

1.25.2. CVE

1.26. Journalisation 5.4.1

Cette version inclut la version 5.4.1 de la correction des bogues de journalisation d'OpenShift RHSA-2022:2216.

1.26.1. Bug fixes

  • Avant cette mise à jour, l'exportateur de métriques de fichiers journaux ne signalait que les journaux créés pendant que l'exportateur était en cours d'exécution, ce qui entraînait des données inexactes sur la croissance des journaux. Cette mise à jour résout ce problème en surveillant /var/log/pods.(LOG-2442)
  • Avant cette mise à jour, le collecteur était bloqué parce qu'il essayait continuellement d'utiliser une connexion périmée lorsqu'il transmettait les journaux aux récepteurs de transfert fluentd. Avec cette version, la valeur de keepalive_timeout a été fixée à 30 secondes (30s) afin que le collecteur recycle la connexion et réessaie d'envoyer les messages échoués dans un délai raisonnable.(LOG-2534)
  • Avant cette mise à jour, une erreur dans le composant de la passerelle appliquant la tenance pour la lecture des journaux limitait l'accès aux journaux avec un espace de noms Kubernetes, ce qui rendait illisibles les journaux \N "audit" et certains journaux \N "infrastructure". Avec cette mise à jour, le proxy détecte correctement les utilisateurs ayant un accès administrateur et autorise l'accès aux journaux sans espace de noms.(LOG-2448)
  • Avant cette mise à jour, le compte de service system:serviceaccount:openshift-monitoring:prometheus-k8s avait des privilèges au niveau du cluster en tant que clusterrole et clusterrolebinding. Cette mise à jour restreint le compte de service` à l'espace de noms openshift-logging avec un rôle et une liaison de rôle.(LOG-2437)
  • Avant cette mise à jour, l'analyse de l'heure du journal d'audit Linux reposait sur la position ordinale d'une paire clé/valeur. Cette mise à jour modifie l'analyse pour utiliser une expression régulière afin de trouver l'entrée temporelle.(LOG-2321)

1.26.2. CVE

1.27. Enregistrement 5.4

Les avis suivants sont disponibles pour la journalisation 5.4 : Sous-système de journalisation pour Red Hat OpenShift version 5.4

1.27.1. Aperçus technologiques

Important

Vector est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

1.27.2. À propos de Vector

Vector est un collecteur de journaux proposé en tant qu'alternative technique au collecteur par défaut du sous-système de journalisation.

Les sorties suivantes sont prises en charge :

  • elasticsearch. Une instance Elasticsearch externe. La sortie elasticsearch peut utiliser une connexion TLS.
  • kafka. Un courtier Kafka. La sortie kafka peut utiliser une connexion non sécurisée ou TLS.
  • loki. Loki, un système d'agrégation de logs horizontalement extensible, hautement disponible et multi-tenant.

1.27.2.1. Vecteur d'habilitation

Vector n'est pas activé par défaut. Suivez les étapes suivantes pour activer Vector sur votre cluster OpenShift Container Platform.

Important

Vector ne prend pas en charge les clusters compatibles FIPS.

Conditions préalables

  • OpenShift Container Platform : 4.12
  • Sous-système de journalisation pour Red Hat OpenShift : 5.4
  • FIPS désactivé

Procédure

  1. Modifiez la ressource personnalisée (CR) ClusterLogging dans le projet openshift-logging:

    $ oc -n openshift-logging edit ClusterLogging instance
  2. Ajouter une annotation logging.openshift.io/preview-vector-collector: enabled à la ressource personnalisée (CR) ClusterLogging.
  3. Ajouter vector comme type de collection à la ressource personnalisée (CR) ClusterLogging.
  apiVersion: "logging.openshift.io/v1"
  kind: "ClusterLogging"
  metadata:
    name: "instance"
    namespace: "openshift-logging"
    annotations:
      logging.openshift.io/preview-vector-collector: enabled
  spec:
    collection:
      logs:
        type: "vector"
        vector: {}

Ressources complémentaires

Important

Loki Operator est une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas de les utiliser en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, permettant aux clients de tester les fonctionnalités et de fournir un retour d'information au cours du processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

1.27.3. À propos de Loki

Loki est un système d'agrégation de journaux horizontalement extensible, hautement disponible et multi-tenant, actuellement proposé comme alternative à Elasticsearch en tant que magasin de journaux pour le sous-système de journalisation.

Ressources complémentaires

1.27.3.1. Déploiement du Lokistack

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Loki.

Conditions préalables

  • OpenShift Container Platform : 4.12
  • Sous-système de journalisation pour Red Hat OpenShift : 5.4

Pour installer l'opérateur Loki à l'aide de la console web d'OpenShift Container Platform :

  1. Installer l'opérateur Loki :

    1. Dans la console web d'OpenShift Container Platform, cliquez sur OperatorsOperatorHub.
    2. Choisissez Loki Operator dans la liste des opérateurs disponibles et cliquez sur Install.
    3. Sous Installation Mode, sélectionnez All namespaces on the cluster.
    4. Sous Installed Namespace, sélectionnez openshift-operators-redhat.

      Vous devez spécifier l'espace de noms openshift-operators-redhat. L'espace de noms openshift-operators peut contenir des Community Operators, qui ne sont pas fiables et qui pourraient publier une métrique avec le même nom qu'une métrique OpenShift Container Platform, ce qui causerait des conflits.

    5. Sélectionnez Enable operator recommended cluster monitoring on this namespace.

      Cette option définit l'étiquette openshift.io/cluster-monitoring: "true" dans l'objet Namespace. Vous devez sélectionner cette option pour vous assurer que la surveillance des clusters récupère l'espace de noms openshift-operators-redhat.

    6. Sélectionnez un site Approval Strategy.

      • La stratégie Automatic permet à Operator Lifecycle Manager (OLM) de mettre automatiquement à jour l'opérateur lorsqu'une nouvelle version est disponible.
      • La stratégie Manual exige qu'un utilisateur disposant des informations d'identification appropriées approuve la mise à jour de l'opérateur.
    7. Cliquez sur Install.
    8. Vérifiez que vous avez installé Loki Operator. Visitez la page OperatorsInstalled Operators et cherchez \N "Loki Operator.\N"
    9. Assurez-vous que Loki Operator est listé dans tous les projets dont Status est Succeeded.

1.27.4. Bug fixes

  • Avant cette mise à jour, le site cluster-logging-operator utilisait des rôles et des liaisons à l'échelle du cluster pour établir des autorisations permettant au compte de service Prometheus d'analyser les mesures. Ces autorisations étaient créées lors du déploiement de l'opérateur à l'aide de l'interface de la console, mais n'existaient pas lors du déploiement à partir de la ligne de commande. Cette mise à jour corrige le problème en faisant en sorte que les rôles et les liaisons soient définis par l'espace de noms.(LOG-2286)
  • Avant cette mise à jour, une modification antérieure visant à corriger la réconciliation du tableau de bord a introduit un champ ownerReferences dans la ressource à travers les espaces de noms. En conséquence, la carte de configuration et le tableau de bord n'ont pas été créés dans l'espace de noms. Avec cette mise à jour, la suppression du champ ownerReferences résout le problème et le tableau de bord OpenShift Logging est disponible dans la console.(LOG-2163)
  • Avant cette mise à jour, les modifications apportées aux tableaux de bord de mesure n'étaient pas déployées car cluster-logging-operator ne comparait pas correctement les cartes de configuration existantes et modifiées contenant le tableau de bord. Avec cette mise à jour, l'ajout d'une valeur de hachage unique aux étiquettes d'objets résout le problème.(LOG-2071)
  • Avant cette mise à jour, le tableau de bord OpenShift Logging n'affichait pas correctement les pods et namespaces dans le tableau qui affiche les conteneurs les plus productifs collectés au cours des dernières 24 heures. Avec cette mise à jour, les pods et namespaces sont affichés correctement.(LOG-2069)
  • Avant cette mise à jour, lorsque le site ClusterLogForwarder était configuré avec Elasticsearch OutputDefault et que les sorties Elasticsearch n'avaient pas de clés structurées, la configuration générée contenait des valeurs incorrectes pour l'authentification. Cette mise à jour corrige le secret et les certificats utilisés.(LOG-2056)
  • Avant cette mise à jour, le tableau de bord OpenShift Logging affichait un graphique CPU vide en raison d'une référence à une métrique invalide. Avec cette mise à jour, le point de données correct a été sélectionné, ce qui résout le problème.(LOG-2026)
  • Avant cette mise à jour, l'image du conteneur Fluentd incluait des outils de construction qui n'étaient pas nécessaires à l'exécution. Cette mise à jour supprime ces outils de l'image.(LOG-1927)
  • Avant cette mise à jour, un changement de nom du collecteur déployé dans la version 5.3 entraînait la génération de l'alerte FluentdNodeDown par le collecteur de journalisation. Cette mise à jour résout le problème en corrigeant le nom du travail pour l'alerte Prometheus.(LOG-1918)
  • Avant cette mise à jour, le collecteur de logs collectait ses propres logs en raison d'une refonte du changement de nom du composant. Cela conduisait à une boucle de rétroaction potentielle du collecteur traitant ses propres journaux, ce qui pouvait entraîner des problèmes de mémoire et de taille des messages de journaux. Cette mise à jour résout le problème en excluant les journaux du collecteur de la collecte.(LOG-1774)
  • Avant cette mise à jour, Elasticsearch générait l'erreur Unable to create PersistentVolumeClaim due to forbidden: exceeded quota: infra-storage-quota. si le PVC existait déjà. Avec cette mise à jour, Elasticsearch vérifie les PVC existants, ce qui résout le problème.(LOG-2131)
  • Avant cette mise à jour, Elasticsearch ne pouvait pas revenir à l'état prêt lorsque le secret elasticsearch-signing était supprimé. Avec cette mise à jour, Elasticsearch est en mesure de revenir à l'état prêt après la suppression de ce secret.(LOG-2171)
  • Avant cette mise à jour, la modification du chemin à partir duquel le collecteur lit les journaux de conteneurs entraînait la transmission de certains enregistrements aux mauvais index. Avec cette mise à jour, le collecteur utilise maintenant la configuration correcte pour résoudre le problème.(LOG-2160)
  • Avant cette mise à jour, les clusters comportant un grand nombre d'espaces de noms empêchaient Elasticsearch de servir les requêtes car la liste des espaces de noms atteignait la limite de taille maximale de l'en-tête. Avec cette mise à jour, les en-têtes n'incluent qu'une liste de noms d'espaces de noms, ce qui résout le problème.(LOG-1899)
  • Avant cette mise à jour, le tableau de bord OpenShift Container Platform Logging affichait un nombre de shards 'x' fois supérieur à la valeur réelle lorsque Elasticsearch avait 'x' nœuds. Ce problème était dû au fait que le tableau de bord imprimait tous les shards primaires pour chaque pod Elasticsearch et calculait une somme, alors que la sortie était toujours pour l'ensemble du cluster Elasticsearch. Avec cette mise à jour, le nombre de shards est maintenant correctement calculé.(LOG-2156)
  • Avant cette mise à jour, les secrets kibana et kibana-proxy n'étaient pas recréés s'ils étaient supprimés manuellement. Avec cette mise à jour, elasticsearch-operator surveillera les ressources et les recréera automatiquement si elles sont supprimées.(LOG-2250)
  • Avant cette mise à jour, le réglage de la taille du bloc de la mémoire tampon pouvait entraîner la génération d'un avertissement par le collecteur concernant la taille du bloc dépassant la limite d'octets pour le flux d'événements. Avec cette mise à jour, vous pouvez également régler la limite de ligne de lecture, ce qui résout le problème.(LOG-2379)
  • Avant cette mise à jour, le lien de la console de journalisation dans la console web d'OpenShift n'était pas supprimé avec le CR ClusterLogging. Avec cette mise à jour, la suppression de la CR ou la désinstallation de Cluster Logging Operator supprime le lien.(LOG-2373)
  • Avant cette mise à jour, une modification du chemin d'accès aux journaux des conteneurs faisait que la métrique de collecte était toujours égale à zéro avec les anciennes versions configurées avec le chemin d'accès d'origine. Avec cette mise à jour, le plugin qui expose les métriques sur les journaux collectés prend en charge la lecture à partir de l'un ou l'autre chemin pour résoudre le problème.(LOG-2462)

1.27.5. CVE

1.28. Journalisation 5.3.14

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

1.28.1. Bug fixes

  • Avant cette mise à jour, la carte de taille des fichiers journaux générée par le composant log-file-metrics-exporter ne supprimait pas les entrées des fichiers supprimés, ce qui augmentait la taille des fichiers et la mémoire du processus. Avec cette mise à jour, le plan de taille des fichiers journaux ne contient pas d'entrées pour les fichiers supprimés.(LOG-3293)

1.28.2. CVE

1.29. Journalisation 5.3.13

Cette version inclut la version 5.3.13 de RHSA-2022:68828-OpenShift Logging Bug Fix.

1.29.1. Bug fixes

Aucun.

1.29.2. CVE

1.30. Journalisation 5.3.12

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

1.30.1. Bug fixes

Aucun.

1.30.2. CVE

1.31. Journalisation 5.3.11

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

1.31.1. Bug fixes

  • Avant cette mise à jour, l'opérateur ne s'assurait pas que le module était prêt, ce qui entraînait un état inopérant du cluster lors d'un redémarrage. Avec cette mise à jour, l'opérateur marque les nouveaux pods comme étant prêts avant de passer à un nouveau pod lors d'un redémarrage, ce qui résout le problème.(LOG-2871)

1.31.2. CVE

1.32. Journalisation 5.3.10

Cette version inclut la version 5.3.10 de RHSA-2022:5908-OpenShift Logging Bug Fix.

1.32.1. Bug fixes

1.32.2. CVE

1.33. Journalisation 5.3.9

Cette version inclut la correction de bogue RHBA-2022:5557-OpenShift Logging Release 5.3.9.

1.33.1. Bug fixes

  • Avant cette mise à jour, le collecteur de journalisation incluait un chemin d'accès comme étiquette pour les mesures qu'il produisait. Ce chemin changeait fréquemment et contribuait à des changements de stockage importants pour le serveur Prometheus. Avec cette mise à jour, l'étiquette a été supprimée pour résoudre le problème et réduire la consommation de stockage.(LOG-2682)

1.33.2. CVE

1.34. Journalisation 5.3.8

Cette version inclut la version 5.3.8 de RHBA-2022:5010-OpenShift Logging Bug Fix

1.34.1. Bug fixes

(Aucun.)

1.34.2. CVE

1.35. OpenShift Logging 5.3.7

Cette version inclut RHSA-2022:2217 OpenShift Logging Bug Fix Release 5.3.7

1.35.1. Bug fixes

  • Avant cette mise à jour, l'analyse de l'heure du journal d'audit Linux reposait sur la position ordinale d'une paire clé/valeur. Cette mise à jour modifie l'analyse en utilisant une expression rationnelle pour trouver l'entrée temporelle.(LOG-2322)
  • Avant cette mise à jour, certaines sorties de transfert de journaux pouvaient réorganiser les journaux ayant le même horodatage. Avec cette mise à jour, un numéro de séquence a été ajouté à l'enregistrement du journal pour ordonner les entrées dont les horodatages correspondent.(LOG-2334)
  • Avant cette mise à jour, les clusters comportant un grand nombre d'espaces de noms empêchaient Elasticsearch de servir les requêtes car la liste des espaces de noms atteignait la limite de taille maximale de l'en-tête. Avec cette mise à jour, les en-têtes n'incluent qu'une liste de noms d'espaces de noms, ce qui résout le problème.(LOG-2450)
  • Avant cette mise à jour, system:serviceaccount:openshift-monitoring:prometheus-k8s avait des privilèges de niveau cluster en tant que clusterrole et clusterrolebinding. Cette mise à jour restreint serviceaccount à l'espace de noms openshift-logging avec un rôle et un lien de rôle.(LOG-2481))

1.35.2. CVE

1.36. OpenShift Logging 5.3.6

Cette version inclut RHBA-2022:1377 OpenShift Logging Bug Fix Release 5.3.6

1.36.1. Bug fixes

  • Avant cette mise à jour, la définition d'une tolérance sans clé avec l'opérateur existant entraînait l'impossibilité pour l'opérateur d'effectuer une mise à niveau. Avec cette mise à jour, cette tolérance ne bloque plus l'achèvement de la mise à niveau.(LOG-2126)
  • Avant cette modification, il était possible que le collecteur génère un avertissement lorsque la limite de l'octet du bloc dépassait un événement émis. Avec ce changement, vous pouvez ajuster la limite de lecture pour résoudre le problème comme le conseille la documentation en amont.(LOG-2380)

1.37. OpenShift Logging 5.3.5

Cette version inclut RHSA-2022:0721 OpenShift Logging Bug Fix Release 5.3.5

1.37.1. Bug fixes

  • Avant cette mise à jour, si vous supprimez OpenShift Logging de OpenShift Container Platform, la console web continuait d'afficher un lien vers la page Logging. Avec cette mise à jour, la suppression ou la désinstallation d'OpenShift Logging supprime également ce lien.(LOG-2182)

1.37.2. CVE

1.38. OpenShift Logging 5.3.4

Cette version inclut RHBA-2022:0411 OpenShift Logging Bug Fix Release 5.3.4

1.38.1. Bug fixes

  • Avant cette mise à jour, les modifications apportées aux tableaux de bord de mesure n'avaient pas encore été déployées parce que le site cluster-logging-operator ne comparait pas correctement les cartes de configuration existantes et souhaitées contenant le tableau de bord. Cette mise à jour corrige la logique en ajoutant une valeur de hachage unique aux étiquettes des objets.(LOG-2066)
  • Avant cette mise à jour, les pods Elasticsearch ne démarraient pas après une mise à jour avec FIPS activé. Avec cette mise à jour, les pods Elasticsearch démarrent avec succès.(LOG-1974)
  • Avant cette mise à jour, elasticsearch générait l'erreur "Unable to create PersistentVolumeClaim due to forbidden : exceeded quota : infra-storage-quota." si le PVC existait déjà. Avec cette mise à jour, elasticsearch vérifie les PVC existants, ce qui résout le problème.(LOG-2127)

1.38.2. CVE

1.39. OpenShift Logging 5.3.3

Cette version inclut RHSA-2022:0227 OpenShift Logging Bug Fix Release 5.3.3

1.39.1. Bug fixes

  • Avant cette mise à jour, les modifications apportées aux tableaux de bord n'avaient pas encore été déployées car l'opérateur cluster-logging-operator ne comparait pas correctement les cartes de configuration existantes et souhaitées contenant le tableau de bord. Cette mise à jour corrige la logique en ajoutant une valeur de hachage unique du tableau de bord aux étiquettes des objets.(LOG-2066)
  • Cette mise à jour modifie la dépendance de log4j en 2.17.1 pour résoudre la CVE-2021-44832.(LOG-2102)

1.39.2. CVE

Exemple 1.11. Cliquez pour agrandir CVEs

1.40. OpenShift Logging 5.3.2

Cette version inclut RHSA-2022:0044 OpenShift Logging Bug Fix Release 5.3.2

1.40.1. Bug fixes

  • Avant cette mise à jour, Elasticsearch rejetait les journaux provenant du routeur d'événements en raison d'une erreur d'analyse. Cette mise à jour modifie le modèle de données pour résoudre l'erreur d'analyse. Cependant, en conséquence, les indices précédents peuvent provoquer des avertissements ou des erreurs dans Kibana. Le champ kubernetes.event.metadata.resourceVersion provoque des erreurs jusqu'à ce que les index existants soient supprimés ou réindexés. Si ce champ n'est pas utilisé dans Kibana, vous pouvez ignorer les messages d'erreur. Si vous avez une politique de rétention qui supprime les anciens index, la politique finit par supprimer les anciens index et arrête les messages d'erreur. Sinon, réindexez manuellement pour arrêter les messages d'erreur.(LOG-2087)
  • Avant cette mise à jour, le tableau de bord OpenShift Logging Dashboard affichait le mauvais pod namespace dans le tableau qui affiche les conteneurs les plus produits et collectés au cours des dernières 24 heures. Avec cette mise à jour, le tableau de bord OpenShift Logging Dashboard affiche le bon espace de noms de pods.(LOG-2051)
  • Avant cette mise à jour, si outputDefaults.elasticsearch.structuredTypeKey dans l'instance de ressource personnalisée (CR) ClusterLogForwarder n'avait pas de clé structurée, la CR remplaçait le secret de sortie par le secret par défaut utilisé pour communiquer avec le magasin de journaux par défaut. Avec cette mise à jour, le secret de sortie défini est correctement utilisé.(LOG-2046)

1.40.2. CVE

1.41. OpenShift Logging 5.3.1

Cette version inclut RHSA-2021:5129 OpenShift Logging Bug Fix Release 5.3.1

1.41.1. Bug fixes

  • Avant cette mise à jour, l'image du conteneur Fluentd incluait des outils de construction qui n'étaient pas nécessaires au moment de l'exécution. Cette mise à jour supprime ces outils de l'image.(LOG-1998)
  • Avant cette mise à jour, le tableau de bord Logging affichait un graphique CPU vide en raison d'une référence à une métrique non valide. Avec cette mise à jour, le tableau de bord d'enregistrement affiche correctement les graphiques de CPU.(LOG-1925)
  • Avant cette mise à jour, le plugin d'exportation Elasticsearch Prometheus compilait les métriques au niveau de l'index à l'aide d'une requête coûteuse qui affectait les performances du nœud Elasticsearch. Cette mise à jour implémente une requête moins coûteuse qui améliore les performances.(LOG-1897)

1.41.2. CVE

1.42. OpenShift Logging 5.3.0

Cette version inclut RHSA-2021:4627 OpenShift Logging Bug Fix Release 5.3.0

1.42.1. Nouvelles fonctionnalités et améliorations

  • Avec cette mise à jour, les options d'autorisation pour le Log Forwarding ont été étendues. Les sorties peuvent désormais être configurées avec SASL, nom d'utilisateur/mot de passe ou TLS.

1.42.2. Bug fixes

  • Avant cette mise à jour, si vous transmettiez des logs en utilisant le protocole syslog, la sérialisation d'un hash ruby encodait les paires clé/valeur pour qu'elles contiennent un caractère '⇒' et remplaçait les tabulations par "#11". Cette mise à jour corrige le problème afin que les messages de log soient correctement sérialisés en tant que JSON valide.(LOG-1494)
  • Avant cette mise à jour, les journaux d'application n'étaient pas correctement configurés pour être transmis au flux Cloudwatch approprié lorsque la détection d'erreurs multilignes était activée.(LOG-1939)
  • Avant cette mise à jour, un changement de nom du collecteur déployé dans la version 5.3 provoquait la génération de l'alerte 'fluentnodedown'.(LOG-1918)
  • Avant cette mise à jour, une régression introduite dans une configuration de version antérieure faisait que le collecteur vidait ses messages en mémoire tampon avant l'arrêt, ce qui retardait l'arrêt et le redémarrage des Pods du collecteur. Avec cette mise à jour, fluentd ne vide plus les tampons à l'arrêt, ce qui résout le problème.(LOG-1735)
  • Avant cette mise à jour, une régression introduite dans une version antérieure désactivait intentionnellement l'analyse des messages JSON. Cette mise à jour réactive l'analyse JSON. Elle définit également l'entrée de journal "niveau" en fonction du champ "niveau" dans le message JSON analysé ou en utilisant une expression rationnelle pour extraire une correspondance d'un champ de message.(LOG-1199)
  • Avant cette mise à jour, la ressource personnalisée (CR) ClusterLogging appliquait la valeur du champ totalLimitSize au champ Fluentd total_limit_size, même si l'espace tampon requis n'était pas disponible. Avec cette mise à jour, la CR applique la plus petite des deux valeurs totalLimitSize ou 'default' au champ Fluentd total_limit_size, ce qui résout le problème.(LOG-1776)

1.42.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.42.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.42.4.1. Le transfert des journaux utilisant les anciennes méthodes Fluentd et syslog a été supprimé

Dans OpenShift Logging 5.3, les anciennes méthodes de transmission des logs vers Syslog et Fluentd sont supprimées. Les corrections de bugs et le support sont fournis jusqu'à la fin du cycle de vie d'OpenShift Logging 5.2. Après cela, aucune nouvelle amélioration de fonctionnalité n'est apportée.

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

1.42.4.2. Les mécanismes de configuration des anciennes méthodes de transfert ont été supprimés

Dans OpenShift Logging 5.3, le mécanisme de configuration pour la transmission des logs est supprimé : Vous ne pouvez pas transférer les journaux en utilisant la méthode Fluentd et la méthode Syslog. Utilisez les méthodes de transfert de logs standard à la place.

1.42.5. CVE

Exemple 1.14. Cliquez pour agrandir CVEs

1.43. Journalisation 5.2.13

Cette version inclut la version 5.2.13 de RHSA-2022:5909-OpenShift Logging Bug Fix.

1.43.1. Bug fixes

1.43.2. CVE

1.44. Journalisation 5.2.12

Cette version inclut la correction de bogue RHBA-2022:5558-OpenShift Logging Release 5.2.12.

1.44.1. Bug fixes

Aucun.

1.44.2. CVE

1.45. Journalisation 5.2.11

Cette version inclut la version 5.2.11 de RHBA-2022:5012-OpenShift Logging Bug Fix

1.45.1. Bug fixes

  • Avant cette mise à jour, les clusters configurés pour effectuer le transfert CloudWatch écrivaient les fichiers journaux rejetés dans le stockage temporaire, ce qui entraînait une instabilité du cluster au fil du temps. Avec cette mise à jour, la sauvegarde de chunk pour CloudWatch a été désactivée, ce qui résout le problème.(LOG-2635)

1.45.2. CVE

1.46. OpenShift Logging 5.2.10

Cette version inclut la version 5.2.10 de la correction des bugs de journalisation d'OpenShift]

1.46.1. Bug fixes

  • Avant cette mise à jour, certaines sorties de transfert de journaux pouvaient réorganiser les journaux ayant le même horodatage. Avec cette mise à jour, un numéro de séquence a été ajouté à l'enregistrement du journal afin d'ordonner les entrées dont les horodatages correspondent.(LOG-2335)
  • Avant cette mise à jour, les clusters comportant un grand nombre d'espaces de noms empêchaient Elasticsearch de servir les requêtes car la liste des espaces de noms atteignait la limite de taille maximale de l'en-tête. Avec cette mise à jour, les en-têtes n'incluent qu'une liste de noms d'espaces de noms, ce qui résout le problème.(LOG-2475)
  • Avant cette mise à jour, system:serviceaccount:openshift-monitoring:prometheus-k8s avait des privilèges de niveau cluster en tant que clusterrole et clusterrolebinding. Cette mise à jour restreint serviceaccount à l'espace de noms openshift-logging avec un rôle et un lien de rôle.(LOG-2480)
  • Avant cette mise à jour, le site cluster-logging-operator utilisait des rôles et des liaisons à l'échelle du cluster pour établir des autorisations permettant au compte de service Prometheus d'analyser les mesures. Ces autorisations n'étaient créées que lors du déploiement de l'opérateur à l'aide de l'interface de la console et n'existaient pas lorsque l'opérateur était déployé à partir de la ligne de commande. Ceci corrige le problème en rendant l'espace de noms de ce rôle et de cette liaison étendu.(LOG-1972)

1.46.2. CVE

1.47. OpenShift Logging 5.2.9

Cette version inclut RHBA-2022:1375 OpenShift Logging Bug Fix Release 5.2.9]

1.47.1. Bug fixes

  • Avant cette mise à jour, la définition d'une tolérance sans clé avec l'opérateur existant entraînait l'impossibilité pour l'opérateur d'effectuer une mise à niveau. Avec cette mise à jour, cette tolérance ne bloque plus l'achèvement de la mise à niveau.(LOG-2304)

1.48. OpenShift Logging 5.2.8

Cette version inclut RHSA-2022:0728 OpenShift Logging Bug Fix Release 5.2.8

1.48.1. Bug fixes

  • Avant cette mise à jour, si vous supprimez OpenShift Logging de OpenShift Container Platform, la console web continuait d'afficher un lien vers la page Logging. Avec cette mise à jour, la suppression ou la désinstallation d'OpenShift Logging supprime également ce lien.(LOG-2180)

1.48.2. CVE

Exemple 1.19. Cliquez pour agrandir CVEs

1.49. OpenShift Logging 5.2.7

Cette version inclut RHBA-2022:0478 OpenShift Logging Bug Fix Release 5.2.7

1.49.1. Bug fixes

  • Avant cette mise à jour, les pods Elasticsearch avec FIPS activé ne démarraient pas après la mise à jour. Avec cette mise à jour, les pods Elasticsearch démarrent avec succès.(LOG-2000)
  • Avant cette mise à jour, si une demande de volume persistant (PVC) existait déjà, Elasticsearch générait une erreur, "Unable to create PersistentVolumeClaim due to forbidden : exceeded quota : infra-storage-quota." Avec cette mise à jour, Elasticsearch vérifie les PVC existants, ce qui résout le problème.(LOG-2118)

1.49.2. CVE

1.50. OpenShift Logging 5.2.6

Cette version inclut RHSA-2022:0230 OpenShift Logging Bug Fix Release 5.2.6

1.50.1. Bug fixes

  • Avant cette mise à jour, la version n'incluait pas un changement de filtre qui provoquait le plantage de Fluentd. Avec cette mise à jour, le filtre manquant a été corrigé.(LOG-2104)
  • Cette mise à jour modifie la dépendance de log4j en 2.17.1 pour résoudre la CVE-2021-44832.(LOG-2101)

1.50.2. CVE

Exemple 1.21. Cliquez pour agrandir CVEs

1.51. OpenShift Logging 5.2.5

Cette version inclut RHSA-2022:0043 OpenShift Logging Bug Fix Release 5.2.5

1.51.1. Bug fixes

  • Avant cette mise à jour, Elasticsearch rejetait les journaux provenant du routeur d'événements en raison d'une erreur d'analyse. Cette mise à jour modifie le modèle de données pour résoudre l'erreur d'analyse. Cependant, en conséquence, les indices précédents peuvent provoquer des avertissements ou des erreurs dans Kibana. Le champ kubernetes.event.metadata.resourceVersion provoque des erreurs jusqu'à ce que les index existants soient supprimés ou réindexés. Si ce champ n'est pas utilisé dans Kibana, vous pouvez ignorer les messages d'erreur. Si vous avez une politique de rétention qui supprime les anciens index, la politique finit par supprimer les anciens index et arrête les messages d'erreur. Sinon, réindexez manuellement pour arrêter les messages d'erreur. LOG-2087)

1.51.2. CVE

Exemple 1.22. Cliquez pour agrandir CVEs

1.52. OpenShift Logging 5.2.4

Cette version inclut RHSA-2021:5127 OpenShift Logging Bug Fix Release 5.2.4

1.52.1. Bug fixes

  • Avant cette mise à jour, les enregistrements envoyés via syslog sérialisaient un hash ruby encodant les paires clé/valeur pour qu'elles contiennent un caractère '⇒', et remplaçaient les tabulations par des "#11". Cette mise à jour sérialise le message correctement en JSON.(LOG-1775)
  • Avant cette mise à jour, le plugin d'exportation Elasticsearch Prometheus compilait les métriques au niveau de l'index à l'aide d'une requête coûteuse qui avait un impact sur les performances du nœud Elasticsearch. Cette mise à jour implémente une requête moins coûteuse qui améliore les performances.(LOG-1970)
  • Avant cette mise à jour, Elasticsearch rejetait parfois des messages lorsque Log Forwarding était configuré avec plusieurs sorties. Cela se produisait parce que la configuration de l'une des sorties modifiait le contenu du message pour en faire un message unique. Avec cette mise à jour, Log Forwarding duplique les messages pour chaque sortie afin que le traitement spécifique à la sortie n'affecte pas les autres sorties.(LOG-1824)

1.52.2. CVE

1.53. OpenShift Logging 5.2.3

Cette version inclut RHSA-2021:4032 OpenShift Logging Bug Fix Release 5.2.3

1.53.1. Bug fixes

  • Avant cette mise à jour, certaines alertes n'incluaient pas d'étiquette d'espace de noms. Cette omission n'est pas conforme aux directives de l'équipe de surveillance d'OpenShift pour l'écriture de règles d'alerte dans OpenShift Container Platform. Avec cette mise à jour, toutes les alertes dans Elasticsearch Operator incluent une étiquette d'espace de noms et suivent toutes les directives pour l'écriture de règles d'alerte dans OpenShift Container Platform.(LOG-1857)
  • Avant cette mise à jour, une régression introduite dans une version antérieure désactivait intentionnellement l'analyse des messages JSON. Cette mise à jour réactive l'analyse JSON. Elle définit également l'entrée de journal level en fonction du champ level dans le message JSON analysé ou en utilisant une expression rationnelle pour extraire une correspondance d'un champ de message.(LOG-1759)

1.53.2. CVE

1.54. OpenShift Logging 5.2.2

Cette version inclut RHBA-2021:3747 OpenShift Logging Bug Fix Release 5.2.2

1.54.1. Bug fixes

  • Avant cette mise à jour, la ressource personnalisée (CR) ClusterLogging appliquait la valeur du champ totalLimitSize au champ Fluentd total_limit_size, même si l'espace tampon requis n'était pas disponible. Avec cette mise à jour, la CR applique la plus petite des deux valeurs totalLimitSize ou 'default' au champ Fluentd total_limit_size, ce qui résout le problème.(LOG-1738)
  • Avant cette mise à jour, une régression introduite dans une configuration de version antérieure faisait que le collecteur vidait ses messages en mémoire tampon avant l'arrêt, ce qui créait un retard dans l'arrêt et le redémarrage des pods collecteurs. Avec cette mise à jour, Fluentd ne vide plus les tampons à l'arrêt, ce qui résout le problème.(LOG-1739)
  • Avant cette mise à jour, un problème dans les bundle manifests empêchait l'installation de l'Elasticsearch Operator via OLM sur OpenShift Container Platform 4.9. Avec cette mise à jour, une correction des bundle manifests permet à nouveau l'installation et la mise à jour en 4.9.(LOG-1780)

1.54.2. CVE

1.55. OpenShift Logging 5.2.1

Cette version inclut RHBA-2021:3550 OpenShift Logging Bug Fix Release 5.2.1

1.55.1. Bug fixes

  • Avant cette mise à jour, en raison d'un problème dans les scripts du pipeline de diffusion, la valeur du champ olm.skipRange restait inchangée à 5.2.0 au lieu de refléter le numéro de diffusion actuel. Cette mise à jour corrige les scripts du pipeline pour mettre à jour la valeur de ce champ lorsque les numéros de version changent.(LOG-1743)

1.55.2. CVE

(Aucun)

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 ObserveDashboardsLogging/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

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)

2.1.5.5. CVE

2.2. Démarrer avec la journalisation 5.6

Cette vue d'ensemble du processus de déploiement de la journalisation est fournie à titre de référence. Elle ne remplace pas la documentation complète. Pour les nouvelles installations, les sites Vector et LokiStack sont recommandés.

Note

À partir de la version 5.5, vous pouvez choisir entre les implémentations de collecteurs Fluentd ou Vector et les magasins de journaux Elasticsearch ou LokiStack. La documentation relative à la journalisation est en cours de mise à jour afin de refléter ces changements de composants sous-jacents.

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.

Conditions préalables

  • Préférence LogStore : Elasticsearch ou LokiStack
  • Préférence de mise en œuvre du collecteur : Fluentd ou Vector
  • Informations d'identification pour vos sorties de transfert de logs
Note

À partir de la version 5.4.3 de Logging, l'Elasticsearch Operator 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. Au lieu d'utiliser l'opérateur Elasticsearch pour gérer le stockage des journaux par défaut, vous pouvez utiliser l'opérateur Loki.

  1. Installez l'opérateur pour le logstore que vous souhaitez utiliser.

    • Pour Elasticsearch, installez le site OpenShift Elasticsearch Operator.
    • Pour LokiStack, installez le site Loki Operator.

      • Créer une instance de ressource personnalisée (CR) à l'adresse LokiStack.
  2. Installer le site Red Hat OpenShift Logging Operator.
  3. Créer une instance de ressource personnalisée (CR) à l'adresse ClusterLogging.

    1. Sélectionnez la mise en œuvre de votre collecteur.

      Note

      À partir de la version 5.6 de l'exploitation forestière, Fluentd est obsolète et il est prévu qu'il soit supprimé 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.

  4. Créer une instance de ressource personnalisée (CR) à l'adresse ClusterLogForwarder.
  5. Créer un secret pour le pipeline de sortie sélectionné.

2.3. Administration du déploiement de la journalisation

Le sous-système de journalisation se compose des éléments logiques suivants :

  • Collector - Lit les données d'enregistrement des conteneurs sur chaque nœud et les transmet aux sorties configurées.
  • Store - Stocke les données du journal en vue de leur analyse ; c'est la sortie par défaut du transitaire.
  • Visualization - Interface graphique pour la recherche, l'interrogation et la visualisation des journaux stockés.

Ces composants sont gérés par des opérateurs et des fichiers YAML de ressources personnalisées (CR).

Le sous-système de journalisation de Red Hat OpenShift collecte les journaux des conteneurs et des nœuds. Ceux-ci sont classés par type :

  • application - Journaux de conteneurs générés par des conteneurs ne faisant pas partie de l'infrastructure.
  • infrastructure - Les journaux des conteneurs des espaces de noms kube-* et openshift-\*, et les journaux des nœuds de journald.
  • audit - Journaux provenant de auditd, kube-apiserver, openshift-apiserver, et ovn si l'option est activée.

Le collecteur de logs est un daemonset qui déploie des pods sur chaque nœud d'OpenShift Container Platform. Les journaux du système et de l'infrastructure sont générés par les messages de journald du système d'exploitation, de l'exécution du conteneur et d'OpenShift Container Platform.

Les journaux de conteneurs sont générés par les conteneurs qui s'exécutent dans des pods sur le cluster. Chaque conteneur génère un flux de journaux distinct. Le collecteur recueille les journaux de ces sources et les transmet en interne ou en externe, comme configuré dans la ressource personnalisée ClusterLogForwarder.

2.4. Administration du déploiement de la journalisation

2.4.1. Déployer Red Hat OpenShift Logging Operator à l'aide de la console web

Vous pouvez utiliser la console web de OpenShift Container Platform pour déployer Red Hat OpenShift Logging Operator.

Conditions préalables

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.

Procédure

Pour déployer Red Hat OpenShift Logging Operator à l'aide de la console web OpenShift Container Platform :

  1. Installez l'opérateur de journalisation Red Hat OpenShift :

    1. Dans la console web d'OpenShift Container Platform, cliquez sur OperatorsOperatorHub.
    2. Tapez Logging dans le champ Filter by keyword.
    3. Choisissez Red Hat OpenShift Logging dans la liste des opérateurs disponibles et cliquez sur Install.
    4. Sélectionnez stable ou stable-5.y comme Update Channel.

      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.

    5. Assurez-vous que A specific namespace on the cluster est sélectionné sous Installation Mode.
    6. Assurez-vous que Operator recommended namespace est openshift-logging sous Installed Namespace.
    7. Sélectionnez Enable Operator recommended cluster monitoring on this Namespace.
    8. Sélectionnez une option pour Update approval.

      • L'option Automatic permet à Operator Lifecycle Manager (OLM) de mettre automatiquement à jour l'opérateur lorsqu'une nouvelle version est disponible.
      • L'option Manual exige qu'un utilisateur disposant des informations d'identification appropriées approuve la mise à jour de l'opérateur.
    9. Sélectionnez Enable ou Disable pour le plugin Console.
    10. Cliquez sur Install.
  2. Vérifiez que le site Red Hat OpenShift Logging Operator est installé en passant à la page OperatorsInstalled Operators.

    1. Assurez-vous que Red Hat OpenShift Logging est listé dans le projet openshift-logging avec un Status de Succeeded.
  3. Créer une instance ClusterLogging.

    Note

    La vue du formulaire de la console web ne comprend pas toutes les options disponibles. Il est recommandé d'utiliser le site YAML view pour compléter votre installation.

    1. Dans la section collection, sélectionnez une implémentation de collecteur.

      Note

      À partir de la version 5.6 de l'exploitation forestière, Fluentd est obsolète et il est prévu qu'il soit supprimé 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. Dans la section logStore, sélectionnez un type.

      Note

      À partir de la version 5.4.3 de Logging, l'Elasticsearch Operator 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. Au lieu d'utiliser l'opérateur Elasticsearch pour gérer le stockage des journaux par défaut, vous pouvez utiliser l'opérateur Loki.

    3. Cliquez sur Create.

2.4.2. Déploiement de l'opérateur Loki à l'aide de la console web

Vous pouvez utiliser la console web d'OpenShift Container Platform pour installer l'opérateur Loki.

Conditions préalables

  • Log Store pris en charge (AWS S3, Google Cloud Storage, Azure, Swift, Minio, OpenShift Data Foundation)

Procédure

Pour installer l'opérateur Loki à l'aide de la console web d'OpenShift Container Platform :

  1. Dans la console web d'OpenShift Container Platform, cliquez sur OperatorsOperatorHub.
  2. Tapez Loki dans le champ Filter by keyword.

    1. Choisissez Loki Operator dans la liste des opérateurs disponibles et cliquez sur Install.
  3. Sélectionnez stable ou stable-5.y comme Update Channel.

    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.

  4. Assurez-vous que All namespaces on the cluster est sélectionné sous Installation Mode.
  5. Assurez-vous que openshift-operators-redhat est sélectionné sous Installed Namespace.
  6. Sélectionnez Enable Operator recommended cluster monitoring on this Namespace.

    Cette option définit l'étiquette openshift.io/cluster-monitoring: "true" dans l'objet Namespace. Vous devez sélectionner cette option pour vous assurer que la surveillance des clusters récupère l'espace de noms openshift-operators-redhat.

  7. Sélectionnez une option pour Update approval.

    • L'option Automatic permet à Operator Lifecycle Manager (OLM) de mettre automatiquement à jour l'opérateur lorsqu'une nouvelle version est disponible.
    • L'option Manual exige qu'un utilisateur disposant des informations d'identification appropriées approuve la mise à jour de l'opérateur.
  8. Cliquez sur Install.
  9. Vérifiez que le site LokiOperator est installé en passant à la page OperatorsInstalled Operators.

    1. Veillez à ce que LokiOperator soit listé avec Status et Succeeded dans tous les projets.
  10. Créez un fichier YAML Secret qui utilise les champs access_key_id et access_key_secret pour spécifier vos informations d'identification et bucketnames, endpoint, et region pour définir l'emplacement de stockage de l'objet. AWS est utilisé dans l'exemple suivant :

    apiVersion: v1
    kind: Secret
    metadata:
      name: logging-loki-s3
      namespace: openshift-logging
    stringData:
      access_key_id: AKIAIOSFODNN7EXAMPLE
      access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
      bucketnames: s3-bucket-name
      endpoint: https://s3.eu-central-1.amazonaws.com
      region: eu-central-1
  11. Sélectionnez Create instance sous LokiStack dans l'onglet Details. Sélectionnez ensuite YAML view. Collez le modèle suivant, en remplaçant les valeurs le cas échéant.

      apiVersion: loki.grafana.com/v1
      kind: LokiStack
      metadata:
        name: logging-loki 1
        namespace: openshift-logging
      spec:
        size: 1x.small 2
        storage:
          schemas:
          - version: v12
            effectiveDate: '2022-06-01'
          secret:
            name: logging-loki-s3 3
            type: s3 4
        storageClassName: <storage_class_name> 5
        tenants:
          mode: openshift-logging
    1
    Le nom doit être logging-loki.
    2
    Sélectionnez la taille de déploiement de votre Loki.
    3
    Définissez le secret utilisé pour le stockage des journaux.
    4
    Définir le type de stockage correspondant.
    5
    Saisissez le nom d'une classe de stockage existante pour le stockage temporaire. Pour de meilleures performances, spécifiez une classe de stockage qui alloue des blocs de stockage. Les classes de stockage disponibles pour votre cluster peuvent être répertoriées à l'aide de oc get storageclasses.
    1. Appliquer la configuration :

      oc apply -f logging-loki.yaml
  12. Créer ou modifier un CR ClusterLogging:

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        name: instance
        namespace: openshift-logging
      spec:
        managementState: Managed
        logStore:
          type: lokistack
          lokistack:
            name: logging-loki
          collection:
            type: vector
    1. Appliquer la configuration :

      oc apply -f cr-lokistack.yaml

2.4.3. Installation à partir d'OperatorHub en utilisant le CLI

Au lieu d'utiliser la console web de OpenShift Container Platform, vous pouvez installer un Operator depuis OperatorHub en utilisant le CLI. Utilisez la commande oc pour créer ou mettre à jour un objet Subscription.

Conditions préalables

  • Accès à un cluster OpenShift Container Platform à l'aide d'un compte disposant des autorisations cluster-admin.
  • Installez la commande oc sur votre système local.

Procédure

  1. Voir la liste des opérateurs disponibles pour la grappe à partir d'OperatorHub :

    $ oc get packagemanifests -n openshift-marketplace

    Exemple de sortie

    NAME                               CATALOG               AGE
    3scale-operator                    Red Hat Operators     91m
    advanced-cluster-management        Red Hat Operators     91m
    amq7-cert-manager                  Red Hat Operators     91m
    ...
    couchbase-enterprise-certified     Certified Operators   91m
    crunchy-postgres-operator          Certified Operators   91m
    mongodb-enterprise                 Certified Operators   91m
    ...
    etcd                               Community Operators   91m
    jaeger                             Community Operators   91m
    kubefed                            Community Operators   91m
    ...

    Notez le catalogue de l'opérateur souhaité.

  2. Inspectez l'opérateur de votre choix pour vérifier les modes d'installation pris en charge et les canaux disponibles :

    oc describe packagemanifests <operator_name> -n openshift-marketplace
  3. Un groupe d'opérateurs, défini par un objet OperatorGroup, sélectionne des espaces de noms cibles dans lesquels générer l'accès RBAC requis pour tous les opérateurs dans le même espace de noms que le groupe d'opérateurs.

    L'espace de noms auquel vous abonnez l'opérateur doit avoir un groupe d'opérateurs qui correspond au mode d'installation de l'opérateur, soit le mode AllNamespaces ou SingleNamespace. Si l'opérateur que vous avez l'intention d'installer utilise le mode AllNamespaces, l'espace de noms openshift-operators dispose déjà d'un groupe d'opérateurs approprié.

    Cependant, si l'opérateur utilise le mode SingleNamespace et que vous n'avez pas déjà un groupe d'opérateurs approprié en place, vous devez en créer un.

    Note

    La version console web de cette procédure gère la création des objets OperatorGroup et Subscription automatiquement dans les coulisses lorsque vous choisissez le mode SingleNamespace.

    1. Créez un fichier YAML de l'objet OperatorGroup, par exemple operatorgroup.yaml:

      Exemple d'objet OperatorGroup

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. Créer l'objet OperatorGroup:

      $ oc apply -f operatorgroup.yaml
  4. Créez un fichier YAML de l'objet Subscription pour abonner un espace de noms à un opérateur, par exemple sub.yaml:

    Exemple d'objet Subscription

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: <subscription_name>
      namespace: openshift-operators 1
    spec:
      channel: <channel_name> 2
      name: <operator_name> 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace 5
      config:
        env: 6
        - name: ARGS
          value: "-v=10"
        envFrom: 7
        - secretRef:
            name: license-secret
        volumes: 8
        - name: <volume_name>
          configMap:
            name: <configmap_name>
        volumeMounts: 9
        - mountPath: <directory_name>
          name: <volume_name>
        tolerations: 10
        - operator: "Exists"
        resources: 11
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        nodeSelector: 12
          foo: bar

    1
    Pour l'utilisation du mode d'installation AllNamespaces, indiquez l'espace de noms openshift-operators. Sinon, indiquez l'espace de noms unique correspondant à l'utilisation du mode d'installation SingleNamespace.
    2
    Nom du canal auquel s'abonner.
    3
    Nom de l'opérateur auquel s'abonner.
    4
    Nom de la source du catalogue qui fournit l'opérateur.
    5
    Espace de noms de la source de catalogue. Utilisez openshift-marketplace pour les sources de catalogue par défaut d'OperatorHub.
    6
    Le paramètre env définit une liste de variables d'environnement qui doivent exister dans tous les conteneurs du module créé par OLM.
    7
    Le paramètre envFrom définit une liste de sources pour alimenter les variables d'environnement dans le conteneur.
    8
    Le paramètre volumes définit une liste de volumes qui doivent exister sur le pod créé par OLM.
    9
    Le paramètre volumeMounts définit une liste de VolumeMounts qui doivent exister dans tous les conteneurs du pod créé par OLM. Si un volumeMount fait référence à un volume qui n'existe pas, OLM ne parvient pas à déployer l'opérateur.
    10
    Le paramètre tolerations définit une liste de tolérances pour le module créé par OLM.
    11
    Le paramètre resources définit les contraintes de ressources pour tous les conteneurs du module créé par OLM.
    12
    Le paramètre nodeSelector définit un NodeSelector pour le module créé par OLM.
  5. Créer l'objet Subscription:

    $ oc apply -f sub.yaml

    A ce stade, OLM connaît l'opérateur sélectionné. Une version de service de cluster (CSV) pour l'opérateur devrait apparaître dans l'espace de noms cible, et les API fournies par l'opérateur devraient être disponibles pour la création.

2.4.4. Suppression d'opérateurs d'une grappe à l'aide de la console web

Les administrateurs de cluster peuvent supprimer les opérateurs installés dans un espace de noms sélectionné à l'aide de la console web.

Conditions préalables

  • Vous avez accès à la console web d'un cluster OpenShift Container Platform en utilisant un compte avec les permissions cluster-admin.

Procédure

  1. Naviguez jusqu'à la page OperatorsInstalled Operators.
  2. Faites défiler ou saisissez un mot-clé dans le champ Filter by name pour trouver l'opérateur que vous souhaitez supprimer. Cliquez ensuite dessus.
  3. Sur le côté droit de la page Operator Details, sélectionnez Uninstall Operator dans la liste Actions.

    Une boîte de dialogue Uninstall Operator? s'affiche.

  4. Sélectionnez Uninstall pour supprimer l'opérateur, les déploiements de l'opérateur et les pods. Suite à cette action, l'opérateur cesse de fonctionner et ne reçoit plus de mises à jour.

    Note

    Cette action ne supprime pas les ressources gérées par l'opérateur, y compris les définitions de ressources personnalisées (CRD) et les ressources personnalisées (CR). Les tableaux de bord et les éléments de navigation activés par la console Web et les ressources hors cluster qui continuent de fonctionner peuvent nécessiter un nettoyage manuel. Pour les supprimer après la désinstallation de l'opérateur, vous devrez peut-être supprimer manuellement les CRD de l'opérateur.

2.4.5. Suppression d'opérateurs d'une grappe à l'aide de la CLI

Les administrateurs de clusters peuvent supprimer les opérateurs installés dans un espace de noms sélectionné à l'aide de l'interface de ligne de commande.

Conditions préalables

  • Accès à un cluster OpenShift Container Platform à l'aide d'un compte disposant des autorisations cluster-admin.
  • oc installée sur le poste de travail.

Procédure

  1. Vérifiez la version actuelle de l'opérateur souscrit (par exemple, jaeger) dans le champ currentCSV:

    $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV

    Exemple de sortie

      currentCSV: jaeger-operator.v1.8.2

  2. Supprimer l'abonnement (par exemple, jaeger) :

    $ oc delete subscription jaeger -n openshift-operators

    Exemple de sortie

    subscription.operators.coreos.com "jaeger" deleted

  3. Supprimez le CSV de l'opérateur dans l'espace de noms cible en utilisant la valeur currentCSV de l'étape précédente :

    $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators

    Exemple de sortie

    clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

2.5. Références en matière d'enregistrement

2.5.1. Caractéristiques du collectionneur

SortieProtocolTesté avecFluentdVecteur

Cloudwatch

REST sur HTTP(S)

 

Elasticsearch v6

 

v6.8.1

Elasticsearch v7

 

v7.12.2, 7.17.7

Elasticsearch v8

 

v8.4.3

 

Fluent Forward (en français dans le texte)

Fluentd forward v1

Fluentd 1.14.6, Logstash 7.10.1

 

Journalisation de Google Cloud

   

HTTP

HTTP 1.1

Fluentd 1.14.6, Vector 0.21

  

Kafka

Kafka 0.11

Kafka 2.4.1, 2.7.0, 3.3.1

Loki

REST sur HTTP(S)

Loki 2.3.0, 2.7

Splunk

HEC

v8.2.9, 9.0.0

 

Syslog

RFC3164, RFC5424

Rsyslog 8.37.0-9.el7

 

Tableau 2.1. Sources des journaux

FonctionnalitéFluentdVecteur

Journaux des conteneurs d'applications

Routage spécifique à l'application

Routage spécifique à l'application par espace de noms

Registres des conteneurs Infra

Journal de bord de l'infra

Journaux d'audit de l'API Kube

Journaux d'audit de l'API OpenShift

Journaux d'audit de l'Open Virtual Network (OVN)

Tableau 2.2. Autorisation et authentification

FonctionnalitéFluentdVecteur

Certificats Elasticsearch

Nom d'utilisateur / mot de passe Elasticsearch

Clés Cloudwatch

Cloudwatch STS

Certificats Kafka

Nom d'utilisateur / mot de passe Kafka

Kafka SASL

Jeton du porteur de Loki

Tableau 2.3. Normalisations et transformations

FonctionnalitéFluentdVecteur

Modèle de données Viaq - app

Modèle de données Viaq - infra

Modèle de données Viaq - infra(journal)

Modèle de données Viaq - Audit Linux

Modèle de données Viaq - audit kube-apiserver

Modèle de données Viaq - Audit API OpenShift

Modèle de données Viaq - OVN

Normalisation des niveaux de journalisation

Analyse JSON

Indice structuré

Détection des erreurs multilignes

 

Indices multiconteneurs / fractionnés

Aplatir les étiquettes

Étiquettes statiques de la NSI

Tableau 2.4. Accorder

FonctionnalitéFluentdVecteur

Limite de lecture de Fluentd

 

Tampon Fluentd

 

- taille limite du chunk

 

- taille totale

 

- débordementaction

 

- flushthreadcount

 

- mode flush

 

- intervalle de rinçage

 

- retrywait

 

- type de tentative

 

- retrymaxinterval

 

- délai de réessai

 

Tableau 2.5. Visibilité

FonctionnalitéFluentdVecteur

Metrics

Tableau de bord

Alertes

 

Tableau 2.6. Divers

FonctionnalitéFluentdVecteur

Prise en charge globale du proxy

support x86

Support ARM

Support IBM Power

Support IBM zSystems

Prise en charge de l'IPv6

Mise en mémoire tampon des événements du journal

 

Groupe déconnecté

Ressources complémentaires

2.5.2. Journalisation 5.6 Référence API

2.5.2.1. ClusterLogForwarder

ClusterLogForwarder est une API permettant de configurer le transfert des journaux.

Vous configurez le transfert en spécifiant une liste de pipelines, qui transfèrent un ensemble d'entrées nommées vers un ensemble de sorties nommées.

Il existe des noms d'entrée intégrés pour les catégories de journaux les plus courantes, et vous pouvez définir des entrées personnalisées pour effectuer des filtrages supplémentaires.

Il existe un nom de sortie intégré pour le magasin de logs openshift par défaut, mais vous pouvez définir vos propres sorties avec une URL et d'autres informations de connexion pour transmettre les logs à d'autres magasins ou processeurs, à l'intérieur ou à l'extérieur du cluster.

Pour plus de détails, voir la documentation sur les champs de l'API.

PropriétéTypeDescription

spécimen

objet

Spécification du comportement souhaité du ClusterLogForwarder

statut

objet

État du ClusterLogForwarder

2.5.2.1.1. .spec
2.5.2.1.1.1. Description

ClusterLogForwarderSpec définit la manière dont les journaux doivent être transmis aux cibles distantes.

2.5.2.1.1.1.1. Type
  • objet
PropriétéTypeDescription

entrées

réseau

(optional) Les entrées sont des filtres nommés pour les messages de journalisation à transmettre.

outputDefaults

objet

(optional) DEPRECATED OutputDefaults spécifie explicitement la configuration du transitaire pour le magasin par défaut.

sorties

réseau

(optional) Les sorties sont des destinations nommées pour les messages de journalisation.

pipelines

réseau

Les pipelines transmettent les messages sélectionnés par un ensemble d'entrées à un ensemble de sorties.

2.5.2.1.2. .spec.inputs[]
2.5.2.1.2.1. Description

InputSpec définit un sélecteur de messages de journalisation.

2.5.2.1.2.1.1. Type
  • réseau
PropriétéTypeDescription

application

objet

(optional) L'application, si elle est présente, active un ensemble nommé de journaux application qui

nom

chaîne de caractères

Nom utilisé pour désigner l'entrée d'un site pipeline.

2.5.2.1.3. .spec.inputs[].application
2.5.2.1.3.1. Description

Sélecteur de journaux d'application. Toutes les conditions du sélecteur doivent être remplies (ET logique) pour sélectionner les journaux.

2.5.2.1.3.1.1. Type
  • objet
PropriétéTypeDescription

espaces nominatifs

réseau

(optional) Espaces de noms à partir desquels collecter les journaux d'application.

sélecteur

objet

(optional) Sélecteur de billes de bois provenant d'une cosse dont l'étiquette correspond à celle de la cosse.

2.5.2.1.4. .spec.inputs[].application.namespaces[]
2.5.2.1.4.1. Description
2.5.2.1.4.1.1. Type
  • réseau
2.5.2.1.5. .spec.inputs[].application.selector
2.5.2.1.5.1. Description

Un sélecteur d'étiquettes est une requête d'étiquettes sur un ensemble de ressources.

2.5.2.1.5.1.1. Type
  • objet
PropriétéTypeDescription

matchLabels

objet

(optional) matchLabels est une carte de paires {key,value}. Un seul {key,value} dans la carte matchLabels

2.5.2.1.6. .spec.inputs[].application.selector.matchLabels
2.5.2.1.6.1. Description
2.5.2.1.6.1.1. Type
  • objet
2.5.2.1.7. .spec.outputDefaults
2.5.2.1.7.1. Description
2.5.2.1.7.1.1. Type
  • objet
PropriétéTypeDescription

elasticsearch

objet

(optional) Valeurs par défaut d'Elasticsearch OutputSpec

2.5.2.1.8. .spec.outputDefaults.elasticsearch
2.5.2.1.8.1. Description

ElasticsearchStructuredSpec est une spécification liée aux modifications du journal structuré pour déterminer l'index Elasticsearch

2.5.2.1.8.1.1. Type
  • objet
PropriétéTypeDescription

enableStructuredContainerLogs (activer les journaux structurés des conteneurs)

bool

(optional) EnableStructuredContainerLogs permet d'activer les journaux structurés multi-conteneurs afin de permettre

structuredTypeKey

chaîne de caractères

(optional) StructuredTypeKey spécifie la clé de métadonnées à utiliser comme nom de l'index elasticsearch

structuredTypeName

chaîne de caractères

(optional) StructuredTypeName spécifie le nom du schéma elasticsearch

2.5.2.1.9. .spec.outputs[]
2.5.2.1.9.1. Description

La sortie définit une destination pour les messages du journal.

2.5.2.1.9.1.1. Type
  • réseau
PropriétéTypeDescription

syslog

objet

(optional)

fluentdForward

objet

(optional)

elasticsearch

objet

(optional)

kafka

objet

(optional)

cloudwatch

objet

(optional)

loki

objet

(optional)

googleCloudLogging

objet

(optional)

splunk

objet

(optional)

nom

chaîne de caractères

Nom utilisé pour désigner la sortie d'un site pipeline.

secret

objet

(optional) Secret d'authentification.

tls

objet

TLS contient des paramètres permettant de contrôler les options des connexions client TLS.

type

chaîne de caractères

Type de plugin de sortie.

url

chaîne de caractères

(optional) URL à laquelle envoyer les enregistrements.

2.5.2.1.10. .spec.outputs[].secret
2.5.2.1.10.1. Description

OutputSecretSpec est une référence secrète contenant uniquement le nom, sans espace de noms.

2.5.2.1.10.1.1. Type
  • objet
PropriétéTypeDescription

nom

chaîne de caractères

Nom d'un secret dans l'espace de noms configuré pour les secrets de transfert de journaux.

2.5.2.1.11. .spec.outputs[].tls
2.5.2.1.11.1. Description

OutputTLSSpec contient des options pour les connexions TLS qui ne dépendent pas du type de sortie.

2.5.2.1.11.1.1. Type
  • objet
PropriétéTypeDescription

insecureSkipVerify

bool

Si InsecureSkipVerify est vrai, le client TLS sera configuré pour ignorer les erreurs de certificats.

2.5.2.1.12. .spec.pipelines[]
2.5.2.1.12.1. Description

Les PipelinesSpec relient un ensemble d'entrées à un ensemble de sorties.

2.5.2.1.12.1.1. Type
  • réseau
PropriétéTypeDescription

détecter les erreurs multilignes

bool

(optional) DetectMultilineErrors active la détection des erreurs multilignes dans les journaux des conteneurs

inputRefs

réseau

InputRefs liste les noms (input.name) des entrées de ce pipeline.

étiquettes

objet

(optional) Étiquettes appliquées aux enregistrements qui passent par ce pipeline.

nom

chaîne de caractères

(optional) Le nom est facultatif, mais il doit être unique dans la liste pipelines s'il est fourni.

outputRefs

réseau

OutputRefs liste les noms (output.name) des sorties de ce pipeline.

analyser

chaîne de caractères

(optional) Parse permet d'analyser les entrées du journal pour en faire des journaux structurés

2.5.2.1.13. .spec.pipelines[].inputRefs[]
2.5.2.1.13.1. Description
2.5.2.1.13.1.1. Type
  • réseau
2.5.2.1.14. .spec.pipelines[].labels
2.5.2.1.14.1. Description
2.5.2.1.14.1.1. Type
  • objet
2.5.2.1.15. .spec.pipelines[].outputRefs[]
2.5.2.1.15.1. Description
2.5.2.1.15.1.1. Type
  • réseau
2.5.2.1.16. .statut
2.5.2.1.16.1. Description

ClusterLogForwarderStatus définit l'état observé du ClusterLogForwarder

2.5.2.1.16.1.1. Type
  • objet
PropriétéTypeDescription

conditions

objet

Conditions de l'expéditeur de journaux.

entrées

Conditions

Les entrées associent le nom de l'entrée à la condition de l'entrée.

sorties

Conditions

Les sorties associent le nom de la sortie à l'état de la sortie.

pipelines

Conditions

Pipelines associe le nom du pipeline à son état.

2.5.2.1.17. .status.conditions
2.5.2.1.17.1. Description
2.5.2.1.17.1.1. Type
  • objet
2.5.2.1.18. .status.inputs
2.5.2.1.18.1. Description
2.5.2.1.18.1.1. Type
  • Conditions
2.5.2.1.19. .status.outputs
2.5.2.1.19.1. Description
2.5.2.1.19.1.1. Type
  • Conditions
2.5.2.1.20. .status.pipelines
2.5.2.1.20.1. Description
2.5.2.1.20.1.1. Type
  • Conditions== ClusterLogging Une instance de journalisation Red Hat OpenShift. ClusterLogging est le schéma de l'API clusterloggings
PropriétéTypeDescription

spécimen

objet

Spécification du comportement souhaité de ClusterLogging

statut

objet

Le statut définit l'état observé de ClusterLogging

2.5.2.1.21. .spec
2.5.2.1.21.1. Description

ClusterLoggingSpec définit l'état souhaité de ClusterLogging

2.5.2.1.21.1.1. Type
  • objet
PropriétéTypeDescription

collection

objet

Spécification du composant de collecte pour le cluster

curation

objet

(DEPRECATED) (optional) Obsolète. Spécification du composant de curation pour le cluster

transitaire

objet

(DEPRECATED) (optional) Déclassé. Spécification du composant Forwarder pour le cluster

logStore

objet

(optional) Spécification du composant Log Storage pour le cluster

état de la gestion

chaîne de caractères

(optional) Indicateur indiquant si la ressource est "gérée" ou "non gérée" par l'opérateur

visualisation

objet

(optional) Spécification du composant de visualisation pour le cluster

2.5.2.1.22. .spec.collection
2.5.2.1.22.1. Description

Il s'agit de la structure qui contiendra les informations relatives à la collecte des journaux et des événements

2.5.2.1.22.1.1. Type
  • objet
PropriétéTypeDescription

ressources

objet

(optional) Les ressources nécessaires pour le collecteur

nodeSelector

objet

(optional) Définir les nœuds sur lesquels les pods sont planifiés.

tolérances

réseau

(optional) Définir les tolérances acceptées par les pods

fluentd

objet

(optional) Fluentd représente la configuration des transitaires de type fluentd.

bûches

objet

(DEPRECATED) (optional) Déclassé. Spécification de la collecte de logs pour le cluster

type

chaîne de caractères

(optional) Le type de collecte de journaux à configurer

2.5.2.1.23. .spec.collection.fluentd
2.5.2.1.23.1. Description

FluentdForwarderSpec représente la configuration des transitaires de type fluentd.

2.5.2.1.23.1.1. Type
  • objet
PropriétéTypeDescription

tampon

objet

 

inFile

objet

 
2.5.2.1.24. .spec.collection.fluentd.buffer
2.5.2.1.24.1. Description

FluentdBufferSpec représente un sous-ensemble de paramètres de tampon fluentd permettant d'ajuster la configuration du tampon pour toutes les sorties fluentd. Il prend en charge un sous-ensemble de paramètres pour configurer la taille des tampons et des files d'attente, les opérations de vidage et les tentatives de vidage.

Pour les paramètres généraux, voir : https://docs.fluentd.org/configuration/buffer-section#buffering-parameters

Pour les paramètres de rinçage, voir : https://docs.fluentd.org/configuration/buffer-section#flushing-parameters

Pour les paramètres de réessai, voir : https://docs.fluentd.org/configuration/buffer-section#retries-parameters

2.5.2.1.24.1.1. Type
  • objet
PropriétéTypeDescription

chunkLimitSize

chaîne de caractères

(optional) ChunkLimitSize représente la taille maximale de chaque bloc. Les événements seront

flushInterval

chaîne de caractères

(optional) FlushInterval représente le temps d'attente entre deux vidanges consécutives

flushMode

chaîne de caractères

(optional) FlushMode représente le mode d'écriture des blocs par le thread de vidange. Le mode

flushThreadCount

int

(optional) FlushThreadCount représente le nombre de threads utilisés par le tampon fluentd

action de débordement

chaîne de caractères

(optional) OverflowAction représente l'action du plugin fluentd buffer pour

retryMaxInterval

chaîne de caractères

(optional) RetryMaxInterval représente l'intervalle de temps maximum pour le backoff exponentiel

délai de réessai

chaîne de caractères

(optional) RetryTimeout représente l'intervalle de temps maximum pour effectuer des tentatives avant d'abandonner

retryType

chaîne de caractères

(optional) RetryType représente le type de répétition des opérations de purge. Les opérations de purge peuvent

retryWait

chaîne de caractères

(optional) RetryWait représente la durée entre deux tentatives consécutives de rinçage

totalLimitSize

chaîne de caractères

(optional) TotalLimitSize représente le seuil d'espace de nœud autorisé par fluentd

2.5.2.1.25. .spec.collection.fluentd.inFile
2.5.2.1.25.1. Description

FluentdInFileSpec représente un sous-ensemble de paramètres du plugin fluentd in-tail permettant d'ajuster la configuration pour toutes les entrées fluentd in-tail.

Pour les paramètres généraux, voir : https://docs.fluentd.org/input/tail#parameters

2.5.2.1.25.1.1. Type
  • objet
PropriétéTypeDescription

readLinesLimit

int

(optional) ReadLinesLimit représente le nombre de lignes à lire à chaque opération d'E/S

2.5.2.1.26. .spec.collection.logs
2.5.2.1.26.1. Description
2.5.2.1.26.1.1. Type
  • objet
PropriétéTypeDescription

fluentd

objet

Spécification du composant Fluentd Log Collection

type

chaîne de caractères

Le type de collecte de journaux à configurer

2.5.2.1.27. .spec.collection.logs.fluentd
2.5.2.1.27.1. Description

CollectorSpec est une spécification permettant de définir l'ordonnancement et les ressources d'un collecteur

2.5.2.1.27.1.1. Type
  • objet
PropriétéTypeDescription

nodeSelector

objet

(optional) Définir les nœuds sur lesquels les pods sont planifiés.

ressources

objet

(optional) Les ressources nécessaires pour le collecteur

tolérances

réseau

(optional) Définir les tolérances acceptées par les pods

2.5.2.1.28. .spec.collection.logs.fluentd.nodeSelector
2.5.2.1.28.1. Description
2.5.2.1.28.1.1. Type
  • objet
2.5.2.1.29. .spec.collection.logs.fluentd.resources
2.5.2.1.29.1. Description
2.5.2.1.29.1.1. Type
  • objet
PropriétéTypeDescription

limites

objet

(optional) Limites décrit la quantité maximale de ressources de calcul autorisée.

demandes

objet

(optional) Les demandes décrivent la quantité minimale de ressources informatiques requises.

2.5.2.1.30. .spec.collection.logs.fluentd.resources.limits
2.5.2.1.30.1. Description
2.5.2.1.30.1.1. Type
  • objet
2.5.2.1.31. .spec.collection.logs.fluentd.resources.requests
2.5.2.1.31.1. Description
2.5.2.1.31.1.1. Type
  • objet
2.5.2.1.32. .spec.collection.logs.fluentd.tolerations[]
2.5.2.1.32.1. Description
2.5.2.1.32.1.1. Type
  • réseau
PropriétéTypeDescription

effet

chaîne de caractères

(optional) Effect indique l'effet d'altération à prendre en compte. Vide signifie que tous les effets d'altération doivent être pris en compte.

clé

chaîne de caractères

(optional) Key est la clé d'altération à laquelle s'applique la tolérance. Vide signifie que la tolérance s'applique à toutes les clés d'altération.

opérateur

chaîne de caractères

(optional) L'opérateur représente la relation entre la clé et la valeur.

secondes de tolérance

int

(optional) TolerationSeconds représente la période de temps pendant laquelle la tolérance (qui doit être

valeur

chaîne de caractères

(optional) La valeur est la valeur d'altération à laquelle correspond la tolérance.

2.5.2.1.33. .spec.collection.logs.fluentd.tolerations[].tolerationSeconds
2.5.2.1.33.1. Description
2.5.2.1.33.1.1. Type
  • int
2.5.2.1.34. .spec.curation
2.5.2.1.34.1. Description

Il s'agit de la structure qui contiendra les informations relatives à la curation du journal (Curator)

2.5.2.1.34.1.1. Type
  • objet
PropriétéTypeDescription

conservateur

objet

La spécification de la curation à configurer

type

chaîne de caractères

Le type de curation à configurer

2.5.2.1.35. .spec.curation.curator
2.5.2.1.35.1. Description
2.5.2.1.35.1.1. Type
  • objet
PropriétéTypeDescription

nodeSelector

objet

Définir les nœuds sur lesquels les pods sont planifiés.

ressources

objet

(optional) Les ressources nécessaires pour le conservateur

calendrier

chaîne de caractères

The cron schedule that the Curator job is run. Defaults to "30 3 * * *"

tolérances

réseau

 
2.5.2.1.36. .spec.curation.curator.nodeSelector
2.5.2.1.36.1. Description
2.5.2.1.36.1.1. Type
  • objet
2.5.2.1.37. .spec.curation.curator.resources
2.5.2.1.37.1. Description
2.5.2.1.37.1.1. Type
  • objet
PropriétéTypeDescription

limites

objet

(optional) Limites décrit la quantité maximale de ressources de calcul autorisée.

demandes

objet

(optional) Les demandes décrivent la quantité minimale de ressources informatiques requises.

2.5.2.1.38. .spec.curation.curator.resources.limits
2.5.2.1.38.1. Description
2.5.2.1.38.1.1. Type
  • objet
2.5.2.1.39. .spec.curation.curator.resources.requests
2.5.2.1.39.1. Description
2.5.2.1.39.1.1. Type
  • objet
2.5.2.1.40. .spec.curation.curator.tolerations[]
2.5.2.1.40.1. Description
2.5.2.1.40.1.1. Type
  • réseau
PropriétéTypeDescription

effet

chaîne de caractères

(optional) Effect indique l'effet d'altération à prendre en compte. Vide signifie que tous les effets d'altération doivent être pris en compte.

clé

chaîne de caractères

(optional) Key est la clé d'altération à laquelle s'applique la tolérance. Vide signifie que la tolérance s'applique à toutes les clés d'altération.

opérateur

chaîne de caractères

(optional) L'opérateur représente la relation entre la clé et la valeur.

secondes de tolérance

int

(optional) TolerationSeconds représente la période de temps pendant laquelle la tolérance (qui doit être

valeur

chaîne de caractères

(optional) La valeur est la valeur d'altération à laquelle correspond la tolérance.

2.5.2.1.41. .spec.curation.curator.tolerations[].tolerationSeconds
2.5.2.1.41.1. Description
2.5.2.1.41.1.1. Type
  • int
2.5.2.1.42. .spec.forwarder
2.5.2.1.42.1. Description

ForwarderSpec contient des paramètres de réglage globaux pour des implémentations spécifiques de transitaires. Ce champ n'est pas nécessaire pour une utilisation générale, mais il permet aux utilisateurs connaissant la technologie sous-jacente du transitaire de régler les performances. Actuellement pris en charge : fluentd.

2.5.2.1.42.1.1. Type
  • objet
PropriétéTypeDescription

fluentd

objet

 
2.5.2.1.43. .spec.forwarder.fluentd
2.5.2.1.43.1. Description

FluentdForwarderSpec représente la configuration des transitaires de type fluentd.

2.5.2.1.43.1.1. Type
  • objet
PropriétéTypeDescription

tampon

objet

 

inFile

objet

 
2.5.2.1.44. .spec.forwarder.fluentd.buffer
2.5.2.1.44.1. Description

FluentdBufferSpec représente un sous-ensemble de paramètres de tampon fluentd permettant d'ajuster la configuration du tampon pour toutes les sorties fluentd. Il prend en charge un sous-ensemble de paramètres pour configurer la taille des tampons et des files d'attente, les opérations de vidage et les tentatives de vidage.

Pour les paramètres généraux, voir : https://docs.fluentd.org/configuration/buffer-section#buffering-parameters

Pour les paramètres de rinçage, voir : https://docs.fluentd.org/configuration/buffer-section#flushing-parameters

Pour les paramètres de réessai, voir : https://docs.fluentd.org/configuration/buffer-section#retries-parameters

2.5.2.1.44.1.1. Type
  • objet
PropriétéTypeDescription

chunkLimitSize

chaîne de caractères

(optional) ChunkLimitSize représente la taille maximale de chaque bloc. Les événements seront

flushInterval

chaîne de caractères

(optional) FlushInterval représente le temps d'attente entre deux vidanges consécutives

flushMode

chaîne de caractères

(optional) FlushMode représente le mode d'écriture des blocs par le thread de vidange. Le mode

flushThreadCount

int

(optional) FlushThreadCount représente le nombre de threads utilisés par le tampon fluentd

action de débordement

chaîne de caractères

(optional) OverflowAction représente l'action du plugin fluentd buffer pour

retryMaxInterval

chaîne de caractères

(optional) RetryMaxInterval représente l'intervalle de temps maximum pour le backoff exponentiel

délai de réessai

chaîne de caractères

(optional) RetryTimeout représente l'intervalle de temps maximum pour effectuer des tentatives avant d'abandonner

retryType

chaîne de caractères

(optional) RetryType représente le type de répétition des opérations de purge. Les opérations de purge peuvent

retryWait

chaîne de caractères

(optional) RetryWait représente la durée entre deux tentatives consécutives de rinçage

totalLimitSize

chaîne de caractères

(optional) TotalLimitSize représente le seuil d'espace de nœud autorisé par fluentd

2.5.2.1.45. .spec.forwarder.fluentd.inFile
2.5.2.1.45.1. Description

FluentdInFileSpec représente un sous-ensemble de paramètres du plugin fluentd in-tail permettant d'ajuster la configuration pour toutes les entrées fluentd in-tail.

Pour les paramètres généraux, voir : https://docs.fluentd.org/input/tail#parameters

2.5.2.1.45.1.1. Type
  • objet
PropriétéTypeDescription

readLinesLimit

int

(optional) ReadLinesLimit représente le nombre de lignes à lire à chaque opération d'E/S

2.5.2.1.46. .spec.logStore
2.5.2.1.46.1. Description

La spécification LogStoreSpec contient des informations sur la manière dont les journaux sont stockés.

2.5.2.1.46.1.1. Type
  • objet
PropriétéTypeDescription

elasticsearch

objet

Spécification du composant Elasticsearch Log Store

lokistack

objet

LokiStack contient des informations sur la LokiStack à utiliser pour le stockage des journaux si Type est défini sur LogStoreTypeLokiStack.

politique de rétention

objet

(optional) La politique de conservation définit l'âge maximum d'un index après lequel il doit être supprimé

type

chaîne de caractères

Le type de stockage de logs à configurer. L'opérateur prend actuellement en charge l'utilisation d'ElasticSearch

2.5.2.1.47. .spec.logStore.elasticsearch
2.5.2.1.47.1. Description
2.5.2.1.47.1.1. Type
  • objet
PropriétéTypeDescription

nodeCount

int

Nombre de nœuds à déployer pour Elasticsearch

nodeSelector

objet

Définir les nœuds sur lesquels les pods sont planifiés.

mandataire

objet

Spécification du composant Elasticsearch Proxy

politique de redondance