Utiliser des SLI Config Sync

Cette page explique comment utiliser les indicateurs de niveau de service (SLI) de Config Sync.

Pour recevoir des notifications lorsque Config Sync ne fonctionne pas comme prévu, configurez des règles d'alerte Prometheus basées sur ces SLI. Chaque SLI inclut un exemple de création d'une règle d'alerte. Pour en savoir plus sur l'utilisation de Prometheus avec Config Sync, consultez la page Surveiller Config Sync avec des métriques.

Pods Config Sync avec un nombre de conteneurs incorrect

Si le nombre de conteneurs d'un pod Config Sync est inférieur à celui attendu, il se peut que Config Sync ne s'exécute pas. Vous pouvez configurer une alerte pour détecter ce problème et inspecter le pod Config Sync pour déterminer pourquoi certains conteneurs sont manquants. Lorsque vous définissez vos alertes, nous vous recommandons de définir un intervalle de temps d'au moins cinq minutes pour éviter les alertes inutiles. Par exemple, lors d'une mise à niveau, le nombre de conteneurs d'un pod peut descendre en dessous de la cible.

Pour vous aider à comprendre le nombre de conteneurs attendu, le tableau suivant répertorie les détails des pods Config Sync et le nombre de conteneurs attendu:

Espace de noms du pod Expression régulière dans le nom du pod Description du pod Nombre de conteneurs attendu Noms des conteneurs
config-management-system config-management-operator-.* Un pod config-management-operator s'exécute sur chaque cluster sur lequel Anthos Config Management est installé et coordonne les objets ConfigManagement. 1
  • manager
    		•
    config-management-system reconciler-manager-.* Un pod reconciler-manager s'exécute sur chaque cluster sur lequel Anthos Config Management est installé et coordonne les objets RootSync et RepoSync. 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system root-reconciler-.* Un pod de rapprochement racine est créé pour chaque objet RootSync. 4 ou 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-system ns-reconciler-.* Un pod de rapprochement d'espace de noms est créé pour chaque objet RepoSync. 4 ou 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-monitoring otel-collector-.* Un pod otel-collector s'exécute sur chaque cluster sur lequel Anthos Config Management est installé, collecte les métriques des composants Config Sync s'exécutant sous les espaces de noms config-management-system et resource-group-system, puis les exporte vers Prometheus et Cloud Monitoring. 1
  • otel-collector
    		•
    resource-group-system resource-group-controller-manager-.* Un pod resource-group-controller-manager s'exécute sur chaque cluster sur lequel Anthos Config Management est installé et coordonne les objets ResourceGroup. Un objet ResourceGroup est créé pour chaque objet RootSync ou RepoSync, et suit l'état de rapprochement des ressources déclarées dans la source fiable. 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system admission-webhook-.* Un pod admission-wehbook s'exécute sur chaque cluster sur lequel Anthos Config Management est installé, et empêche les autres contrôleurs de modifier ou de supprimer les ressources gérées par Config Sync. Le webhook d'admission Config Sync est désactivé par défaut. 1
  • admission-webhook
    		•

    1 Dans la plupart des cas, lorsque spec.sourceType d'un objet RootSync ou RepoSync est git et que spec.git.auth est gcenode ou gcpserviceaccount, le nombre de conteneurs est 5. Sinon, le nombre de conteneurs est de 4. Toutefois, si votre cluster comporte des webhooks en mutation (par exemple, vous avez installé Anthos Service Mesh) qui injectent des conteneurs side-car aux pods, le webhook augmente le nombre total de conteneurs dans le pod de rapprochement. Vous devez ajuster le nombre indiqué ici.

    2 L'élément gcenode-askpass-sidecar n'est installé que lorsque spec.git.auth est défini sur gcenode ou gcpserviceaccount.

    Exemples de règles d'alerte Prometheus

    Cette section contient des exemples qui vous informent lorsqu'il y a des pods avec un nombre de conteneurs incorrect.

    • Pour recevoir une notification lorsque le nombre de conteneurs d'un pod de rapprochement racine est inférieur au nombre attendu, créez la règle d'alerte suivante:

      alert: RootReconcilerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"root-reconciler-.*"}) < 4
# Setting the for field to 5m to avoid unnecessary alerts.
for: 5m

    • Pour recevoir une notification lorsque le nombre de conteneurs d'un pod de rapprochement d'espace de noms est inférieur au nombre attendu, créez la règle d'alerte suivante:

      alert: NamespaceReconcilerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"ns-reconciler-.*"}) < 4
for: 5m

    • Pour recevoir une notification lorsque le nombre de conteneurs d'un pod de rapprochement-manager est inférieur au nombre attendu, créez la règle d'alerte suivante:

      alert: ReconcilerManagerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"reconciler-manager-.*"}) < 2
for: 5m

    Conteneurs Config Sync non opérationnels

    Si le nombre de redémarrages d'un conteneur Config Sync atteint un certain seuil, il y a un problème. Par exemple, un conteneur de rapprochement racine qui ne dispose pas de suffisamment de ressources de mémoire redémarre avec l'erreur OOMKilled jusqu'à ce qu'il ait suffisamment de mémoire.

    Exemple de règle d'alerte Prometheus

    Pour recevoir une notification lorsqu'un conteneur Config Sync a redémarré plus de trois fois, créez la règle d'alerte suivante:

    alert: TooManyContainerRestarts
expr: kubernetes_io:container_restart_count{namespace_name=~"config-management-system|config-management-monitoring|resource-group-system"} > 3

    Config Sync rencontre des erreurs persistantes

    Si Config Sync rencontre des erreurs persistantes, un problème est survenu. Lorsque Config Sync rencontre des erreurs, il tente à nouveau de synchroniser les configurations de la source avec un cluster jusqu'à ce que l'opération aboutisse. Cependant, certaines erreurs ne peuvent pas être corrigées après une nouvelle tentative et nécessitent votre intervention.

    Exemple de règle d'alerte Prometheus

    Pour recevoir une notification lorsqu'un rapprochement racine ou d'espace de noms rencontre des erreurs persistantes pendant deux heures, créez la règle d'alerte suivante:

    alert: PersistentConfigSyncErrors
expr: sum by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace, errorclass) (config_sync_reconciler_errors) > 0
for: 2h

    Dans cet exemple :

    • L'étiquette configsync_sync_kind peut avoir les valeurs suivantes : RootSync ou RepoSync.
    • Le libellé configsync_sync_name indique le nom d'un objet RootSync ou RepoSync.
    • Le libellé configsync_sync_namespace indique l'espace de noms d'un objet RootSync ou RepoSync.

    • Le libellé errorclass peut avoir trois valeurs: 1xxx, 2xxx et 9xxx. Chaque libellé correspond à un type d'erreur différent:

      • 1xxx erreurs de configuration que vous pouvez corriger
      • Erreurs 2xxx: erreurs côté serveur que vous ne pourrez peut-être pas corriger
      • 9xxx erreurs internes que vous ne pouvez pas corriger

      Le libellé errorclass est compatible avec Anthos Config Management version 1.14.0 et ultérieure.

    Config Sync reste bloqué à l'étape de synchronisation

    Une tentative de synchronisation dans Config Sync ne peut pas être interrompue. Si les configurations de la source sont trop volumineuses ou complexes (par exemple, votre source contient un grand nombre de ressources Config Connector), la synchronisation de ces configurations au cluster peut prendre plus d'une heure. Toutefois, si deux heures se sont écoulées depuis la dernière synchronisation, il peut y avoir un problème.

    Vous pouvez vérifier si la tentative de synchronisation actuelle est toujours en cours en vérifiant l'état de RootSync ou RepoSync. Si la tentative de synchronisation actuelle est toujours en cours, vous pouvez choisir de séparer vos dépôts pour qu'ils puissent être synchronisés plus rapidement, ou d'augmenter le seuil d'alerte de deux heures à plus. Si aucune tentative de synchronisation n'est en cours, le rapprochement de Config Sync est interrompu, car il doit effectuer de nouvelles tentatives jusqu'à ce qu'il synchronise les configurations de la source avec le cluster. Dans ce cas, signalez le problème à l'assistance Google Cloud.

    Exemple de règle d'alerte Prometheus

    Pour être informé lorsque la dernière synchronisation réussie d'un rapprochement racine ou d'un espace de noms a eu lieu il y a plus de deux heures, créez l'une des règles d'alerte suivantes.

    • Si vous utilisez Anthos Config Management version 1.14.0 ou ultérieure, créez la règle d'alerte suivante:

      alert: OldLastSyncTimestamp
# The status label indicates whether the last sync succeeded or not.
# Possible values: success, error.
expr: time() - topk by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace) (1, config_sync_last_sync_timestamp{status="success"}) > 7200

    • Si vous utilisez une version antérieure à 1.14.0, utilisez plutôt la règle suivante:

      alert: OldLastSyncTimestamp
expr: time() - topk by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace) (1, config_sync_last_sync_timestamp{status="success", status!="NONE"}) > 7200

      Vous devez créer une règle différente, car dans les versions d'Anthos Config Management antérieures à la version 1.14.0, le libellé commit de la métrique config_sync_last_sync_timestamp peut être défini sur NONE pour certaines séries temporelles.

    Config Sync connaît des régressions de performances

    Après la mise à niveau, Config Sync peut présenter des régressions de performances. Les régressions de performances peuvent se produire de différentes manières:

    • Augmentation du temps nécessaire au rapprochement d'un objet RootSync ou RepoSync
    • Augmentation du temps nécessaire au rapprochement d'un objet ResourceGroup
    • Augmentation du temps de synchronisation des configurations de la source vers un cluster

    Durée du rapprochement d'un objet RootSync ou RepoSync

    Le déploiement reconciler-manager rapproche les objets RootSync et RepoSync. Vous pouvez utiliser le 90e centile du temps nécessaire au rapprochement d'un objet RootSync ou RepoSync pour détecter des régressions de performances.

    Exemples de règles d'alerte Prometheus

    Cette section inclut des exemples de règles d'alerte Prometheus qui vous avertissent lorsque le déploiement reconciler-manager comporte des régressions de performances.

    Les exemples suivants vous envoient une notification lorsque le quatre-vingt-dixième centile du temps de rapprochement d'un objet RootSync ou RepoSync au cours des 5 dernières heures est supérieur à 0,1 seconde pendant 10 minutes. Vous pouvez créer des règles d'alerte qui surveillent tous les clusters ou un seul cluster.

    • Créez la règle suivante pour surveiller tous les clusters:

      alert: HighLatencyReconcileRootSyncAndRepoSyncOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_reconcile_duration_seconds_bucket[5h]))) > 0.1
for: 10m

    • Créez la règle suivante pour surveiller un seul cluster:

      alert: HighLatencyReconcileRootSyncAndRepoSyncClusterLevel
expr: histogram_quantile(0.9, sum by (cluster, le) (rate(config_sync_reconcile_duration_seconds_bucket[5h]))) > 0.1
for: 10m

    Durée du rapprochement d'un objet ResourceGroup

    Le déploiement resource-group-controller-manager rapproche les objets ResourceGroup. Vous pouvez utiliser le 90e centile du temps nécessaire au rapprochement d'un ResourceGroup pour intercepter les régressions de performances.

    Exemples de règles d'alerte Prometheus

    Cette section inclut des règles d'alerte Prometheus qui vous avertissent lorsque le déploiement resource-group-controller-manager présente des régressions de performances.

    Les exemples suivants vous envoient une notification lorsque le quatre-vingt-dixième centile du temps de rapprochement d'un objet ResourceGroup au cours des cinq dernières heures est supérieur à cinq secondes pendant 10 minutes. Vous pouvez créer des règles d'alerte qui surveillent tous les clusters ou un seul cluster.

    • Créez la règle suivante pour surveiller tous les clusters:

      alert: HighLatencyReconcileResourceGroupOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_rg_reconcile_duration_seconds_bucket[5h]))) > 5
for: 10m

    • Créez la règle suivante pour surveiller un seul cluster:

      alert: HighLatencyReconcileResourceGroupClusterLevel
expr: histogram_quantile(0.9, sum by (cluster, le) (rate(config_sync_rg_reconcile_duration_seconds_bucket[5h]))) > 5
for: 10m

    Durée de synchronisation des configurations de la source vers un cluster

    Un rapprochement racine ou d'espace de noms synchronise les configurations de la source fiable avec un cluster. Vous pouvez utiliser le 90e centile de la durée de synchronisation des configurations de la source vers un cluster pour détecter les régressions de performances.

    Exemples de règles d'alerte Prometheus

    Cette section inclut les règles d'alerte Prometheus qui vous avertissent lorsque le déploiement du rapprochement de l'espace de noms ou de la racine est soumis à des régressions de performances.

    Les exemples suivants vous envoient une notification lorsque le quatre-vingt-dixième centile de la surcharge de synchronisation des configurations sur tous les clusters au cours des cinq dernières heures est supérieur à une heure pendant cinq minutes.Vous pouvez créer des règles d'alerte qui surveillent tous les clusters, ou un seul cluster.

    • Créez la règle suivante pour surveiller tous les clusters:

      alert: HighApplyDurationOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_apply_duration_seconds_bucket[5h]))) > 3600
for: 5m

    • Créez la règle suivante pour surveiller un seul cluster:

      alert: HighApplyDurationRootSyncRepoSyncLevel
expr: histogram_quantile(0.9, sum by (cluster, configsync_sync_kind,configsync_sync_name, configsync_sync_namespace, le) (rate(config_sync_apply_duration_seconds_bucket[5h]))) > 3600
for: 5m