Modèles de surveillance et de journalisation hybrides et multicloud

Last reviewed 2023-03-29 UTC

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.

Arbre de décision pour la sélection d'une architecture de surveillance et de journalisation

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.

Architecture de haut niveau pour la surveillance et la journalisation

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 :

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.

Architecture de haut niveau pour la surveillance et la journalisation avec BindPlane et Monitoring

Cette architecture présente les avantages suivants :

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 GKE sur VMwaredans 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.

Architecture de haut niveau pour la surveillance GKE avec Prometheus et Monitoring

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 de 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 des contrôles de 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 GKE 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.

Architecture de haut niveau pour la surveillance GKE avec Fluentd ou Fluent Bit, Monitoring et Logging

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 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 ne sont compatibles qu'avec la journalisation. La surveillance doit donc ê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 les pages Personnaliser les journaux Logging pour Google Kubernetes Engine avec Fluentd ou Personnaliser les journaux Logging pour Google Kubernetes Engine avec Fluent Bit.

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.

Architecture de haut niveau permettant l'exportation de données de surveillance et de journalisation vers les services partenaires

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 :

Analyser les métriques de Prometheus et Logging avec 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 qui analyse les métriques de Google Cloud et sur site.

Architecture de haut niveau pour la surveillance avec Grafana en tant que vue centralisée

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 :

Pour en savoir plus, consultez la page 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.

Architecture de haut niveau permettant d'exporter des journaux directement depuis Fluentd ou Fluent Bit

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 des 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 ne sont compatibles qu'avec les journaux. La surveillance doit donc ê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 GKE VMware 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.

Architecture de haut niveau pour la séparation des données d'application et des données d'opération

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.

Séparer les données d'application des données système avec GKE Enterprise

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.

Étapes suivantes