Migrer vers les métriques de charge de travail GKE à partir du side-car Stackdriver Prometheus

Ce tutoriel explique comment migrer un pipeline de collecte de métriques basé sur le side-car Stackdriver Prometheus vers des métriques de charge de travail Google Kubernetes Engine (GKE) entièrement gérées. L'utilisation des métriques de charge de travail GKE présente de nombreux avantages par rapport au side-car Stackdriver Prometheus :

  • Configuration facile : une commande kubectl permettant de déployer une ressource personnalisée PodMonitor suffit pour commencer à collecter des métriques.
  • Haute configuration : ajustez les points de terminaison scrapés, la fréquence et d'autres paramètres.
  • Entièrement gérées : Google gère le pipeline, ce qui réduit le coût total de possession.
  • Contrôle des coûts : gérez facilement les coûts Cloud Monitoring grâce au filtrage flexible des métriques.
  • Standard ouvert : configurez les métriques liées aux charges de travail à l'aide de la ressource personnalisée PodMonitor, modélisée à partir de la ressource PodMonitor de l'opérateur Prometheus.
  • Compatibilité AHP : compatible avec l'adaptateur de métriques personnalisées Stackdriver pour permettre l'autoscaling horizontal sur les métriques personnalisées.
  • Meilleurs tarifs : tarifs plus intuitifs, prévisibles et économiques.
  • Compatibilité avec Autopilot : les métriques de charge de travail GKE sont disponibles pour les clusters GKE Standard et GKE Autopilot.

Vérifier que vous utilisez le side-car Stackdriver Prometheus

Le side-car Stackdriver Prometheus était auparavant l'approche recommandée pour collecter des métriques de type Prometheus à partir de clusters GKE et les ingérer dans Cloud Monitoring. Dans cette approche, une installation Prometheus existante, généralement exécutée en tant que StatefulSet ou Deployment sous GKE, est corrigée avec un side-car qui exporte toutes les métriques qu'il scrape dans Cloud Monitoring. Le chart Helm Prometheus est un moyen pratique de configurer cette intégration.

Déterminer si les métriques de charge de travail GKE correspondent à votre utilisation

La checklist suivante peut vous aider à déterminer si vous utilisez des fonctionnalités de l'approche side-car Stackdriver Prometheus qui ne peuvent pas être reproduites à l'aide de métriques de charges de travail GKE.

Caractéristique Assistance/solutions
Prometheus est-il utilisé pour surveiller autre chose que les pods d'un même cluster ? Pour ce faire, vérifiez l'utilisation des éléments suivants :
  • static_config
  • Tout plug-in de détection de services autre que kubernetes_sd_config
  • Tout rôle kubernetes_sd_config autre que endpoint ou pod
  • api_server ou kubeconfig utilisés pour pointer vers un autre cluster Kubernetes
 Le rôle pod est prêt à l'emploi. Le rôle endpoint peut être simulé en exposant et en nommant le port.
Les pods sont-ils sélectionnés en fonction des champs plutôt que des libellés ? Utilisez un sélecteur de libellés équivalent, qui peut nécessiter l'ajout de nouveaux libellés aux pods souhaités.
Prometheus est-il configuré avec une forme d'autorisation HTTP ou de TLS mutuelle pour le scraping ? Cette fonctionnalité n'est pas compatible avec les métriques de charge de travail GKE.
Prometheus est-il configuré avec metric_relabel_configs qui utilise des actions autres que keep et drop ? Cette fonctionnalité n'est pas compatible avec les métriques de charge de travail GKE.
Utilisez-vous les fonctionnalités d'agrégateur de compteurs ou de renommage de métriques du side-car Stackdriver Prometheus ? Cette fonctionnalité n'est pas compatible avec les métriques de charge de travail GKE.
Votre configuration Prometheus inclut-elle des alertes ? Convertir ces données en alertes dans Monitoring.
Votre configuration side-car inclut-elle static_metadata ? Les métriques de charge de travail GKE collectent vos métriques, mais ignorent la documentation.

Migrer la configuration Prometheus vers les ressources personnalisées PodMonitor

Pour chaque tâche (élément du tableau scrape_configs) définie dans la configuration Prometheus, créez une ressource personnalisée PodMonitor correspondante. En voici un exemple :

Configuration Prometheus CRD PodMonitor 

scrape_configs:
- job_name: example
  metrics_path: /metrics
  scheme: http
  scrape_interval: 20s
  kubernetes_sd_configs:
  - role: endpoints
    namespaces:
      names:
      - gke-workload-metrics
    selectors:
    - role: endpoints
      label: "app=prom-example"
      field: "port=metrics-port"
 

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: example
spec:
  namespaceSelector:
    matchNames:
    - gke-workload-metrics
  selector:
    matchLabels:
      app: prom-example
  podMetricsEndpoints:
  - port: metrics-port
    path: /metrics
    scheme: http
    interval: 20s

Migrer la configuration du side-car vers les ressources personnalisées PodMonitor

Les filtres configurés au niveau du side-car s'appliquent à toutes les tâches de scraping. Par conséquent, vous devez ajouter ces configurations à chaque CRD de PodMonitor que vous avez créée à l'étape précédente.

CLI du side-car CRD PodMonitor 

$ stackdriver-prometheus-sidecar \
--include='metric_name{label="foo"}'
 

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: example
spec:
  namespaceSelector:
    matchNames:
    - gke-workload-metrics
  selector:
    matchLabels:
      app: prom-example
  podMetricsEndpoints:
  - port: metrics-port
    path: /metrics
    scheme: http
    interval: 20s
    metricRelabelings:
      - sourceLabels: [__name__, label]
        regex: "^metric_name;foo$"
        action: keep
      - sourceLabels: [__name__]

Afficher les métriques dans Google Cloud Monitoring

Utilisez l'Explorateur de métriques pour vérifier que la métrique est désormais ingérée via le pipeline de métriques de la charge de travail GKE.

Notez que si la métrique s'appelait auparavant external.googleapis.com/prometheus/metric_name, elle s'appelle désormais workload.googleapis.com/metric_name. N'oubliez pas de modifier les tableaux de bord ou les alertes qui dépendent de ces métriques pour utiliser plutôt le nouveau schéma de nommage.