Configurer la journalisation et la surveillance

Google Distributed Cloud (logiciel uniquement) pour Bare Metal prend en charge plusieurs options de journalisation et de surveillance des clusters, y compris des services gérés basés dans le cloud, des outils Open Source et une compatibilité validée avec des solutions commerciales tierces. Cette page décrit ces options et fournit des conseils de base pour sélectionner la solution adaptée à votre environnement.

Cette page s'adresse aux administrateurs, aux architectes et aux opérateurs qui souhaitent surveiller l'état des applications ou des services déployés, par exemple pour vérifier la conformité avec les objectifs de niveau de service (SLO). Pour en savoir plus sur les rôles courants et les exemples de tâches référencés dans le contenu Google Cloud , consultez la section Rôles utilisateur et tâches courantes de l'utilisateur dans GKE Enterprise.

Options pour Google Distributed Cloud

Vous disposez de plusieurs options de journalisation et de surveillance pour votre cluster :

  • Cloud Logging et Cloud Monitoring, activés par défaut sur les composants du système Bare Metal.
  • Prometheus et Grafana, disponibles depuis Cloud Marketplace
  • Configurations validées avec des solutions tierces

Cloud Logging et Cloud Monitoring

Google Cloud Observability est la solution d'observabilité intégrée pourGoogle Cloud. Elle offre une solution de journalisation entièrement gérée, la collecte de métriques, la surveillance, la création de tableaux de bord et les alertes. Cloud Monitoring surveille les clusters Google Distributed Cloud de la même manière que les clusters GKE basés dans le cloud.

Cloud Logging et Cloud Monitoring sont activés par défaut lorsque vous créez des clusters avec les comptes de service et les rôles IAM requis. Vous ne pouvez pas désactiver Cloud Logging et Cloud Monitoring. Pour en savoir plus sur les comptes de service et les rôles requis, consultez la section Configurer des comptes de service.

Les agents peuvent être configurés pour modifier les éléments suivants:

  • Champ d'application de la journalisation et de la surveillance, allant des seuls composants système (par défaut) aux composants système et aux applications.
  • Niveau de métriques collectées, de seulement un ensemble optimisé de métriques (par défaut) à toutes les métriques.

Pour en savoir plus, consultez la section Configurer des agents Stackdriver pour Google Distributed Cloud dans ce document.

Logging et Monitoring fournissent une solution d'observabilité basée sur le cloud unique, puissante et facile à configurer. Nous vous recommandons vivement d'utiliser Logging et Monitoring lorsque vous exécutez des charges de travail sur Google Distributed Cloud. Pour les applications avec des composants s'exécutant sur une infrastructure standard sur site et sur Google Distributed Cloud, vous pouvez envisager d'autres solutions pour une vue de bout en bout de ces applications.

Prometheus et Grafana

Prometheus et Grafana sont deux produits de surveillance Open Source populaires disponibles dans Cloud Marketplace :

  • Prometheus recueille des métriques sur les applications et le système.

  • Alertmanager gère l'envoi d'alertes à l'aide de différents mécanismes.

  • Grafana est un outil de création de tableaux de bord.

Nous vous recommandons d'utiliser Google Cloud Managed Service pour Prometheus, qui est basé dans Cloud Monitoring, pour tous vos besoins de surveillance. Avec Google Cloud Managed Service pour Prometheus, vous pouvez surveiller les composants système sans frais. Google Cloud Managed Service pour Prometheus est également compatible avec Grafana. Toutefois, si vous préférez un système de surveillance purement local, vous pouvez choisir d'installer Prometheus et Grafana dans vos clusters.

Si vous avez installé Prometheus localement et que vous souhaitez collecter des métriques à partir de composants système, vous devez autoriser votre instance Prometheus locale à accéder aux points de terminaison de métriques des composants système:

  • Liez le compte de service de votre instance Prometheus au ClusterRole gke-metrics-agent prédéfini et utilisez le jeton de compte de service comme identifiant pour extraire les métriques des composants système suivants:

    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • node-exporter

  • Utilisez la clé et le certificat client stockés dans le secret kube-system/stackdriver-prometheus-etcd-scrape pour authentifier l'extraction de métriques à partir d'etcd.

  • Créez un objet NetworkPolicy pour autoriser l'accès de votre espace de noms à kube-state-metrics.

Solutions tierces

Google a collaboré avec plusieurs fournisseurs de solutions tierces de journalisation et de surveillance pour faire en sorte que leurs produits fonctionnent bien avec Google Distributed Cloud. Ces fournisseurs incluent notamment Datadog, Elastic et Splunk. D'autres solutions tierces validées seront ajoutées ultérieurement.

Les guides de solution suivants sont disponibles pour utiliser des solutions tierces avec Google Distributed Cloud :

Fonctionnement de Logging et Monitoring pour Google Distributed Cloud

Cloud Logging et Cloud Monitoring sont installés et activés dans chaque cluster dès la création d'un cluster d'administrateur ou d'utilisateur.

Les agents Stackdriver incluent plusieurs composants sur chaque cluster :

  • Opérateur Stackdriver (stackdriver-operator-*). Gère le cycle de vie de tous les autres agents Stackdriver déployés sur le cluster.

  • Ressource personnalisée Stackdriver. Ressource créée automatiquement dans le cadre du processus d'installation de Google Distributed Cloud.

  • Agent de métriques GKE (gke-metrics-agent-*). Un DaemonSet basé sur un collecteur OpenTelemetry qui scrape les métriques de chaque nœud pour Cloud Monitoring. Un DaemonSet node-exporter et un déploiement kube-state-metrics sont également inclus pour fournir plus de métriques sur le cluster.

  • Transfert de journaux Stackdriver (stackdriver-log-forwarder-*). Un daemonset Fluent Bit qui transmet les journaux de chaque machine à Cloud Logging. Le transfert de journaux met en mémoire tampon les entrées de journal sur le nœud localement et les renvoie pendant quatre heures maximum. Si la mémoire tampon est saturée ou si le service de transfert de journaux ne peut pas atteindre l'API Cloud Logging pendant plus de quatre heures, les journaux sont supprimés.

  • Agent de métadonnées (stackdriver-metadata-agent-). Un déploiement qui envoie des métadonnées pour des ressources Kubernetes telles que des pods, des déploiements ou des nœuds à l'API Config Monitoring pour Ops. L'ajout de métadonnées vous permet d'interroger vos données de métriques par nom de déploiement, nom de nœud ou même par nom de service Kubernetes.

Vous pouvez afficher les agents installés par Stackdriver en exécutant la commande suivante :

kubectl -n kube-system get pods -l "managed-by=stackdriver"

La sortie de la commande ressemble à ceci :

kube-system   gke-metrics-agent-4th8r                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-8lt4s                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-dhxld                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-lbkl2                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-pblfk                                     1/1     Running   1 (40h ago)   40h
kube-system   gke-metrics-agent-qfwft                                     1/1     Running   1 (40h ago)   40h
kube-system   kube-state-metrics-9948b86dd-6chhh                          1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-5s4pg                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-d9gwv                                         1/1     Running   2 (40h ago)   40h
kube-system   node-exporter-fhbql                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-gzf8t                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-tsrpp                                         1/1     Running   1 (40h ago)   40h
kube-system   node-exporter-xzww7                                         1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-8lwxh                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-f7cgf                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-fl5gf                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-q5lq8                             1/1     Running   2 (40h ago)   40h
kube-system   stackdriver-log-forwarder-www4b                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-log-forwarder-xqgjc                             1/1     Running   1 (40h ago)   40h
kube-system   stackdriver-metadata-agent-cluster-level-5bb5b6d6bc-z9rx7   1/1     Running   1 (40h ago)   40h

Métriques Cloud Monitoring

Pour obtenir la liste des métriques collectées par Cloud Monitoring, consultez la page Afficher les métriques de Google Distributed Cloud.

Configurer des agents Stackdriver pour Google Distributed Cloud

Les agents Stackdriver installés avec Google Distributed Cloud collectent des données sur les composants système à des fins de maintenance et de dépannage des clusters. Les sections suivantes décrivent la configuration de Stackdriver et les modes de fonctionnement.

Composants système uniquement (mode par défaut)

Lors de l'installation, les agents Stackdriver sont configurés par défaut pour collecter les journaux et les métriques, y compris les détails des performances (par exemple, l'utilisation du processeur et de la mémoire) et les métadonnées similaires pour les composants système fournis par Google, y compris toutes les charges de travail du cluster d'administrateur et, pour les clusters d'utilisateur, les charges de travail dans les espaces de noms kube-system, gke-system, gke-connect, istio-system et config-management-system.

Composants système et applications

Pour activer la journalisation et la surveillance des applications en plus du mode par défaut, suivez la procédure décrite dans Activer la journalisation et la surveillance des applications.

Métriques optimisées (métriques par défaut)

Par défaut, les déploiements kube-state-metrics exécutés dans le cluster collectent et signalent un ensemble optimisé de métriques kube à Google Cloud Observability (anciennement Stackdriver).

Moins de ressources sont nécessaires pour collecter cet ensemble optimisé de métriques, ce qui améliore les performances globales et l'évolutivité.

Pour désactiver les métriques optimisées (non recommandé), remplacez le paramètre par défaut dans votre ressource personnalisée Stackdriver.

Utiliser Google Cloud Managed Service pour Prometheus pour certains composants système

Google Cloud Managed Service pour Prometheus fait partie de Cloud Monitoring et est disponible en tant qu'option pour les composants système. Voici quelques-uns des avantages de Google Cloud Managed Service pour Prometheus:

  • Vous pouvez continuer à utiliser votre surveillance basée sur Prometheus existante sans modifier vos alertes et vos tableaux de bord Grafana.

  • Si vous utilisez à la fois GKE et Google Distributed Cloud, vous pouvez utiliser le même langage de requête Prometheus (PromQL) pour les métriques de tous vos clusters. Vous pouvez également utiliser l'onglet PromQL de l'explorateur de métriques dans la console Google Cloud .

Activer et désactiver Google Cloud Managed Service pour Prometheus

À partir de la version 1.30.0-gke.1930 de Google Distributed Cloud, Google Cloud Managed Service pour Prometheus est toujours activé. Dans les versions antérieures, vous pouvez modifier la ressource Stackdriver, stackdriver, pour activer ou désactiver Google Cloud Managed Service pour Prometheus. Pour désactiver Google Cloud Managed Service pour Prometheus pour les versions de cluster antérieures à 1.30.0-gke.1930, définissez spec.featureGates.enableGMPForSystemMetrics dans la ressource stackdriver sur false.

Afficher les données de métrique

Lorsque enableGMPForSystemMetrics est défini sur true, les métriques des composants suivants ont un format différent pour leur stockage et les requêtes dans Cloud Monitoring:

  • kube-apiserver
  • kube-scheduler
  • kube-controller-manager
  • kubelet and cadvisor
  • Métriques des kube-state
  • node-exporter

Dans le nouveau format, vous pouvez interroger les métriques précédentes à l'aide de PromQL ou du langage de requête Monitoring (MQL):

PromQL

Exemple de requête PromQL:

histogram_quantile(0.95, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le))

MQL

Pour utiliser MQL, définissez la ressource surveillée sur prometheus_target, utilisez le nom de la métrique avec le préfixe kubernetes.io/anthos et ajoutez le type Prometheus comme suffixe au nom de la métrique.

fetch prometheus_target
| metric 'kubernetes.io/anthos/apiserver_request_duration_seconds/histogram'
| align delta(5m)
| every 5m
| group_by [], [value_histogram_percentile: percentile(value.histogram, 95)]

Configurer des tableaux de bord Grafana avec Google Cloud Managed Service pour Prometheus

Pour utiliser Grafana avec les données de métriques de Google Cloud Managed Service pour Prometheus, vous devez d'abord configurer et authentifier la source de données Grafana. Pour configurer et authentifier la source de données, vous devez utiliser le synchronisateur de sources de données (datasource-syncer) pour générer des identifiants OAuth2 et les synchroniser avec Grafana via l'API de source de données Grafana. Le synchronisateur de sources de données définit l'API Cloud Monitoring comme URL du serveur Prometheus (la valeur de l'URL commence par https://monitoring.googleapis.com) sous la source de données dans Grafana.

Suivez la procédure décrite dans Interroger à l'aide de Grafana pour authentifier et configurer une source de données Grafana afin d'interroger les données de Google Cloud Managed Service pour Prometheus.

Un ensemble d'exemples de tableaux de bord Grafana est fourni dans le dépôt anthos-samples sur GitHub. Pour installer les exemples de tableaux de bord, procédez comme suit:

  1. Téléchargez les exemples de fichiers JSON:

    git clone https://github.com/GoogleCloudPlatform/anthos-samples.git
cd anthos-samples/gmp-grafana-dashboards

  2. Si votre source de données Grafana a été créée avec un nom différent de Managed Service for Prometheus, modifiez le champ datasource dans tous les fichiers JSON:

    sed -i "s/Managed Service for Prometheus/[DATASOURCE_NAME]/g" ./*.json

    Remplacez [DATASOURCE_NAME] par le nom de la source de données de votre Grafana qui pointait vers le service frontend Prometheus.

  3. Accédez à l'interface utilisateur de Grafana depuis votre navigateur, puis sélectionnez + Import (Importer) dans le menu Dashboards (Tableaux de bord).

    Accès à l'importation de tableaux de bord dans Grafana.

  4. Importez le fichier JSON, ou copiez-collez son contenu, puis sélectionnez Charger. Une fois le contenu du fichier chargé, sélectionnez Importer. Vous pouvez également modifier le nom et l'UID du tableau de bord avant de l'importer.

    Importer un tableau de bord dans Grafana

  5. Le tableau de bord importé devrait se charger correctement si votre Google Distributed Cloud et la source de données sont correctement configurés. Par exemple, la capture d'écran suivante montre le tableau de bord configuré par cluster-capacity.json.

    Tableau de bord de la capacité du cluster dans Grafana.

Autres ressources

Pour en savoir plus sur Google Cloud Managed Service pour Prometheus, consultez les ressources suivantes:

Configurer les ressources des composants Stackdriver

Lorsque vous créez un cluster, Google Distributed Cloud crée automatiquement une ressource personnalisée Stackdriver. Vous pouvez modifier la spécification de la ressource personnalisée pour remplacer les valeurs par défaut des demandes et limites de processeurs et de mémoire d'un composant Stackdriver, et remplacer séparément le paramètre de métrique optimisée par défaut.

Remplacer les valeurs par défaut de processeur et les demandes de mémoire et limites pour un composant Stackdriver

Les clusters à densité élevée des pods introduit des volumes de journalisation et de surveillance plus importants.accrues. Dans les cas extrêmes, les composants Stackdriver peuvent indiquer être à proximité de la limite d'utilisation du processeur et de la mémoire, ou même de subir des redémarrages constants du fait des limites de ressources. Dans ce cas, pour remplacer les valeurs par défaut des demandes de ressources mémoire et de processeur et des limites d'un composant Stackdriver, procédez comme suit :

  1. Exécutez la commande suivante pour ouvrir votre ressource personnalisée Stackdriver dans un éditeur de ligne de commande:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Dans la ressource personnalisée Stackdriver, ajoutez la section resourceAttrOverride sous le champ spec :

    resourceAttrOverride:
      DAEMONSET_OR_DEPLOYMENT_NAME/CONTAINER_NAME:
        LIMITS_OR_REQUESTS:
          RESOURCE: RESOURCE_QUANTITY

    Notez que la section resourceAttrOverride remplace toutes les limites et demandes par défaut du composant spécifié. Les composants suivants sont compatibles avec resourceAttrOverride :

    • gke-metrics-agent/gke-metrics-agent
    • stackdriver-log-forwarder/stackdriver-log-forwarder
    • stackdriver-metadata-agent-cluster-level/metadata-agent
    • node-exporter/node-exporter
    • kube-state-metrics/kube-state-metrics

    Voici un exemple de fichier :

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
  name: stackdriver
  namespace: kube-system
spec:
  anthosDistribution: baremetal
  projectID: my-project
  clusterName: my-cluster
  clusterLocation: us-west-1a
  resourceAttrOverride:
    gke-metrics-agent/gke-metrics-agent:
      requests:
        cpu: 110m
        memory: 240Mi
      limits:
        cpu: 200m
        memory: 4.5Gi

  3. Pour enregistrer les modifications apportées à la ressource personnalisée Stackdriver, enregistrez et quittez l'éditeur de ligne de commande.

  4. Vérifiez l'état du pod :

    kubectl -n kube-system get pods -l "managed-by=stackdriver"

    Une réponse pour un pod opérationnel se présente comme suit :

    gke-metrics-agent-4th8r                1/1     Running   1   40h

  5. Vérifiez la spécification du pod du composant pour vous assurer que les ressources sont définies correctement.

    kubectl -n kube-system describe pod POD_NAME

    Remplacez POD_NAME par le nom du pod que vous venez de modifier. Par exemple, gke-metrics-agent-4th8r.

    La réponse se présente comme suit :

      Name:         gke-metrics-agent-4th8r
  Namespace:    kube-system
  ...
  Containers:
    gke-metrics-agent:
      Limits:
        cpu: 200m
        memory: 4.5Gi
      Requests:
        cpu: 110m
        memory: 240Mi
      ...

Désactiver les métriques optimisées

Par défaut, les déploiements kube-state-metrics exécutés dans le cluster collectent et transmettent un ensemble optimisé de métriques kube à Stackdriver. Si vous avez besoin de métriques supplémentaires, nous vous recommandons de trouver un remplacement dans la liste des métriques de Google Distributed Cloud.

Voici quelques exemples de remplacements que vous pouvez utiliser :

Métrique désactivée Remplacements
kube_pod_start_time container/uptime
kube_pod_container_resource_requests container/cpu/request_cores
container/memory/request_bytes
kube_pod_container_resource_limits container/cpu/limit_cores
container/memory/limit_bytes

Pour désactiver le paramètre par défaut des métriques optimisées (non recommandé), procédez comme suit:

  1. Ouvrez votre ressource personnalisée Stackdriver dans un éditeur de ligne de commande:

    kubectl -n kube-system edit stackdriver stackdriver

  2. Définissez le champ optimizedMetrics sur false.

    apiVersion: addons.gke.io/v1alpha1
kind: Stackdriver
metadata:
name: stackdriver
namespace: kube-system
spec:
anthosDistribution: baremetal
projectID: my-project
clusterName: my-cluster
clusterLocation: us-west-1a
optimizedMetrics: false

  3. Enregistrez les modifications et quittez l'éditeur de ligne de commande.

Serveur de métriques

Metrics-server est la source des métriques de ressources de conteneur pour divers pipelines d'autoscaling. Metrics-server extrait les métriques des kubelets et les expose via l'API Metrics de Kubernetes. Les autoscalers horizontal et vertical de pods exploitent ensuite ces métriques pour savoir à quel moment déclencher l'autoscaling. Metrics-server est mis à l'échelle à l'aide du module addon-resizer.

Dans les cas extrêmes où la densité de pods élevée entraîne trop de journalisation et de surveillance, metrics-server peut être arrêté et redémarré en raison de limites de ressources. Dans ce cas, vous pouvez allouer davantage de ressources au serveur de métriques en modifiant le fichier ConfigMap metrics-server-config dans l'espace de noms gke-managed-metrics-server, et en modifiant la valeur de cpuPerNode et memoryPerNode.

kubectl edit cm metrics-server-config -n gke-managed-metrics-server

L'exemple de contenu du fichier ConfigMap est le suivant :

apiVersion: v1
data:
  NannyConfiguration: |-
    apiVersion: nannyconfig/v1alpha1
    kind: NannyConfiguration
    cpuPerNode: 3m
    memoryPerNode: 20Mi
kind: ConfigMap

Après avoir mis à jour le fichier ConfigMap, recréez les pods metrics-server à l'aide de la commande suivante :

kubectl delete pod -l k8s-app=metrics-server -n gke-managed-metrics-server

Routage des journaux et des métriques

Le transfert de journaux Stackdriver (stackdriver-log-forwarder) envoie les journaux de chaque machine de nœud à Cloud Logging. De même, l'agent de métriques GKE (gke-metrics-agent) envoie les métriques de chaque machine de nœud à Cloud Monitoring. Avant l'envoi des journaux et des métriques, l'opérateur Stackdriver (stackdriver-operator) associe la valeur du champ clusterLocation de la ressource personnalisée stackdriver à chaque entrée de journal et à chaque métrique avant qu'elles ne soient acheminées vers Google Cloud. En outre, les journaux et les métriques sont associés au projet Google Cloud spécifié dans la spécification de la ressource personnalisée stackdriver (spec.projectID).

La ressource stackdriver obtient les valeurs des champs clusterLocation et projectID à partir des champs location et projectID de la section clusterOperations de la ressource Cluster au moment de la création du cluster.

Toutes les métriques et les entrées de journal envoyées par les agents Stackdriver sont acheminées vers un point de terminaison d'ingestion global. De là, les données sont transférées vers le point de terminaison régional Google Cloud le plus proche pour garantir la fiabilité du transport des données.

Une fois que le point de terminaison global a reçu la métrique ou l'entrée de journal, la suite dépend du service:

  • Configuration du routage des journaux: lorsque le point de terminaison de journalisation reçoit un message de journal, Cloud Logging le transmet via le routeur de journaux. Les sinks et les filtres de la configuration du routeur de journaux déterminent comment acheminer le message. Vous pouvez acheminer les entrées de journal vers des destinations telles que des buckets Logging régionaux, qui stockent l'entrée de journal, ou vers Pub/Sub. Pour en savoir plus sur le fonctionnement du routage des journaux et sur la façon de le configurer, consultez la page Présentation du routage et du stockage.

    Ni le champ clusterLocation de la ressource personnalisée stackdriver, ni le champ clusterOperations.location de la spécification du cluster ne sont pris en compte dans ce processus de routage. Pour les journaux, clusterLocation permet uniquement d'étiqueter les entrées de journal, ce qui peut être utile pour le filtrage dans l'explorateur de journaux.

  • Configuration du routage des métriques: lorsque le point de terminaison des métriques reçoit une entrée de métrique, elle est routée automatiquement pour être stockée à l'emplacement spécifié par la métrique. L'emplacement de la métrique provient du champ clusterLocation de la ressource personnalisée stackdriver.

  • Planifiez votre configuration: lorsque vous configurez Cloud Logging et Cloud Monitoring, configurez Log Router et spécifiez un clusterOperations.location approprié avec les emplacements qui répondent le mieux à vos besoins. Par exemple, si vous souhaitez que les journaux et les métriques soient stockés au même endroit, définissez clusterOperations.location sur la même région Google Cloud que celle utilisée par Log Router pour votre Google Cloud projet.

  • Mettez à jour la configuration de vos journaux si nécessaire: vous pouvez modifier à tout moment les paramètres de destination des journaux en raison de besoins métier, tels que des plans de reprise après sinistre. Les modifications apportées à la configuration du routeur de journaux dansGoogle Cloud prennent rapidement effet. Les champs location et projectID de la section clusterOperations de la ressource Cluster sont immuables. Ils ne peuvent donc pas être mis à jour une fois le cluster créé. Nous vous déconseillons de modifier directement les valeurs de la ressource stackdriver. Cette ressource est rétablie à l'état d'origine de la création du cluster chaque fois qu'une opération de cluster, telle qu'une mise à niveau, déclenche une mise en correspondance.

Configuration requise pour Logging et Monitoring

Plusieurs configurations sont requises pour activer Cloud Logging et Cloud Monitoring avec Google Distributed Cloud. Ces étapes sont incluses dans la section Configurer un compte de service à utiliser avec Logging et Monitoring sur la page "Activer les services Google" et dans la liste suivante :

  1. Un espace de travail Cloud Monitoring doit être créé dans le projetGoogle Cloud . Pour ce faire, cliquez sur Monitoring dans la consoleGoogle Cloud et suivez le workflow.

  2. Vous devez activer les API Stackdriver suivantes :

  3. Vous devez attribuer les rôles IAM suivants au compte de service utilisé par les agents Stackdriver :

    • logging.logWriter
    • monitoring.metricWriter
    • stackdriver.resourceMetadata.writer
    • monitoring.dashboardEditor
    • opsconfigmonitoring.resourceMetadata.writer

Balises de journal

De nombreux journaux Google Distributed Cloud comportent une balise F:

logtag: "F"

Cette balise signifie que l'entrée de journal est complète ou pleine. Pour en savoir plus sur cette balise, consultez la section Format de journal dans les propositions de conception Kubernetes sur GitHub.

Tarifs

Les journaux système et les métriques de l'édition Enterprise de Google Kubernetes Engine (GKE) sont gratuits.

Dans un cluster Google Distributed Cloud, les journaux système et les métriques de Google Kubernetes Engine (GKE) édition Enterprise incluent les éléments suivants:

  • Journaux et métriques de tous les composants d'un cluster d'administrateur.
  • Journaux et métriques des composants de ces espaces de noms dans un cluster d'utilisateur : kube-system, gke-system, gke-connect, knative-serving, istio-system, monitoring-system, config-management-system, gatekeeper-system, cnrm-system.

Pour en savoir plus, consultez la section Tarifs de Google Cloud Observability.

Pour en savoir plus sur l'attribution de crédits pour les métriques Cloud Logging, contactez le service commercial au sujet des tarifs.