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
- Utiliser Monitoring avec Prometheus et Fluentd
- Utiliser Monitoring avec Blue Medora BindPlane
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. La suite des opérations Google Cloud fournit une solution de stockage robuste pour les métriques, les journaux, les traces et les événements dans une vue centralisée. 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 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 appliquer un filtre pour recueillir les données avec une configuration Fluentd personnalisée ou pour l'ingestion de données avec des exclusions de journaux. Vous pouvez exporter les journaux non filtrés séparément pour répondre aux exigences de conformité.
- Pour optimiser vos coûts, analysez votre utilisation de Monitoring et de Logging, et mettez en œuvre des contrôles de coûts. Monitoring et Logging sont des services gérés générant des frais basés sur le volume pour les journaux et les métriques.
Surveillance et journalisation hybrides avec Monitoring et Blue Medora BindPlane
Le partenaire de Google Blue Medora BindPlane 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, Blue Medora dispose d'une intégration approfondie pour plus de 150 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 selon les tarifs standards. 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 Procéder à la journalisation et à la surveillance des ressources sur site avec Blue Medora.
Surveillance hybride de Google Kubernetes Engine avec Prometheus et Monitoring
Prometheus, une solution de surveillance Open Source populaire, et le side-car Monitoring pour Prometheus vous permettent 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 des clusters Google Cloud et Anthos sur VMware dans votre centre de données sur site, car elle fournit une interface unifiée. Le schéma suivant montre comment utiliser Prometheus et le side-car 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.
- L'utilisation de Prometheus ne génère aucun coût supplémentaire. Les métriques Prometheus sont importées dans Monitoring sous forme de métriques personnalisées qui sont facturées selon les tarifs standards.
Cette architecture présente les inconvénients suivants :
- Le side-car Monitoring pour Prometheus n'est compatible qu'avec les environnements GKE.
- 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, Fluentd.
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 personnalisée facturable. Pour éviter des coûts inattendus, mettez en œuvre le contrôle des coûts Monitoring et envisagez d'ajouter des filtres dans le side-car Monitoring pour Prometheus afin de limiter l'ingestion.
Pour plus d'informations sur la mise en œuvre de ce modèle, consultez la section Surveiller des applications s'exécutant sur plusieurs clusters GKE à l'aide de Prometheus et de Cloud Monitoring.
Journalisation GKE hybride avec Fluentd et Logging
Avec Fluentd, un agent de journalisation Open Source populaire, et Cloud Logging, vous pouvez assurer l'ingestion des journaux d'applications exécutées sur plusieurs clusters GKE dans Cloud Logging. Cette architecture est utile lorsque vous exécutez des charges de travail Kubernetes réparties entre GKE sur des clusters Google Cloud et Anthos sur VMware 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 ne génère aucun coût supplémentaire. Les journaux Fluentd importés dans Logging sont facturés selon les tarifs standards.
Cette architecture présente les inconvénients suivants :
- Fluentd n'accepte 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 plus d'informations sur la mise en œuvre de ce modèle, consultez la page Personnalisation des journaux Cloud Logging pour Google Kubernetes Engine avec Fluentd.
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
Exporter des métriques de Prometheus et Logging vers Grafana
Grafana est un outil de surveillance Open Source fréquemment 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 exportant des métriques depuis Google Cloud et depuis 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 et Grafana n'acceptent que la surveillance ; ainsi, la journalisation doit être configurée séparément, par exemple, à l'aide de Fluentd.
- 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 plus d'informations, consultez la présentation de Logging en tant que source de données pour Grafana. Pour accéder à un tutoriel détaillé sur le déploiement de Prometheus et Grafana avec GKE et Logging, consultez la page sur l'utilisation de Prometheus et Grafana pour la surveillance IoT.
Exporter des journaux à l'aide de Fluentd
Un modèle décrit précédemment utilise Fluentd 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, 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.
Cette architecture présente les inconvénients suivants :
- Fluentd n'accepte 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 est un outil tiers, et non un produit Google officiel. Google ne fournit aucune assistance pour Fluentd.
- Les journaux exportés ne sont pas disponibles pour l'assistance Google Cloud. En particulier, Google ne fournit aucune assistance pour les clusters Anthos sur les clusters VMware sans l'activation de Logging.
Pour accéder à un exemple d'intégration de Fluentd à BigQuery, consultez la page Analyser les journaux en temps réel à l'aide de Fluentd et BigQuery.
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 Anthos
Anthos déployé sur VMware fait partie de la suite Anthos et 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 Anthos 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 topologies de réseau.
- 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.
- Testez d'autres fonctionnalités de Google Cloud. Découvrez nos tutoriels.