Modèles de surveillance et de journalisation hybrides et multicloud

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
  • 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.

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. 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 :

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.

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 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 Google Cloud et GKE On-Prem 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.

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.
  • 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 d'adopter 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 Google Cloud et GKE On-Prem 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, 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 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 :

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.

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 :

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.

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 :

  • 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.

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

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 :

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.

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 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.

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

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.

Étapes suivantes