Coletar e visualizar métricas do plano de controle

Esta página descreve como configurar um cluster do Google Kubernetes Engine (GKE) para enviar métricas emitidas pelo servidor da API Kubernetes, pelo programador e pelo gerenciador do controlador ao Cloud Monitoring usando o Google Cloud Managed Service para Prometheus. Esta página também descreve como essas métricas são formatadas quando são gravadas no Monitoring e como consultar métricas.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.

Requisitos

O envio de métricas emitidas por componentes do plano de controle do Kubernetes para o Cloud Monitoring tem os seguintes requisitos:

Configurar a coleta de métricas do plano de controle

É possível ativar as métricas do plano de controle em um cluster atual do GKE usando o console do Google Cloud, a gcloud CLI ou o Terraform.

Console

É possível ativar as métricas do plano de controle de um cluster na guia Observabilidade do cluster ou na guia Detalhes do cluster. Ao usar a guia Observabilidade, é possível visualizar os gráficos e métricas disponíveis antes de ativar o pacote de métricas.

Para ativar as métricas do plano de controle na guia Observabilidade do cluster, faça o seguinte:

  1. No Console do Google Cloud, acesse a página de clusters do Kubernetes:

    Acesse Clusters do Kubernetes

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Kubernetes Engine.

  2. Clique no nome do cluster e selecione a guia Observabilidade.

  3. Selecione Plano de controle na lista de recursos.

  4. Clique em Ativar pacote.

    Se as métricas do plano de controle já estiverem ativadas, você verá um conjunto de gráficos para as métricas do plano de controle.

Para ativar as métricas do plano de controle na guia Detalhes do cluster, faça o seguinte:

  1. No Console do Google Cloud, acesse a página de clusters do Kubernetes:

    Acesse Clusters do Kubernetes

    Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Kubernetes Engine.

  2. Clique no nome do cluster.

  3. Na linha Recursosdenominada Cloud Monitoring, clique no ícone Editar.

  4. Na caixa de diálogo Editar o Cloud Monitoring, confirme se Ativar o Cloud Monitoring está selecionado.

  5. No menu suspenso Componentes, selecione os componentes do plano de controle para a coleta de métricas: Servidor de API, Programador ou Gerenciador de controladores.

  6. Clique em OK.

  7. Clique em Salvar alterações.

gcloud

Atualize o cluster para coletar métricas emitidas pelo servidor da API Kubernetes, pelo programador e pelo gerenciador do controlador:

gcloud container clusters update CLUSTER_NAME \
    --location=COMPUTE_LOCATION \
    --monitoring=SYSTEM,API_SERVER,SCHEDULER,CONTROLLER_MANAGER

Substitua:

Terraform

Para configurar a coleta de métricas de plano de controle do Kubernetes usando o Terraform, consulte o bloco monitoring_config no registro do Terraform para google_container_cluster. Para informações gerais sobre como usar o Google Cloud com o Terraform, consulte Terraform com o Google Cloud.

Cota

As métricas do plano de controle consomem a cota "Solicitações de ingestão de séries temporais por minuto" da API Cloud Monitoring. Antes de ativar os pacotes de métricas, verifique o pico de uso recente dessa cota. Se você tiver muitos clusters no mesmo projeto ou já estiver perto do limite dessa cota, solicite um aumento no limite de cota antes de ativar qualquer pacote de observabilidade.

Preços

As métricas do plano de controle do GKE usam o Google Cloud Managed Service para Prometheus para carregar métricas no Cloud Monitoring. O Cloud Monitoring cobra pela ingestão dessas métricas com base no número de amostras ingeridas. No entanto, essas métricas são gratuitas para os clusters registrados que pertencem a um projeto com o GKE edição Enterprise ativado.

Para mais informações, consulte preços do Cloud Monitoring.

Formato da métrica

Todas as métricas do plano de controle do Kubernetes gravadas no Cloud Monitoring usam o tipo de recurso prometheus_target. Cada nome de métrica é prefixado com prometheus.googleapis.com/ e tem um sufixo indicando o tipo de métrica do Prometheus, como /gauge, /histogram ou /counter. Caso contrário, cada nome de métrica será idêntico ao nome da métrica exposto pelo Kubernetes de código aberto.

Como exportar do Cloud Monitoring

As métricas do plano de controle podem ser exportadas do Cloud Monitoring usando a API Cloud Monitoring. Como todas as métricas do plano de controle são ingeridas usando Google Cloud Managed Service para Prometheus, as métricas do plano de controle do Kubernetes podem ser consultadas usando o Prometheus Query Language (PromQL). Elas também podem ser consultadas usando a linguagem de consulta do Monitoring (MQL).

Métricas de consulta

Quando você consulta as métricas do plano de controle do Kubernetes, o nome usado depende do uso dos recursos baseados no PromQL ou Cloud Monitoring, como o MQL ou o Metrics Explorer interface de menu do Google Analytics.

As tabelas de métricas do plano de controle do Kubernetes a seguir mostram duas versões do nome de cada métrica:

  • Nome da métrica do PromQL: ao usar o PromQL em páginas do Cloud Monitoring do console do Google Cloud ou em campos do PromQL do API Cloud Monitoring, use o nome da métrica do PromQL.
  • Nome da métrica do Cloud Monitoring: ao usar outros recursos do Monitoring, use o nome de métrica do Cloud Monitoring nas tabelas abaixo. Esse nome precisa ser prefixado com prometheus.googleapis.com/, que foi omitido das entradas na tabela.

Métricas do servidor de API

Nesta seção, apresentamos uma lista das métricas do servidor de API e mais informações sobre como interpretar e usar as métricas.

Lista de métricas do servidor de API

Quando as métricas do servidor de API estão ativadas, todas as métricas mostradas na tabela a seguir são exportadas para o Cloud Monitoring no mesmo projeto que o cluster do GKE.

Os nomes das métricas do Cloud Monitoring nesta tabela precisam ser prefixados com prometheus.googleapis.com/. Esse prefixo foi omitido das entradas na tabela.

Nome da métrica do PromQL Estágio de lançamento
Nome da métrica do Cloud Monitoring
Tipo, Classe, Unidade
Recursos monitorados
Versão obrigatória do GKE		 Descrição
Rótulos
apiserver_current_inflight_requests GA
apiserver_current_inflight_requests/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número máximo de limites de solicitações em andamento atualmente do apiserver para cada tipo de solicitação no último segundo.

request_kind
apiserver_flowcontrol_current_executing_seats BETA
apiserver_flowcontrol_current_executing_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ 		Simultaneidade (número de licenças por usuário) ocupada pelas solicitações em execução no momento (estágio inicial para WATCH; caso contrário, qualquer estágio) no subsistema de prioridade e imparcialidade da API.

flow_schema
priority_level
apiserver_flowcontrol_current_inqueue_requests BETA
apiserver_flowcontrol_current_inqueue_requests/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Número de solicitações pendentes no momento nas filas do subsistema de prioridade e imparcialidade da API.

flow_schema
priority_level
apiserver_flowcontrol_nominal_limit_seats BETA
apiserver_flowcontrol_nominal_limit_seats/gauge
Gauge, Double, 1
prometheus_target
1.28.3+ (1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Número nominal de licenças de execução por usuário configuradas para cada nível de prioridade.

priority_level
apiserver_flowcontrol_rejected_requests_total BETA
apiserver_flowcontrol_rejected_requests_total/counter
Cumulative, Double, 1
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Número de solicitações rejeitadas pelo subsistema de prioridade e imparcialidade da API.

flow_schema
priority_level
reason
apiserver_flowcontrol_request_wait_duration_seconds BETA
apiserver_flowcontrol_request_wait_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.28.3+ (1.25.16-gke.1360000+, 1.26.11+, 1.27.8+ para versões secundárias anteriores) 		Tempo que uma solicitação ficou aguardando na fila.

execute
flow_schema
priority_level
apiserver_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Distribuição de latência da resposta em segundos para cada verbo, valor de simulação, grupo, versão, recurso, sub-recurso, escopo e componente.

component
dry_run
group
resource
scope
subresource
verb
version
apiserver_request_total GA
apiserver_request_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Contador de solicitações de apiserver dividido para cada verbo, valor de simulação, grupo, versão, recurso, escopo, componente e código de resposta HTTP.

code
component
dry_run
group
resource
scope
subresource
verb
version
apiserver_response_sizes GA
apiserver_response_sizes/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Distribuição do tamanho da resposta em bytes para cada grupo, versão, verbo, recurso, sub-recurso, escopo e componente.

component
group
resource
scope
subresource
verb
version
apiserver_storage_objects GA
apiserver_storage_objects/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número de objetos armazenados no momento da última verificação dividido por tipo.

resource
apiserver_admission_controller_admission_duration_seconds GA
apiserver_admission_controller_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.23.6+ 		Histograma de latência do controlador de admissão em segundos, identificado por nome e detalhado para cada operação e tipo e recurso da API (validar ou permitir).

name
operation
rejected
type
apiserver_admission_step_admission_duration_seconds GA
apiserver_admission_step_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histograma de latência da subetapa de entrada em segundos, detalhado para cada operação e tipo de etapa e recurso da API (validar ou permitir).

operation
rejected
type
apiserver_admission_webhook_admission_duration_seconds GA
apiserver_admission_webhook_admission_duration_seconds/histogram
Cumulative, Distribution, s
prometheus_target
1.22.13+ 		Histograma de latência do webhook de entrada em segundos, identificado por nome e detalhado para cada operação e tipo e recurso da API (validar ou permitir).

name
operation
rejected
type

As seções a seguir fornecem mais informações sobre as métricas do servidor da API.

apiserver_request_duration_seconds

Use essa métrica para monitorar a latência no servidor de API. A duração da solicitação registrada por essa métrica inclui todas as fases de processamento de solicitação, desde o momento em que a solicitação é recebida até o momento em que o servidor conclui a resposta ao cliente. Especificamente, ele inclui o tempo gasto no seguinte:

  • A autenticação e autorização da solicitação.
  • Chamar os webhooks de terceiros e do sistema associados à solicitação.
  • Buscar o objeto solicitado de um cache na memória (para solicitações que especificam um parâmetro de URL resourceVersion) ou de etcd (para todas as outras solicitações).
  • Você pode usar os rótulos group, version, resource e subresource para identificar exclusivamente uma solicitação lenta para uma investigação mais aprofundada.
  • Escrever a resposta para o cliente e receber a resposta dele.

Para mais informações sobre como usar essa métrica, consulte Latência.

Essa métrica tem cardinalidade muito alta. Ao usar essa métrica, é preciso usar filtros ou agrupamento para encontrar fontes específicas de latência.

apiserver_admission_controller_admission_duration_seconds

Essa métrica mede a latência em webhooks de admissão integrados, não em webhooks de terceiros. Para diagnosticar problemas de latência com webooks de terceiros, use a métrica apiserver_admission_webhook_admission_duration_seconds.

apiserver_admission_webhook_admission_duration_seconds e
apiserver_admission_step_admission_duration_seconds

Essas métricas medem a latência em webhooks de admissão externa e de terceiros. A métrica apiserver_admission_webhook_admission_duration_seconds geralmente é a mais útil. Para mais informações sobre como usar essa métrica, consulte Latência.

apiserver_request_total

Use essa métrica para monitorar o tráfego de solicitação no servidor de API. Também é possível usá-la para determinar as taxas de sucesso e falha das suas solicitações. Para mais informações sobre como usar essa métrica, consulte Taxa de tráfego e erro.

Essa métrica tem cardinalidade muito alta. Ao usar essa métrica, é preciso usar filtros ou agrupamento para identificar fontes de erros.

apiserver_storage_objects

Use essa métrica para detectar a saturação do sistema e identificar possíveis vazamentos de recursos. Para ver mais informações, consulte Saturação.

apiserver_current_inflight_requests

Essa métrica registra o número máximo de solicitações que estavam sendo ativamente atendidas na última janela de um segundo. Para ver mais informações, consulte Saturação.

A métrica não inclui solicitações de longa duração, como "relógio".

Como monitorar o servidor de API

As métricas do servidor de API podem fornecer insights sobre os principais sinais de integridade do sistema:

  • Latência: quanto tempo leva para atender a uma solicitação?
  • Tráfego: quanta demanda o sistema está passando?
  • Taxa de erro: com que frequência as solicitações falham?
  • Saturação: quão cheio está o sistema?

Nesta seção, descrevemos como usar as métricas do servidor de API para monitorar a integridade dele.

Latência

Quando a API do servidor está sobrecarregada, a latência da solicitação aumenta. Para medir a latência das solicitações para o servidor de API, use a métrica apiserver_request_duration_seconds. Para identificar a origem da latência de maneira mais específica, é possível agrupar as métricas pelo rótulo verb ou resource.

O limite superior sugerido para uma chamada de recurso único, como GET, POST ou PATCH, é de um segundo. O limite superior sugerido para chamadas LIST com escopo de namespace e de cluster é de 30 segundos. As expectativas de limite superior são definidas pelos SLOs definidos pela comunidade de código aberto do Kubernetes. Para mais informações, consulte Detalhes dos SLIs/SLOs de latência da chamada de API.

Se o valor da métrica apiserver_request_duration_seconds estiver aumentando além da duração esperada, investigue as seguintes possíveis causas:

  • O plano de controle do Kubernetes pode estar sobrecarregado. Para verificar isso, observe as métricas apiserver_request_total e apiserver_storage_objects.
    • Use o rótulo code para determinar se as solicitações estão sendo processadas. Para ver informações sobre os valores possíveis, consulte Códigos de status HTTP.
    • Use os rótulos group, version, resource e subresource para identificar exclusivamente uma solicitação.

  • Um webhook de admissão de terceiros é lento ou não responde. Se o valor da métrica apiserver_admission_webhook_admission_duration_seconds estiver aumentando, alguns webhooks de admissão de terceiros ou definidos pelo usuário são lentos ou não respondem. A latência no webhook de admissão pode causar atrasos na programação de jobs.

    • Para consultar a latência do webhook do percentil 99 por instância do plano de controle do Kubernetes, use a seguinte consulta PromQL:

      sum by (instance) (histogram_quantile(0.99, rate(apiserver_admission_webhook_admission_duration_seconds_bucket{cluster="CLUSTER_NAME"}[1m])))

      Recomendamos também analisar os percentis 50, 90, 95 e 99.9. É possível ajustar a consulta modificando o valor de 0.99.

    • Os webhooks externos têm um tempo limite aproximado de 10 segundos. É possível definir políticas de alertas na métrica apiserver_admission_webhook_admission_duration_seconds para avisar quando você estiver se aproximando do tempo limite do webhook.

    • Também é possível agrupar a métrica apiserver_admission_webhook_admission_duration_seconds no rótulo name para diagnosticar possíveis problemas com webhooks específicos.

  • Você está listando muitos objetos. Espera-se que a latência de chamadas de LIST aumente conforme o número de objetos de um determinado tipo (o tamanho de resposta).

  • Problemas no lado do cliente:

    • O cliente pode não ter recursos suficientes para receber respostas em tempo hábil. Verifique as métricas de uso de CPU do pod cliente.
    • O cliente tem uma conexão de rede lenta. Isso pode acontecer quando o cliente é executado em um dispositivo como um smartphone, mas é improvável que os clientes sejam executados em uma rede do Compute Engine.
    • O cliente foi encerrado inesperadamente, mas a conexão TCP tem um tempo limite em dezenas de segundos. Antes do tempo limite da conexão, os recursos do servidor são bloqueados, o que pode aumentar a latência.

Para mais informações, consulte Boas práticas para usar a prioridade e a imparcialidade da API na documentação do Kubernetes.

Taxa de tráfego e erros

Para medir o tráfego e o número de solicitações bem-sucedidas e com falha no servidor de API, use a métrica apiserver_request_total. Por exemplo, para medir o tráfego do servidor de API por instância do plano de controle do Kubernetes, use a seguinte consulta PromQL:

sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME"}[1m]))

  • Para consultar as solicitações malsucedidas, filtre o rótulo code pelos valores 4xx e 5xx usando a seguinte consulta PromQL:

    sum(rate(apiserver_request_total{code=~"[45].."}[5m]))

  • Para consultar as solicitações bem-sucedidas, filtre o rótulo code por valores 2xx usando a seguinte consulta PromQL:

    sum(rate(apiserver_request_total{code=~"2.."}[5m]))

  • Para consultar as solicitações rejeitadas pelo servidor de API por instância do plano de controle do Kubernetes, filtre o rótulo code pelo valor 429 (http.StatusTooManyRequests) usando a seguinte consulta PromQL:

    sum by (instance) (increase(apiserver_request_total{cluster="CLUSTER_NAME", code="429"}[1m]))

Saturação

É possível medir a saturação no sistema usando as métricas apiserver_current_inflight_requests e apiserver_storage_objects .

Se o valor da métrica apiserver_storage_objects estiver aumentando, você pode estar tendo um problema em um controlador personalizado que cria objetos, mas não os exclui. É possível filtrar ou agrupar a métrica pelo rótulo resource para identificar o recurso que está tendo o aumento.

Avalie a métrica apiserver_current_inflight_requests de acordo com as configurações de prioridade de imparcialidade da API. Essas configurações afetam como as solicitações são priorizadas. Portanto, não é possível tirar conclusões somente dos valores de métricas. Para mais informações, consulte Prioridade e imparcialidade da API.

Métricas do programador

Nesta seção, apresentamos uma lista das métricas do programador e informações adicionais sobre como interpretar e usar as métricas.

Lista de métricas do programador

Quando as métricas do programador estão ativadas, todas as métricas mostradas na tabela a seguir são exportadas para o Cloud Monitoring no mesmo projeto que o cluster do GKE.

Os nomes das métricas do Cloud Monitoring nesta tabela precisam ser prefixados com prometheus.googleapis.com/. Esse prefixo foi omitido das entradas na tabela.

Nome da métrica do PromQL Estágio de lançamento
Nome da métrica do Cloud Monitoring
Tipo, Classe, Unidade
Recursos monitorados
Versão obrigatória do GKE		 Descrição
Rótulos
scheduler_pending_pods GA
scheduler_pending_pods/gauge
Gauge, Double, 1
prometheus_target
1.22.13+ 		Número de pods pendentes por tipo de fila. "active" significa o número de pods em activeQ; "backoff" significa o número de pods em backoffQ; "unschedulable" indica o número de pods em unschedulablePods.

queue
scheduler_pod_scheduling_duration_seconds DESCONTINUADO
scheduler_pod_scheduling_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.25.1 a 1.29 (1.22.17-gke.3100+ , 1.23.11+ e 1.24.5+ para versões secundárias anteriores) 		[Descontinuado na v. 1.29; removido na v. 1.30 e substituído por scheduler_pod_scheduling_sli_duration_seconds.] Latência E2e de um pod sendo programado, o que pode incluir várias tentativas de programação.

attempts
scheduler_pod_scheduling_sli_duration_seconds BETA
scheduler_pod_scheduling_sli_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.30+ 		Latência E2e de um pod sendo programado, desde o momento em que o pod entra na fila de programação, e pode envolver várias tentativas de programação.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		Total de tentativas de preempção no cluster até o momento
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
Cumulative, Distribution, 1
prometheus_target
1.22.13+ 		Número de vítimas de preempção selecionadas
scheduler_scheduling_attempt_duration_seconds GA
scheduler_scheduling_attempt_duration_seconds/histogram
Cumulative, Distribution, 1
prometheus_target
1.23.6+ 		Latência de tentativa da programação em segundos (algoritmo de programação + vinculação).

profile
result
scheduler_schedule_attempts_total GA
scheduler_schedule_attempts_total/counter
Cumulative, Double, 1
prometheus_target
1.22.13+ 		O número de tentativas de programar pods por resultado. "unschedulable" significa que um pod não pode ser programado, enquanto "error" significa um problema interno do programador.

profile
result

As seções a seguir fornecem mais informações sobre as métricas do servidor da API.

scheduler_pending_pods

É possível usar a métrica scheduler_pending_pods para monitorar a carga no programador. O aumento dos valores nessa métrica pode indicar problemas de recursos. O programador tem três filas, e essa métrica informa o número de solicitações pendentes por fila. As seguintes filas são compatíveis:

  • Fila active
    • O conjunto de pods que o programador está tentando programar. O pod com a prioridade mais alta está no cabeçalho da fila.
  • Fila backoff
    • O conjunto de pods não estava programável na última vez que o programador tentou, mas que pode ser programado na próxima vez.
    • Os pods nessa fila precisam aguardar um período de espera (máximo de 10 segundos). Depois disso, eles são movidos de volta para a fila active para outra tentativa de programação. Para mais informações sobre o gerenciamento da fila backoff, consulte a solicitação de implementação, Problema do Kubernetes 75417.

  • Conjunto unschedulable

    • O conjunto de pods que o programador tentou programar, mas que foram determinados como não programáveis. A posição nesta fila pode indicar problemas de prontidão ou compatibilidade com os nós ou a configuração dos seletores de nós.

      Quando as restrições de recursos impedem que os pods sejam programados, os pods não estão sujeitos ao tratamento de espera. Em vez disso, quando um cluster está cheio, novos pods não são programados e são colocados na fila unscheduled.

    • A presença de pods não programados pode indicar que você tem recursos insuficientes ou um problema de configuração do nó. Os pods são movidos para a fila backoff ou active após eventos que alteram o estado do cluster. Os pods nessa fila indicam que nada mudou no cluster que tornaria os pods programáveis.

    • Afinidades definem regras de atribuição de pods aos nós. O uso de regras de afinidade ou antiafinidade pode ser um motivo para um aumento nos pods não programados.

    • Alguns eventos, por exemplo, ADD/UPDATE de PVC/serviço, término de um pod ou o registro de novos nós, movem alguns ou todos os pods não programados para a fila backoff ou active. Para saber mais, consulte Problema do Kubernetes 81214.

Para saber mais, consulte Latência do programador e Problemas de recursos.

scheduler_scheduling_attempt_duration_seconds

Essa métrica mede a duração de uma única tentativa de programação no próprio programador e é dividida pelo resultado: programado, não programável ou erro. A duração vai do momento em que o programador pega um pod até o momento em que o programador localiza um nó e o coloca no nó, determina que o pod não é programável ou encontra um erro. A duração da programação inclui o tempo do processo de programação e o tempo de vinculação. Vinculação é o processo em que o programador comunica a atribuição de nó ao servidor da API. Para mais informações, consulte Latência do programador.

Essa métrica não captura o tempo que o pod gasta no controle de admissão ou na validação.

Para mais informações sobre programação, consulte Como programar um pod.

scheduler_schedule_attempts_total

Esta métrica mede o número de tentativas de agendamento cada tentativa de programar um pod aumenta o valor. Use essa métrica para determinar se o programador está disponível: se o valor está aumentando, então o programador está operacional. Você pode usar o rótulo result para determinar o sucesso. Os pods são scheduled ou unschedulable.

Essa métrica está altamente correlacionada com a métrica scheduler_pending_pods: quando há muitos pods pendentes, você pode esperar muitas tentativas para programar os pods. Para saber mais, consulte Problemas de recursos.

Essa métrica não aumentará se o programador não tiver pods a serem programados, o que poderá ser o caso se você tiver um programador secundário personalizado.

scheduler_preemption_attempts_total e scheduler_preemptions_victims

Use as métricas de preempção para ajudar a determinar se você precisa adicionar recursos.

Talvez você tenha pods de maior prioridade que não podem ser programados porque não há espaço para eles. Nesse caso, o programador libera recursos interrompendo temporariamente um ou mais pods em execução em um nó. A métrica scheduler_preemption_attempts_total rastreia o número de vezes que o programador tentou forçar a interrupção de pods.

A métrica scheduler_preemptions_victims conta os pods selecionados para preempção.

O número de tentativas de preempção tem uma forte correlação com o valor da métrica scheduler_schedule_attempts_total quando o valor do identificador result é unschedulable. Os dois valores não são equivalentes: por exemplo, se um cluster tem 0 nós, não há tentativas de preempção, mas pode haver tentativas de programação que falham.

Para saber mais, consulte Problemas de recursos.

Como monitorar o programador

As métricas do programador podem fornecer insights sobre o desempenho dele:

Nesta seção, descrevemos como usar a métrica do programador para monitorá-lo.

Latência do programador

A tarefa do programador é garantir que os pods sejam executados. Portanto, é importante saber quando o programador está travado ou em execução lenta.

  • Para verificar se o programador está em execução e programando pods, use a métrica scheduler_schedule_attempts_total.

  • Quando o programador estiver lento, investigue as seguintes causas possíveis:

    • O número de pods pendentes está aumentando. Use a métrica scheduler_pending_pods para monitorar o número de pods pendentes. A seguinte consulta PromQL retorna o número de pods pendentes por fila em um cluster:

      sum by (queue)
(delta(scheduler_pending_pods{cluster="CLUSTER_NAME"}[2m]))

    • Tentativas individuais de programar pods são lentas. Use a métrica scheduler_scheduling_attempt_duration_seconds para monitorar a latência das tentativas de agendamento.

      Recomendamos observar essa métrica pelo menos nos percentis 50 e 95. A consulta PromQL a seguir recupera valores do percentil 95, mas pode ser ajustada:

      sum by (instance) (histogram_quantile(0.95, rate(
scheduler_scheduling_attempt_duration_seconds_bucket{cluster="CLUSTER_NAME"}[5m])))

Problemas com recursos

As métricas do programador também podem ajudar você a avaliar se você tem recursos suficientes. Se o valor da métrica scheduler_preemption_attempts_total estiver aumentando, verifique o valor de scheduler_preemption_victims usando a seguinte consulta PromQL:

scheduler_preemption_victims_sum{cluster="CLUSTER_NAME"}

O número de tentativas de preempção e o número de vítimas de preempção aumentam quando há pods de prioridade mais alta a serem programados. As métricas de preempção não informam se os pods de alta prioridade que acionaram as preempções foram programados. Portanto, quando você vê aumentos no valor das métricas de preempção, também é possível monitorar o valor da métrica scheduler_pending_pods. Se o número de pods pendentes também estiver aumentando, é possível que você não tenha recursos suficientes para lidar com os pods de maior prioridade. Pode ser necessário escalonar verticalmente os recursos disponíveis, criar novos pods com declarações de recursos reduzidas ou alterar o seletor de nós.

  • Se o número de vítimas de preempção não estiver aumentando, não haverá pods restantes com baixa prioridade que possam ser removidos. Nesse caso, considere adicionar mais nós para que os novos pods possam ser alocados.

  • Se o número de vítimas de preempção estiver aumentando, isso significa que há pods de maior prioridade aguardando a programação, então o programador interrompe alguns pods em execução. As métricas de preempção não informam se os pods de prioridade mais alta foram programados com sucesso.

    Para determinar se os pods de maior prioridade estão sendo programados, procure diminuir os valores da métrica scheduler_pending_pods. Se o valor dessa métrica estiver aumentando, talvez seja necessário adicionar mais nós.

É possível que haja picos temporários nos valores da métrica scheduler_pending_pods quando as cargas de trabalho forem programadas no cluster, por exemplo, durante eventos como atualizações ou escalonamentos. Se você tiver recursos suficientes no cluster, esses picos serão temporários. Se o número de pods pendentes não diminuir, faça o seguinte:

  • Verifique se os nós não estão limitados. Nós limitados não aceitam novos pods.
  • Verifique as diretivas de programação a seguir, que podem ser configuradas incorretamente e podem tornar um pod não programável:
    • Afinidade e seletor de nós.
    • Taints e tolerâncias
    • Restrições de propagação de topologia de pods.

Se não for possível programar os pods devido à insuficiência de recursos, libere alguns dos nós atuais ou aumente o número de nós.

Métricas do Controller Manager

Quando as métricas do gerenciador do controlador estão ativadas, todas as métricas mostradas na tabela a seguir são exportadas para o Cloud Monitoring no mesmo projeto que o cluster do GKE.

Os nomes das métricas do Cloud Monitoring nesta tabela precisam ser prefixados com prometheus.googleapis.com/. Esse prefixo foi omitido das entradas na tabela.

Nome da métrica do PromQL Estágio de lançamento
Nome da métrica do Cloud Monitoring
Tipo, Classe, Unidade
Recursos monitorados
Versão obrigatória do GKE		 Descrição
Rótulos
node_collector_evictions_total GA
node_collector_evictions_total/counter
Cumulative, Double, 1
prometheus_target
1.24+ 		Número de remoções de nós que ocorreram desde que a instância atual do NodeController foi iniciada.

zone