Configurer la journalisation et la surveillance

Les clusters Anthos sur Bare Metal comprennent plusieurs options pour la journalisation et la surveillance de clusters, y compris les services gérés basés sur le cloud et des outils Open Source, mais aussi 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.

Options pour les clusters Anthos sur Bare Metal

Vous disposez de plusieurs options de journalisation et de surveillance pour vos clusters Anthos sur Bare Metal :

  • 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

La suite Google Cloud Operations est la solution d'observabilité intégrée pour Google 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 Anthos sur Bare Metal de la même manière que les clusters GKE basés sur le cloud.

Les agents peuvent être configurés avec deux niveaux différents de journalisation et de surveillance :

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

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 les clusters Anthos sur Bare Metal seulement, ou lorsque vous les exécutez sur GKE et les clusters Anthos sur Bare Metal. Pour les applications avec des composants s'exécutant sur une infrastructure standard traditionnelle sur site et sur les clusters Anthos sur Bare Metal, 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.

Prometheus et Grafana peuvent être activés sur chaque cluster d'administrateur et d'utilisateur. Prometheus et Grafana sont recommandés pour les équipes d'application ayant déjà une expérience de ces produits. Ces produits sont également recommandés pour les équipes opérationnelles qui préfèrent conserver les métriques d'application dans le cluster à des fins de dépannage des problèmes de connexion réseau.

Solutions tierces

Google a travaillé avec plusieurs fournisseurs de solutions tierces de journalisation et de surveillance pour faire en sorte que leurs produits fonctionnent correctement avec les clusters Anthos sur Bare Metal. 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 les clusters Anthos sur Bare Metal :

Fonctionnement de Logging et Monitoring pour les clusters Anthos sur Bare Metal

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 des clusters Anthos sur Bare Metal.

  • 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 Anthos (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. Ces données sont utilisées pour enrichir les requêtes de métriques en vous permettant d'effectuer des requêtes par nom de déploiement, par 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 des clusters Anthos sur Bare Metal.

Configurer des agents Stackdriver pour les clusters Anthos sur Bare Metal

Les agents Stackdriver installés avec clusters Anthos sur Bare Metal 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), ainsi que des métadonnées similaires pour les composants système fournis par Google. Celles-ci comprennent toutes les charges de travail du cluster d'administrateur, ainsi que les charges de travail des clusters d'utilisateur dans les espaces de noms du système 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.

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

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 kube-system, et en modifiant la valeur de cpuPerNode et memoryPerNode.

kubectl edit cm metrics-server-config -n kube-system

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 kube-system

Configuration requise pour Logging et Monitoring

Plusieurs conditions de configuration sont requises pour activer Cloud Logging et Cloud Monitoring avec les clusters Anthos sur Bare Metal. 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. Vous devez créer un espace de travail Cloud Monitoring dans le projet Google Cloud. Pour ce faire, cliquez sur Monitoring dans la console Google 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

Tarifs

Aucuns frais ne s'appliquent pour les journaux système et les métriques Anthos.

Dans un cluster Anthos sur Bare Metal, les journaux et les métriques du système Anthos 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 la suite Google Cloud Operations.

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