O arquivo secundário do Managed Service para Prometheus do Cloud Run é a maneira recomendada pelo Google para receber monitoramento no estilo do Prometheus para serviços do Cloud Run. Se o serviço do Cloud Run gravar métricas do OTLP, use o arquivo secundário do OpenTelemetry. No entanto, para serviços que gravam métricas do Prometheus, use o arquivo secundário do Managed Service para Prometheus descrito neste documento.
Este documento explica como fazer o seguinte:
- Adicione o arquivo secundário do Managed Service para Prometheus a um serviço atual do Cloud Run.
- Crie um app de exemplo com o arquivo secundário. É possível usar o app de exemplo para ver como o arquivo secundário funciona se você não tiver um serviço do Cloud Run.
O arquivo secundário usa o Google Cloud Managed Service para Prometheus no lado do servidor e uma distribuição do OpenTelemetry Collector, personalizado para cargas de trabalho sem servidor, no lado do cliente. Essa distribuição personalizada inclui algumas alterações para oferecer suporte ao Cloud Run. O coletor executa uma raspagem de dados de inicialização após 10 segundos e de encerramento, não importa a duração da instância. Para máxima confiabilidade, recomendamos que os serviços do Cloud Run que executam o arquivo secundário também usem uma CPU sempre alocada. Para mais informações, consulte Alocação de CPU (serviços). Algumas tentativas de raspagem poderão falhar se a alocação da CPU for limitada devido ao baixo número de consultas por segundo (QPS). Uma CPU sempre alocada permanece disponível.
O arquivo secundário depende do recurso de vários contêineres (arquivo secundário) do Cloud Run para executar o coletor como um contêiner de arquivo secundário junto com o contêiner de carga de trabalho. Para mais informações sobre arquivos secundários no Cloud Run, consulte Como implantar vários contêineres em um serviço (arquivos secundários).
O arquivo secundário do Managed Service para Prometheus para Cloud Run apresenta uma nova configuração,
RunMonitoring, um subconjunto do recurso personalizado
PodMonitoring do
Kubernetes. A maioria dos usuários pode usar a configuração RunMonitoring
padrão, mas também é possível criar configurações personalizadas. Para mais
informações sobre as configurações RunMonitoring padrão e personalizadas, consulte Adicionar o arquivo secundário a um serviço do
Cloud Run.
Antes de começar
Esta seção descreve a configuração necessária para usar este documento.
Instalar e configurar a gcloud CLI
Muitas das etapas descritas neste documento usam a Google Cloud CLI. Para informações sobre como instalar a CLI gcloud, consulte Como gerenciar componentes da CLI do Google Cloud.
Ao invocar comandos gcloud, especifique o identificador para seu projeto do Google Cloud. É possível definir um projeto padrão para a
Google Cloud CLI e eliminar a necessidade de inseri-lo com todos os comandos.
Para definir seu projeto como padrão, digite este comando:
gcloud config set project PROJECT_ID
Também é possível definir uma região padrão para o serviço do Cloud Run. Para definir uma região padrão, digite o seguinte comando:
gcloud config set run/region REGION
Ativar APIs
Ative as seguintes APIs no seu projeto do Google Cloud:
- API Cloud Run Admin:
run.googleapis.com - API Artifact Registry:
artifactregistry.googleapis.com - API Cloud Monitoring:
monitoring.googleapis.com - API Cloud Logging:
logging.googleapis.com - (Opcional) Se você criar uma configuração
RunMonitoringpersonalizada, será necessário ativar a API Secret Manager:secretmanager.googleapis.com - (Opcional) Se você executar o aplicativo de amostra usando o Cloud Build,
também será necessário ativar as seguintes APIs:
- API Cloud Build:
cloudbuild.googleapis.com - API Identity and Access Management:
iam.googleapis.comPara saber mais, consulte Criar e executar o app de exemplo.
- API Cloud Build:
Para conferir as APIs ativadas no seu projeto, execute o seguinte comando:
gcloud services list
Para ativar uma API que não está ativada, execute um dos seguintes comandos:
gcloud services enable run.googleapis.com gcloud services enable artifactregistry.googleapis.com gcloud services enable secretmanager.googleapis.com gcloud services enable monitoring.googleapis.com gcloud services enable logging.googleapis.com gcloud services enable cloudbuild.googleapis.com gcloud services enable iam.googleapis.com
Conta de serviço do Cloud Run
Por padrão, os jobs e serviços do Cloud Run usam a
conta de serviço padrão do Compute Engine,
PROJECT_NUMBER-compute@developer.gserviceaccount.com.
Essa conta de serviço geralmente tem os papéis do Identity and Access Management (IAM)
necessários para gravar as métricas e os registros descritos neste documento:
roles/monitoring.metricWriterroles/logging.logWriter
Se você criar uma configuração RunMonitoring personalizada,
sua conta de serviço também precisará ter os seguintes papéis:
roles/secretmanager.adminroles/secretmanager.secretAccessor
Também é possível configurar uma conta de serviço gerenciada pelo usuário para o Cloud Run. Uma conta de serviço gerenciada pelo usuário também precisa ter esses papéis. Para mais informações sobre contas de serviço do Cloud Run, consulte Como configurar a identidade do serviço.
Configurar e adicionar o arquivo secundário a um serviço do Cloud Run
O arquivo secundário do Managed Service para Prometheus do Cloud Run apresenta uma nova configuração,
RunMonitoring, que é um subconjunto do recurso personalizado
PodMonitoring do
Kubernetes. A configuração RunMonitoring usa as opções
PodMonitoring existentes para oferecer suporte ao Cloud Run
e eliminar algumas opções específicas do Kubernetes.
É possível usar a configuração RunMonitoring padrão ou
criar uma configuração personalizada. As seções abaixo descrevem as duas
abordagens. Não é necessário fazer as duas. Para mais informações sobre como usar
configurações padrão ou personalizadas, selecione a guia correspondente.
Configuração padrão
Usar a configuração padrão do RunMonitoring
Se você não criar uma configuração RunMonitoring personalizada,
o coletor do arquivo secundário sintetiza a seguinte configuração padrão
para capturar caminhos de métricas /metrics da porta 8080 a cada 30 segundos:
apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
name: run-gmp-sidecar
spec:
endpoints:
- port: 8080
path: /metrics
interval: 30s
Para usar a configuração padrão, nenhuma outra configuração é necessária além de adicionar o arquivo secundário ao serviço do Cloud Run.
Adicionar o arquivo secundário a um serviço do Cloud Run
Para usar o arquivo secundário com a configuração RunMonitoring
padrão, modifique a configuração atual do Cloud Run
para adicionar o arquivo secundário. Para adicionar o arquivo secundário, faça o seguinte:
- Adicione uma anotação de dependência de contêiner que especifique a ordem de inicialização e encerramento dos contêineres. No exemplo a seguir, o contêiner do arquivo secundário, chamado "collector", começa depois e é desligado antes do contêiner do aplicativo, chamado "app".
- Crie um contêiner para o coletor, chamado "collector" no exemplo a seguir.
Por exemplo, adicione as linhas precedidas pelo caractere + (mais) à
configuração do Cloud Run e reimplante o serviço:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
annotations:
run.googleapis.com/launch-stage: ALPHA
run.googleapis.com/cpu-throttling: 'false'
name: my-cloud-run-service
spec:
template:
metadata:
annotations:
run.googleapis.com/execution-environment: gen2
+ run.googleapis.com/container-dependencies: '{"collector":["app"]}'
spec:
containers:
- image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
name: app
startupProbe:
httpGet:
path: /startup
port: 8000
livenessProbe:
httpGet:
path: /liveness
port: 8000
ports:
- containerPort: 8000
+ - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.2.0"
+ name: collector
Para reimplantar o serviço do Cloud Run com o arquivo de configuração
run-service.yaml, execute o seguinte comando:
gcloud run services replace run-service.yaml --region=REGION
Configuração personalizada
Criar uma configuração personalizada do RunMonitoring
É possível criar uma configuração RunMonitoring para um
serviço do Cloud Run se a configuração padrão não for suficiente.
Por exemplo, você pode criar um conjunto de dados como este:
apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
name: my-custom-cloud-run-job
spec:
endpoints:
- port: 8080
path: /metrics
interval: 10s
metricRelabeling:
- action: replace
sourceLabels:
- __address__
targetLabel: label_key
replacement: label_value
targetLabels:
metadata:
- service
- revision
Essa configuração faz o seguinte:
- Coleta métricas da porta 8080 e usa o caminho de métricas padrão
/metrics. - Usa um intervalo de raspagem de dados de 10 segundos.
- Usa a nova rotulação para adicionar o rótulo
label_keycom o valorlabel_valuea cada métrica coletada. - Adiciona os rótulos de metadados
serviceerevisiona cada métrica coletada.
Para informações sobre as opções de configuração disponíveis, consulte Especificação do RunMonitoring: opções de configuração.
Quando você usa uma configuração RunMonitoring personalizada, é necessário
executar a seguinte configuração extra:
- Ative a API Secret Manager e conceda à sua conta de serviço do Cloud Run papéis do Secret Manager. Para mais informações, consulte Antes de começar.
- Armazene a configuração personalizada como um secret.
- Adicione o arquivo secundário a um serviço do Cloud Run.
Armazenar a configuração usando o Secret Manager
Para fornecer uma configuração RunMonitoring personalizada, faça o seguinte:
- Crie um arquivo com a configuração personalizada.
- Crie um secret do Secret Manager que contenha a configuração personalizada.
O comando a seguir cria um secret chamado mysecret a partir do
arquivo custom-config.yaml:
gcloud secrets create mysecret --data-file=custom-config.yaml
Para aplicar uma alteração na configuração depois de modificar o arquivo custom-config.yaml, é necessário excluir e recriar o secret e, em seguida, reimplantar o serviço do Cloud Run.
Como atualizar a configuração no Secret Manager
Se você quiser atualizar a configuração RunMonitoring personalizada a qualquer
momento, adicione uma nova versão do secret ao
Secret Manager.
Por exemplo, para atualizar mysecret com uma nova configuração armazenada no arquivo custom-config-updated.yaml, execute:
gcloud secrets versions add mysecret --data-file=custom-config-updated.yaml
O arquivo secundário recarrega automaticamente e aplica as alterações à própria configuração.
Adicionar o arquivo secundário a um serviço do Cloud Run
Depois de criar um secret do Secret Manager para sua
configuração RunMonitoring, modifique a
configuração do Cloud Run para fazer o seguinte:
- Adicione o arquivo secundário do Managed Service para Prometheus
- Adicione uma anotação de dependência de contêiner que especifique a ordem de inicialização e encerramento dos contêineres. No exemplo a seguir, o contêiner do arquivo secundário, chamado "collector", começa depois e é desligado antes do contêiner do aplicativo, chamado "app".
- Crie um contêiner para o coletor, chamado "collector" no exemplo a seguir.
- Adicione o secret montando-o no local
/etc/rungmp/config.yaml:- Adicione uma anotação de secrets que aponte para o secret que contém sua
configuração
RunMonitoringpersonalizada. - Crie um volume, chamado "config" no exemplo a seguir, para o secret
que aponta para o arquivo
config.yaml. - Monte o volume como parte da imagem do coletor no caminho de ativação
/etc/rungmp.
- Adicione uma anotação de secrets que aponte para o secret que contém sua
configuração
Por exemplo, adicione as linhas precedidas pelo caractere + (mais) à
configuração do Cloud Run e reimplante o serviço:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
annotations:
run.googleapis.com/launch-stage: ALPHA
run.googleapis.com/cpu-throttling: 'false'
name: my-cloud-run-service
spec:
template:
metadata:
annotations:
run.googleapis.com/execution-environment: gen2
+ run.googleapis.com/container-dependencies: '{"collector":["app"]}'
+ run.googleapis.com/secrets: 'mysecret:projects/PROJECT_ID/secrets/mysecret'
spec:
containers:
- image: "REGION-docker.pkg.dev/PROJECT_ID/run-gmp/sample-app"
name: app
startupProbe:
httpGet:
path: /startup
port: 8000
livenessProbe:
httpGet:
path: /liveness
port: 8000
ports:
- containerPort: 8000
+ - image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.2.0"
+ name: collector
+ volumeMounts:
+ - mountPath: /etc/rungmp/
+ name: config
+ volumes:
+ - name: config
+ secret:
+ items:
+ - key: latest
+ path: config.yaml
+ secretName: 'mysecret'
Para reimplantar o serviço do Cloud Run com o arquivo de configuração
run-service.yaml, execute o seguinte comando:
gcloud run services replace run-service.yaml --region=REGION
Especificação do RunMonitoring: opções de configuração
Nesta seção, descrevemos a especificação de configuração RunMonitoring para o
arquivo secundário do Managed Service para Prometheus. Confira abaixo um exemplo de configuração personalizada:
apiVersion: monitoring.googleapis.com/v1beta
kind: RunMonitoring
metadata:
name: my-custom-cloud-run-job
spec:
endpoints:
- port: 8080
path: /metrics
interval: 10s
metricRelabeling:
- action: replace
sourceLabels:
- __address__
targetLabel: label_key
replacement: label_value
targetLabels:
metadata:
- service
- revision
RunMonitoring
A configuração RunMonitoring monitora um serviço do Cloud Run.
| Campo | Descrição | Esquema | Obrigatório |
|---|---|---|---|
metadata |
Metadados que todos os recursos persistentes precisam ter. |
metav1.ObjectMeta |
falso |
spec |
Especificação da implantação do Cloud Run selecionada para descoberta de destino pelo Prometheus. | RunMonitoringSpec |
verdadeiro |
RunMonitoringSpec
Esta especificação descreve como a configuração RunMonitoring
monitora um serviço do Cloud Run.
| Campo | Descrição | Esquema | Obrigatório |
|---|---|---|---|
endpoints |
Endpoints a serem raspados nos pods selecionados. | []ScrapeEndpoint |
verdadeiro |
targetLabels |
Rótulos a serem adicionados ao destino do Prometheus para endpoints descobertos.
O rótulo instance é sempre definido como o
ID da instância do Cloud Run. |
RunTargetLabels |
falso |
limits |
Limites a serem aplicados no momento da raspagem dos dados. | *ScrapeLimits |
falso |
RunTargetLabels
A configuração RunTargetLabels permite incluir
rótulos do Cloud Run dos destinos descobertos do Prometheus.
| Campo | Descrição | Esquema | Obrigatório |
|---|---|---|---|
metadata |
Rótulos de metadados do Cloud Run
definidos em todos os destinos raspados. As chaves permitidas são instance, revision,
service e configuration.Se as chaves permitidas forem definidas, o arquivo secundário adicionará o valor correspondente da instância do Cloud Run como rótulos a cada métrica: instanceID, revision_name, service_name e
configuration_name.O padrão é todas as chaves permitidas definidas. |
*[]string |
falso |
Criar e executar um app de exemplo
Nesta seção, descrevemos como executar o arquivo secundário do Managed Service para Prometheus com um app de exemplo. Esta seção é opcional. Se você já tiver um serviço do Cloud Run e quiser implantar o arquivo secundário com ele, consulte Adicionar o arquivo secundário do Managed Service para Prometheus a um serviço do Cloud Run.
Clone o repositório run-gmp-sidecar
Para conseguir o app de exemplo e os arquivos de configuração dele, clone o repositório run-gmp-sidecar
executando o seguinte comando:
git clone https://github.com/GoogleCloudPlatform/run-gmp-sidecar/
Depois de clonar o repositório, mude para o diretório run-gmp-sidecar:
cd run-gmp-sidecar
Criar e executar o app de exemplo
O app de exemplo requer o Docker ou um sistema de build de contêiner semelhante para Linux. Você pode criar e executar o app de amostra de uma das seguintes maneiras:
- Usar o Cloud Build para executar sem suporte local ao Docker. Se você usar o Cloud Build, também precisará ativar a API Cloud Build.
- Crie e execute o app de exemplo manualmente.
As seções a seguir descrevem as duas abordagens. Não é necessário fazer as duas. Para mais informações, selecione a guia de uma das abordagens.
Usar o Cloud Build
Usar o Cloud Build
O repositório run-gmp-sidecar inclui arquivos de configuração para o Cloud Build. Esses arquivos agrupam as etapas necessárias para criar e implantar o app de exemplo.
Também é possível executar manualmente as etapas processadas pelo Cloud Build. Para mais informações, consulte Criar e executar manualmente.
Configurar para o Cloud Build
Esses arquivos de configuração exigem uma conta de serviço do Cloud Build
e um repositório do Artifact Registry. O repositório run-gmp-sidecar também inclui um script create-sa-and-ar.sh, que faz o seguinte:
- Cria uma conta de serviço,
run-gmp-sa@PROJECT_ID.iam.gserviceaccount.com. - Conceda os papéis a seguir à conta de serviço:
roles/iam.serviceAccountUserroles/storage.objectViewerroles/logging.logWriterroles/artifactregistry.createOnPushWriterroles/secretmanager.adminroles/secretmanager.secretAccessorroles/run.admin
- Cria um repositório do Artifact Registry,
run-gmp, para as imagens de contêiner.
Para criar a conta de serviço run-gmp-sa e o repositório run-gmp,
execute o seguinte comando:
./create-sa-and-ar.sh
As permissões levam algum tempo para serem propagadas. Portanto, recomendamos aguardar cerca de 30 segundos antes de prosseguir para a próxima etapa. Caso contrário, talvez apareçam erros de autorização.
Enviar solicitação do Cloud Build
Depois de configurar a conta de serviço run-gmp-sa e o repositório run-gmp, você pode iniciar um job do Cloud Build enviando o
arquivo de configuração do Cloud Build. É possível usar o seguinte comando gcloud builds submit:
gcloud builds submit . --config=cloudbuild-simple.yaml --region=REGION
Esse comando leva alguns minutos para ser executado, mas indica quase imediatamente onde você pode encontrar os detalhes da versão do Cloud Build. A mensagem é semelhante a esta:
Logs are available at [ https://console.cloud.google.com/cloud-build/builds/637860fb-7a14-46f2-861e-09c1dc4cea6b?project=PROJECT_NUMBER].
Para acompanhar o progresso da criação, acesse o URL retornado no seu navegador. Também é possível acessar os registros de arquivos secundários no Cloud Logging.
Verificar o URL do serviço
Depois que o job do Cloud Build terminar, verifique o URL do endpoint do serviço do Cloud Run executando o seguinte comando:
gcloud run services describe my-cloud-run-service --region=REGION --format="value(status.url)"
Esse comando retorna o URL do serviço, que tem a seguinte aparência:
https://my-cloud-run-service-abcdefghij-ue.a.run.app
Use o URL retornado como o valor de SERVICE_URL na seção Verificar se o app está em execução.
Criar e executar manualmente
Criar e executar manualmente
É possível executar manualmente as etapas processadas pelo Cloud Build, descritas em Usar o Cloud Build. As seções a seguir descrevem como executar manualmente as mesmas tarefas.
Definir as variáveis usadas pelas etapas posteriores
Várias das etapas posteriores usam variáveis de ambiente para valores comuns. Configure essas variáveis usando os seguintes comandos:
export GCP_PROJECT=PROJECT_ID export REGION=REGION
Criar um repositório de imagens de contêiner
Crie um repositório do Artifact Registry para a imagem do contêiner executando o seguinte comando:
gcloud artifacts repositories create run-gmp \
--repository-format=docker \
--location=${REGION}
Criar e enviar o app de exemplo
Este exemplo usa o Docker no Linux para criar o app de amostra e enviá-lo para um repositório do Artifact Registry. Talvez seja necessário adaptar esses comandos se você estiver trabalhando em um ambiente Windows ou macOS.
Para criar o app de exemplo e enviá-lo para o Artifact Registry, faça o seguinte:
Autentique o cliente do Docker com a CLI do Google Cloud:
gcloud auth configure-docker ${REGION}-docker.pkg.devAcesse o diretório
simple-appno repositóriorun-gmp-sidecar:pushd sample-apps/simple-app
Crie o app
simple-appexecutando o seguinte comando:docker build -t ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app .Envie a imagem para o app criado executando o seguinte comando:
docker push ${REGION}-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-appRetorne ao diretório
run-gmp-sidecar:popd
Configurar o serviço do Cloud Run
O arquivo run-service-simple.yaml no repositório run-gmp-sidecar define um
serviço do Cloud Run com vários contêineres que usa o app de exemplo e
as imagens do coletor que você criou nas etapas anteriores. O arquivo run-service-simple.yaml contém a seguinte especificação de serviço:
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
annotations:
run.googleapis.com/launch-stage: ALPHA
run.googleapis.com/cpu-throttling: 'false'
name: my-cloud-run-service
spec:
template:
metadata:
annotations:
run.googleapis.com/execution-environment: gen2
run.googleapis.com/container-dependencies: '{"collector":["app"]}'
spec:
containers:
- image: "%SAMPLE_APP_IMAGE%"
name: app
startupProbe:
httpGet:
path: /startup
port: 8000
livenessProbe:
httpGet:
path: /liveness
port: 8000
ports:
- containerPort: 8000
- image: "us-docker.pkg.dev/cloud-ops-agents-artifacts/cloud-run-gmp-sidecar/cloud-run-gmp-sidecar:1.2.0"
name: collector
Esse arquivo contém um valor de marcador para as imagens criadas nas etapas anteriores. Por isso, é necessário atualizar os marcadores com os valores reais do projeto do Google Cloud.
Substitua o marcador %SAMPLE_APP_IMAGE% executando o seguinte comando:
sed -i s@%SAMPLE_APP_IMAGE%@REGION-docker.pkg.dev/${GCP_PROJECT}/run-gmp/sample-app@g run-service-simple.yaml
Implante o serviço do Cloud Run
Depois de atualizar o arquivo run-service-simple.yaml com seus valores, crie e implante o serviço do Cloud Run executando o
seguinte comando:
gcloud run services replace run-service-simple.yaml --region=REGION
Esse comando retorna o URL do serviço, que tem a seguinte aparência:
https://my-cloud-run-service-abcdefghij-ue.a.run.app
Use o URL retornado como o valor de SERVICE_URL na seção Verificar se o app está em execução.
Permitir acesso HTTP não autenticado
Antes de fazer uma solicitação ao URL de serviço, altere a política de serviço do Cloud Run para aceitar o acesso HTTP não autenticado. O arquivo policy.yaml no repositório run-gmp-sidecar
contém a mudança necessária.
Para alterar a política de serviço, execute o seguinte comando:
gcloud run services set-iam-policy my-cloud-run-service policy.yaml --region=REGION
Verifique se o app está em execução:
Para verificar se o serviço do Cloud Run executou corretamente o app de exemplo, use o utilitário curl para acessar o endpoint metrics do serviço.
Defina a variável de ambiente
SERVICE_URLcomo o URL do serviço do Cloud Run da etapa anterior:export SERVICE_URL=SERVICE_URL
Envie uma solicitação ao URL do serviço executando o seguinte comando:
curl $SERVICE_URL
Se o app tiver sido iniciado com sucesso, você verá a seguinte resposta:
User request received!
Visualizar métricas do app no Metrics Explorer
O contêiner de amostra app grava as seguintes métricas:
foo_metric: o horário atual como um valor de ponto flutuante (medidor).bar_metric: o horário atual como um valor de ponto flutuante (contador).
Para visualizar essas métricas no Metrics Explorer, faça o seguinte:
-
No Console do Google Cloud, acesse a página do leaderboard Metrics Explorer:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
Na barra de ferramentas do painel do criador de consultas, selecione o botão code MQL ou code PromQL.
Verifique se PromQL está selecionado na opção de ativar/desativar Idioma. A alternância de idiomas está na mesma barra de ferramentas que permite formatar sua consulta.
Insira a seguinte consulta no painel do editor:
foo_metric
Clique em Adicionar consulta.
Na barra de ferramentas do painel do criador de consultas, selecione o botão code MQL ou code PromQL.
Verifique se PromQL está selecionado na opção de ativar/desativar Idioma. A alternância de idiomas está na mesma barra de ferramentas que permite formatar sua consulta.
Insira a seguinte consulta no segundo painel do editor:
bar_metric
Clique em Executar consulta.
Para ver detalhes sobre as métricas, no seletor chamado Tabela de gráficos Ambos, selecione Ambos.
Limpeza
Quando terminar de testar o app de exemplo, use o script clean-up-cloud-run.sh no repositório run-gmp-sidecar para excluir os seguintes recursos que você possa ter criado para a amostra:
- O serviço do Cloud Run.
- O repositório do Artifact Registry.
- A conta de serviço criada para o Cloud Build.
A exclusão desses recursos garante que não haja custos após a execução da amostra.
Para limpar o app de exemplo, execute o script clean-up-cloud-run.sh:
./clean-up-cloud-run.sh
Visualizar métricas próprias no Metrics Explorer
O arquivo secundário do Managed Service para Prometheus informa as seguintes métricas sobre si mesmo ao Cloud Monitoring:
agent_uptime: o tempo de atividade do coletor de arquivos secundários (contador).agent_memory_usage: a memória consumida pelo coletor de arquivo secundário (medidor).agent_api_request_count: o número de solicitações de API do coletor secundário (contador).agent_monitoring_point_count: o número de pontos de métricas gravados no Cloud Monitoring pelo coletor do arquivo secundário (contador).
Para visualizar as próprias métricas do arquivo secundário no Metrics Explorer, faça o seguinte:
-
No Console do Google Cloud, acesse a página do leaderboard Metrics Explorer:
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
Na barra de ferramentas do painel do criador de consultas, selecione o botão code MQL ou code PromQL.
Verifique se PromQL está selecionado na opção de ativar/desativar Idioma. A alternância de idiomas está na mesma barra de ferramentas que permite formatar sua consulta.
Insira o nome da métrica que você quer consultar no painel do editor, por exemplo:
agent_api_request_count
Clique em Executar consulta.
Para ver detalhes sobre as métricas, no seletor chamado Tabela de gráficos Ambos, selecione Ambos.
Visualizar os registros próprios na Análise de registros
O arquivo secundário do Managed Service para Prometheus grava registros no Cloud Logging. O arquivo secundário grava registros no tipo de recurso monitorado do Logging cloud_run_revision.
Para visualizar os registros do arquivo secundário na Análise de registros, faça o seguinte:
-
No console do Google Cloud, acesse a página do Análise de registros.
Acessar a Análise de registros
Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Geração de registros.
Selecione o tipo de recurso Revisão do Cloud Run ou insira a consulta a seguir e clique em Executar consulta:
resource.type="cloud_run_revision"
Sobre as métricas coletadas
Quando as métricas emitidas pelo arquivo secundário são ingeridas no Cloud Monitoring,
as métricas são gravadas em relação ao tipo de recurso monitorado
prometheus_target do Cloud Monitoring.
Esse tipo de recurso é usado tanto para métricas do aplicativo quanto métricas próprias do arquivo secundário.
Ao gravar as métricas, o arquivo secundário define os rótulos de recursos da seguinte maneira:
project_id: o ID do projeto do Google Cloud em que o contêiner está em execução.location: a região do Google Cloud em que o contêiner está sendo executado.cluster: o valor__run__.namespace: o nome do serviço do Cloud Run em execução vem da variável de ambienteK_SERVICE.job: nome da configuraçãoRunMonitoring; o padrão érun-gmp-sidecar.instance: o valorfaas.ID:PORTda carga de trabalho local de que o contêiner está configurado para extrair métricas. O valor faas.ID é o ID da instância do Cloud Run.
O arquivo secundário também adiciona os seguintes rótulos de métricas:
instanceId: o ID da instância do Cloud Run.service_name: o nome do serviço do Cloud Run em execução.revision_name: o nome da revisão do Cloud Run em execução.configuration_name: o nome da configuração do Cloud Run em execução.
Esses rótulos de métricas são adicionados por padrão. Se você usar uma configuração RunMonitoring personalizada, poderá omitir os rótulos service_name, revision_name e configuration_name usando o Opção targetLabels na especificação RunMonitoring. Também é possível usar uma configuração personalizada para remarcar os valores dos rótulos service_name, revision_name e configuration_name.
Todos os outros rótulos que aparecem com as métricas ingeridas vêm da sua métrica.
Se um rótulo definido pelo usuário entrar em conflito com um dos fornecidos pelo sistema,
o rótulo definido pelo usuário será prefixado com a string exported_. Por exemplo,
um rótulo especificado pelo usuário namespace="playground" entra em conflito com o rótulo namespace
definido pelo sistema, então o rótulo do usuário aparece como exported_namespace="playground".
Tipo de métrica
Quando as métricas emitidas pelo arquivo secundário são ingeridas no Cloud Monitoring,
as métricas são gravadas como prometheus.googleapis.com, e o tipo
da métrica do Prometheus é anexado ao final do nome. Por exemplo,
o app de exemplo emite uma métrica de medidor do Prometheus chamada foo_metric. No
Cloud Monitoring, a métrica é armazenada como o tipo de métrica
prometheus.googleapis.com/foo_metric/gauge.
Ao consultar a métrica com PromQL, é possível usar o nome do Prometheus, conforme ilustrado em Visualizar métricas do app no Metrics Explorer e Visualizar métricas próprias no Metrics Explorer. Ao usar ferramentas como o criador de consultas ou a linguagem de consulta do Monitoring (MQL, na sigla em inglês) no Metrics Explorer, o tipo de métrica do Cloud Monitoring é relevante.
Faturamento
As métricas emitidas pelo arquivo secundário são ingeridas no Cloud Monitoring com
o prefixo prometheus.googleapis.com. As métricas com esse prefixo são cobradas pelo número de amostras ingeridas. Para mais informações sobre faturamento e
o Managed Service para Prometheus, consulte Faturamento.