Utiliser Prometheus

Prometheus est un outil de surveillance facultatif souvent employé avec Kubernetes. Si vous configurez Stackdriver Kubernetes Engine Monitoring pour qu'il soit compatible avec Prometheus, les services qui exposent les métriques du modèle de données Prometheus peuvent alors être exportés du cluster et rendus visibles en tant que métriques externes dans Stackdriver.

Cette page présente un mécanisme permettant à Stackdriver de collecter des données à partir de clients Prometheus, grâce à Stackdriver Kubernetes Engine Monitoring. Le code source servant à l'intégration est disponible publiquement.

Avant de commencer

La compatibilité Prometheus décrite ici ne fonctionne pas avec l'ancienne compatibilité Stackdriver décrite sur la page Stackdriver Monitoring.

Installer le collecteur

Stackdriver propose un collecteur qui doit être déployé en tant que side-car dans le même pod Kubernetes que votre serveur Prometheus. Exécutez les commandes d'interface système suivantes pour installer le collecteur Stackdriver dans un nouveau cluster à l'aide de Stackdriver Kubernetes Engine Monitoring.

Connectez-vous au cluster, puis exécutez le script suivant avec les variables d'environnement requises :

  • KUBE_NAMESPACE : espace de noms sur lequel exécuter le script
  • KUBE_CLUSTER : paramètre de nom de cluster pour le side-car
  • GCP_REGION : paramètre de région GCP pour le side-car
  • GCP_PROJECT : paramètre de projet GCP pour le side-car
  • DATA_DIR : répertoire de données pour le side-car
  • DATA_VOLUME : nom du volume contenant les données de Prometheus
  • SIDECAR_IMAGE_TAG : version de l'image Docker pour le side-car Prometheus. Nous vous recommandons d'utiliser la dernière version de Container Registry.
#!/bin/sh

set -e
set -u

usage() {
  echo -e "Usage: $0 <deployment|statefulset> <name>\n"
}

if [  $# -le 1 ]; then
  usage
  exit 1
fi

# Override to use a different Docker image name for the sidecar.
export SIDECAR_IMAGE_NAME=${SIDECAR_IMAGE_NAME:-'gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar'}

kubectl -n "${KUBE_NAMESPACE}" patch "$1" "$2" --type strategic --patch "
spec:
  template:
    spec:
      containers:
      - name: sidecar
        image: ${SIDECAR_IMAGE_NAME}:${SIDECAR_IMAGE_TAG}
        imagePullPolicy: Always
        args:
        - \"--stackdriver.project-id=${GCP_PROJECT}\"
        - \"--prometheus.wal-directory=${DATA_DIR}/wal\"
        - \"--stackdriver.kubernetes.location=${GCP_REGION}\"
        - \"--stackdriver.kubernetes.cluster-name=${KUBE_CLUSTER}\"
        #- \"--stackdriver.generic.location=${GCP_REGION}\"
        #- \"--stackdriver.generic.namespace=${KUBE_CLUSTER}\"
        ports:
        - name: sidecar
          containerPort: 9091
        volumeMounts:
        - name: ${DATA_VOLUME}
          mountPath: ${DATA_DIR}
"

Valider la configuration

Après avoir configuré Prometheus, exécutez la commande suivante pour valider l'installation :

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name> -o=go-template='{{$output := "stackdriver-prometheus-sidecar does not exists."}}{{range .spec.template.spec.containers}}{{if eq .name "stackdriver-prometheus-sidecar"}}{{$output = (print "stackdriver-prometheus-sidecar exists. Image: " .image)}}{{end}}{{end}}{{printf $output}}{{"\n"}}'

En cas d'installation réussie du side-car Prometheus, le résultat du script indique :

stackdriver-prometheus-sidecar exists. Image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:0.3.2

En cas d'échec de l'installation du side-car Prometheus, le résultat du script indique :

stackdriver-prometheus-sidecar does not exist.

Pour vérifier si une charge de travail est à jour et disponible, exécutez :

kubectl -n "${KUBE_NAMESPACE}" get <deployment|statefulset> <name>

Mettre à jour la configuration

Après avoir vérifié que le collecteur a bien été installé, mettez à jour la configuration du cluster pour rendre les modifications permanentes :

  1. Assurez-vous que le serveur Prometheus écrit sur un volume partagé :

    1. Vérifiez que le pod Prometheus comprend un volume partagé :

      volumes:
        - name: data-volume
          emptyDir: {}
      
    2. Faites en sorte que Prometheus installe le volume sous /data :

      volumeMounts:
      - name: data-volume
        mountPath: /data
      
    3. Indiquez au serveur Prometheus d'écrire sur le volume partagé dans /data. Ajoutez la ligne suivante à son conteneur args :

      --storage.tsdb.path=/data
      
  2. Ajoutez le conteneur collecteur en tant que side-car.

    - name: sidecar
      image: gcr.io/stackdriver-prometheus/stackdriver-prometheus-sidecar:[SIDECAR_IMAGE_TAG]
      args:
      - "--stackdriver.project-id=[GCP_PROJECT]"
      - "--prometheus.wal-directory=/data/wal"
      - "--stackdriver.kubernetes.location=[GCP_REGION]"
      - "--stackdriver.kubernetes.cluster-name=[KUBE_CLUSTER]"
      ports:
      - name: sidecar
        containerPort: 9091
      volumeMounts:
      - name: data-volume
        mountPath: /data
    

Pour plus de détails sur la configuration du collecteur, reportez-vous à la documentation relative au side-car Stackdriver Prometheus.

Afficher les métriques

Le logiciel Prometheus que vous avez installé est configuré pour commencer à exporter les métriques vers Monitoring en tant que métriques externes. Vous pouvez les voir dans Stackdriver > Resources > Metrics Explorer (Stackdriver > Ressources > Explorateur de métriques) :

ACCÉDER À L'EXPLORATEUR DE MÉTRIQUES

Dans le type de ressource surveillée Kubernetes Container (k8s_container), recherchez des métriques nommées external/prometheus/.... external/prometheus/go_memstats_alloc_bytes est une métrique qui devrait comporter des données intéressantes. Si votre espace de travail contient plusieurs clusters, vous pouvez filtrer le graphique en fonction du nom du cluster, comme illustré dans la capture d'écran suivante :

Graphique Prometheus

Problèmes d'intégration de Prometheus

Aucune donnée ne s'affiche dans Stackdriver.

Si aucune donnée ne s'affiche dans Stackdriver après avoir suivi les étapes d'installation, consultez les journaux du collecteur pour rechercher les éventuels messages d'erreur pouvant indiquer des problèmes.

Si les journaux ne contiennent aucun message d'échec évident, transmettez l'indicateur -log.level=debug au collecteur afin d'activer la journalisation de débogage. Après avoir redémarré le collecteur, vous verrez peut-être de nouveaux messages pouvant indiquer l'origine du problème.

J'utilise des règles d'enregistrement et les métriques n'apparaissent pas dans Stackdriver.

Les règles d'enregistrement nécessitent un traitement spécial. Nous recommandons d'ingérer dans la mesure du possible la métrique brute dans les fonctionnalités de Stackdriver et de Stackdriver Monitoring afin d'agréger les données au moment de la requête (graphique, tableau de bord, etc.).

Si l'ingestion de la métrique brute n'est pas possible, vous pouvez ajouter une entrée static_metadata dans la configuration du collecteur (documents). Cette option nécessite de conserver les étiquettes job et instance. Par exemple, la configuration actuelle est valide :

Dans la configuration du serveur Prometheus :

groups:
- name: my-groups
  rules:
  - record: backlog_avg_10m
    expr: avg_over_time(backlog_k8s[10m])
  - record: backlog_k8s
    expr: sum(total_lag) by (app, job, instance)

Dans la configuration du collecteur Stackdriver Prometheus :

static_metadata:
  - metric: backlog_avg_10m
    type: gauge

Les règles d'enregistrement en cours qui modifient ou suppriment les étiquettes job ou instance ne sont pas acceptées.

Mes métriques ne comportent pas les libellés Prometheus job et instance.

Le collecteur Stackdriver Prometheus construit une ressource MonitoredResource Stackdriver pour vos objets Kubernetes à partir d'étiquettes Prometheus bien connues. Si vous modifiez par mégarde les descripteurs de libellés, le collecteur ne peut pas écrire les métriques dans Stackdriver.

Des erreurs telles que "série temporelle en double" ou "écritures non ordonnées" s'affichent dans les journaux.

Ces erreurs peuvent être causées par une double écriture de données de métriques dans la même série temporelle. Elles peuvent se produire si vos points de terminaison Prometheus exposent les mêmes données de métriques (le même ensemble de valeurs d'étiquettes de métriques) à deux reprises à partir d'une seule ressource surveillée Stackdriver.

Par exemple, un conteneur Kubernetes peut exposer des métriques Prometheus sur plusieurs ports. Comme la ressource surveillée k8s_container de Stackdriver ne différencie pas les ressources en fonction du port, Stackdriver détecte que vous écrivez deux points dans la même série temporelle. Pour contourner le problème, vous pouvez ajouter dans Prometheus une étiquette de métrique qui différencie la série temporelle. Par exemple, vous pouvez employer l'étiquette __meta_kubernetes_pod_annotation_prometheus_io_port, car il doit rester constant pendant le redémarrage du conteneur.

Je vois des erreurs telles que "le type de métrique est X, mais il devrait être Y" dans les journaux.

Ces erreurs peuvent être causées par la modification du type de métrique Prometheus dans le code source entre jauge, compteur et autres. Les métriques Stackdriver correspondent à des types stricts que Stackdriver applique de façon stricte, car la sémantique des données varie selon le type.

Si vous souhaitez modifier le type d'une métrique, vous devez supprimer les descripteurs de métrique correspondants. Les données des séries temporelles seront ainsi inaccessibles.

Je suis sûr d'avoir déjà vu des types de métriques Prometheus, mais je ne les trouve plus.

Le logiciel Prometheus que vous avez installé est préconfiguré pour exporter les métriques vers Stackdriver Monitoring en tant que métriques externes. Une fois les données exportées, Monitoring crée le descripteur approprié pour la métrique externe. Si aucune donnée de ce type de métrique n'est par la suite écrite pendant au moins six semaines, le descripteur de la métrique est sujet à suppression.

Rien ne garantit que les descripteurs de métriques non utilisés seront supprimés au bout de six semaines, mais Monitoring se réserve le droit de supprimer tout descripteur de métrique Prometheus non utilisé au cours des six dernières semaines.

Règle relative aux abandons

L'intégration de Stackdriver Prometheus est soumise au Règlement d'obsolescence des agents Stackdriver.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Stackdriver Monitoring
Besoin d'aide ? Consultez notre page d'assistance.