Primeiros passos com a coleta gerenciada

Neste documento, descrevemos como configurar o Google Cloud Managed Service para Prometheus com coleção gerenciada. A configuração é um exemplo mínimo de ingestão de trabalho, usando uma implantação Prometheus que monitora um aplicativo de exemplo e armazena métricas coletadas no Monarch.

Esta página mostra como fazer o seguinte:

  • Configure o ambiente e as ferramentas de linha de comando.
  • Configurar a coleção gerenciada para o cluster.
  • Configurar um recurso para extração de destino e ingestão de métricas.
  • Migre os recursos personalizados atuais do operador Prometheus.

Recomendamos que você use a coleta gerenciada. reduz a complexidade da implantação, do escalonamento, da fragmentação, da configuração e da manutenção dos coletores. A coleta gerenciada é compatível com o GKE e todos os outros ambientes do Kubernetes.

A coleta gerenciada executa coletores com base no Prometheus como um Daemonset e garante a escalonabilidade apenas ao extrair destinos em nós colocalizados. Configure os coletores com recursos personalizados leves para extrair os exportadores usando a coleção pull. Em seguida, eles enviam os dados raspados para o armazenamento de dados central do Monarch. O Google Cloud nunca acessa diretamente o cluster para extrair ou raspar dados de métricas. Seus coletores enviam dados para o Google Cloud. Para mais informações sobre a coleta de dados gerenciada e autoimplantada, consulte Coleta de dados com o serviço gerenciado para o Prometheus e Ingestão e consulta com coleta gerenciada e autoimplantada.

Antes de começar

Nesta seção, descrevemos a configuração necessária para as tarefas descritas neste documento.

Configurar projetos e ferramentas

Para usar o Google Cloud Managed Service para Prometheus, você precisa dos seguintes recursos:

  • Um projeto do Google Cloud com a API Cloud Monitoring ativada.

    • Se você não tiver um projeto do Google Cloud, faça o seguinte:

      1. No Console do Google Cloud, acesse Novo projeto:

        Crie um novo projeto

      2. No campo Project Name, insira um nome para o projeto e clique em Criar.

      3. Acesse o Faturamento:

        Acessar "Faturamento"

      4. Selecione o projeto recém-criado se ele ainda não estiver selecionado na parte superior da página.

      5. Você precisará escolher um perfil para pagamentos atual ou criar um novo.

      A API Monitoring é ativada por padrão para novos projetos.

    • Se você já tem um projeto do Google Cloud, verifique se a API Monitoring está ativada:

      1. Acessar APIs e serviços

        Acessar APIs e serviços

      2. Selecione o projeto.

      3. Clique em Ativar APIs e serviços.

      4. Pesquise "Monitoring".

      5. Nos resultados da pesquisa, clique em "API Cloud Monitoring".

      6. Se a opção "API ativada" não for exibida, clique no botão Ativar.

  • Um cluster do Kubernetes. Se você não tiver um cluster do Kubernetes, siga as instruções no Guia de início rápido do GKE.

Você também precisa das seguintes ferramentas de linha de comando:

  • gcloud
  • kubectl

As ferramentas gcloud e kubectl fazem parte da Google Cloud CLI. Para mais informações sobre como instalá-los, consulte Como gerenciar componentes da CLI do Google Cloud. Para ver os componentes da CLI gcloud que você instalou, execute o seguinte comando:

gcloud components list

Configurar o ambiente

Para evitar inserir repetidamente o ID do projeto ou o nome do cluster, execute a seguinte configuração:

  • Configure as ferramentas de linha de comando da seguinte maneira:

    • Configure a CLI gcloud para se referir ao ID do projeto do Google Cloud:

      gcloud config set project PROJECT_ID

    • Configure a CLI kubectl para usar o cluster:

      kubectl config set-cluster CLUSTER_NAME

    Para mais informações sobre essas ferramentas, consulte estes recursos:

Configurar um namespace

Crie o namespace NAMESPACE_NAME do Kubernetes para os recursos que você criar como parte do aplicativo de exemplo:

kubectl create ns NAMESPACE_NAME

Configurar a coleção gerenciada

É possível usar a coleta gerenciada tanto em clusters do Kubernetes do GKE quanto naqueles que não são do GKE.

Depois de a coleta gerenciada ser ativada, os componentes no cluster serão executados, mas nenhuma métrica será gerada ainda. Os recursos do PodMonitoring ou do ClusterPodMonitoring são necessários por esses componentes para capturar corretamente os endpoints das métricas. É necessário implantar esses recursos com endpoints de métricas válidos ou ativar um dos pacotes de métricas gerenciados, por exemplo, métricas de estado do Kube, integradas ao GKE. Para ver informações sobre solução de problemas, consulte Problemas no processamento.

A ativação da coleção gerenciada instala os seguintes componentes no cluster:

Para ver a documentação de referência sobre o operador do Managed Service para Prometheus, consulte a página de manifestos.

Ativar a coleta gerenciada: GKE

A coleta gerenciada é ativada por padrão para:

Se sua execução for em um ambiente do GKE que não ativa a coleta gerenciada por padrão, consulte Ativar a coleta gerenciada manualmente.

A coleta gerenciada no GKE é atualizada automaticamente quando novas versões de componentes no cluster são lançadas.

A coleta gerenciada no GKE usa permissões concedidas à conta de serviço padrão do Compute Engine. Se você tiver uma política que modifique as permissões padrão na conta de serviço do nó padrão, talvez seja necessário adicionar o papel Monitoring Metric Writer para continuar.

Ativar a coleta gerenciada manualmente

Se você estiver executando em um ambiente do GKE que não permita a coleta gerenciada por padrão, será possível ativar a coleta gerenciada usando o seguinte:

  • O painel de Clusters do GKE no Cloud Monitoring.
  • A página do Kubernetes Engine no console do Google Cloud.
  • Google Cloud CLI. Para usar a CLI gcloud, é necessário executar o GKE versão 1.21.4-gke.300 ou mais recente.

  • Terraform para o Google Kubernetes Engine. Para usar o Terraform para ativar o Serviço gerenciado para o Prometheus, é preciso executar o GKE versão 1.21.4-gke.300 ou mais recente.

Painel de clusters do GKE

É possível fazer o seguinte usando o painel de Clusters do GKE no Cloud Monitoring.

  • Determinar se o Managed Service para Prometheus está ativado nos clusters e se você está usando a coleta gerenciada ou implantada automaticamente.
  • Ativar a coleta gerenciada em clusters no seu projeto.
  • Ver outras informações sobre os clusters.

Para visualizar o painel de Clusters do GKE, faça o seguinte:

  1. No console do Google Cloud, acesse a página  Painéis:

    Ir para Painéis

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

  2. Selecione a categoria Painel do G​C​P e depois Clusters do GKE.

O painel de Clusters do GKE no Cloud Monitoring.

Para ativar a coleta gerenciada em um ou mais clusters do GKE usando o painel de clusters do GKE, faça o seguinte:

  1. Marque a caixa de seleção de cada cluster do GKE em que você quer ativar a coleta gerenciada.

  2. Selecione Ativar selecionada.

IU do Kubernetes Engine

É possível fazer o seguinte usando o console do Google Cloud:

  • Ative a coleta gerenciada em um cluster atual do GKE.
  • Criar um novo cluster do GKE com a coleta gerenciada ativada.

Para atualizar um cluster existente, 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 lista Recursos, localize a opção Serviço gerenciado para o Prometheus. Se ele estiver listado como desativado, clique em Editar e selecione Ativar serviço gerenciado para o Prometheus.

  4. Clique em Salvar alterações.

Para criar um cluster com a coleção gerenciada ativada, 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 em Criar.

  3. Clique em Configurar para a opção Padrão.

  4. No painel de navegação, clique em Recursos.

  5. Na seção Operações, selecione Ativar serviço gerenciado para o Prometheus.

  6. Clique em Salvar.

CLI gcloud

É possível fazer o seguinte usando a CLI gcloud:

  • Ative a coleta gerenciada em um cluster atual do GKE.
  • Criar um novo cluster do GKE com a coleta gerenciada ativada.

A conclusão desses comandos pode levar até 5 minutos.

Primeiro, defina seu projeto:

gcloud config set project PROJECT_ID

Para atualizar um cluster, execute um dos seguintes comandos update com base no fato de o cluster ser zonal ou regional:

  • gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --zone ZONE

  • gcloud container clusters update CLUSTER_NAME --enable-managed-prometheus --region REGION

Para criar um cluster com a coleta gerenciada ativada, execute o seguinte comando:

gcloud container clusters create CLUSTER_NAME --zone ZONE --enable-managed-prometheus

Autopilot do GKE

A coleta gerenciada é ativada por padrão nos clusters do GKE Autopilot que executam a versão 1.25 ou mais recente do GKE. Não é possível desativar a coleta gerenciada.

Se o cluster não ativar a coleta gerenciada automaticamente ao fazer upgrade para a versão 1.25, será possível ativá-la manualmente executando o comando de atualização na seção da CLI gcloud.

Terraform

Para instruções sobre como configurar a coleta gerenciada usando o Terraform, consulte o 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.

Desativar a coleta gerenciada

Se você quiser desativar a coleta gerenciada nos clusters, use um dos seguintes métodos:

interface do Kubernetes Engine

É possível fazer o seguinte usando o console do Google Cloud:

  • Desativar a coleta gerenciada em um cluster do GKE atual.
  • Cancelar a ativação automática da coleta gerenciada ao criar um novo cluster do GKE Standard executando a versão 1.27 ou mais recente do GKE.

Para atualizar um cluster existente, 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 seção Recursos, localize a opção Serviço gerenciado para o Prometheus. Clique em  Editar e limpe Ativar Serviço gerenciado para o Prometheus.

  4. Clique em Salvar alterações.

Para cancelar a ativação automática da coleta gerenciada ao criar um novo cluster do GKE Standard (versão 1.27 ou superior), 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 em Criar.

  3. Clique em Configurar para a opção Padrão.

  4. No painel de navegação, clique em Recursos.

  5. Na seção Operações, limpe Ativar serviço gerenciado para o Prometheus.

  6. Clique em Salvar.

CLI gcloud

É possível fazer o seguinte usando a CLI gcloud:

  • Desativar a coleta gerenciada em um cluster do GKE atual.
  • Cancelar a ativação automática da coleta gerenciada ao criar um novo cluster do GKE Standard executando a versão 1.27 ou mais recente do GKE.

A conclusão desses comandos pode levar até 5 minutos.

Primeiro, defina seu projeto:

gcloud config set project PROJECT_ID

Para desativar a coleta gerenciada em um cluster atual, execute um dos comandos update a seguir com base no estado do cluster, zonal ou regional:

  • gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --zone ZONE

  • gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus --region REGION

Para cancelar a ativação automática da coleta gerenciada ao criar um novo cluster do GKE Standard (versão 1.27 ou superior), execute o seguinte comando:

gcloud container clusters create CLUSTER_NAME --zone ZONE --no-enable-managed-prometheus

Autopilot do GKE

Não é possível desativar a coleta gerenciada em clusters do Autopilot do GKE executando a versão 1.25 ou mais recente do GKE.

Terraform

Para desativar a coleta gerenciada, defina o atributo enabled no bloco de configuração managed_prometheus como false. Para mais informações sobre esse bloco de configuração, consulte o 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.

Ativar a coleta gerenciada: Kubernetes fora do GKE

Se você estiver executando em um ambiente que não seja do GKE, será possível ativar a coleta gerenciada usando o seguinte:

  • A CLI kubectl.

  • A solução empacotada incluída nas implantações do GKE Enterprise executando a versão 1.12 ou mais recente.

CLI kubectl

Para instalar coletores gerenciados quando você estiver usando um cluster do Kubernetes que não seja do GKE, execute os seguintes comandos para instalar os manifestos de configuração e operador:

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/setup.yaml

kubectl apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

GKE Enterprise

Saiba como configurar a coleta gerenciada para clusters do GKE Enterprise na documentação da sua distribuição:

Implantar o aplicativo de exemplo

O aplicativo de exemplo emite a métrica de contador example_requests_total e a métrica de histograma example_random_numbers (entre outras) na porta metrics. O manifesto do aplicativo define três réplicas.

Para implantar o aplicativo de exemplo, execute o seguinte comando:

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/example-app.yaml

Configurar um recurso do PodMonitoring

Para ingerir os dados de métrica emitidos pelo aplicativo de exemplo, o Managed Service para Prometheus usa a captura de destino. A raspagem dos dados de destino e a ingestão de métricas são configuradas usando os recursos personalizados do Kubernetes. O serviço gerenciado usa os recursos personalizados (CRs) do PodMonitoring.

Uma coleta de resposta automática do PodMonitoring só segmenta no namespace em que a resposta automática está implantada. Para coletar objetivos em vários namespaces, implante a mesma resposta automática do PodMonitoring em cada namespace. Para verificar se o recurso PodMonitoring está instalado no namespace pretendido, execute kubectl get podmonitoring -A.

Para a documentação de referência sobre todas as respostas automáticas gerenciadas pelo serviço do Prometheus, consulte a referência do prometheus-engine/doc/api.

O manifesto a seguir define um recurso do PodMonitoring, prom-example, no namespace NAMESPACE_NAME. O recurso usa um seletor de rótulos do Kubernetes para encontrar todos os pods no namespace que têm o rótulo app.kubernetes.io/name com o valor prom-example. A raspagem de dados dos pods correspondentes é feita em uma porta chamada metrics, a cada 30 segundos, no caminho HTTP /metrics.

apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s

Para aplicar esse recurso, execute o seguinte comando:

kubectl -n NAMESPACE_NAME apply -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/pod-monitoring.yaml

Seu coletor gerenciado agora está extraindo os pods correspondentes. É possível ver o status do destino da raspagem de dados ativando o recurso de status do destino.

Para configurar uma coleção horizontal que se aplique a um intervalo de pods em todos os namespaces, use o recurso ClusterPodMonitoring. O recurso ClusterPodMonitoring fornece a mesma interface que o PodPod, mas não limita os pods descobertos a um determinado namespace.

Se você estiver executando no GKE, faça o seguinte:

Se você estiver executando fora do GKE, será necessário criar uma conta de serviço e autorizá-la a gravar seus dados de métrica, conforme descrito na seção a seguir.

Fornecer credenciais explicitamente

Ao executar no GKE, o servidor do Prometheus que coleta é recuperado automaticamente com base na conta de serviço do nó. Em clusters que não são do Kubernetes, as credenciais precisam ser explicitamente fornecidas por meio do recurso OperatorConfig no namespace gmp-public.

  1. Defina o contexto para seu projeto de destino:

    gcloud config set project PROJECT_ID

  2. Crie uma conta de serviço:

    gcloud iam service-accounts create gmp-test-sa

  3. Conceda as permissões necessárias à conta de serviço:

    gcloud projects add-iam-policy-binding PROJECT_ID\
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.metricWriter

  4. Crie e faça o download de uma chave para a conta de serviço:

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. Adicione o arquivo de chave como secret ao cluster que não é do GKE:

    kubectl -n gmp-public create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Abra o recurso OperatorConfig para edição:

    kubectl -n gmp-public edit operatorconfig config

    1. Adicione o texto exibido em negrito ao recurso:

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
collection:
  credentials:
    name: gmp-test-sa
    key: key.json
      Também é preciso adicionar essas credenciais à seção rules para que a avaliação da regra gerenciada funcione.

    2. Salve o arquivo e feche o editor. Depois que a alteração é aplicada, os pods são recriados e começam a autenticar no back-end da métrica com a conta de serviço especificada.

    Outros tópicos da coleção gerenciada

    Esta seção explica como fazer o seguinte:

    • Ative o recurso de status do destino para facilitar a depuração.
    • Configurar a extração de destino usando o Terraform.
    • Filtre os dados exportados para o serviço gerenciado.
    • Coletar métricas do Kubelet e do cAdvisor.
    • Converta os recursos atuais do operador para uso com o serviço gerenciado.
    • Execute a coleção gerenciada fora do GKE.

    Como ativar o recurso de status do destino

    O Managed Service para Prometheus oferece uma maneira de verificar se os destinos estão sendo descobertos e extraídos corretamente pelos coletores. Esse relatório de status do destino é uma ferramenta para depurar problemas graves. Recomendamos ativar esse recurso apenas para investigar problemas imediatos. Deixar o relatório de status do destino ativado em clusters grandes pode fazer com que o operador fique sem memória e cause um loop de falha.

    Para verificar o status dos destinos nos recursos do PodMonitoring ou ClusterPodMonitoring, defina o valor features.targetStatus.enabled no recurso do OperatorConfig como true, conforme mostrado a seguir:

        apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    features:
      targetStatus:
        enabled: true

    Após alguns segundos, o campo Status.Endpoint Statuses aparece em todos os recursos válidos do PodMonitoring ou ClusterPodMonitoring, quando configurados.

    Se você tiver um recurso do PodMonitoring com o nome prom-example no namespace NAMESPACE_NAME, execute o seguinte comando para verificar o status:

    kubectl -n NAMESPACE_NAME describe podmonitorings/prom-example

    A saída será assim:

    API Version:  monitoring.googleapis.com/v1
Kind:         PodMonitoring
...
Status:
  Conditions:
    ...
    Status:                True
    Type:                  ConfigurationCreateSuccess
  Endpoint Statuses:
    Active Targets:       3
    Collectors Fraction:  1
    Last Update Time:     2023-08-02T12:24:26Z
    Name:                 PodMonitoring/custom/prom-example/metrics
    Sample Groups:
      Count:  3
      Sample Targets:
        Health:  up
        Labels:
          Cluster:                     CLUSTER_NAME
          Container:                   prom-example
          Instance:                    prom-example-589ddf7f7f-hcnpt:metrics
          Job:                         prom-example
          Location:                    REGION
          Namespace:                   NAMESPACE_NAME
          Pod:                         prom-example-589ddf7f7f-hcnpt
          project_id:                  PROJECT_ID
        Last Scrape Duration Seconds:  0.020206416
        Health:                        up
        Labels:
          ...
        Last Scrape Duration Seconds:  0.054189485
        Health:                        up
        Labels:
          ...
        Last Scrape Duration Seconds:  0.006224887

    A saída inclui os seguintes campos de status:

    • Status.Conditions.Status é verdadeiro quando o serviço gerenciado para Prometheus confirma e processa o PodMonitoring ou o ClusterPodMonitoring.
    • Status.Endpoint Statuses.Active Targets mostra o número de destinos de verificação que o Managed Service para Prometheus conta em todos os coletores para esse recurso do PodMonitoring. No aplicativo de exemplo, a implantação prom-example tem três réplicas com um único destino de métrica. Portanto, o valor é 3. Se houver destinos não íntegros, o campo Status.Endpoint Statuses.Unhealthy Targets será exibido.
    • Status.Endpoint Statuses.Collectors Fraction mostra um valor de 1 (ou seja, 100%) se todos os coletores gerenciados forem acessíveis pelo Managed Service para o Prometheus.
    • Status.Endpoint Statuses.Last Update Time mostra o horário da última atualização. Quando o tempo da última atualização é significativamente maior que o tempo desejado do intervalo de coleta, a diferença pode indicar problemas com seu destino ou cluster.
    • O campo Status.Endpoint Statuses.Sample Groups mostra exemplos de destinos agrupados por rótulos de destino comuns injetados pelo coletor. Esse valor é útil para depurar situações em que seus destinos não são descobertos. Se todos os destinos estiverem íntegros e sendo coletados, o valor esperado para o campo Health será up e o valor para o campo Last Scrape Duration Seconds será a duração habitual de um destino típico.

    Para mais informações sobre esses campos, consulte o documento da API Managed Service para Prometheus.

    Qualquer um dos itens a seguir pode indicar um problema com sua configuração:

    • O campo Status.Endpoint Statuses não consta no recurso PodMonitoring.
    • O valor do campo Last Scrape Duration Seconds é muito antigo.
    • Você vê poucas segmentações.
    • O valor do campo Health indica que o destino é down.

    Para mais informações sobre problemas de descoberta de destinos para depuração, consulte Problemas no lado da ingestão na documentação da solução de problemas.

    Como configurar um endpoint de raspagem de dados autorizado

    Se o destino de extração exigir autorização, configure o coletor para usar o tipo de autorização correto e fornecer segredos relevantes.

    O Google Cloud Managed Service para Prometheus oferece suporte aos seguintes tipos de autorização:

    mTLS

    O mTLS é geralmente configurado em ambientes de confiança zero, como a malha de serviço do Istio ou o Cloud Service Mesh.

    Para ativar os endpoints de raspagem de dados protegidos com mTLS, defina o campo Spec.Endpoints[].Scheme no recurso PodMonitoring como https. Embora não seja recomendado, é possível definir o campo Spec.Endpoints[].insecureSkipVerify no recurso PodMonitoring como true para pular a verificação da autoridade do certificado. Como alternativa, configure o serviço gerenciado para o Prometheus para carregar certificados e chaves de recursos secretos.

    Por exemplo, o recurso de secret a seguir contém chaves para os certificados de cliente (cert), chave privada (key) e autoridade certificadora (ca):

    kind: Secret
metadata:
  name: secret-example
stringData:
  cert: ********
  key: ********
  ca: ********

    Conceda ao coletor do Managed Service para Prometheus permissão para acessar esse recurso secreto:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Nos clusters do GKE Autopilot, isso fica assim:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Para configurar um recurso do PodMonitoring que use o recurso Secret anterior, modifique o recurso para adicionar uma seção scheme e tls:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    scheme: https
    tls:
      ca:
        secret:
          name: secret-example
          key: ca
      cert:
        secret:
          name: secret-example
          key: cert
      key:
        secret:
          name: secret-example
          key: key

    Para a documentação de referência sobre todas as opções de mTLS do Managed Service para Prometheus, consulte a documentação de referência da API.

    BasicAuth

    Para ativar os endpoints de raspagem de dados protegidos com BasicAuth, defina o campo Spec.Endpoints[].BasicAuth no recurso PodMonitoring com seu nome de usuário e senha. Para outros tipos de cabeçalho de autorização HTTP, consulte Cabeçalho de autorização HTTP.

    Por exemplo, o recurso Secret a seguir contém uma chave para armazenar a senha:

    kind: Secret
metadata:
  name: secret-example
stringData:
  password: ********

    Conceda ao coletor do Managed Service para Prometheus permissão para acessar esse recurso secreto:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Nos clusters do GKE Autopilot, isso fica assim:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Para configurar um recurso do PodMonitoring que use o recurso Secret anterior e um nome de usuário de foo, modifique o recurso para adicionar uma seção basicAuth:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    basicAuth:
      username: foo
      password:
        secret:
          name: secret-example
          key: password

    Para a documentação de referência sobre todas as opções de BasicAuth do Managed Service para Prometheus, consulte a documentação de referência da API.

    Cabeçalho de autorização HTTP

    Para ativar endpoints de extração protegidos usando cabeçalhos de autorização HTTP, defina o campo Spec.Endpoints[].Authorization no recurso PodMonitoring com o tipo e as credenciais. Para endpoints BasicAuth, use a configuração BasicAuth.

    Por exemplo, o recurso Secret a seguir contém uma chave para armazenar as credenciais:

    kind: Secret
metadata:
  name: secret-example
stringData:
  credentials: ********

    Conceda ao coletor do Managed Service para Prometheus permissão para acessar esse recurso secreto:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Nos clusters do GKE Autopilot, isso fica assim:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Para configurar um recurso do PodMonitoring que use o recurso Secret anterior e um tipo de Bearer, adicione uma seção authorization:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    authorization:
      type: Bearer
      credentials:
        secret:
          name: secret-example
          key: credentials

    Para a documentação de referência sobre todas as opções de cabeçalho de autorização HTTP do Managed Service para Prometheus, consulte a documentação de referência da API.

    OAuth 2

    Para ativar a raspagem de endpoints protegidos usando o OAuth 2, defina o campo Spec.Endpoints[].OAuth2 no recurso PodMonitoring.

    Por exemplo, o recurso Secret a seguir contém uma chave para armazenar o secret do cliente:

    kind: Secret
metadata:
  name: secret-example
stringData:
  clientSecret: ********

    Conceda ao coletor do Managed Service para Prometheus permissão para acessar esse recurso secreto:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gmp-system
  kind: ServiceAccount

    Nos clusters do GKE Autopilot, isso fica assim:

    apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: secret-example-read
rules:
- resources:
  - secrets
  apiGroups: [""]
  verbs: ["get", "list", "watch"]
  resourceNames: ["secret-example"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: gmp-system:collector:secret-example-read
  namespace: default
roleRef:
  name: secret-example-read
  kind: Role
  apiGroup: rbac.authorization.k8s.io
subjects:
- name: collector
  namespace: gke-gmp-system
  kind: ServiceAccount

    Para configurar um recurso do PodMonitoring que use o recurso Secret anterior com um ID do cliente de foo e um URL do token de example.com/token, modifique o recurso para adicionar uma seção oauth2:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-example
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: prom-example
  endpoints:
  - port: metrics
    interval: 30s
    oauth2:
      clientID: foo
      clientSecret:
        secret:
          name: secret-example
          key: password
      tokenURL: example.com/token

    Para a documentação de referência sobre todas as opções do OAuth 2 do Managed Service para Prometheus, consulte a documentação de referência da API.

    Como configurar a raspagem de dados de destino usando o Terraform

    É possível automatizar a criação e o gerenciamento de recursos PodMonitoring e ClusterPodMonitoring usando o tipo de recurso kubernetes_manifest do Terraform ou tipo de recurso kubectl_manifest do Terraform, que permite especificar recursos personalizados arbitrários.

    Para informações gerais sobre como usar o Google Cloud com o Terraform, consulte Terraform com o Google Cloud.

    Filtrar métricas exportadas

    Se você coletar muitos dados, convém evitar que algumas séries temporais sejam enviadas ao serviço gerenciado para o Prometheus, para manter os custos baixos. Para isso, use as regras de re-rotulação do Prometheus com uma ação keep para uma lista de permissões ou uma ação drop para uma lista de bloqueio. Para a coleta gerenciada, essa regra entra na seção metricRelabeling do recurso PodMonitoring ou ClusterPodMonitoring.

    Por exemplo, a seguinte regra de rerótulo de métrica vai filtrar qualquer métrica que comece com foo_bar_, foo_baz_ ou foo_qux_:

      metricRelabeling:
  - action: drop
    regex: foo_(bar|baz|qux)_.+
    sourceLabels: [__name__]

    A página Gerenciamento de métricas do Cloud Monitoring fornece informações que podem ajudar a controlar o valor gasto em métricas sujeitas a cobrança, sem afetar a observabilidade. A página Gerenciamento de métricas mostra as seguintes informações:

    • Volumes de ingestão para faturamento baseado em byte e amostra, em domínios de métricas e para métricas individuais.
    • Dados sobre rótulos e cardinalidade de métricas.
    • Número de leituras de cada métrica.
    • Uso de métricas em políticas de alertas e painéis personalizados.
    • Taxa de erros de gravação de métrica.

    Você também pode usar o Gerenciamento de métricas para excluir métricas desnecessárias, eliminando o custo de ingestão delas. Para mais informações sobre a página Gerenciamento de métricas, consulte Ver e gerenciar o uso de métricas.

    Para mais sugestões sobre como reduzir seus custos, consulte Atribuição de controles de custo.

    Como coletar métricas do Kubelet e cAdvisor

    O Kubelet expõe métricas sobre ele mesmo, bem como métricas do cAdvisor sobre contêineres em execução no nó. É possível configurar a coleta gerenciada para extrair métricas do Kubelet e cAdvisor editando o recurso OperatorConfig. Para instruções, consulte a documentação do exportador para Kubelet e cAdvisor.

    Converter recursos atuais de operador do Prometheus

    Geralmente, é possível converter os recursos do operador Prometheus atuais para os recursos do serviço gerenciado da coleção gerenciada do Prometheus do PodMonitoring e do ClusterPodMonitoring.

    Por exemplo, o recurso ServiceMonitor define o monitoramento para um conjunto de serviços. O recurso PodMonitoring atende a um subconjunto dos campos exibidos pelo recurso ServiceMonitor. É possível converter uma resposta automática do ServiceMonitor em uma resposta automática do PodMonitoring mapeando os campos conforme descrito na tabela a seguir:

    monitoring.coreos.com/v1
    ServiceMonitor     		Compatibilidade
          		monitoring.googleapis.com/v1
    PodMonitoring
    .ServiceMonitorSpec.Selector Idênticos .PodMonitoringSpec.Selector
    .ServiceMonitorSpec.Endpoints[] .TargetPort Mapeado para .Port
    .Path: compatible
    .Interval: compatible
    .Timeout: compatible     		.PodMonitoringSpec.Endpoints[]
    .ServiceMonitorSpec.TargetLabels O podMonitor precisa especificar:
    .FromPod[].From rótulo do pod
    .FromPod[].To rótulo de destino     		.PodMonitoringSpec.TargetLabels

    Veja a seguir uma amostra de uma resposta automática do ServiceMonitor: o conteúdo em negrito é substituído na conversão, e o conteúdo em itálico é mapeado diretamente:

    apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - targetPort: web
    path: /stats
    interval: 30s
  targetLabels:
  - foo

    Veja a seguir a resposta análoga do PodMonitoring, supondo que seu serviço e seus pods sejam rotulados com app=example-app. Se essa suposição não se aplicar, será necessário usar os seletores de rótulo do recurso de Serviço subjacente.

    O conteúdo em negrito foi substituído na conversão:

    apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: example-app
spec:
  selector:
    matchLabels:
      app: example-app
  endpoints:
  - port: web
    path: /stats
    interval: 30s
  targetLabels:
    fromPod:
    - from: foo # pod label from example-app Service pods.
      to: foo

    Sempre é possível continuar usando os recursos e operadores de implantação prometheus atuais usando coletores implantados automaticamente em vez de coletores gerenciados. É possível consultar métricas enviadas dos dois tipos de coletores. Por isso, pode ser útil usar coletores autoimplantados nas implantações atuais do Prometheus enquanto usa coletores gerenciados para novas implantações do Prometheus.

    Rótulos reservados

    O Serviço gerenciado para Prometheus adiciona automaticamente os seguintes rótulos a todas as métricas coletadas. Esses rótulos são usados para identificar exclusivamente um recurso no Monarch:

    • project_id: o identificador do projeto do Google Cloud associado à sua métrica.
    • location: o local físico (região do Google Cloud) em que os dados são armazenados. Esse valor geralmente é a região do cluster do GKE. Se os dados forem coletados de uma AWS ou implantação no local, o valor poderá ser a região do Google Cloud mais próxima.
    • cluster: o nome do cluster do Kubernetes associado à métrica.
    • namespace: o nome do namespace do Kubernetes associado à sua métrica.
    • job: o rótulo do job do destino do Prometheus, se conhecido. Pode estar vazio para resultados de avaliação de regras.
    • instance: o rótulo da instância de destino do Prometheus, se conhecido. Pode estar vazio para os resultados de avaliação de regras.

    Embora não seja recomendado ao executar no Google Kubernetes Engine, é possível substituir os rótulos project_id, location e cluster adicionando-os comoargs ao recurso de implantação em operator.yaml. Se você usar rótulos reservados como rótulos de métricas, o serviço gerenciado para Prometheus os adicionará novamente com o prefixo exported_. Esse comportamento corresponde a como o Prometheus upstream lida com conflitos com rótulos reservados.

    Compactar configurações

    Se você tiver muitos recursos do PodMonitoring, poderá ficar sem espaço no ConfigMap. Para corrigir isso, ative a compactação gzip no recurso OperatorConfig:

      apiVersion: monitoring.googleapis.com/v1
  kind: OperatorConfig
  metadata:
    namespace: gmp-public
    name: config
  features:
    config:
      compression: gzip

    Ativar o escalonamento automático vertical de pods (VPA, na sigla em inglês) para a coleta gerenciada

    Se você encontrar erros de falta de memória (OOM) nos pods de coletor no cluster ou se as solicitações e os limites de recursos padrão para os coletores não atenderem às suas necessidades, use o escalonamento automático vertical de pods para alocar recursos dinamicamente.

    Quando você define o campo scaling.vpa.enabled: true no recurso OperatorConfig, o operador implanta um manifesto VerticalPodAutoscaling no cluster que permite que as solicitações e limites de recursos dos pods de coletor sejam definidos automaticamente com base no uso.

    Para ativar a VPA para pods de coletor no Managed Service para Prometheus, execute o seguinte comando:

    kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge

    Se o comando for concluído, o operador vai configurar o escalonamento automático do pod vertical para os pods de coletor. Erros de falta de memória resultam em um aumento imediato dos limites de recursos. Se não houver erros de OOM, o primeiro ajuste nas solicitações de recursos e nos limites dos pods de coletor geralmente ocorre em 24 horas.

    Você pode receber este erro ao tentar ativar a VPA:

    vertical pod autoscaling is not available - install vpa support and restart the operator

    Para resolver esse erro, primeiro ative o escalonamento automático de pods verticais no nível do cluster:

    1. Acesse a página Kubernetes Engine – Clusters no console do Google Cloud.

      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. Selecione o cluster que você quer modificar.

    3. Na seção Automação, edite o valor da opção Escalonamento automático vertical de pods.

    4. Marque a caixa de seleção Ativar o escalonamento automático vertical de pods e clique em Salvar alterações. Essa mudança reinicia o cluster. O operador é reinicializado como parte desse processo.

    5. Tente novamente o comando a seguir: kubectl -n gmp-public patch operatorconfig/config -p '{"scaling":{"vpa":{"enabled":true}}}' --type=merge para ativar o VPA no serviço gerenciado para Prometheus.

    Para confirmar que o recurso OperatorConfig foi editado, abra-o usando o comando kubectl -n gmp-public edit operatorconfig config. Se for bem-sucedido, o OperatorConfig vai incluir a seção em negrito a seguir:

    apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
scaling:
  vpa:
    enabled: true

    O escalonamento automático vertical de pods funciona melhor ao ingerir números constantes de amostras, divididas igualmente entre os nós. Se a carga de métricas for irregular ou irregular ou se a carga de métricas variar muito entre os nós, a VPA pode não ser uma solução eficiente.

    Para mais informações, consulte Escalonamento automático vertical de pods no GKE.

    Eliminação

    Para desativar a coleta gerenciada implantada usando gcloud ou a IU do GKE, realize um dos seguintes procedimentos:

    • Execute este comando:

      gcloud container clusters update CLUSTER_NAME --disable-managed-prometheus

    • Use a IU do GKE:

      1. Selecione Kubernetes Engine no console do Google Cloud e, em seguida, selecione Clusters.

      2. Localize o cluster em que você quer desativar a coleta gerenciada e clique no nome dela.

      3. Na guia Detalhes, role para baixo até Recursos e mude o estado para Desativado usando o botão de edição.

    Para desativar a coleta gerenciada implantada usando o Terraform, especifique enabled = false na seção managed_prometheus do recurso google_container_cluster.

    Para desativar a coleta gerenciada implantada usando kubectl, execute o seguinte comando:

    kubectl delete -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/manifests/operator.yaml

    Desativar a coleta gerenciada faz com que o cluster pare de enviar novos dados para o Managed Service para Prometheus. Essa ação não exclui os dados de métricas já armazenados no sistema.

    Desativar a coleta gerenciada também exclui o namespace gmp-public e todos os recursos dentro dele, incluindo os exportadores instalados nesse namespace.

    Executar a coleção gerenciada fora do GKE

    Nos ambientes do GKE, é possível executar a coleta gerenciada sem nenhuma configuração. Em outros ambientes do Kubernetes, é necessário fornecer explicitamente credenciais, um valor project-id para conter suas métricas, um valor location (região do Google Cloud) em que suas métricas serão armazenadas e um valor de cluster para salvar o nome do cluster em que o coletor está sendo executado.

    Como gcloud não funciona fora dos ambientes do Google Cloud, você precisa implantar usando o kubectl. Ao contrário do gcloud, a implantação da coleta gerenciada usando kubectl não faz o upgrade automático do cluster quando uma nova versão está disponível. Lembre-se de assistir às versões de lançamento para novas versões e fazer upgrade manualmente executando novamente os comandos kubectl com a nova versão.

    É possível fornecer uma chave de conta de serviço modificando o recurso OperadorConfig em operator.yaml, conforme descrito em Fornecer credenciais explicitamente. É possível fornecer valores project-id, location e cluster adicionando-os como args ao recurso de implantação em operator.yaml.

    Recomendamos escolher project-id com base no modelo de locação planejada para leituras. Escolha um projeto para armazenar métricas com base na forma como você planeja organizar as leituras posteriormente com escopos de métricas. Se não se importar, coloque tudo em um só projeto.

    Para location, é recomendável escolher a região do Google Cloud mais próxima da implantação. Quanto mais distante a região escolhida do Google Cloud estiver da implantação, mais será a latência de gravação e o impacto por possíveis problemas de rede. Consulte esta lista de regiões em várias nuvens. Se você não se importar, poderá colocar tudo em uma única região do Google Cloud. Não é possível usar global como local.

    Para cluster, recomendamos escolher o nome do cluster em que o operador está implantado.

    Quando configurado corretamente, o OperatorConfig ficará assim:

        apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    collection:
      credentials:
        name: gmp-test-sa
        key: key.json
    rules:
      credentials:
        name: gmp-test-sa
        key: key.json

    O recurso de implantação será semelhante a este:

    apiVersion: apps/v1
kind: Deployment
...
spec:
  ...
  template:
    ...
    spec:
      ...
      containers:
      - name: operator
        ...
        args:
        - ...
        - "--project-id=PROJECT_ID"
        - "--cluster=CLUSTER_NAME"
        - "--location=REGION"

    Neste exemplo, presumimos que você definiu a variável REGION como um valor como us-central1, por exemplo.

    A execução do Managed Service para Prometheus fora do Google Cloud gera taxas de transferência de dados. Há taxas para transferir dados para o Google Cloud, e pode haver taxas para transferir dados de outra nuvem. É possível minimizar esses custos ativando a compactação gzip pela rede usando o OperatorConfig. Adicione o texto exibido em negrito ao recurso:

        apiVersion: monitoring.googleapis.com/v1
    kind: OperatorConfig
    metadata:
      namespace: gmp-public
      name: config
    collection:
      compression: gzip
      ...

    Leitura adicional sobre recursos personalizados da coleção gerenciada

    Para a documentação de referência sobre todos os recursos personalizados do Managed Service para Prometheus, consulte a referência do prometheus-engine/doc/api.

    A seguir