Chapitre 10. Journal de stockage

L’instance d’enregistrement Elasticsearch est optimisée et testée pour le stockage à court terme, environ sept jours. Lorsque vous souhaitez conserver vos journaux à plus long terme, il est recommandé de déplacer les données vers un système de stockage tiers.

Elasticsearch organise les données de log de Fluentd en datastores, ou indices, puis subdivise chaque index en plusieurs morceaux appelés shards, qu’il diffuse à travers un ensemble de nœuds Elasticsearch dans un cluster Elasticsearch. Il est possible de configurer Elasticsearch pour faire des copies des fragments, appelés répliques, qu’Elasticsearch diffuse également à travers les nœuds Elasticsearch. La ressource personnalisée ClusterLogging (CR) vous permet de spécifier comment les fragments sont reproduits pour fournir une redondance des données et une résilience à l’échec. Il est également possible de spécifier combien de temps les différents types de journaux sont conservés à l’aide d’une stratégie de rétention dans le ClusterLogging CR.

Le Red Hat OpenShift Logging Operator et son compagnon OpenShift Elasticsearch Operator s’assurent que chaque nœud Elasticsearch est déployé à l’aide d’un déploiement unique qui inclut son propre volume de stockage. Au besoin, vous pouvez utiliser une ressource personnalisée ClusterLogging (CR) pour augmenter le nombre de nœuds Elasticsearch. Consultez la documentation Elasticsearch pour les considérations impliquées dans la configuration du stockage.

Le contrôle d’accès basé sur les rôles (RBAC) appliqué sur les indices Elasticsearch permet l’accès contrôlé des journaux aux développeurs. Les administrateurs peuvent accéder à tous les journaux et les développeurs ne peuvent accéder qu’aux journaux de leurs projets.