Comece a usar a recolha implementada automaticamente

Este documento descreve como configurar o serviço gerido do Google Cloud para Prometheus com a recolha implementada automaticamente. Uma aplicação de exemplo é implementada num cluster do Kubernetes e é monitorizada por um servidor Prometheus que armazena as métricas recolhidas no Monarch.

Este documento mostra como fazer o seguinte:

  • Configure o seu ambiente e ferramentas de linha de comandos.
  • Configure uma conta de serviço para a federação de identidades da carga de trabalho para clusters ativados para o GKE.
  • Execute o binário do Prometheus de substituição no Kubernetes.
  • Controle que métricas são carregadas no Managed Service for Prometheus.
  • Integre o Managed Service for Prometheus com configurações do prometheus-operator.
  • Compile e execute manualmente o ficheiro binário do Prometheus.

Com a recolha de dados implementada automaticamente, gere a sua instalação do Prometheus como sempre fez. A única diferença é que executa o ficheiro binário de substituição direta do Managed Service for Prometheus, gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1, em vez do ficheiro binário do Prometheus a montante.

O ficheiro binário incorporado oferece opções de configuração adicionais com as flags --export.*. Para mais informações, consulte o resultado da opção --help. Este documento destaca as opções mais importantes.

O Managed Service for Prometheus não suporta a exportação de métricas de um servidor de federação nem de um servidor usado como recetor de gravação remota. Pode replicar todas as funcionalidades do servidor de federação, incluindo a redução do volume de carregamento agregando dados antes de os enviar para o Monarch, através de filtros e agregações locais.

O streaming de dados para o serviço gerido para Prometheus consome recursos adicionais. Se estiver a implementar coletores automaticamente, recomendamos que aumente os limites de CPU e memória 5 vezes e os ajuste com base na utilização real.

Para mais informações sobre a recolha de dados gerida e implementada automaticamente, consulte o artigo Recolha de dados com o serviço gerido para Prometheus.

Antes de começar

Esta secção descreve a configuração necessária para as tarefas descritas neste documento.

Configure projetos e ferramentas

Para usar o serviço gerido do Google Cloud para Prometheus, precisa dos seguintes recursos:

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

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

      1. Na Google Cloud consola, aceda a Novo projeto:

        Crie um novo projeto

      2. No campo Nome do projeto, introduza um nome para o projeto e, de seguida, clique em Criar.

      3. Aceda a Faturação:

        Aceder a Faturação

      4. Selecione o projeto que acabou de criar, se ainda não estiver selecionado na parte superior da página.

      5. É-lhe pedido que escolha um perfil de pagamentos existente ou que crie um novo.

      A API Monitoring está ativada por predefinição para novos projetos.

    • Se já tiver um Google Cloud projeto, certifique-se de que a API Monitoring está ativada:

      1. Aceda a APIs e serviços:

        Aceda a APIs e serviços

      2. Selecione o seu projeto.

      3. Clique em Ativar APIs e serviços.

      4. Pesquise "Monitorização".

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

      6. Se não for apresentado "API ativada", clique no botão Ativar.

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

Também precisa das seguintes ferramentas de linha de comandos:

  • gcloud
  • kubectl

As ferramentas gcloud e kubectl fazem parte da CLI gcloud do Google Cloud. Para obter informações sobre a instalação destes componentes, consulte o artigo Faça a gestão dos componentes da CLI gcloud. Para ver os componentes da CLI gcloud que instalou, execute o seguinte comando:

gcloud components list

Configure o seu ambiente

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

  • Configure as ferramentas de linha de comandos da seguinte forma:

    • Configure a CLI gcloud para fazer referência ao ID do seu Google Cloud projeto:

      gcloud config set project PROJECT_ID

    • Configure a CLI kubectl para usar o seu cluster:

      kubectl config set-cluster CLUSTER_NAME

    Para mais informações sobre estas ferramentas, consulte o seguinte:

Configure um espaço de nomes

Crie o espaço de nomes do Kubernetes NAMESPACE_NAME para os recursos que criar como parte da aplicação de exemplo:

kubectl create ns NAMESPACE_NAME

Valide as credenciais da conta de serviço

Se o seu cluster do Kubernetes tiver a federação de identidade da carga de trabalho para o GKE ativada, pode ignorar esta secção.

Quando executado no GKE, o Managed Service for Prometheus obtém automaticamente as credenciais do ambiente com base na conta de serviço predefinida do Compute Engine. A conta de serviço predefinida tem as autorizações necessárias, monitoring.metricWriter e monitoring.viewer, por predefinição. Se não usar a Workload Identity Federation para o GKE e tiver removido anteriormente uma dessas funções da conta de serviço do nó predefinida, tem de readicionar essas autorizações em falta antes de continuar.

Configure uma conta de serviço para a federação de identidades da carga de trabalho para o GKE

Se o seu cluster do Kubernetes não tiver a Workload Identity Federation para o GKE ativada, pode ignorar esta secção.

O Managed Service for Prometheus captura dados de métricas através da API Cloud Monitoring. Se o seu cluster estiver a usar a Workload Identity Federation para o GKE, tem de conceder autorização à sua conta de serviço do Kubernetes para a API Monitoring. Esta secção descreve o seguinte:

Crie e associe a conta de serviço

Este passo aparece em vários locais na documentação do Managed Service for Prometheus. Se já realizou este passo como parte de uma tarefa anterior, não precisa de o repetir. Avance para a secção Autorize a conta de serviço.

A seguinte sequência de comandos cria a conta de serviço gmp-test-sa e associa-a à conta de serviço Kubernetes predefinida no espaço de nomes NAMESPACE_NAME:

gcloud config set project PROJECT_ID \
&&
gcloud iam service-accounts create gmp-test-sa \
&&
gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE_NAME/default]" \
  gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
&&
kubectl annotate serviceaccount \
  --namespace NAMESPACE_NAME \
  default \
  iam.gke.io/gcp-service-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

Se estiver a usar um espaço de nomes ou uma conta de serviço do GKE diferente, ajuste os comandos adequadamente.

Autorize a conta de serviço

Os grupos de autorizações relacionadas são recolhidos em funções e concede as funções a um principal, neste exemplo, a Google Cloud conta de serviço. Para mais informações sobre as funções de monitorização, consulte o artigo Controlo de acesso.

O comando seguinte concede à Google Cloud conta de serviçogmp-test-sa as funções da API Monitoring de que precisa para escrever dados de métricas.

Se já tiver concedido à Google Cloud conta de serviço uma função específica como parte de uma tarefa anterior, não tem de o fazer novamente.

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

Depure a configuração da federação de identidades de cargas de trabalho para o GKE

Se tiver problemas com a federação de identidade da carga de trabalho para o GKE, consulte a documentação para validar a configuração da federação de identidade da carga de trabalho para o GKE e o guia de resolução de problemas da federação de identidade da carga de trabalho para o GKE.

Uma vez que os erros ortográficos e as operações de copiar e colar parciais são as origens mais comuns de erros ao configurar a Workload Identity Federation para o GKE, recomendamos vivamente que use as variáveis editáveis e os ícones de copiar e colar clicáveis incorporados nos exemplos de código nestas instruções.

Workload Identity Federation para o GKE em ambientes de produção

O exemplo descrito neste documento associa a conta de serviço à conta de serviço predefinida do Kubernetes e concede à conta de serviço todas as autorizações necessárias para usar a API Monitoring. Google Cloud Google Cloud

Num ambiente de produção, pode querer usar uma abordagem mais detalhada, com uma conta de serviço para cada componente, cada uma com autorizações mínimas. Para mais informações sobre a configuração de contas de serviço para a gestão de identidades da carga de trabalho, consulte o artigo Usar a federação de identidades da carga de trabalho para o GKE.

Configure a recolha implementada autonomamente

Esta secção descreve como configurar e executar uma aplicação de exemplo que usa a recolha implementada automaticamente.

Implemente a aplicação de exemplo

A aplicação 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 da aplicação define três réplicas.

Para implementar a aplicação de exemplo, execute o seguinte comando:

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

Execute o ficheiro binário do Prometheus de substituição

Para carregar os dados de métricas emitidos pela aplicação de exemplo, implementa a versão bifurcada do servidor Prometheus da Google, que está configurada para extrair as métricas da carga de trabalho, bem como o respetivo ponto final de métricas.

  1. Para implementar o servidor bifurcado, execute o seguinte comando:

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

    Este servidor Prometheus implementado é uma ramificação simples do ficheiro binário Prometheus a montante. Comporta-se como um servidor Prometheus padrão, mas também introduz dados no serviço gerido para Prometheus.

    O manifesto acima fornece um exemplo de funcionamento básico que envia dados para o armazenamento de dados global, o Monarch. Não armazena persistentemente uma cópia local dos dados. Para informações sobre como esta configuração predefinida funciona e como a expandir, consulte a documentação de configuração do Prometheus de código aberto.

    A imagem pré-criada só funciona em nós Linux. Para extrair dados de destinos em execução em nós Windows, implemente o servidor num nó Linux e configure-o para extrair dados de pontos finais nos nós Windows ou crie o ficheiro binário para Windows.

  2. Verifique se os pods do servidor Prometheus e da aplicação de exemplo foram implementados com êxito:

    kubectl -n NAMESPACE_NAME get pod

    Se a implementação tiver sido bem-sucedida, vê um resultado semelhante ao seguinte:

    NAME                            READY   STATUS    RESTARTS   AGE
prom-example-84c6f547f5-fglbr   1/1     Running   0          5m
prom-example-84c6f547f5-jnjp4   1/1     Running   0          5m
prom-example-84c6f547f5-sqdww   1/1     Running   0          5m
prometheus-test-0               2/2     Running   1          3m

Se estiver a usar o GKE, pode fazer o seguinte:

Se estiver a executar fora do GKE, tem de criar uma conta de serviço e autorizá-la a escrever os dados das métricas, conforme descrito na secção seguinte.

Forneça credenciais explicitamente

Quando executado no GKE, o servidor Prometheus de recolha obtém automaticamente as credenciais do ambiente com base na conta de serviço do nó ou na federação de identidades da carga de trabalho para a configuração do GKE. Em clusters Kubernetes não GKE, as credenciais têm de ser fornecidas explicitamente ao servidor Prometheus de recolha através de flags ou da variável de ambiente GOOGLE_APPLICATION_CREDENTIALS.

  1. Defina o contexto para o projeto de destino:

    gcloud config set project PROJECT_ID

  2. Crie uma conta de serviço:

    gcloud iam service-accounts create gmp-test-sa

    Este passo cria a conta de serviço que pode já ter criado nas instruções da federação de identidades da carga de trabalho para o GKE.

  3. Conceda as autorizaçõ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 transfira 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 ficheiro de chave como um segredo ao seu cluster não GKE:

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

  6. Abra o recurso StatefulSet do Prometheus para edição:

    kubectl -n NAMESPACE_NAME edit statefulset prometheus-test

    1. Adicione o texto apresentado em negrito ao recurso:

      apiVersion: apps/v1
kind: StatefulSet
metadata:
  namespace: NAMESPACE_NAME
  name: example
spec:
  template
    containers:
    - name: prometheus
      args:
      - --export.credentials-file=/gmp/key.json
...
      volumeMounts:
      - name: gmp-sa
        mountPath: /gmp
        readOnly: true
...
    volumes:
    - name: gmp-sa
      secret:
        secretName: gmp-test-sa
...

    2. Guarde o ficheiro e feche o editor. Após a aplicação da alteração, os pods são recriados e começam a autenticar-se no back-end de métricas com a conta de serviço fornecida.

    Em alternativa, em vez de usar as flags definidas neste exemplo, pode definir o caminho do ficheiro de chave usando a GOOGLE_APPLICATION_CREDENTIALSvariável de ambiente.

    Tópicos adicionais para a recolha implementada autonomamente

    Esta secção descreve como fazer o seguinte:

    • Filtre os dados que exporta para o serviço gerido.
    • Converta as suas configurações de implementação existentes.
    • Execute o ficheiro binário do Prometheus no modo de alta disponibilidade.
    • Crie e execute o ficheiro binário do Prometheus de substituição.
    • Execute o Managed Service for Prometheus fora do Google Cloud.

    Filtre métricas exportadas

    Se recolher muitos dados, pode querer impedir que algumas séries cronológicas sejam enviadas para o Managed Service for Prometheus para manter os custos baixos.

    Pode usar configurações de reetiquetagem de métricas normais na configuração de extração de dados do Prometheus. Com as configurações de reetiquetagem, pode eliminar métricas com base em correspondências de etiquetas no momento do carregamento.

    Por vezes, pode querer carregar dados localmente, mas não exportá-los para o Managed Service for Prometheus. Para filtrar métricas exportadas, pode usar a flag --export.match.

    A flag especifica um ou mais seletores de séries PromQL e pode ser usada várias vezes. Uma série cronológica é exportada para o Managed Service for Prometheus se satisfizer todos os seletores em, pelo menos, uma das flags. Ou seja, ao determinar a elegibilidade, as condições numa única flag são unidas por um operador E, enquanto as condições em flags separadas são unidas por um operador OU. O exemplo seguinte usa duas instâncias da flag:

    ./prometheus \
  --export.match='{job="prometheus"}' \
  --export.match='{__name__=~"job:.+"}' \
  ...

    Esta alteração faz com que apenas as métricas para a tarefa "prometheus" e as métricas produzidas por regras de gravação que agregam ao nível da tarefa (quando seguem as práticas recomendadas de nomenclatura) sejam exportadas. As amostras de todas as outras séries são filtradas. Por predefinição, não são especificados seletores e todas as séries cronológicas são exportadas.

    A flag --export.match tem a mesma semântica que o parâmetro match[] para a federação do Prometheus. Por conseguinte, pode migrar as configurações de federação para o Managed Service for Prometheus usando os seletores do servidor de federação diretamente como flags nos servidores Prometheus recolhidos pelo servidor Prometheus de federação. A exportação de métricas de um servidor de federação para o serviço gerido não é suportada.

    Para incluir métricas do tipo histogramnum filtro, tem de especificar as métricas _count, _sum e _bucket. Também pode fazê-lo com um correspondente de carateres universais, por exemplo, o seletor {__name__=~"histogram_metric_.+"}.

    Se estiver a usar a biblioteca prometheus-operator, defina quaisquer flags --export.match através da variável de ambiente EXTRA_ARGS do contentor. Para mais informações, consulte o artigo Use com o prometheus-operator.

    Pode combinar flags de filtros com regras de gravação executadas localmente para "acumular" dados antes de os enviar para o Monarch, reduzindo a cardinalidade e o custo. Para mais informações, consulte o artigo Controlos de custos e atribuição.

    A página Gestão de métricas do Cloud Monitoring fornece informações que podem ajudar a controlar o valor gasto em métricas faturáveis sem afetar a observabilidade. A página Gestão de métricas apresenta as seguintes informações:

    • Volumes de carregamento para a faturação baseada em bytes e em amostras, em domínios de métricas e para métricas individuais.
    • Dados sobre as etiquetas e a cardinalidade das métricas.
    • Número de leituras para cada métrica.
    • Utilização de métricas em políticas de alerta e painéis de controlo personalizados.
    • Taxa de erros de escrita de métricas.

    Também pode usar a página Gestão de métricas para excluir métricas desnecessárias, eliminando o custo da respetiva ingestão. Para mais informações sobre a página Gestão de métricas, consulte o artigo Veja e faça a gestão da utilização de métricas.

    Use com o prometheus-operator

    O binário do Prometheus do Managed Service for Prometheus também pode ser usado com uma implementação do Prometheus do GKE existente gerida pelo prometheus-operator.

    Para usar o ficheiro binário do serviço gerido, substitua a especificação da imagem no recurso do Prometheus:

      apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    name: NAMESPACE_NAME
    namespace: gmp-system
  spec:
    image: gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1
    ...
    replicas: 1
    serviceAccountName: default
    version: v2.35.0
    ...

    Se estiver numa federação de identidades da carga de trabalho para o cluster do GKE e o espaço de nomes ou a conta de serviço no seu recurso for diferente, repita as instruções da federação de identidades da carga de trabalho para o GKE para o espaço de nomes adicional e o par de contas de serviço do Kubernetes.

    Quando executado num cluster do Kubernetes não GKE, tem de fornecer credenciais manualmente. Para fornecer credenciais, faça o seguinte:

    1. Adicione um ficheiro de chave de conta de serviço adequado como segredo, conforme descrito em Forneça credenciais explicitamente.

    2. Modifique o recurso Prometheus para adicionar o texto apresentado em negrito:

        apiVersion: monitoring.coreos.com/v1
  kind: Prometheus
  metadata:
    namespace: NAMESPACE_NAME
    name: example
  spec:
    ...
    secrets:
    - gmp-test-sa
    containers:
    - name: prometheus
      env:
      - name: GOOGLE_APPLICATION_CREDENTIALS
        value: /gmp/key.json
      volumeMounts:
      - name: secret-gmp-test-sa
        mountPath: /gmp
        readOnly: true

    Pode definir a variável de ambiente EXTRA_ARGS do contentor para adicionar flags adicionais, como as flags de filtragem de métricas. Isto é feito através de uma variável de ambiente, porque a secção args da especificação do contentor é gerida pelo operador do Prometheus.

    Use com o kube-prometheus

    Pode configurar implementações criadas com a popular biblioteca kube-prometheus para usar o serviço gerido para Prometheus.

    O Kube-prometheus tem algumas dependências internas rigorosas nos respetivos espaços de nomes e contas de serviço predefinidos, pelo que recomendamos que altere apenas o número mínimo de campos necessários para enviar dados para o Managed Service for Prometheus.

    Em manifests/prometheus-prometheus.yaml, substitua a especificação da imagem e desative a recolha de alta disponibilidade reduzindo replicas para 1:

        apiVersion: monitoring.coreos.com/v1
    kind: Prometheus
    ...
    spec:
      image: gke.gcr.io/prometheus-engine/prometheus:v2.53.4-gmp.0-gke.1
      ...
      replicas: 1
      version: v2.35.0
      ...

    Se estiver a executar o GKE e não tiver modificado a conta de serviço predefinida no nó, a aplicação dos manifestos modificados deve começar imediatamente a enviar dados para o Managed Service for Prometheus. Caso contrário, pode ter de configurar e aplicar uma conta de serviço. Quando executar o comando no GKE e usar a identidade da carga de trabalho, pode ter de criar e autorizar a conta de serviço prometheus-k8s no espaço de nomes monitoring. Quando executado num cluster do Kubernetes que não seja do GKE, siga as instruções na secção do operador do Prometheus.

    Tenha em atenção que o kube-prometheus recolhe muitas métricas por predefinição, a maioria das quais não são frequentemente necessárias num ambiente Kubernetes gerido, como o GKE. Para poupar nos custos de carregamento, pode personalizar o kube-prometheus para que extraia apenas as métricas que lhe interessam e filtre as métricas exportadas de forma agressiva.

    Para mais sugestões, consulte o artigo Controlos de custos e atribuição.

    Implementação de alta disponibilidade

    O ficheiro binário do Prometheus de substituição inclui suporte incorporado para recolha de alta disponibilidade através da eleição de líder. Os servidores Prometheus replicados no modo de alta disponibilidade recolhem métricas e avaliam regras como habitualmente, mas apenas um deles envia dados para o Google Cloud Managed Service for Prometheus.

    As réplicas do mesmo servidor Prometheus têm de ter sempre configurações idênticas, incluindo o mesmo external_labels. Este requisito difere de outros sistemas, que dependem de uma etiqueta externa especial, como __replica__, para tornar as réplicas explicitamente diferentes.

    O servidor da API Kubernetes é um back-end de eleição de líder suportado e pode ser ativado definindo as seguintes flags:

    ./prometheus
  ...
  --export.ha.backend=kube \
  --export.ha.kube.namespace=LEASE_NAMESPACE \
  --export.ha.kube.name=LEASE_NAME

    Os valores LEASE_NAMESPACE e LEASE_NAME identificam o recurso de concessão através do qual a eleição de líder tem lugar. Todos os servidores Prometheus que apontam para o mesmo recurso pertencem ao mesmo conjunto de réplicas. A conta de serviço do Kubernetes da implementação do Prometheus precisa de autorização para ler e escrever o recurso de concessão respetivo. Quando executa o servidor Prometheus fora de um cluster do Kubernetes, pode fornecer uma configuração explícita através da flag --export.ha.kube.config.

    Depois de o fazer, pode aumentar o valor replicas para 2 ou mais.

    Etiquetas reservadas

    O serviço gerido para Prometheus usa seis etiquetas reservadas para identificar exclusivamente um recurso no Monarch:

    • project_id: o identificador do projeto Google Cloud associado à sua métrica. Obrigatório.
    • location: a localização física (Google Cloud região) onde os dados são armazenados. Este valor é normalmente a região do seu cluster do GKE. Se os dados forem recolhidos a partir de uma implementação local ou da AWS, o valor pode ser a região Google Cloud mais próxima. Obrigatório.
    • cluster: o nome do cluster do Kubernetes associado à sua métrica. Se não estiver a ser executado no Kubernetes, pode ser usado como um nível de hierarquia arbitrário, como um grupo de instâncias. Opcional, mas vivamente recomendado.
    • namespace: o nome do espaço de nomes do Kubernetes associado à sua métrica. Se não estiver a ser executado no Kubernetes, pode ser usado como um nível de hierarquia arbitrário, como um subgrupo de instâncias. Opcional, mas vivamente recomendado.
    • job: a etiqueta de tarefa do destino do Prometheus, se for conhecida; pode estar vazia para resultados de avaliação de regras. Obrigatório e normalmente adicionado automaticamente pelo Prometheus.
    • instance: a etiqueta de instância do destino do Prometheus, se for conhecida; pode estar vazia para resultados de avaliação de regras. Obrigatório e normalmente adicionado automaticamente pelo Prometheus. Se forem definidos ou reetiquetados manualmente, não use valores codificados, como localhost, uma vez que tal provoca colisões de séries cronológicas.

    Quando executado no Google Cloud, as etiquetas project_id, location e cluster são adicionadas automaticamente a todas as métricas.

    Embora não seja recomendado quando executado no Google Cloud, pode substituir as etiquetas project_id, location, cluster e namespace através da secção global.external_labels da configuração do Prometheus. Para mais informações, consulte o artigo Execute a recolha implementada automaticamente fora do Google Cloud.

    Se usar quaisquer etiquetas reservadas como etiquetas de métricas, a recolha implementada automaticamente usa a etiqueta de métrica como o valor da etiqueta reservada. Isto pode oferecer alguma flexibilidade, mas também pode originar erros se, por exemplo, usar a etiqueta location para se referir a algo que não seja umaGoogle Cloud região.

    Configure o statsd_exporter e outros exportadores que comunicam métricas de forma centralizada

    Se usar o statsd_exporter para o Prometheus, o Envoy para o Istio, o SNMP exporter, o Prometheus Pushgateway, o kube-state-metrics ou tiver um exportador semelhante que intermedeia e comunica métricas em nome de outros recursos em execução no seu ambiente, tem de fazer algumas pequenas alterações para que o exportador funcione com o Managed Service for Prometheus.

    Para ver instruções sobre como configurar estes exportadores, consulte esta nota na secção Resolução de problemas.

    Implementações binárias

    Se quiser executar num ambiente não contentorizado, pode criar o ficheiro binário do Prometheus de substituição diretamente.

    Criar a origem

    Se tiver um processo existente para compilar o Prometheus, pode substituir de forma transparente o nosso repositório do GitHub no seu processo. O Managed Service for Prometheus tem a sua própria extensão de etiqueta de versão para distinguir os seus lançamentos dos lançamentos a montante.

    Para criar o binário simples, a cadeia de ferramentas Go e as versões recentes do NPM/Yarn têm de estar instaladas no computador. Para mais informações, consulte as instruções de compilação a montante.

    1. Clone o repositório:

      git clone https://github.com/GoogleCloudPlatform/prometheus &&
cd prometheus

    2. Verifique a etiqueta da versão pretendida:

      git checkout v2.53.4-gmp.0

    3. Para criar um ficheiro tar.gz do Managed Service for Prometheus, execute os seguintes comandos:

      make build && make tarball

    O ficheiro TAR.GZ e os binários resultantes são totalmente compatíveis com as respetivas variantes upstream em termos de estrutura de diretórios e funcionalidade.

    Limites na criação e atualização de métricas e etiquetas

    O Managed Service for Prometheus aplica um limite de taxa por minuto à criação de novas métricas e à adição de novas etiquetas de métricas a métricas existentes. Este limite de taxa é normalmente atingido apenas quando se faz a primeira integração com o Managed Service for Prometheus, por exemplo, quando migra uma implementação do Prometheus existente e desenvolvida para usar a recolha implementada automaticamente. Isto não é um limite de taxa para a introdução de pontos de dados. Este limite de taxa só se aplica quando cria métricas nunca antes vistas ou quando adiciona novas etiquetas a métricas existentes.

    Esta quota é fixa, mas quaisquer problemas devem ser resolvidos automaticamente à medida que são criadas novas métricas e etiquetas de métricas até ao limite por minuto.

    Para mais informações, consulte o artigo Resolução de problemas.

    Execute a recolha implementada automaticamente fora do Google Cloud

    Em ambientes do Compute Engine, ambientes do GKE ou numa máquina onde executou o gcloud login com uma conta suficientemente autorizada, pode executar a recolha implementada automaticamente sem configuração adicional. Fora do Google Cloud, tem de fornecer explicitamente credenciais, um project_id para conter as suas métricas e uma location (Google Cloud região) para armazenar as suas métricas. Também deve definir as etiquetas cluster e namespace, mesmo que esteja a ser executado num ambiente não Kubernetes.

    Pode fornecer uma chave da conta de serviço através da flag --export.credentials-file ou da variável de ambiente GOOGLE_APPLICATION_CREDENTIALS, conforme descrito no artigo Forneça credenciais explicitamente.

    Recomendamos que escolha project_id com base no modelo de arrendamento planeado para leituras. Escolha um projeto para armazenar métricas com base na forma como planeia organizar as leituras mais tarde com âmbitos de métricas. Se não se importar, pode colocar tudo num único projeto.

    Para location, recomendamos que escolha a região mais próxima da sua implementação Google Cloud . Quanto mais distante estiver a Google Cloud região escolhida da sua implementação,0x0A>maior será a latência de escrita e mais será afetado por potenciais problemas de rede. Recomendamos que consulte esta lista de regiões em várias nuvens. Se não tiver interesse, pode colocar tudo numa única Google Cloud região. Não pode usar global como a sua localização.

    Se estiver a ser executado num ambiente do Kubernetes, defina os valores cluster e namespace para o cluster e o espaço de nomes locais. Se estiver a executar fora do Kubernetes, defina-os para valores que façam sentido hierarquicamente. Por exemplo, num ambiente baseado em VM em execução no AWS, defina o valor cluster como __aws__ e o valor namespace como o ID da instância. Pode preencher dinamicamente o ID da instância através de uma regra de reetiquetagem que chama o servidor de metadados local.

    Para um exemplo de funcionamento mínimo, pode executar um ficheiro binário do Prometheus de monitorização automática local com o seguinte comando:

    ./prometheus \
  --config.file=documentation/examples/prometheus.yaml \
  --export.label.project-id=PROJECT_ID \
  --export.label.location=REGION \
  --export.label.cluster=CLUSTER_NAME \

    Este exemplo pressupõe que definiu a variável REGION para um valor como us-central1, por exemplo.

    No entanto, recomendamos que defina as export etiquetas de destino para o serviço gerido na secção global.external_labels da configuração do Prometheus. Por exemplo, em ambientes do Kubernetes, pode usar a seguinte configuração:

    global:
  external_labels:
    project_id: PROJECT_ID
    location: REGION
    cluster: CLUSTER_NAME
    namespace: local-testing

scrape_configs:
  ...

    A execução do Managed Service for Prometheus fora do Google Cloud incorre em taxas de transferência de dados. Existem taxas para transferir dados para o Google Cloude pode incorrer em taxas para transferir dados de outra nuvem. Pode minimizar este custo ativando a compressão com a flag --export.compression=gzip.

    O que se segue?