Usar métricas do plano de controle

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

É possível configurar um cluster do Google Kubernetes Engine (GKE) para enviar determinadas métricas emitidas pelo servidor da API Kubernetes, pelo programador e pelo gerenciador do controlador para o Cloud Monitoring. Neste documento, descrevemos como essas métricas são formatadas quando são gravadas no Cloud Monitoring e como consultá-las. Neste documento, também fornecemos tabelas que listam as métricas em cada conjunto e informações sobre como você pode usar essas métricas.

Antes de usar as métricas do plano de controle, é necessário ativar a coleta delas.

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 postfix indicando o tipo de métrica PromQL, 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 podem ser consultadas usando PromQL ou consultadas usando MQL.

Métricas de consulta

Quando você consulta as métricas do plano de controle, o nome usado depende do recurso PromQL ou Cloud Monitoring que está sendo usado, como Metrics Explorer, MQL ou painéis. As tabelas nas seções Métricas do servidor de API, Métricas do programador e Métricas do gerenciador do controlador abaixo mostram duas versões de nome de cada métrica:

  • Nome da métrica do PromQL: ao usar o PromQL nas páginas do Cloud Monitoring do Console do Google Cloud](/stackdriver/docs/managed-prometheus/query#gmp-promql-in-monitoring) ou na 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 G​K​E.

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
GaugeDouble1
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_request_duration_seconds GA
apiserver_request_duration_seconds/histogram
CumulativeDistributions
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
CumulativeDouble1
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
CumulativeDistribution1
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
GaugeDouble1
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
CumulativeDistributions
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
CumulativeDistributions
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
CumulativeDistributions
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 alta cardinalidade. 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 alta cardinalidade. 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 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 mais informações, consulte Saturação.

A métrica não inclui solicitações de longa duração, como "relógio". Para informações sobre a métrica apiserver_longrunning_requests futura, consulte Solicitação de envio 1103100 do Kubernetes.

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.

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 G​K​E.

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
GaugeDouble1
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 GA
scheduler_pod_scheduling_duration_seconds/histogram
CumulativeDistribution1
prometheus_target
1.23.6+
Latência E2e para um pod programado, o que pode incluir várias tentativas de programação.

attempts
scheduler_preemption_attempts_total GA
scheduler_preemption_attempts_total/counter
CumulativeDouble1
prometheus_target
1.22.13+
Total de tentativas de preempção no cluster até o momento
scheduler_preemption_victims GA
scheduler_preemption_victims/histogram
CumulativeDistribution1
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
CumulativeDistribution1
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
CumulativeDouble1
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 o Problema 81214 do Kubernetes.

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 com 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 G​K​E.

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
CumulativeDouble1
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