Ce document traite des architectures de surveillance et de journalisation destinées aux déploiements hybrides et multicloud, ainsi que des bonnes pratiques pour les mettre en œuvre à l'aide de Google Cloud. Il vous permet d'identifier les modèles et les produits les mieux adaptés à vos environnements.
Chaque entreprise dispose d'un portefeuille unique de charges de travail d'application qui imposent des exigences et des contraintes à l'architecture d'une configuration hybride ou multicloud. Bien que vous deviez concevoir et adapter votre architecture pour répondre à ces contraintes et exigences, vous pouvez aussi vous appuyer sur certains modèles courants.
Les modèles abordés dans ce document sont classés en deux catégories :
- Dans une architecture centralisée, c'est-à-dire, sur un écran unique, la surveillance et la journalisation sont centralisées dans le but de fournir un point d'accès et de contrôle unique.
- Dans une architecture dont l'application et les opérations sont distinctes, les données d'application sensibles sont séparées des données d'opérations moins sensibles dans le but de respecter les exigences de conformité liées aux données sensibles.
Choisir le modèle d'architecture
Vous pouvez utiliser l'arbre de décision du schéma suivant pour identifier l'architecture qui convient le mieux à votre cas d'utilisation.
Les détails de chaque architecture sont abordés plus en détail dans ce document. De manière générale, vous disposez des options suivantes :
- Exporter depuis Monitoring vers l'ancienne solution
- Exporter directement vers l'ancienne solution
- Utilisez Monitoring avec Prometheus et Fluentd ou Fluent Bit.
- Utilisez Monitoring avec BindPlane d'observIQ.
Architecture centralisée
Un système hybride a pour objectif courant d'intégrer les informations de surveillance et de journalisation provenant de diverses sources réparties sur plusieurs applications et environnements dans un écran unique. Ce type d'affichage est appelé vue centralisée.
Le schéma ci-dessous illustre ce modèle dans lequel les données de surveillance et de journalisation de toutes les applications, sur site et dans le cloud, sont centralisées dans un dépôt unique hébergé dans le cloud.
Cette architecture présente les avantages suivants :
- Vous disposez d'une vue unique et cohérente pour toutes les données de surveillance et de journalisation.
- Vous disposez d'un espace unique pour gérer le stockage et la conservation des données.
- Vous bénéficiez d'un contrôle des accès et d'une gestion des audits centralisés. Cependant, vous devez toujours garantir la sécurité des données en transit vers le dépôt central.
Surveillance centralisée
Cloud Monitoring est une solution gérée par Google pour la surveillance et la gestion des services, des conteneurs, des applications et de l'infrastructure. Pour obtenir une solution de stockage robuste pour les métriques, les journaux, les traces et les événements dans une vue centralisée, utilisez Google Cloud Observability. Elle propose également une gamme complète d'outils d'observabilité comprenant des tableaux de bord, des rapports et des alertes.
Tous les produits et services Google Cloud sont compatibles avec l'intégration avec Monitoring. En outre, vous disposez de plusieurs outils intégrés pour étendre les fonctionnalités de surveillance Monitoring aux ressources hybrides et sur site.
Les bonnes pratiques suivantes s'appliquent à toutes les architectures utilisant Monitoring comme vue centralisée :
- Pour répondre aux exigences de conformité sur la conservation des journaux, configurez des récepteurs de journaux pour votre organisation.
- Pour obtenir une analyse rapide des événements de journaux, configurez des exportations de journaux vers BigQuery pour l'analyse de la sécurité et des accès.
- Pour analyser les journaux stockés dans votre bucket de journaux, exécutez des requêtes SQL via Log Analytics.
- Pour les projets contenant des données sensibles, envisagez d'activer les journaux d'audit pour l'accès aux données afin de savoir qui a accédé aux données.
- Pour supprimer des informations sensibles, telles que les numéros de sécurité sociale, les numéros de carte de crédit et les adresses e-mail, vous pouvez filtrer les données des journaux. Vous pouvez filtrer selon une configuration Fluent Bit personnalisée ou ingérer avec des exclusions de journaux. Vous pouvez également exporter les journaux non filtrés séparément pour répondre aux exigences de conformité.
Surveillance et journalisation hybrides avec Monitoring et BindPlane d'observIQ
BindPlane, proposé par le partenaire de Google observIQ, vous permet d'importer des données de surveillance et de journalisation depuis des VM sur site et d'autres fournisseurs cloud, tels qu'Amazon Web Services (AWS), Microsoft Azure, Alibaba Cloud et IBM Cloud dans Monitoring. Le schéma suivant montre comment Monitoring et BindPlane peuvent fournir une vue centralisée pour un cloud hybride.
Cette architecture présente les avantages suivants :
- En plus de surveiller des ressources telles que les VM, BindPlane dispose d'une intégration approfondie pour plus de 50 sources de données populaires.
- L'utilisation de BindPlane ne génère aucun coût supplémentaire. Les métriques BindPlane sont importées dans Monitoring sous forme de métriques personnalisées qui sont facturées. De même, les journaux BindPlane sont facturés au même tarif que les autres journaux Logging.
Pour plus d'informations sur la mise en œuvre de ce modèle, consultez la page Journaliser et surveiller les ressources sur site avec BindPlane.
Surveillance hybride de Google Kubernetes Engine avec Prometheus et Monitoring
Google Cloud Managed Service pour Prometheus, une solution de surveillance Open Source populaire qui est entièrement gérée par Google Cloud, vous permet de surveiller les applications exécutées sur plusieurs clusters Kubernetes avec Monitoring. Cette architecture est utile lorsque vous exécutez des charges de travail Kubernetes réparties entre Google Kubernetes Engine (GKE) sur Google Cloud et Google Distributed Cloud dans votre centre de données sur site, car elle fournit une interface unifiée. Le schéma suivant montre comment utiliser Prometheus et les collecteurs Monitoring pour la collecte de données.
Cette architecture présente les avantages suivants :
- Métriques Kubernetes cohérentes dans les environnements cloud et sur site.
- Il vous permet de surveiller vos charges de travail et d'envoyer des alertes à l'échelle mondiale à l'aide de Prometheus, sans avoir à gérer et exploiter manuellement Prometheus à grande échelle.
- L'utilisation de Prometheus ne génère aucun coût supplémentaire. Les métriques Prometheus sont importées dans Monitoring. Les importations sont à facturer et facturées en fonction du nombre d'échantillons ingérés.
Cette architecture présente les inconvénients suivants :
- Prometheus n'accepte que la surveillance ; ainsi, la journalisation doit être configurée séparément. La section suivante décrit une option courante pour la journalisation à l'aide de Fluentd ou Fluent Bit.
Nous vous recommandons de suivre la bonne pratique suivante :
- Par défaut, Prometheus collecte toutes les métriques exposées, chacune devenant une métrique à facturer. Pour éviter des coûts inattendus, envisagez de mettre en œuvre le contrôle des coûts Monitoring.
Journalisation GKE hybride avec Fluentd ou Fluent Bit et Cloud Logging
Avec Fluentd ou Fluent Bit, un agent de journalisation Open Source populaire, et Cloud Logging, vous pouvez ingérer des journaux à partir d'applications exécutées sur plusieurs clusters GKE vers Cloud Logging. Cette architecture est utile lorsque vous exécutez des charges de travail Kubernetes réparties entre GKE sur Google Cloud et Google Distributed Cloud dans votre centre de données sur site, car elle fournit une interface unifiée. Le schéma suivant illustre le flux des journaux.
Cette architecture présente les avantages suivants :
- Vous pouvez bénéficier d'une journalisation Kubernetes cohérente sur les environnements cloud et sur site.
- Vous pouvez personnaliser Logging pour filtrer les informations sensibles.
- L'utilisation de Fluentd ou de Fluent Bit ne génère aucun coût supplémentaire. Les journaux importés dans Logging à l'aide de Fluentd ou Fluent Bit sont à facturer.
Cette architecture présente les inconvénients suivants :
- Fluentd et Fluent Bit n'acceptent que la journalisation ; ainsi, la surveillance doit être configurée séparément. La section précédente décrit une option courante pour la surveillance avec Prometheus.
Pour en savoir plus sur la mise en œuvre de ce modèle, consultez la section Personnaliser Fluent Bit pour les journaux Google Kubernetes Engine.
Services partenaires avec vue centralisée
Si vous utilisez déjà un service de surveillance ou de journalisation tiers tel que Datadog ou Splunk, vous ne souhaiterez peut-être pas passer à Logging. Si c'est le cas, vous pouvez exporter des données de Google Cloud vers de nombreux services de surveillance et de journalisation courants. Vous pouvez choisir d'utiliser un service de surveillance et de journalisation intégré ou sélectionner des services de surveillance et de journalisation distincts qui répondent le mieux à vos besoins.
Exporter depuis Logging vers des services partenaires
Avec ce modèle, vous autorisez le service de surveillance partenaire, tel que Datadog, à se connecter à l'API Cloud Monitoring. Cette autorisation permet au service d'ingérer toutes les métriques disponibles pour Logging. Datadog peut ainsi faire office de point central pour les opérations de surveillance.
Pour la journalisation des données, Logging fournit des exportations (récepteurs de journaux) vers Pub/Sub. Ces exportations fournissent une méthode robuste et performante pour que les services partenaires de journalisation tels que Elastic et Splunk puissent ingérer de grands volumes de données depuis Logging en temps réel et ainsi faire office de point central pour les opérations de journalisation.
L'architecture combinée de journalisation et de surveillance est présentée dans le schéma suivant.
Cette architecture présente les avantages suivants :
- Vous pouvez continuer à utiliser vos outils habituels.
- L'assistance Google Cloud continue d'avoir accès aux journaux de Logging à des fins de dépannage.
Cette architecture présente les inconvénients suivants :
- Les solutions partenaires sont généralement hébergées en externe, ce qui signifie qu'elles peuvent ne pas être disponibles ou ne pas être en mesure de collecter des données en cas de perturbation des connexions réseau. Parfois, vous pouvez atténuer ce risque via l'auto-hébergement, mais vous devrez alors assurer vous-même la maintenance de l'infrastructure de la solution.
- Les tableaux de bord hébergés en externe ne sont pas directement disponibles pour l'assistance Google Cloud. Ce manque de disponibilité peut ralentir le dépannage et l'atténuation des risques.
- Les solutions partenaires peuvent entraîner des frais de licence supplémentaires.
Voici quelques exemples d'intégrations détaillées :
- Datadog : Surveillance des métriques Compute Engine et Collecte des journaux Logging
- Elastic : Exportation des journaux Logging vers Elastic Cloud
- Splunk : Scénarios d'exportation de Logging
Analyser les métriques de Prometheus et de Logging avec Grafana
Grafana est un outil de surveillance Open Source populaire, généralement associé à Prometheus pour la collecte de métriques. Dans cette architecture, vous utilisez Prometheus en tant que couche de collecte sur site et Grafana en tant que vue centralisée pour Google Cloud et les ressources sur site. Le schéma suivant présente un exemple d'architecture qui analyse les métriques de Google Cloud et des ressources sur site.
Cette architecture présente les avantages suivants :
- Elle est adaptée aux environnements hybrides comprenant des VM et des conteneurs.
- Si votre organisation utilise déjà Prometheus et Grafana, vos utilisateurs peuvent continuer à les utiliser.
Cette architecture présente les inconvénients suivants :
- Prometheus n'accepte que la surveillance ; ainsi, la journalisation doit être configurée séparément, par exemple, à l'aide de Fluentd ou du plug-in Cloud Logging pour Grafana.
- Prometheus est une solution Open Source et extensible, mais n'accepte qu'une gamme limitée d'intégrations logicielles d'entreprise.
- Prometheus et Grafana sont des outils tiers, et non des produits Google officiels. Google n'offre aucune assistance pour Prometheus ou Grafana.
Pour en savoir plus, consultez Améliorer le dépannage avec un plug-in Cloud Logging pour Grafana.
Exporter des journaux à l'aide de Fluentd
Un modèle décrit précédemment utilise Fluentd ou Fluent Bit comme collecteur de journaux pour Logging. La même architecture de base peut également être utilisée pour d'autres systèmes de journalisation ou d'analyse de données qui sont compatibles avec Fluentd ou Fluent Bit, y compris BigQuery, Elastic et Splunk. Le schéma suivant illustre ce modèle.
Cette architecture présente les avantages suivants :
- Elle est adaptée aux environnements hybrides comprenant des VM et des conteneurs.
- Fluentd peut lire de nombreuses sources de données, y compris les journaux système.
- Fluentd propose des plug-ins de sortie pour de nombreux systèmes tiers de journalisation et d'analyse de données.
- Fluent Bit peut également lire de nombreuses entrées, y compris les journaux système.
- Fluent Bit propose des sorties pour de nombreux systèmes tiers de journalisation et d'analyse de données.
Cette architecture présente les inconvénients suivants :
- Fluentd et Fluent Bit n'acceptent que la journalisation ; ainsi, la surveillance doit être configurée séparément. La section précédente décrit des options courantes pour la surveillance avec Prometheus et Grafana.
- Fluentd et Fluent Bit sont des outils tiers, et non des produits Google officiels. Google ne fournit aucune assistance pour ces outils.
- Les journaux exportés ne sont pas disponibles pour l'assistance Google Cloud. En particulier, Google ne fournit aucune assistance pour les clusters Google Distributed Cloud sans l'activation de Logging.
Séparer les données d'application des données d'opérations
Les architectures centralisées exigent des flux de données de surveillance et de journalisation des applications dans le cloud. Cependant, vous pouvez être soumis à des exigences réglementaires ou de conformité qui nécessitent la conservation des données client sur site ou qui imposent des contraintes strictes sur les données qui peuvent être stockées sur le cloud public.
Un modèle utile pour ces environnements hybrides consiste à séparer les données d'application sensibles des données d'opérations à faible risque, comme illustré dans le schéma suivant.
Séparer les données d'application des données système avec GKE Enterprise
GKE Enterprise sur VMware, qui fait partie de la suite GKE Enterprise, inclut Grafana pour surveiller les clusters sur site. Vous pouvez également choisir d'installer une solution partenaire telle que Elastic Stack ou Splunk pour la journalisation. Grâce à ces solutions, vous pouvez ingérer et afficher les données d'application sensibles sur site tout en exportant les données système vers Logging sur Google Cloud. Cette architecture est décrite dans le schéma suivant.
Cette architecture présente les avantages suivants :
- Les données d'application sensibles sont conservées sur site.
- La surveillance et la journalisation sur site ne dépendent pas du cloud et restent disponibles même si la connexion réseau est interrompue.
- Toutes les données du système GKE, sur site et sur Google Cloud, sont centralisées dans Logging et sont également accessibles à l'assistance Google Cloud si nécessaire.
Pour obtenir un exemple de mise en œuvre utilisant Elastic Stack comme solution partenaire, consultez la page sur la surveillance de GKE Enterprise avec Elastic Stack.
Étape suivante
- Découvrez les bonnes pratiques hybrides et multicloud avec la série Modèles et pratiques hybrides et multicloud, y compris les modèles d'architecture et les modèles d'architecture réseau sécurisée.
- Inscrivez-vous à la quête des bonnes pratiques Cloud Kubernetes pour obtenir des exercices pratiques sur l'observabilité et des ressources supplémentaires sur GKE.
- Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Cloud Architecture Center.