Cette page explique comment utiliser les indicateurs de niveau de service (SLI) 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 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 à ce qui est attendu, il est possible que Config Sync ne soit pas en cours d'exécution. 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 configurez vos alertes, nous vous recommandons de définir l'intervalle de temps sur au moins cinq minutes pour éviter les alertes inutiles. Par exemple, lors d'une mise à niveau, le nombre de conteneurs d'un pod peut être inférieur à la cible.
Si vous ne connaissez pas le nombre de conteneurs attendu, consultez Déploiements, pods et conteneurs Config Sync.
Exemples de règles d'alerte Prometheus
Cette section inclut des exemples de notifications qui vous avertissent lorsque le nombre de conteneurs d'un pod est 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 des espaces 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 gestionnaire de rapprochement 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, cela signifie qu'il y a un problème. Par exemple, un conteneur de réconciliateur racine qui ne dispose pas de suffisamment de ressources de mémoire redémarrera avec l'erreur OOMKilled
jusqu'à ce qu'il obtienne 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, cela signifie qu'un problème est survenu. Lorsque Config Sync rencontre des erreurs, il continue de réessayer de synchroniser les configurations de la source vers un cluster jusqu'à ce qu'il y parvienne. Toutefois, certaines erreurs ne peuvent pas être corrigées en relançant la requête et nécessitent votre intervention.
Exemple de règle d'alerte Prometheus
Pour recevoir une notification lorsqu'un rapprochement racine ou de l'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 :
- Le libellé
configsync_sync_kind
peut avoir les valeurs suivantes :RootSync
ouRepoSync
. - 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
et9xxx
. Chaque libellé correspond à un type d'erreur différent :- Erreurs
1xxx
: erreurs de configuration que vous pouvez corriger - Erreurs
2xxx
: erreurs côté serveur que vous ne pourrez peut-être pas corriger - Erreurs
9xxx
: erreurs internes que vous ne pouvez pas corriger
- Erreurs
Config Sync 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 sur le cluster peut prendre plus d'une heure. Toutefois, si deux heures se sont écoulées depuis la dernière synchronisation réussie, il se peut qu'un problème soit survenu.
Vous pouvez vérifier si la tentative de synchronisation en cours est toujours en cours en vérifiant l'état de RootSync ou de RepoSync. Si la tentative de synchronisation en cours est toujours en cours, vous pouvez choisir de diviser votre source fiable afin que toutes les sources fiables puissent être synchronisées plus rapidement, ou augmenter le seuil d'alerte de deux heures à une durée plus longue. Si aucune tentative de synchronisation n'est en cours, le rapprochement Config Sync est défectueux, car il est censé continuer à réessayer jusqu'à ce qu'il synchronise correctement les configurations de la source vers le cluster. Si cela se produit, escaladez le problème à l'assistanceGoogle Cloud .
Exemple de règle d'alerte Prometheus
Pour recevoir une notification lorsque la dernière synchronisation réussie d'un rapprochement racine ou de l'espace de noms remonte à plus de deux heures, créez une règle d'alerte :
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
Config Sync rencontre des régressions de performances
Il est possible que Config Sync rencontre des régressions de performances après sa mise à niveau. Les régressions de performances peuvent se produire de différentes manières :
- Une augmentation du temps nécessaire au rapprochement d'un objet RootSync ou RepoSync
- Une augmentation du temps nécessaire au rapprochement d'un objet ResourceGroup
- Une augmentation du temps nécessaire à la synchronisation des configurations de la source vers un cluster
Temps nécessaire au 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 les 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
présente des régressions de performances.
Les exemples suivants vous envoient une notification lorsque le 90e centile du temps nécessaire au rapprochement d'un objet RootSync ou RepoSync au cours des cinq dernières heures dépasse 0,1 seconde pendant 10 minutes. Vous pouvez créer des règles d'alerte qui surveillent tous les clusters ou un seul.
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
Temps nécessaire au rapprochement d'un objet ResourceGroup
Le déploiement resource-group-controller-manager
rapproche les objets ResourceGroup. Vous pouvez utiliser le 90e centile du temps de traitement de la réconciliation d'un ResourceGroup pour détecter 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 90e centile du temps nécessaire au rapprochement d'un objet ResourceGroup au cours des cinq dernières heures dépasse cinq secondes pendant 10 minutes. Vous pouvez créer des règles d'alerte qui surveillent tous les clusters ou un seul.
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
Temps nécessaire à la synchronisation des configurations de la source vers un cluster
Un rapprochement racine ou d'espace de noms synchronise les configurations de la source de vérité avec un cluster. Vous pouvez utiliser le 90e centile du temps de latence de la 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 des règles d'alerte Prometheus qui vous avertissent lorsque le déploiement du rapprochement racine ou de l'espace de noms présente des régressions de performances.
Les exemples suivants vous envoient une notification lorsque le 90e centile du temps supplémentaire de synchronisation des configurations sur tous les clusters au cours des cinq dernières heures dépasse une heure pendant cinq minutes.Vous pouvez créer des règles d'alerte qui surveillent tous les clusters ou un seul.
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