Como gerenciar métricas do GKE

O Google Kubernetes Engine (GKE) facilita o envio de métricas para o Cloud Monitoring. No Cloud Monitoring, as métricas podem ser preenchidas com painéis personalizados, geraralertas, criarObjetivos de nível de serviço ou ser buscados por serviços de monitoramento de terceiros usando oAPI Monitoring de dados.

O G​K​E o fornece duas fontes de métricas:

  • Métricas do sistema: métricas de componentes essenciais do sistema, descrevendo recursos de baixo nível, como CPU, memória e armazenamento.
  • Métricas de carga de trabalho: métricas expostas por qualquer carga de trabalho do G​K​E, como um CronJob ou uma implantação de um aplicativo.

Métricas do sistema

Quando um cluster é criado, o G​K​E, por padrão, coleta algumas métricas emitidas por componentes do sistema.

Você tem a opção de enviar ou não métricas do seu cluster do G​K​E para o Cloud Monitoring. Se você optar por enviar métricas para o Cloud Monitoring, precisará enviar métricas do sistema.

Todas as métricas do sistema G​K​E são ingeridas no Cloud Monitoring com o prefixo kubernetes.io.

Preços

O Cloud Monitoring não cobra pela ingestão de métricas do sistema GKE. Saiba mais sobre os preços do Cloud Monitoring.

Como configurar a coleta de métricas do sistema

Para ativar a coleta de métricas do sistema, transmita o valor SYSTEM para --monitoringa sinalização de gcloud container clusters create ou comandos gcloud container clusters update.

Para desativar a coleta de métricas do sistema, use o valor NONE para a sinalização --monitoring. Se a coleta de métricas do sistema estiver desativada, informações básicas, como uso de CPU e de memória e disco, não estarão disponíveis para um cluster naSeção G K E do Console do Cloud. Além disso, o painel G K E do Cloud Monitoring não contém informações sobre o cluster.

Consulte Como configurar o Cloud Operations para GKE para mais detalhes sobre a integração do Cloud Monitoring com o G​K​E.

Lista de métricas do sistema

As métricas do sistema incluem métricas de componentes essenciais do sistema, importantes para a funcionalidade principal do Kubernetes. Veja uma lista completa de m étricas do sistema.

Métricas de carga de trabalho

As métricas de carga de trabalho do G​K​E são o modo recomendado pelo Google de monitorar aplicativos do Kubernetes usando o Cloud Monitoring.

O G​K​E 1.20.8-gke.2100 ou posterior oferece um pipeline de coleta de métricas totalmente gerenciado para raspagem de dados no estilo do Prometheus expostas por qualquer carga de trabalho do G​K​E (como um CronJob ou uma implantação de um aplicativo) e enviar essas métricas para o Cloud Monitoring.

Todas as métricas coletadas pelo pipeline de métricas da carga de trabalho do G​K​E são ingeridas no Cloud Monitoring com o prefixo workload.googleapis.com.

Os benefícios das métricas de carga de trabalho do G​K​E incluem:

  • Configuração fácil: com um único comando kubectl para implantar um recurso personalizado do PodMonitor, é possível começar a coletar métricas. Não é necessária a instalação manual de um agente.
  • Altamente configurável: ajuste os endpoints de scrape, a frequência e outros parâmetros.
  • Totalmente gerenciado: o Google mantém o pipeline para que você possa se concentrar nos aplicativos.
  • Controlar custos: gerencie os custos do Cloud Monitoring com facilidade por meio de filtros de métricas flexíveis.
  • Padrão aberto: configure as métricas de carga de trabalho usando o recurso personalizado PodMonitor, que é modelado após o recurso PodMonitor do Operador do Prometheus.
  • Compatibilidade com HPA: compatível com o adaptador de métricas personalizadas do Stackdriver para ativar o escalonamento horizontal em métricas personalizadas.
  • Preços melhores: preços mais intuitivos, previsíveis e mais baixos.
  • Suporte ao Autopilot: compatível com os clusters G​K​E Standard e G​K​E Autopilot.

Requisitos

As métricas de carga de trabalho do G​K​E exigem o plano de controle do G​K​E versão 1.20.8-gke.2100 ou superior e não é compatível com as cargas de trabalho do G​K​E Windows.

Se você ativar o pipeline de métricas da carga de trabalho, precisará também ativar a coleta de métricas do sistema.

Etapa 1: ativar o pipeline de métricas da carga de trabalho

Para ativar o pipeline de coleta de métricas de carga de trabalho em um cluster atual do GKE, siga estas etapas:

CONSOLE

  1. No Console do Google Cloud, acesse a lista de clusters do G K E:

    Acessar os clusters do Kubernetes

  2. Clique no nome do cluster.

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

  4. Na caixa de diálogo "Editar Cloud Monitoring" exibida, confirme se a opção Ativar o Cloud Monitoring está selecionada.

  5. No menu suspenso, selecione Cargas de trabalho.

  6. Clique em OK.

  7. Clique em Save Changes.

GCLOUD

  1. Abra uma janela de terminal com o SDK do Cloud e a ferramenta de linha de comando gcloud instaladas. Uma maneira de fazer isso é usando o Cloud Shell.

  2. No Console do Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente com o SDK do Cloud pré-instalado com a ferramenta de linha de comando gcloud e os valores já definidos para seu projeto atual. A inicialização da sessão pode levar alguns segundos.

  3. Execute este comando:

    gcloud beta container clusters update [CLUSTER_ID] \
      --zone=[ZONE] \
      --project=[PROJECT_ID] \
      --monitoring=SYSTEM,WORKLOAD
    

    Incluindo o valor WORKLOAD para a sinalização --monitoring de gcloud beta container clusters create ou gcloud beta container clusters update para ativar o pipeline de coleta de métricas de carga de trabalho.

Ativar o pipeline de coleta de métricas de carga de trabalho implanta um agente de coleta de métricas em cada nó capaz de coletar métricas de aplicativo emitidas pelas cargas de trabalho do Kubernetes.

Consulte Como configurar o Cloud Operations para GKE para mais detalhes sobre a integração do Cloud Monitoring com o G K E.

Etapa 2: configurar quais métricas são coletadas

1) crie um recurso personalizado do PodMonitor chamado my-pod-monitor.yaml:


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2) Inicialize a credencial usando a ferramenta de linha de comando gcloud para configurar o kubectl:

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3) implante o recurso personalizado do PodMonitor:

kubectl apply -f my-pod-monitor.yaml

Migrating

Se você já estiver usando o sidecar do Stackdriver Prometheus, as métricas de carga de trabalho do G​K​E oferecem várias melhorias. É altamente recomendável alternar para o uso de métricas de carga de trabalho do G​K​E para coletar métricas emitidas pelo aplicativo. Consulte o guia de migração do arquivo secundário do Stackdriver Prometheus para métricas de carga de trabalho do G K E.

Preços

O Cloud Monitoring cobra pelas métricas de carga de trabalho do GKE com base no número de amostras ingeridas. Saiba mais sobre os preços do Cloud Monitoring.

Como gerenciar custos

Para gerenciar custos, comece determinando quais métricas de carga de trabalho são mais valiosas para suas necessidades de monitoramento. O pipeline de métricas da carga de trabalho do G K E fornece controles granulares para atingir a compensação certa entre capturar métricas detalhadas e manter os custos baixos.

Muitos aplicativos expõem uma grande variedade de métricas do Prometheus e, por padrão, o pipeline de métricas de carga de trabalho do G​K​E coleta todas as métricas de cada pod selecionado a cada 60 segundos.

Use as técnicas a seguir para reduzir o custo das métricas:

  1. Como ajustar a frequência da verificação: para reduzir o custo das métricas, recomendamos reduzir a frequência da verificação quando apropriado. Por exemplo, é possível que um KPI relevante para os negócios mude lentamente o suficiente para ser copiado a cada 10 minutos. No PodMonitor, defina interval para controlar a frequência de extração.

  2. Métricas de filtragem: identifique qualquer métrica que não esteja sendo usada no Cloud Monitoring e use metricRelabelings para garantir que somente métricas úteis para painéis, alertas ou SLOs sejam enviadas ao Cloud. Monitoring.

Veja um exemplo concreto para um recurso personalizado do PodMonitor que usa ambas as técnicas:

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

Para identificar quais métricas têm o maior número de amostras ingeridas, use a métrica monitoring.googleapis.com/collection/attribution/write_sample_count:

  1. No Console do Cloud, selecione Monitoring:

    Acessar o Monitoramento

  2. No painel de navegação do Monitoring, clique em Metrics Explorer.

  3. No campo Métrica, selecione monitoring.googleapis.com/collection/attribution/write_sample_count.

  4. (Opcional) Filtre apenas as métricas de carga de trabalho do GKE:

    • Clique em Adicionar filtro.

    • No campo Rótulo, selecione metric_domain.

    • No campo Valor, insira workload.googleapis.com.

    • Clique em Concluído.

  5. Opcionalmente, agrupe o número de amostras ingeridas pelo namespace do Kubernetes, pela região do GKE, projeto do Google Cloud ou pelo tipo de recurso monitorado:

    • Clique em Agrupar por.

    • Para agrupar por namespace do Kubernetes, selecione attribution_dimension e attribution_id.

    • Para agrupar por região do GKE, selecione location.

    • Para agrupar por projeto do Cloud, selecione resource_container.

    • Para agrupar por tipo de recurso monitorado, selecione resource_type.

  6. Para classificar a lista de métricas em ordem decrescente, clique no cabeçalho da coluna Valor acima da lista de métricas.

Estas etapas mostram as métricas com a maior taxa de amostras ingeridas no Cloud Monitoring. Como as métricas de carga de trabalho do GKE são cobradas pelo número de amostras ingeridas, preste atenção às métricas com a maior taxa de amostragem ingerida. Avalie se é possível reduzir a frequência de verificação de qualquer uma dessas métricas ou parar de coletar qualquer uma delas.

Por fim, há muitos recursos disponíveis para entender o custo das métricas do G K E ingeridas no Cloud Monitoring e otimizar esses custos. Consulte o guia de otimização de custos para mais formas de reduzir o custo do Cloud Monitoring.

Versões anteriores do G​K​E

Para coletar métricas de aplicativo em um cluster com uma versão do plano de controle G​K​E menor que 1.20.8-gke.2100, use o sidecar do Stackdriver Prometheus.

Solução de problemas

Se as métricas de carga de trabalho não estiverem disponíveis no Cloud Monitoring conforme o esperado, veja algumas etapas para solucionar o problema.

Confirmar se o cluster atende aos requisitos mínimos

Verifique se o cluster do G K E está executando a versão de plano de controle 1.20.8-gke.2100 ou posterior. Caso contrário, faça upgrade do plano de controle do cluster.

Confirmar se as métricas da carga de trabalho estão ativadas

Verifique se o cluster do G​K​E está configurado para ativar o pipeline de coleta de métricas da carga de trabalho seguindo estas etapas:

CONSOLE

  1. No Console do Google Cloud, acesse a lista de clusters do G K E:

    Acessar os clusters do Kubernetes

  2. Clique no nome do cluster.

  3. No painel Detalhes do cluster, confirme se a "Carga de trabalho" está incluída no status do Cloud Monitoring. Se "Carga de trabalho" não for exibida aqui, ative as métricas de carga de trabalho.

GCLOUD

  1. Abra uma janela de terminal com o SDK do Cloud e gcloud instalados. Uma maneira de fazer isso é usando o Cloud Shell.

  2. No Console do Cloud, ative o Cloud Shell.

    Ativar o Cloud Shell

    Na parte inferior do Console do Cloud, uma sessão do Cloud Shell é iniciada e exibe um prompt de linha de comando. O Cloud Shell é um ambiente com o SDK do Cloud pré-instalado com a ferramenta de linha de comando gcloud e os valores já definidos para seu projeto atual. A inicialização da sessão pode levar alguns segundos.

  3. Execute este comando:

    gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
    

    Na saída desse comando, procure a linha monitoringConfig:. Algumas linhas depois, confirme se a seção enableComponents: inclui WORKLOADS. Se WORKLOADS não for exibido aqui, ative as métricas de carga de trabalho.

Confirme se as métricas são coletadas no seu aplicativo

Se você não conseguir visualizar as métricas do seu aplicativo no Cloud Monitoring, siga as etapas abaixo para resolver problemas. Nestas etapas, usamos um aplicativo de amostra para fins de demonstração, mas você pode aplicar as mesmas etapas abaixo para resolver problemas de qualquer aplicativo.

As primeiras etapas abaixo implantam um aplicativo de amostra, que pode ser usado para testes. As etapas restantes demonstram as etapas a serem seguidas para solucionar problemas de porque as métricas desse aplicativo não estão aparecendo no Cloud Monitoring.

  1. Crie um arquivo chamado prometheus-example-app.yaml contendo o seguinte:

    # This example application exposes prometheus metrics on port 1234.
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      labels:
        app: prom-example
      name: prom-example
      namespace: gke-workload-metrics
    spec:
      selector:
        matchLabels:
          app: prom-example
      template:
        metadata:
          labels:
            app: prom-example
        spec:
          containers:
          - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
            name: prom-example
            ports:
            - name: metrics-port
              containerPort: 1234
            command:
            - "/main"
            - "--process-metrics"
            - "--go-metrics"
    
  2. Inicialize a credencial usando a ferramenta de linha de comando gcloud para configurar o kubectl:

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  3. Crie o namespace gke-workload-metrics

    kubectl create ns gke-workload-metrics
    
  4. Implantar o aplicativo de exemplo:

    kubectl apply -f prometheus-example-app.yaml
    
  5. Confirme se o aplicativo de exemplo está em execução executando este comando:

    kubectl get pod -n gke-workload-metrics -l app=prom-example
    

    A saída será semelhante a esta:

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-775d8685f4-ljlkd   1/1     Running   0          25m
    
  6. Confirme se o aplicativo está expondo as métricas conforme o esperado

    Usando um dos pods retornados do comando acima, verifique se o endpoint de métricas está funcionando corretamente:

    POD_NAME=prom-example-775d8685f4-ljlkd
    NAMESPACE=gke-workload-metrics
    PORT_NUMBER=1234
    METRICS_PATH=/metrics
    kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH
    

    Se você estiver usando o aplicativo de exemplo acima, receberá uma saída semelhante a esta:

    # HELP example_random_numbers A histogram of normally distributed random numbers.
    # TYPE example_random_numbers histogram
    example_random_numbers_bucket{le="0"} 501
    example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
    example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
    example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
    example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
    example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
    example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
    ...
    
  7. Crie um arquivo chamado my-pod-monitor.yaml contendo o seguinte:

    # Note that this PodMonitor is in the monitoring.gke.io domain,
    # rather than the monitoring.coreos.com domain used with the
    # Prometheus Operator.  The PodMonitor supports a subset of the
    # fields in the Prometheus Operator's PodMonitor.
    apiVersion: monitoring.gke.io/v1alpha1
    kind: PodMonitor
    metadata:
      name: example
      namespace: gke-workload-metrics
    # spec describes how to monitor a set of pods in a cluster.
    spec:
      # selector determines which pods are monitored.  Required
      # This example matches pods with the `app: prom-example` label
      selector:
        matchLabels:
          app: prom-example
      podMetricsEndpoints:
        # port is the name of the port of the container to be scraped.
      - port: metrics-port
        # path is the path of the endpoint to be scraped.
        # Default /metrics
        path: /metrics
        # scheme is the scheme of the endpoint to be scraped.
        # Default http
        scheme: http
        # interval is the time interval at which metrics should
        # be scraped. Default 60s
        interval: 20s
    
  8. Crie este recurso do PodMonitor:

    kubectl apply -f my-pod-monitor.yaml
    

    Depois de criar o recurso PodMonitor, o pipeline de métricas da carga de trabalho do G K E detectará os pods apropriados e começará a recuperá-los periodicamente automaticamente. O pipeline enviará as métricas coletadas para o Cloud Monitoring

  9. Confirme se o identificador e o namespace estão definidos corretamente no PodMonitor. Atualize os valores de NAMESPACE e SELECTOR abaixo para refletir namespace e matchLabels no recurso personalizado do PodMonitor. Em seguida, execute este comando:

    NAMESPACE=gke-workload-metrics
    SELECTOR=app=prom-example
    kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
    

    O resultado deve ser parecido com este:

    NAME                            READY   STATUS    RESTARTS   AGE
    prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
    
  10. Confirme se o PodMonitor está no estado "Pronto".

    Execute este comando para retornar todos os PodMonitors instalados no cluster:

    kubectl get podmonitor.monitoring.gke.io --all-namespaces
    

    A resposta será parecida com esta:

    NAMESPACE              NAME      AGE
    gke-workload-metrics   example   2m36s
    

    Identifique o PodMonitor relevante do conjunto retornado e execute este comando, substituindo example no comando abaixo pelo nome do PodMonitor:

    kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
    

    Analise os resultados retornados por kubectl describe e confirme se a condição "Ready" é "Verdadeira". Se "Pronto" for "Falsa", procure eventos que indiquem por que ele não está pronto.

  11. Em seguida, confirmaremos se essas métricas foram realmente recebidas pelo Cloud Monitoring. Na seção do Cloud Monitoring no Console do Google Cloud, acesse Metrics Explorer.

  12. No campo Métrica, digite example_requests_total.

  13. No menu suspenso exibido, selecione workload.googleapis.com/example_requests_total.

    Essa métrica example_requests_total é uma das métricas do Prometheus emitidas pelo aplicativo de exemplo.

    Se o menu suspenso não aparecer ou se você não vir workload.googleapis.com/example_requests_total no menu suspenso, tente novamente em alguns minutos.

    Todas as métricas estão associadas ao recurso de contêiner do Kubernetes (k8s_container) do qual são coletados. Use o campo Tipo de recurso do Metrics Explorer para selecionar k8s_container. Também é possível agrupar por qualquer rótulo, como namespace_name ou pod_name.

    Essa métrica pode ser usada em qualquer lugar no Cloud Monitoring ou consultada por meio da API Cloud Monitoring. Por exemplo, para adicionar este gráfico a um painel atual ou novo, clique no botão Save Chart no canto superior direito e selecione o painel desejado em uma janela de diálogo.

Verifique se há erros ao enviar para a API Cloud Monitoring

As métricas enviadas ao Cloud Monitoring precisam permanecer dentro dos limites de métricas personalizadas. Os erros serão exibidos nos registros de auditoria do Cloud Monitoring.

Usando o Explorador de registros do Cloud Logging, procure nos registros com este filtro de registro (substitua PROJECT_ID pelo nome do seu projeto):

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*-compute@developer.gserviceaccount.com"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

Isso mostrará erros em todas as gravações no Cloud Monitoring do projeto, não apenas nas do cluster.

Verificar a cota de processamento do Cloud Monitoring

  1. Acesse a página Cotas da API Cloud Monitoring
  2. Selecione o projeto relevante
  3. Expanda a seção Solicitações de processamento de séries temporais
  4. Confirme se a Contagem da cota de erros excedidos para "Solicitações de ingestão de série temporal por minuto" é 0. Se esse for o caso, o gráfico "Contagem da cota de erros excedidos" indicará que "Não há dados disponíveis para o período selecionado".
  5. Se a porcentagem de pico de uso exceder 100%, considere selecionar menos pods, selecionar menos métricas ou solicitar um limite de cota mais alto para a cota monitoring.googleapis.com/ingestion_requests.

Confirmar se o DaemonSet foi implantado

Verifique se o DaemonSet de métricas de carga de trabalho foi implantado no cluster. Para verificar se isso está funcionando, use kubectl:

  1. Inicialize a credencial usando a ferramenta de linha de comando gcloud para configurar o kubectl:

    gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
    
  2. Verifique se o DaemonSet de carga de trabalho para métricas está presente e íntegro. Execute este comando:

    kubectl get ds -n kube-system workload-metrics
    

    Se os componentes forem implantados, você verá algo semelhante a esta saída:

    NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
    workload-metrics   3         3         3       3            3           2m
    

    O número de réplicas acima precisa corresponder ao número de nós do GKE para Linux no cluster. Por exemplo, um cluster com três nós terá DESIRED = 3. Após alguns minutos, os números READY e AVAILABLE corresponderão ao número DESIRED. Caso contrário, pode haver um problema na implantação.

Outras métricas

Além das métricas do sistema e das métricas de carga de trabalho descritas acima, algumas métricas adicionais disponíveis para um cluster do G​K​E incluem: