Usar SLIs do Config Sync

Nesta página, descrevemos como usar os indicadores de nível de serviço (SLIs) do Config Sync.

Para receber notificações quando o Config Sync não estiver funcionando conforme o esperado, configure as regras de alerta do Prometheus com base nesses SLIs. Cada SLI inclui um exemplo de como criar uma regra de alerta. Para saber mais sobre como usar o Prometheus com o Config Sync, consulte Monitorar o Config Sync com métricas.

Pods do Config Sync com contagem incorreta de contêineres

Se a contagem do contêiner de um pod do Config Sync for menor que o esperado, talvez o Config Sync não esteja em execução. É possível configurar um alerta para detectar esse problema e inspecionar o pod do Config Sync para descobrir por que alguns contêineres estão ausentes. Para evitar alertas desnecessários, defina o intervalo de tempo para pelo menos cinco minutos. Por exemplo, durante o upgrade, a contagem de contêineres de um pod pode ficar abaixo do objetivo.

Para ajudar você a entender a contagem de contêineres esperada, a tabela a seguir lista detalhes sobre os pods do Config Sync e as contagens de contêineres esperadas:

Namespace do pod Regex do nome do pod Descrição do pod Contagem de contêineres esperada Nomes de contêiner
config-management-system config-management-operator-.* Um pod config-management-operator é executado em cada cluster com o Anthos Config Management instalado e reconcilia objetos ConfigManagement. 1
  • manager
    		•
    config-management-system reconciler-manager-.* Um pod reconciler-manager é executado em cada cluster com o Anthos Config Management instalado e reconcilia objetos RootSync e RepoSync. 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system root-reconciler-.* Um pod de reconciliação raiz é criado para cada objeto RootSync. 4 ou 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-system ns-reconciler-.* Um pod de reconciliação do namespace é criado para cada objeto RepoSync. 4 ou 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-monitoring otel-collector-.* Um pod otel-collector é executado em cada cluster com o Anthos Config Management instalado, coleta métricas dos componentes do Config Sync em execução nos namespaces config-management-system e resource-group-system e exporta essas métricas para o Prometheus e o Cloud Monitoring. 1
  • otel-collector
    		•
    resource-group-system resource-group-controller-manager-.* Um pod resource-group-controller-manager é executado em todos os clusters com o Anthos Config Management instalado e reconcilia objetos ResourceGroup. Um objeto ResourceGroup é criado para cada objeto RootSync ou RepoSync e rastreia os status de reconciliação dos recursos declarados na fonte da verdade. 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system admission-webhook-.* Um pod admission-wehbook é executado em cada cluster com o Anthos Config Management instalado e impede que outros controladores modifiquem ou excluam os recursos gerenciados pelo Config Sync. O webhook de admissão do Config Sync é desativado por padrão. 1
  • admission-webhook
    		•

    1 Na maioria dos casos, quando spec.sourceType de um objeto RootSync ou RepoSync é git e spec.git.auth é gcenode ou gcpserviceaccount, a contagem do contêiner é 5. Caso contrário, a contagem de contêineres será 4. No entanto, se o cluster tiver webhooks de modificação (por exemplo, você instalou o Anthos Service Mesh) que injetam contêineres de arquivo secundário em pods, o webhook aumentará o número total de contêineres no pod de reconciliação. Ajuste o número aqui de acordo.

    2 O gcenode-askpass-sidecar só é instalado quando spec.git.auth é gcenode ou gcpserviceaccount.

    Exemplos de regras de alerta do Prometheus

    Esta seção inclui exemplos que notificam você quando há pods com uma contagem de contêineres incorreta.

    • Para receber uma notificação quando a contagem de contêineres de um pod de reconciliação raiz estiver abaixo da contagem esperada, crie a seguinte regra de alerta:

      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

    • Para receber uma notificação quando a contagem de contêineres de um pod de reconciliação de namespace estiver abaixo da contagem esperada, crie a seguinte regra de alerta:

      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

    • Para receber uma notificação quando a contagem do contêiner de um pod de reconciliação-administrador estiver abaixo da contagem esperada, crie a seguinte regra de alerta:

      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

    Contêineres não íntegros do Config Sync

    Se a contagem de reinicializações de um contêiner do Config Sync atingir um determinado limite, isso significa que há algo errado. Por exemplo, um contêiner de reconciliação raiz que não tem recursos de memória suficientes será reiniciado com o erro OOMKilled até conseguir memória suficiente.

    Exemplo de regra de alerta do Prometheus

    Para receber uma notificação quando um contêiner do Config Sync for reiniciado mais de três vezes, crie a seguinte regra de alerta:

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

    O Config Sync está encontrando erros persistentes

    Se o Config Sync encontrar erros persistentes, isso significa que há algo errado. Quando o Config Sync encontra erros, ele continua tentando sincronizar as configurações da origem com um cluster até ser bem-sucedido. No entanto, alguns erros não podem ser corrigidos ao tentar novamente e exigem sua intervenção.

    Exemplo de regra de alerta do Prometheus

    Para receber uma notificação quando um reconciliador de raiz ou namespace encontrar erros persistentes por duas horas, crie a seguinte regra de alerta:

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

    Neste exemplo:

    • O identificador configsync_sync_kind pode ter os seguintes valores: RootSync ou RepoSync.
    • O identificador configsync_sync_name indica o nome de um objeto RootSync ou RepoSync.
    • O identificador configsync_sync_namespace indica o namespace de um objeto RootSync ou RepoSync.

    • O identificador errorclass pode ter três valores: 1xxx, 2xxx e 9xxx. Cada identificador corresponde a um tipo diferente de erro:

      • Erros de 1xxx: erros de configuração que podem ser corrigidos por você
      • 2xxx erro: erros do lado do servidor que você não consegue corrigir
      • 9xxx erro: erros internos que não podem ser corrigidos por você

      O identificador errorclass é compatível com o Anthos Config Management versão 1.14.0 e posterior.

    O Config Sync trava no estágio de sincronização

    Uma tentativa de sincronização no Config Sync é ininterrupta. Se as configurações na origem forem muito grandes ou complexas (por exemplo, se a origem tiver um número alto de recursos do Config Connector), pode levar mais de uma hora para terminar de sincronizar essas configurações com o cluster. No entanto, se já se passaram duas horas desde a última sincronização bem-sucedida, algo pode estar errado.

    Para verificar se a tentativa de sincronização atual ainda está em andamento, verifique o status de RootSync ou RepoSync. Se a tentativa de sincronização atual ainda estiver em andamento, você pode dividir os repositórios para que eles sejam sincronizados mais rapidamente ou aumentar o limite de alerta de duas horas para algo mais longo. Se não houver tentativa de sincronização em andamento, o reconciliador do Config Sync está corrompido porque precisa continuar tentando sincronizar as configurações da origem com o cluster. Se isso acontecer, encaminhe para o suporte do Google Cloud.

    Exemplo de regra de alerta do Prometheus

    Para receber uma notificação quando a última sincronização de um reconciliador de raiz ou namespace for mais de duas horas atrás, crie uma das seguintes regras de alerta.

    • Se você estiver usando a versão 1.14.0 ou posterior do Anthos Config Management, crie a seguinte regra de alerta:

      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

    • Se você estiver usando uma versão anterior à 1.14.0, use a seguinte regra:

      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

      É necessário criar uma regra diferente porque, nas versões do Anthos Config Management anteriores à 1.14.0, o identificador commit da métrica config_sync_last_sync_timestamp pode ser definido como NONE para algumas séries temporais.

    Config Sync com regressões de desempenho

    O Config Sync pode ter regressões de desempenho após o upgrade. As regressões de desempenho podem acontecer das seguintes maneiras:

    • um aumento na sobrecarga de tempo de reconciliação de um objeto RootSync ou RepoSync;
    • um aumento na sobrecarga de tempo de reconciliação de um objeto ResourceGroup;
    • um aumento na sobrecarga de tempo de sincronização de configurações da origem para um cluster;

    a sobrecarga de tempo de reconciliação de um objeto RootSync ou RepoSync.

    A implantação reconciler-manager reconcilia objetos RootSync e RepoSync. Use o percentil 99 da sobrecarga de tempo de reconciliação de um objeto RootSync ou RepoSync para detectar regressões de desempenho.

    Exemplos de regras de alerta do Prometheus

    Nesta seção, incluímos exemplos de regras de alerta do Prometheus que notificam você quando a implantação reconciler-manager tem regressões de desempenho.

    Os exemplos a seguir enviam uma notificação quando o percentil 99 da sobrecarga de tempo de reconciliação de um objeto RootSync ou RepoSync nas últimas 5 horas é maior que 0,1 segundo por 10 minutos. É possível criar regras de alerta que monitoram todos os clusters ou um único cluster.

    • Crie a regra a seguir para monitorar todos os clusters:

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

    • Crie a regra a seguir para monitorar um cluster:

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

    A sobrecarga de tempo de reconciliação de um objeto ResourceGroup

    A implantação resource-group-controller-manager reconcilia objetos ResourceGroup. É possível usar o percentil 99 da sobrecarga de tempo de reconciliação de um ResourceGroup para capturar regressões de desempenho.

    Exemplos de regras de alerta do Prometheus

    Esta seção inclui regras de alerta do Prometheus que notificam você quando a implantação resource-group-controller-manager tem regressões de desempenho.

    Os exemplos a seguir enviam uma notificação quando o percentil 99 da sobrecarga de tempo de reconciliação de um objeto ResourceGroup nas últimas 5 horas é maior que 5 segundos por 10 minutos. É possível criar regras de alerta que monitoram todos os clusters ou um único cluster.

    • Crie a regra a seguir para monitorar todos os clusters:

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

    • Crie a regra a seguir para monitorar um cluster:

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

    A sobrecarga de tempo de sincronização das configurações da origem para um cluster

    Um reconciliador de raiz ou namespace sincroniza as configurações da fonte da verdade com um cluster. Use o percentil 99 da sobrecarga de tempo de sincronização das configurações da origem com um cluster para detectar regressões de desempenho.

    Exemplos de regras de alerta do Prometheus

    Esta seção inclui regras de alerta do Prometheus que notificam você quando a implantação do reconciliador de raiz ou namespace tem regressões de desempenho.

    Os exemplos a seguir enviam uma notificação quando o percentil 99 da sobrecarga de tempo de sincronização das configurações em todos os clusters nas últimas cinco horas é superior a uma hora por cinco minutos. Você pode criar regras de alerta que monitoram todos os clusters ou um cluster.

    • Crie a regra a seguir para monitorar todos os clusters:

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

    • Crie a regra a seguir para monitorar um 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