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 e, 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:

  • Visão geral da CLI gcloud
  • Comandos kubectl

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:

• A implantação gmp-operator, que implanta o operador do Kubernetes para o serviço gerenciado para o Prometheus.
• A implantação rule-evaluator, que é usada para configurar e executar regras de alerta e gravação.
• O DaemonSet collector, que escalona horizontalmente a coleta raspando dados de métricas apenas de pods em execução no mesmo nó de cada coletor.
• O StatefulSet alertmanager, que está configurado para enviar alertas acionados aos seus canais de notificação preferidos.

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:

• Clusters do GKE Autopilot que executam a versão 1.25 ou superior do GKE.

• Clusters do GKE Standard executando o GKE versão 1.27 ou posterior. É possível modificar esse padrão ao criar o cluster. Consulte Desativar a coleta gerenciada.

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 painel de navegação do console do Google Cloud, selecione Monitoramento e  Painéis:

   Ir para Painéis

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

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.

Observação: este painel mostra apenas clusters do GKE no projeto atual, mesmo que o projeto tenha vários projetos no escopo da métrica. Para mais informações, consulte Visão geral de métricas de visualização de vários projetos.

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 painel de navegação do console do Google Cloud, selecione Kubernetes Engine e, depois, Clusters:

   Acessar os clusters do Kubernetes

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 painel de navegação do console do Google Cloud, selecione Kubernetes Engine e, depois, Clusters:

   Acessar os clusters do Kubernetes

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 painel de navegação do console do Google Cloud, selecione Kubernetes Engine e, depois, Clusters:

   Acessar os clusters do Kubernetes

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 painel de navegação do console do Google Cloud, selecione Kubernetes Engine e, depois, Clusters:

   Acessar os clusters do Kubernetes

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.8.2/manifests/setup.yaml

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

GKE Enterprise

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

• Clusters do Anthos no VMware (v1.12 ou mais recente)
• Clusters do Anthos em bare metal (v1.12+)

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.8.2/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.8.2/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.

Observação: o campo targetLabels fornece uma configuração de novo rótulo simplificada no estilo do Prometheus. É possível usar a remarcação para adicionar rótulos de pod como rótulos na série temporal ingerida. Não é possível substituir os rótulos de destino obrigatórios. para uma lista desses rótulos, consulte o recurso prometheus_target.

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

• Para consultar as métricas ingeridas pelo aplicativo de exemplo usando o PromQL no Cloud Monitoring, consulte Consultar usando o Cloud Monitoring.
• Para consultar as métricas ingeridas pelo aplicativo de exemplo usando o Grafana, acesse Consulta usando o Grafana ou qualquer consumidor da API Prometheus.
• Para saber como filtrar métricas exportadas e adaptar seus recursos de operador de promessa, consulte Outros tópicos para coleta gerenciada.

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

   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 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 rerotificaçã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.
   • Uso de métricas em políticas de alertas e painéis personalizados.
   • Taxa de erros de gravação de métrica.
   Para mais informações sobre a página Gerenciamento de métricas, consulte Visualização 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
   

   Observação: é possível converter uma PodMonitor do operador do Prometheus na resposta automática do PodMonitoring do serviço gerenciado da mesma maneira. os seletores de rótulo sempre são copiáveis.

   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:

   • 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.

   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.8.2/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. Nas versões 0.5.0 e mais recentes, é possível minimizar esses custos ativando a compactação gzip por meio do 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

   • Use o PromQL no Cloud Monitoring para consultar as métricas do Prometheus.
   • Use o Grafana para consultar as métricas do Prometheus.
   • Use os alertas do PromQL no Cloud Monitoring.
   • Configure a avaliação de regras gerenciadas.
   • Configure os exportadores usados com frequência.