Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Surveiller Config Sync

Cette page explique comment surveiller vos ressources Config Sync.

Lorsque vous activez les API RootSync et RepoSync, Config Sync utilise OpenCensus pour créer et enregistrer des métriques et OpenTelementry pour exporter ses métriques vers Prometheus et Cloud Monitoring. Vous pouvez également utiliser OpenTelemetry pour exporter des métriques vers un système de surveillance personnalisé. Ce processus vous fournit trois méthodes permettant de surveiller vos ressources :

  1. Cloud Monitoring
  2. Système de surveillance personnalisé
  3. Prometheus

Si vous n'activez pas les API RootSync et RepoSync, vous ne pouvez surveiller les ressources qu'avec Prometheus.

Métriques OpenTelementry disponibles

Une fois les API RootSync et RepoSync activées, Config Sync et le contrôleur de groupe de ressources collectent les métriques suivantes et les mettent à la disposition d'OpenTelemetry. La colonne Tags répertorie tous les tags applicables à chaque métrique. Les métriques avec des tags représentent plusieurs mesures, une pour chaque combinaison de valeurs de tags.

Métriques Config Sync

Les métriques suivantes sont disponibles à partir d'Anthos Config Management version 1.10.1 et ultérieure.

Nom Type Tags Description
api_duration_seconds Distribution État de l'opération Distribution de la latence des appels de serveur d'API
apply_duration_seconds Distribution état Distribution de la latence des événements de synchronisation des ressources d'application
apply_operations_total Nombre État de l'opération Nombre total d'opérations effectuées pour synchroniser les ressources avec la source fiable
declared_resources Dernière valeur rapprochement Nombre de ressources déclarées analysées à partir de Git
internal_errors_total Nombre rapprochement, source Nombre total d'erreurs internes déclenchées par Config Sync
last_sync_timestamp Dernière valeur rapprochement Horodatage de la dernière synchronisation à partir de Git
parser_duration_seconds Distribution rapprochement, état, déclencheur, source Distribution de la latence de la boucle parse-apply-watch
pipeline_error_observed Dernière valeur name, reconciler, component État des ressources personnalisées RootSync et RepoSync. Une valeur de 1 indique un échec.
reconcile_duration_seconds Distribution état Distribution de la latence des événements de rapprochement gérés par le gestionnaire de rapprochement.
reconciler_errors Dernière valeur rapprochement, composant Nombre d'erreurs dans les rapprochements RootSync et RepoSync
remediate_duration_seconds Distribution état Distribution de la latence des événements de rapprochement de correction
resource_conflicts_total Nombre rapprochement Nombre total de conflits de ressources résultant d'une différence entre les ressources mises en cache et les ressources du cluster
resource_fights_total Nombre rapprochement Nombre total de ressources synchronisées trop fréquemment. Tout résultat supérieur à zéro indique un problème. Pour en savoir plus, consultez la page KNV2005 : ResourceFightWarning.
rendering_count_total Nombre rapprochement Nombre d'exécutions de synchronisation utilisant le rendu Kustomize ou Helm sur les ressources.
skip_rendering_count_total Nombre rapprochement Le nombre d'exécutions de synchronisation qui n'ont pas utilisé de rendus Kustomize ou Helm sur les ressources.
resource_override_count_total Nombre rapprochement, conteneur, ressource Nombre de remplacements de ressources spécifiés dans le correctif de ressource
git_sync_depth_override_count_total Nombre - Nombre d'objets Root/RepoSync dans lesquels le remplacement spec.override.gitSyncdeep est défini. La profondeur Git peut être utilisée pour améliorer les performances lors de la synchronisation à partir de dépôts volumineux.
no_ssl_verify_count_total Nombre - Nombre d'objets Root/RepoSync avec le remplacement .spec.git.noSSLVerify.

Métriques de contrôleur de groupe de ressources

Le contrôleur de groupe de ressources est un composant de Config Sync qui effectue le suivi des ressources gérées et vérifie si chacune d'elles est prête ou rapprochée. Les métriques suivantes sont disponibles :

Nom Type Tags Description
reconcile_duration_seconds Distribution stallreason Répartition du temps nécessaire au rapprochement d'une RS ResourceGroup
resource_group_total Dernière valeur Nombre actuel de RS ResourceGroup
resource_count_total Sum Nombre total de ressources suivies par toutes les RS ResourceGroup du cluster
resource_count Dernière valeur resourcegroup Nombre total de ressources suivies par une RS ResourceGroup
ready_resource_count_total Sum Nombre total de ressources prêtes à travers toutes les RS ResourceGroup du cluster
ready_resource_count Dernière valeur resourcegroup Nombre total de ressources prêtes dans une RS ResourceGroup
resource_ns_count Dernière valeur resourcegorup Nombre d'espaces de noms utilisés par les ressources dans une RS ResourceGroup
cluster_scoped_resource_count Dernière valeur resourcegroup Nombre de ressources à l'échelle du cluster dans une RS ResourceGroup
crd_count Dernière valeur resourcegroup Nombre de CRD dans une RS ResourceGroup
kcc_resource_count_total Sum Nombre total de ressources Config Connector pour toutes les RS ResourceGroup du cluster
kcc_resource_count Jauge resourcegroup Nombre total de ressources KCC dans un ResourceGroup
pipeline_error_observed Dernière valeur name, reconciler, component État des ressources personnalisées RootSync et RepoSync. Une valeur de 1 indique un échec.

Tags de métriques Config Sync

Les tags de métriques peuvent être utilisés pour agréger les données de métriques. Il peut être sélectionné dans la liste déroulante "Grouper par" de la console Monitoring.

Tags personnalisés

Les tags personnalisés sont répertoriés pour chaque métrique dans la colonne "Tag" des tables ci-dessus.

Nom Values Description
operation création, correction, mise à jour, suppression Le type d'opération effectuée
status réussite, erreur État de l'exécution d'une opération
reconciler rootsync, reposync Type de rapprochement
source analyseur, différence, outil de résolution Source de l'erreur interne.
trigger réessayez, watchUpdate, managementConflict, resync, reimport Déclencheur d'un événement de rapprochement
name Nom du rapprochement Nom du rapprochement
component analyse, source, synchronisation, rendu, aptitude Le nom du composant / étape du rapprochement actuelle
container rapprochement, git-sync Nom du conteneur
resource Processeur, mémoire Le type de la ressource

Tags de ressource

Les métriques de surveillance personnalisées de Config Sync utilisent le type de ressource K8s_Pod, fourni avec les tags suivants.

Nom Description
project ID du projet
cluster_name Le nom du cluster
location L'emplacement / la zone du cluster
namespace_name Nom de l'espace de noms à partir duquel les métriques sont exportées.
pod_name Le nom du pod à partir duquel les métriques sont exportées

Comprendre la métrique pipeline_error_observed

La métrique pipeline_error_observed est une métrique qui peut vous aider à identifier rapidement les RS RepoSync ou RootSync qui ne sont pas synchronisées ou qui contiennent des ressources qui ne sont pas rapprochées de l'état souhaité.

  • Pour une synchronisation réussie par RootSync ou RepoSync, les métriques avec tous les composants (rendering, source, sync, readiness) sont observées avec la valeur 0.

    Capture d'écran de la métrique pipeline_error_observed avec tous les composants observés avec la valeur 0

  • Lorsque le dernier commit échoue l'affichage automatisé, la métrique avec le composant rendering est observée avec la valeur 1.

  • En cas d'erreur lors du dernier commit ou si le dernier commit contient une configuration non valide, la métrique du composant source est observée avec la valeur 1.

  • Lorsqu'une ressource ne peut pas être appliquée au cluster, la métrique avec le composant sync est observée avec la valeur 1.

  • Lorsqu'une ressource est appliquée, mais ne parvient pas à atteindre son état souhaité, la métrique avec le composant readiness est observée avec la valeur 1. Par exemple, un déploiement est appliqué au cluster, mais les pods correspondants ne sont pas créés correctement.

Surveiller des ressources avec Cloud Monitoring

Si Config Sync s'exécute dans un environnement Google Cloud disposant d'un compte de service par défaut, Config Sync exporte automatiquement les métriques vers Cloud Monitoring.

Si Workload Identity est activé, procédez comme suit :

  1. Liez le compte de service Kubernetes default dans l'espace de noms config-management-monitoring à un compte de service Google doté du rôle de rédacteur de métriques :

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    Remplacez les éléments suivants :

    • PROJECT_ID : ID de votre projet.
    • GSA_NAME : compte de service Google disposant du rôle IAM "Rédacteur de métriques Monitoring" (roles/monitoring.metricWriter). Si vous ne disposez pas d'un compte de service avec ce rôle, vous pouvez en créer un.

    Cette action nécessite une autorisation iam.serviceAccounts.setIamPolicy sur le projet.

  2. Annotez le compte de service Kubernetes à l'aide de l'adresse e-mail du compte de service Google :

    kubectl annotate serviceaccount \
        --namespace config-management-monitoring \
        default \
        iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

Pour obtenir des exemples sur la façon d'afficher ces métriques, consultez la section Exemples de procédures de débogage et l'article Métriques OpenCensus dans Cloud Monitoring.

Exemples de procédures de débogage pour Cloud Monitoring

Les exemples Cloud Monitoring suivants illustrent certains modèles d'utilisation des métriques OpenCensus pour détecter et diagnostiquer les problèmes liés à Config Sync lorsque vous utilisez les API RootSync et RepoSync.

Format de la métrique

Dans Cloud Monitoring, les métriques sont au format suivant : custom.googleapis.com/opencensus/config_sync/METRIC.

Ce nom de métrique comprend les composants suivants :

  • custom.googleapis.com : toutes les métriques personnalisées ont ce préfixe
  • opencensus : ce préfixe est ajouté, car Config Sync utilise la bibliothèque OpenCensus.
  • config_sync/ : les métriques exportées par Config Sync vers Cloud Monitoring ont ce préfixe
  • METRIC : nom de la métrique que vous souhaitez interroger.

Interroger des métriques par rapprochement

Les objets RootSync et RepoSync sont instrumentés avec des métriques de haut niveau qui vous donnent des informations précieuses sur le fonctionnement de Config Sync sur le cluster. La quasi-totalité des métriques sont marquées par le nom du rapprochement. Vous pouvez donc voir si des erreurs se sont produites et configurer des alertes pour Cloud Monitoring.

Un rapprochement est un pod qui est déployé en tant que déploiement. Il synchronise les fichiers manifestes d'un dépôt Git avec un cluster. Lorsque vous créez un objet RootSync, Config Sync crée un rapprochement appelé root-reconciler-ROOT_SYNC_NAME ou root-reconciler si le nom de RootSync est root-sync. Lorsque vous créez un objet RepoSync, Config Sync crée un rapprochement appelé ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH ou ns-reconciler-NAMESPACE si le nom de RepoSync est repo-sync, où NAMESPACE est l'espace de noms dans lequel vous avez créé votre objet RepoSync.

Le schéma suivant montre comment fonctionnent les pods de rapprochement :

Flux de rapprochement

Par exemple, pour filtrer par nom de rapprochement lorsque vous utilisez Cloud Monitoring, effectuez les tâches suivantes :

  1. Dans Google Cloud Console, accédez à Monitoring.

    Accéder à Monitoring

  2. Dans le volet de navigation Surveillance, cliquez sur Explorateur de métriques.

  3. Dans la liste déroulante Sélectionner une métrique, ajoutez : custom.googleapis.com/opencensus/config_sync/reconciler_errors.

  4. Dans la liste déroulante Filtre, sélectionnez reconciler. Une zone de filtre s'affiche.

  5. Dans le champ de filtre, sélectionnez = dans le premier champ et le nom du rapprochement (par exemple, root-reconciler) dans le second.

  6. Cliquez sur Appliquer.

Vous pouvez maintenant voir les métriques de vos objets RootSync.

Pour en savoir plus sur le filtrage par type de données, consultez la section Filtrer les données.

Interroger les opérations Config Sync par composant et état

Lorsque vous avez activé les API RootSync et RepoSync, l'importation et l'approvisionnement à partir d'un dépôt Git, ainsi que la synchronisation avec un cluster, sont gérées par les rapprochements. La métrique reconciler_errors est libellée par composant, ce qui vous permet de savoir où se sont produites les erreurs.

Par exemple, pour filtrer par composant lorsque vous utilisez Cloud Monitoring, effectuez les tâches suivantes :

  1. Dans Google Cloud Console, accédez à Monitoring :

    Accéder à Monitoring

  2. Dans le volet de navigation Surveillance, cliquez sur Explorateur de métriques.

  3. Dans le menu déroulant Sélectionner une métrique, ajoutez custom.googleapis.com/opencensus/config_sync/reconciler_errors.

  4. Dans la liste déroulante Filtre, sélectionnez composant. Une zone de filtre s'affiche.

  5. Dans la zone des champs de filtre, sélectionnez = dans la première case et source dans la seconde.

  6. Cliquez sur Appliquer.

Vous pouvez désormais voir les erreurs qui se sont produites lorsque vous approvisionnez un compte Git à partir d'un dépôt Git.

Vous pouvez également vérifier les métriques des processus source et de synchronisation en interrogeant les métriques suivantes et en filtrant par le tag status :

custom.googleapis.com/opencensus/config_sync/parser_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

Configurer un exportateur OpenTelemetry personnalisé

Si vous souhaitez envoyer vos métriques à un autre système de surveillance, vous pouvez modifier la configuration d'OpenTelemetry. Pour obtenir la liste des systèmes de surveillance compatibles, consultez les pages relatives aux exportateurs OpenTelemetry Collector et aux exportateurs OpenTelemetry Collector-Contrib.

Les ressources de surveillance OpenTelemetry sont gérées dans un espace de noms config-management-monitoring distinct. Pour configurer un exportateur OpenTelemetry personnalisé à utiliser avec Config Sync, vous devez créer un fichier ConfigMap nommé otel-collector-custom dans cet espace de noms config-management-monitoring. Le fichier ConfigMap doit contenir une clé otel-collector-config.yaml et sa valeur doit correspondre au contenu du fichier de configuration personnalisée d'OpenTelemetry. Pour en savoir plus sur les options de configuration, consultez la documentation sur la configuration d'OpenTelemetry Collector.

Le fichier ConfigMap suivant est un exemple de ConfigMap avec un exportateur de journalisation personnalisé :

# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-custom
  namespace: config-management-monitoring
  labels:
    app: opentelemetry
    component: otel-collector
data:
  otel-collector-config.yaml: |
    receivers:
      opencensus:
    exporters:
      logging:
        logLevel: debug
    processors:
      batch:
    extensions:
      health_check:
    service:
      extensions: [health_check]
      pipelines:
        metrics:
          receivers: [opencensus]
          processors: [batch]
          exporters: [logging]

Toutes les configurations personnalisées doivent définir un récepteur opencensus et un pipeline metrics. Les autres champs sont facultatifs et configurables, mais nous vous recommandons d'inclure un processeur batch et une extension de vérification d'état, comme dans l'exemple.

Après avoir créé le ConfigMap, utilisez kubectl pour créer la ressource :

kubectl apply -f otel-collector-custom-cm.yaml

Le déploiement de l'OpenTelemetry Collector récupère ce ConfigMap et redémarre automatiquement pour appliquer la configuration personnalisée.

Surveiller les ressources avec Prometheus

Config Sync utilise Prometheus pour collecter et afficher des métriques liées à ses processus.

Vous pouvez également configurer Cloud Monitoring pour extraire des métriques personnalisées de Prometheus. Ces métriques peuvent ensuite être affichées dans Prometheus et Monitoring. Pour en savoir plus, consultez la page Utiliser Prometheus.

Scraper les métriques

Toutes les métriques Prometheus peuvent être scrapées (c'est-à-dire récupérées) sur le port 8675. Pour pouvoir scraper des métriques, vous devez configurer votre cluster pour Prometheus L'une des options ci-dessous :

  • Reportez-vous à la documentation Prometheus pour configurer votre cluster en vue du scrape ou

  • Utilisez l'opérateur Prometheus avec les fichiers manifestes ci-dessous de façon à récupérer l'ensemble des métriques Anthos Config Management toutes les 10 secondes.

    1. Créez un répertoire temporaire pour y placer les fichiers manifestes.

      mkdir acm-monitor
      cd acm-monitor
      
    2. Téléchargez le manifeste de l'opérateur Prometheus à partir du dépôt CoreOS, à l'aide de la commande curl :

      curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
      

      Ce fichier manifeste est configuré pour utiliser l'espace de noms default, ce qui n'est pas recommandé. L'étape suivante modifie la configuration pour utiliser un espace de noms appelé monitoring. Pour utiliser un autre espace de noms, remplacez-le par monitoring dans les étapes restantes.

    3. Créez un fichier pour mettre à jour l'objet Namespace de la ressource ClusterRoleBinding dans le package ci-dessus.

      # patch-crb.yaml
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: prometheus-operator
      subjects:
      - kind: ServiceAccount
        name: prometheus-operator
        namespace: monitoring # we are patching from default namespace
      
    4. Créez un fichier kustomization.yaml qui applique le correctif et modifie l'objet Namespace pour les autres ressources du fichier manifeste.

      # kustomization.yaml
      resources:
      - bundle.yaml
      
      namespace: monitoring
      
      patchesStrategicMerge:
      - patch-crb.yaml
      
    5. Créez l'espace de noms monitoring s'il n'en existe pas. Vous pouvez utiliser un nom différent pour l'espace de noms, mais vous devrez modifier la valeur de namespace dans les fichiers manifestes YAML des étapes précédentes.

      kubectl create namespace monitoring
      
    6. Appliquez le fichier manifeste Kustomize à l'aide des commandes suivantes :

      kubectl apply -k .
      
      until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \
      do date; sleep 1; echo ""; done

      La deuxième commande bloque jusqu'à ce que les CRD soient disponibles sur le cluster.

    7. Créez le fichier manifeste pour les ressources nécessaires à la configuration d'un serveur Prometheus qui récupère les métriques d'Anthos Config Management.

      # acm.yaml
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRole
      metadata:
        name: prometheus-acm
      rules:
      - apiGroups: [""]
        resources:
        - nodes
        - services
        - endpoints
        - pods
        verbs: ["get", "list", "watch"]
      - apiGroups: [""]
        resources:
        - configmaps
        verbs: ["get"]
      - nonResourceURLs: ["/metrics"]
        verbs: ["get"]
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      kind: ClusterRoleBinding
      metadata:
        name: prometheus-acm
      roleRef:
        apiGroup: rbac.authorization.k8s.io
        kind: ClusterRole
        name: prometheus-acm
      subjects:
      - kind: ServiceAccount
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: Prometheus
      metadata:
        name: acm
        namespace: monitoring
        labels:
          prometheus: acm
      spec:
        replicas: 2
        serviceAccountName: prometheus-acm
        serviceMonitorSelector:
          matchLabels:
            prometheus: config-management
        podMonitorSelector:
          matchLabels:
            prometheus: config-management
        alerting:
          alertmanagers:
          - namespace: default
            name: alertmanager
            port: web
        resources:
          requests:
            memory: 400Mi
      ---
      apiVersion: v1
      kind: Service
      metadata:
        name: prometheus-acm
        namespace: monitoring
        labels:
          prometheus: acm
      spec:
        type: NodePort
        ports:
        - name: web
          nodePort: 31900
          port: 9190
          protocol: TCP
          targetPort: web
        selector:
          app: prometheus
          prometheus: acm
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        name: acm-service
        namespace: monitoring
        labels:
          prometheus: config-management
      spec:
        selector:
          matchLabels:
            monitored: "true"
        namespaceSelector:
          matchNames:
          # If you are using RootSync and RepoSync APIs, change
          # config-management-system to config-management-monitoring
          - config-management-system
        endpoints:
        - port: metrics
          interval: 10s
      ---
      
    8. Appliquez le fichier manifeste à l'aide des commandes suivantes :

      kubectl apply -f acm.yaml
      
      until kubectl rollout status statefulset/prometheus-acm -n monitoring; \
      do sleep 1; done
      

      La deuxième commande bloque jusqu'à ce que les pods soient en cours d'exécution.

    9. Vous pouvez vérifier l'installation en transférant le port Web du serveur Prometheus sur votre ordinateur local.

      kubectl -n monitoring port-forward svc/prometheus-acm 9190
      

      Vous pouvez désormais accéder à l'interface utilisateur Web de Prometheus à l'adresse http://localhost:9190.

    10. Supprimez le répertoire temporaire.

      cd ..
      rm -rf acm-monitor
      

Métriques Prometheus disponibles

Config Sync collecte les métriques ci-dessous et les met à la disposition de Prometheus. La colonne Libellés répertorie tous les libellés applicables à chaque métrique. Les métriques sans libellés représentent une seule mesure dans le temps tandis que les métriques avec libellés représentent plusieurs mesures, une pour chaque combinaison de valeurs de libellé.

Si cette table n'est plus synchronisée, vous pouvez filtrer les métriques par préfixe dans l'interface utilisateur de Prometheus. Toutes les métriques commencent par le préfixe gkeconfig_.

Nom Type Étiquettes Description
gkeconfig_importer_cycle_duration_seconds_bucket Histogramme état Nombre de cycles que l'outil d'importation a tenté d'exécuter afin d'importer des configurations dans le cluster (répartis en buckets par durée de chaque cycle)
gkeconfig_importer_cycle_duration_seconds_count Histogramme état Nombre de cycles que l'outil d'importation a tenté d'exécuter afin d'importer des configurations dans le cluster (en ignorant la durée)
gkeconfig_importer_cycle_duration_seconds_sum Histogramme état Somme des durées de tous les cycles que l'outil d'importation a tenté d'exécuter afin d'importer des configurations dans le cluster
gkeconfig_importer_namespace_configs Jauge Nombre de configurations d'espace de noms dans l'état actuel
gkeconfig_monitor_errors Jauge composant Nombre d'erreurs dans le dépôt de configuration regroupées selon le composant où elles se sont produites
gkeconfig_monitor_configs Jauge état Nombre de configurations (cluster et espace de noms) regroupées par leur état de synchronisation
gkeconfig_monitor_last_import_timestamp Jauge Horodatage de la dernière importation
gkeconfig_monitor_last_sync_timestamp Jauge Horodatage de la dernière synchronisation
gkeconfig_monitor_sync_latency_seconds_bucket Histogramme Nombre de mesures d'importation pour synchronisation relevées (réparties en buckets en fonction de la latence entre les deux)
gkeconfig_monitor_sync_latency_seconds_count Histogramme Nombre de mesures d'importation pour synchronisation relevées (en ignorant la latence entre les deux)
gkeconfig_monitor_sync_latency_seconds_sum Histogramme Somme des latences de toutes les mesures d'importation pour synchronisation relevées
gkeconfig_syncer_api_duration_seconds_bucket Histogramme opération, type, état Nombre d'appels effectués par le synchroniseur au serveur d'API (répartis en buckets par durée de chaque appel)
gkeconfig_syncer_api_duration_seconds_count Histogramme opération, type, état Nombre d'appels effectués par l'outil d'importation au serveur d'API (en ignorant la durée)
gkeconfig_syncer_api_duration_seconds_sum Histogramme opération, type, état Somme des durées de tous les appels effectués par le synchroniseur au serveur d'API
gkeconfig_syncer_controller_restarts_total Nombre source Nombre total de redémarrages pour les contrôleurs de configuration d'espace de noms et de cluster
gkeconfig_syncer_operations_total Nombre opération, type, état Nombre total d'opérations effectuées pour synchroniser les ressources avec les configurations
gkeconfig_syncer_reconcile_duration_seconds_bucket Histogramme type, état Nombre d'événements de rapprochement traités par le synchroniseur (répartis en buckets par durée)
gkeconfig_syncer_reconcile_duration_seconds_count Histogramme type, état Nombre d'événements de rapprochement traités par le synchroniseur (en ignorant la durée)
gkeconfig_syncer_reconcile_duration_seconds_sum Histogramme type, état Somme des durées de tous les événements de rapprochement traités par le synchroniseur
gkeconfig_syncer_reconcile_event_timestamps Jauge type Horodatages lorsque les événements de rapprochement du synchroniseur se sont produits

Exemples de procédures de débogage pour Prometheus

Les exemples suivants illustrent certains modèles d'utilisation des métriques Prometheus, des champs d'état d'objet et des annotations d'objets pour détecter et diagnostiquer les problèmes liés à Config Sync. Ces exemples montrent comment commencer avec une surveillance de haut niveau qui détecte un problème, puis comment affiner progressivement votre recherche pour en identifier et diagnostiquer la cause.

Interroger des configurations par état

Le processus monitor fournit des métriques de haut niveau qui donnent des indications précieuses sur une vue d'ensemble du fonctionnement de Config Sync sur le cluster. Vous pouvez voir si des erreurs se sont produites et même configurer des alertes pour ces erreurs.

gkeconfig_monitor_errors

Interroger des métriques par rapprochement

Si vous utilisez les API Config Sync RootSync et RepoSync, vous pouvez surveiller les objets RootSync et RepoSync. Les objets RootSync et RepoSync sont instrumentés avec des métriques de haut niveau qui vous donnent des informations précieuses sur le fonctionnement de Config Sync sur le cluster. La quasi-totalité des métriques sont marquées par le nom du rapprochement. Vous pouvez donc voir si des erreurs se sont produites et configurer des alertes pour Prometheus.

Un rapprochement est un pod qui synchronise les fichiers manifestes d'un dépôt Git avec un cluster. Lorsque vous créez un objet RootSync, Config Sync crée un rapprochement nommé root-reconciler. Lorsque vous créez un objet RepoSync, Config Sync crée un rapprochement appelé ns-reconciler-NAMESPACE, où NAMESPACE est l'espace de noms dans lequel vous avez créé votre objet RepoSync.

Dans Prometheus, vous pouvez utiliser les filtres suivants pour les rapprochements :

# Querying Root reconciler
config_sync_reconciler_errors{root_reconciler="root-reconciler"}

# Querying Namespace reconciler for a namespace called retail
config_sync_reconciler_errors{ns_reconciler_retail="ns-reconciler-retail"}

Utiliser nomos status pour afficher les erreurs

En plus d'utiliser les métriques Prometheus pour surveiller l'état de Config Sync sur vos clusters, vous pouvez utiliser la commande nomos status qui affiche les erreurs de tous vos clusters sur la ligne de commande.

Interroger des opérations d'importation et de synchronisation par état

Config Sync utilise un processus en deux étapes pour appliquer les configurations du dépôt à un cluster. La métrique gkeconfig_monitor_errors est libellée par composant, ce qui vous permet de savoir où se sont produites les erreurs.

gkeconfig_monitor_errors{component="importer"}
gkeconfig_monitor_errors{component="syncer"}

Vous pouvez également vérifier les métriques des processus d'importation et de synchronisation eux-mêmes.

gkeconfig_importer_cycle_duration_seconds_count{status="error"}
gkeconfig_syncer_reconcile_duration_seconds_count{status="error"}

Lorsque vous avez activé les API RootSync et RepoSync, l'importation et l'approvisionnement à partir d'un dépôt Git, ainsi que la synchronisation avec un cluster, sont gérées par les rapprochements. La métrique reconciler_errors est libellée par composant, ce qui vous permet de savoir où se sont produites les erreurs.

Dans Prometheus, vous pouvez utiliser les requêtes suivantes :

# Check for errors that occurred when sourcing configs from the Git repository.
config_sync_reconciler_errors{component="source"}

# Check for errors that occurred when syncing configs to the cluster.
config_sync_reconciler_errors{component="sync"}

Vous pouvez également vérifier les métriques des processus source et de synchronisation :

config_sync_parse_duration_seconds{status="error"}
config_sync_apply_duration_seconds{status="error"}
config_sync_remediate_duration_seconds{status="error"}

Vérifier l'état d'un objet de configuration

Config Sync définit deux objets Kubernetes personnalisés : ClusterConfig et NamespaceConfig. Ces objets définissent un champ d'état contenant des informations sur la dernière modification appliquée à la configuration et sur les erreurs qui se sont produites. Par exemple, si une erreur se produit dans un espace de noms appelé shipping-dev, vous pouvez vérifier l'état du NamespaceConfig correspondant.

kubectl get namespaceconfig shipping-dev -o yaml

Vérifier l'annotation token d'un objet

Vous pouvez savoir quand un objet Kubernetes géré a été mis à jour pour la dernière fois par Config Sync. Chaque objet géré est annoté avec le hachage du commit Git lors de sa dernière modification, ainsi qu'avec le chemin d'accès à la configuration contenant la modification.

kubectl get clusterrolebinding namespace-readers
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    configmanagement.gke.io/source-path: cluster/namespace-reader-clusterrolebinding.yaml
    configmanagement.gke.io/token: bbb6a1e2f3db692b17201da028daff0d38797771
  name: namespace-readers
...

Pour en savoir plus, consultez la section Libellés et annotations.

Étapes suivantes