Red Hat SummitChapitre 4. À propos de Logging
En tant qu’administrateur de cluster, vous pouvez déployer la journalisation sur un cluster dédié OpenShift et l’utiliser pour collecter et agréger les journaux d’audit système de nœuds, les journaux de conteneurs d’applications et les journaux d’infrastructure. Il est possible d’envoyer les journaux vers les sorties de journal que vous avez choisies, y compris le stockage de journaux géré par Red Hat. Il est également possible de visualiser les données de votre journal dans la console Web dédiée OpenShift ou la console Web Kibana, en fonction de votre solution de stockage de log déployée.
La console Web Kibana est maintenant désapprouvée est prévue pour être supprimée dans une prochaine version de journalisation.
Les administrateurs de cluster dédiés à OpenShift peuvent déployer la journalisation à l’aide d’opérateurs. À titre d’information, voir Installing logging.
Les opérateurs sont responsables du déploiement, de la mise à niveau et de la maintenance de l’enregistrement. Après l’installation des opérateurs, vous pouvez créer une ressource personnalisée ClusterLogging (CR) pour programmer les pods de journalisation et d’autres ressources nécessaires pour prendre en charge la journalisation. Il est également possible de créer un ClusterLogForwarder CR pour spécifier quels journaux sont recueillis, comment ils sont transformés et où ils sont transférés.
Étant donné que le journal interne OpenShift Dedicated Elasticsearch ne fournit pas de stockage sécurisé pour les journaux d’audit, les journaux d’audit ne sont pas stockés dans l’instance interne Elasticsearch par défaut. Lorsque vous souhaitez envoyer les journaux d’audit au journal interne Elasticsearch par défaut, par exemple pour afficher les journaux d’audit dans Kibana, vous devez utiliser l’API d’expédition de journal comme décrit dans les journaux d’audit Forward au journal de bord.
4.1. Architecture d’enregistrement
Les principales composantes de l’exploitation forestière sont:
- Collectionneur
Le collecteur est un daemonset qui déploie des pods dans chaque nœud dédié OpenShift. Il collecte les données de log de chaque nœud, transforme les données et les transmet aux sorties configurées. Il est possible d’utiliser le collectionneur Vecteur ou l’ancien collectionneur Fluentd.
NoteFluentd est déprécié et devrait être retiré dans une version ultérieure. Le Red Hat fournit des corrections de bogues et une prise en charge de cette fonctionnalité pendant le cycle de vie de la version actuelle, mais cette fonctionnalité ne reçoit plus d’améliorations. Comme alternative à Fluentd, vous pouvez utiliser Vector à la place.
- Log Store
Le log store stocke les données de log pour analyse et est la sortie par défaut pour l’expéditeur de journal. Il est possible d’utiliser le log store LokiStack par défaut, l’ancien magasin de journal Elasticsearch ou les journaux vers d’autres magasins de journaux externes.
NoteLa version Logging 5.9 ne contient pas une version mise à jour de l’opérateur OpenShift Elasticsearch. Actuellement, si vous utilisez l’opérateur OpenShift Elasticsearch publié avec Logging 5.8, il continuera à fonctionner avec Logging jusqu’à ce que l’EOL de Logging 5.8. Comme alternative à l’utilisation de l’opérateur OpenShift Elasticsearch pour gérer le stockage de journaux par défaut, vous pouvez utiliser l’opérateur Loki. Consultez Platform Agnostic Operators pour plus d’informations sur les dates du cycle de vie de l’enregistrement.
- La visualisation
Il est possible d’utiliser un composant d’interface utilisateur pour visualiser une représentation visuelle de vos données de journal. L’interface utilisateur fournit une interface graphique pour rechercher, interroger et afficher les journaux stockés. L’interface utilisateur de console Web dédiée OpenShift est fournie en activant le plugin de console dédié OpenShift.
NoteLa console Web Kibana est maintenant désapprouvée est prévue pour être supprimée dans une prochaine version de journalisation.
L’enregistrement collecte les journaux de conteneurs et les journaux de nœuds. Ceux-ci sont classés en types:
- Journaux des applications
- Journaux de conteneurs générés par les applications utilisateur s’exécutant dans le cluster, à l’exception des applications de conteneurs d’infrastructure.
- Journaux de l’infrastructure
- Journaux de conteneurs générés par des espaces de noms d’infrastructure: openshift*, kube* ou par défaut, ainsi que des messages journalisés à partir de nœuds.
- Journaux d’audit
- Journaux générés par audit, le système d’audit des nœuds, qui sont stockés dans le fichier /var/log/audit/audit.log, et les journaux des services audités, kube-apiserver, openshift-apiserver, ainsi que le projet ovn si activé.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}