Esta página foi traduzida pela API Cloud Translation.

Solução de problemas do Managed Service para Prometheus

Neste documento, você verá alguns problemas que podem ser encontrados ao usar o Google Cloud Managed Service para Prometheus, além de informações sobre como diagnosticar e resolver os problemas.

Você configurou o Managed Service para Prometheus, mas não vê dados de métrica no Grafana ou na IU do Prometheus. Em geral, a causa pode ser uma das seguintes:

Há um problema no lado da consulta, por isso os dados não podem ser lidos. Problemas no lado da consulta geralmente são causados por permissões incorretas na conta de serviço que lê os dados ou pela configuração incorreta do Grafana.
Um problema no processamento, para que nenhum dado seja enviado. Problemas no processamento podem ser causados por problemas de configuração com contas de serviço, coletores ou avaliação de regras.

Para determinar se o problema está no lado da ingestão ou da consulta, tente consultar os dados usando a guia PromQL do Metrics Explorer no Console do Google Cloud. Esta página não tem problemas com permissões de leitura ou configurações do Grafana.

Para visualizar essa página, faça o seguinte:

Use o seletor de projeto do console do Google Cloud para selecionar o projeto cujos dados você não está vendo.
No Console do Google Cloud, acesse a página do Metrics Explorer:
Acesse o 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 MQL ou 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.
Digite a consulta a seguir no Editor e clique em Executar consulta:
```
up
```

Se você consultar a métrica up e vir resultados, o problema estará na consulta. Se você precisar de informações para resolver esses problemas, consulte Problemas de consulta.

Se você consultar a métrica up e não encontrar resultados, o problema estará no processamento. Para informações sobre como resolver esses problemas, consulte Problemas no processamento.

Um firewall também pode causar problemas de ingestão e consulta. para mais informações, consulte Firewalls.

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

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

Você também pode usar o Gerenciamento de métricas para excluir métricas desnecessárias, eliminando o custo de ingestão delas.

Para visualizar a página Gerenciamento de métricas, faça o seguinte:

No console do Google Cloud, acesse a página Gerenciamento de métricas:
Acesse os Gerenciamento de métricas

Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoramento.
Na barra de ferramentas, selecione a janela de tempo. Por padrão, a página Gerenciamento de métricas exibe informações sobre as métricas coletadas no dia anterior.

Para mais informações sobre a página Gerenciamento de métricas, consulte Ver e gerenciar o uso de métricas.

Problemas no lado da consulta

A causa da maioria dos problemas de consulta é uma das seguintes:

Credenciais ou permissões incorretas para contas de serviço.
Configuração incorreta da federação de identidade da carga de trabalho para o GKE, se o seu cluster tiver esse recurso ativado. Para mais informações, consulte Configurar uma conta de serviço para a Federação de Identidade da Carga de Trabalho para GKE.

Comece fazendo o seguinte:

Verifique sua configuração com atenção de acordo com as instruções de configuração para consulta.
Se você estiver usando a federação de identidade da carga de trabalho para o GKE, verifique se a conta de serviço tem as permissões corretas fazendo o seguinte:
1. No console do Google Cloud, abra a página IAM.
  Acesse o IAM
  
  Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo IAM e administrador.
2. Identifique o nome da conta de serviço na lista de principais. Verifique se o nome da conta de serviço está digitado corretamente. Em seguida, clique em editar.
3. Selecione o campo Papel, clique em Usado atualmente e procure o papel de leitor do Monitoring. Se a conta de serviço não tiver esse papel, adicione-a agora.

Se o problema persistir, considere as seguintes possibilidades:

Chaves secretas configuradas incorretamente ou com erros de digitação

Caso você veja algum dos itens a seguir, pode ser que um secret esteja ausente ou tenha sido digitado incorretamente:

Um destes erros "proibidos" no Grafana ou na interface do Prometheus:
- "Aviso: status de resposta inesperado ao buscar o horário do servidor: proibido"
- "Aviso: erro ao buscar a lista de métricas: status de resposta inesperado ao buscar nomes de métricas: proibido"
Você verá uma mensagem como esta nos registros:
"não é possível ler o arquivo de credenciais: abra /gmp/key.json: não há arquivo ou diretório desse tipo"

Se você estiver usando o sincronizador de fonte de dados para autenticar e configurar o Grafana, realize as seguintes ações para tentar resolver esses erros:

Verifique se você escolheu o endpoint correto da API Grafana, o UID da fonte de dados do Grafana e o token da API Grafana. Execute o comando kubectl describe cronjob datasource-syncer para inspecionar as variáveis no CronJob.
Verifique se você definiu o ID do projeto do sincronizador de fonte de dados como o mesmo escopo de métricas ou projeto para o qual sua conta de serviço tem credenciais.
Verifique se a conta de serviço do Grafana tem o papel "Administrador" e se o token da API não expirou.
Verifique se sua conta de serviço tem o papel de Leitor do Monitoring para o ID do projeto escolhido.
Execute kubectl logs job.batch/datasource-syncer-init para verificar se não há erros nos registros do job do sincronizador de fonte de dados. Esse comando precisa ser executado logo após a aplicação do arquivo datasource-syncer.yaml.
Se estiver usando a federação de identidade da carga de trabalho para o GKE, verifique se você não digitou errado a chave de conta ou credenciais e verifique se você a vinculou o namespace correto.

Se você estiver usando o proxy da interface do front-end legado, realize as seguintes ações para tentar resolver esses erros:

Verifique se você definiu o ID do projeto da IU de front-end como o mesmo escopo de métricas ou projeto em que sua conta de serviço tem credenciais.
Verifique o ID do projeto especificado para qualquer sinalização --query.project-id.
Verifique se sua conta de serviço tem o papel de Leitor do Monitoring para o ID do projeto escolhido.
Verifique se você definiu o ID de projeto correto ao implantar a IU de front-end e não a deixou definido como a string literal PROJECT_ID.
Se estiver usando a Identidade da carga de trabalho, verifique se você não digitou incorretamente a chave ou as credenciais da conta e se você a vinculou o namespace correto.
Se estiver montando seu próprio secret, verifique se ele está presente:
```
kubectl get secret gmp-test-sa -o json | jq '.data | keys'
```

Verifique se o secret está ativado corretamente:

kubectl get deploy frontend -o json | jq .spec.template.spec.volumes

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].volumeMounts

Verifique se o secret foi transmitido corretamente para o contêiner:

kubectl get deploy frontend -o json | jq .spec.template.spec.containers[].args

Método HTTP incorreto para Grafana

Se você vir o seguinte erro de API do Grafana, isso significa que o Grafana está configurado para enviar uma solicitação POST em vez de uma solicitação GET:

"{"status":"error","errorType":"bad_data","error":"no match[] parameter provided"}%"

Para resolver esse problema, configure o Grafana para usar uma solicitação GET seguindo as instruções em Configurar uma fonte de dados.

Tempos limite em consultas grandes ou de longa duração

Se o erro a seguir for exibido no Grafana, o tempo limite padrão da consulta será muito baixo:

"Post "http://frontend.NAMESPACE_NAME.svc:9090/api/v1/query_range": net/http: timeout awaiting response headers"

O Managed Service para Prometheus não expira até que uma consulta exceda 120 segundos, enquanto o Grafana expira após 30 segundos por padrão. Para corrigir isso, aumente os tempos limite no Grafana para 120 segundos seguindo as instruções em Configurar uma fonte de dados.

Erros de validação de rótulos

Se você vir um dos seguintes erros no Grafana, é possível que um endpoint não compatível seja usado:

"Validação: marcadores diferentes de nome ainda não são compatíveis"
"Mapeamento de [job]: Erro ao atualizar opções: rótulos diferentes de name ainda não são compatíveis."

O Managed Service para Prometheus é compatível com o endpoint /api/v1/$label/values apenas para o rótulo __name__. Essa limitação faz com que as consultas que usam a variável label_values($label) no Grafana falhem.

Em vez disso, use o formulário label_values($metric, $label). Essa consulta é recomendada porque restringe os valores de rótulo retornados pela métrica, o que impede a recuperação de valores não relacionados ao conteúdo do painel. Esta consulta chama um endpoint compatível com o Prometheus.

Para mais informações sobre os endpoints compatíveis, consulte Compatibilidade da API.

Cota excedida

Se for exibido o seguinte erro, você terá excedido sua cota de leitura para a API Cloud Monitoring:

"429: RESOURCE_EXHAUSTED: cota excedida para a métrica de cota "Consultas de série temporal" e limitar "Consultas de série temporal por minuto" do serviço "monitoring.googleapis.com" para o consumidor "project_number:...".

Para resolver esse problema, envie uma solicitação para aumentar a cota de leitura para a API Monitoring. Para receber ajuda, entre em contato com o Suporte do Google Cloud. Para mais informações sobre cotas, consulte Como trabalhar com cotas.

Métricas de vários projetos

Se você quiser ver métricas de vários projetos do Google Cloud, não precisará configurar vários sincronizadores de fonte de dados ou criar várias fontes de dados no Grafana.

Em vez disso, crie um escopo de métricas do Cloud Monitoring em um projeto do Google Cloud, o projeto de escopo, que contém os projetos que você quer monitorar. Ao configurar a fonte de dados do Grafana com um projeto de escopo, você recebe acesso aos dados de todos os projetos no escopo de métricas. Para mais informações, consulte Escopos de consultas e métricas.

Nenhum tipo de recurso monitorado especificado

Se o erro a seguir for exibido, especifique um tipo de recurso monitorado ao usar o PromQL para consultar uma métrica do sistema do Google Cloud:

"A métrica está configurada para ser usada com mais de um tipo de recurso monitorado. O seletor de série precisa especificar um matcher de rótulo no nome do recurso monitorado."

É possível especificar um tipo de recurso monitorado por filtro usando o identificador monitored_resource. Para mais informações sobre como identificar e escolher um tipo de recurso monitorado válido, consulte Como especificar um tipo de recurso monitorado.

Valores brutos de contador, histograma e resumo não correspondentes entre a UI do coletor e o console do Google Cloud

Talvez você perceba uma diferença entre os valores na IU do coletor local Prometheus e no console do Google Cloud ao consultar o valor bruto de métricas cumulativas do Prometheus, incluindo contadores, histogramas e resumos. Esse comportamento é esperado.

O Monarch requer carimbos de data/hora de início, mas o Prometheus não tem carimbos de data/hora de início. O Serviço gerenciado para o Prometheus gera carimbos de data/hora de início ignorando o primeiro ponto ingerido em qualquer série temporal e o convertendo em um carimbo de data/hora de início. Os pontos seguintes têm o valor do ponto inicial pulado subtraído do valor para garantir que as taxas estejam corretas. Isso causa um déficit permanente no valor bruto desses pontos.

A diferença entre o número na UI do coletor e o número no console do Google Cloud é igual ao primeiro valor registrado na UI do coletor, o que é esperado, porque o sistema ignora esse valor inicial e o subtrai dos pontos seguintes.

Isso é aceitável porque não é necessária produção para executar uma consulta para valores brutos de métricas cumulativas. Todas as consultas úteis exigem uma função rate() ou semelhante. Nesse caso, a diferença em qualquer horizonte de tempo é idêntica entre as duas interfaces. As métricas cumulativas só aumentam. Então não é possível definir um alerta em uma consulta bruta porque uma série temporal atinge um limite apenas uma vez. Todos os alertas e gráficos úteis analisam a mudança ou a taxa de alteração no valor.

O coletor armazena apenas cerca de 10 minutos de dados localmente. Discrepâncias nos valores cumulativos brutos também podem surgir devido a uma redefinição ocorrendo antes do horizonte de 10 minutos. Para descartar essa possibilidade, tente definir apenas um período de lookback de consulta de 10 minutos ao comparar a interface do coletor com o console do Google Cloud.

Discrepâncias também podem ser causadas por ter várias linhas de execução de worker no aplicativo, cada uma com um endpoint /metrics. Se o aplicativo ativar várias linhas de execução, será necessário colocar a biblioteca de cliente do Prometheus no modo multiprocesso. Para mais informações, consulte a documentação sobre como usar o modo multiprocesso na biblioteca de cliente Python do Prometheus.

Dados de contador ausentes ou histogramas corrompidos

O sinal mais comum desse problema é não ver dados ou observar lacunas de dados ao consultar uma métrica de contador simples (por exemplo, uma consulta PromQL de metric_name_foo). É possível confirmar isso se os dados aparecerem depois que você adicionar uma função rate à consulta (por exemplo, rate(metric_name_foo[5m])).

Você também pode notar que suas amostras ingeridas aumentaram drasticamente sem qualquer alteração significativa no volume de raspagem de dados ou que novas métricas estão sendo criadas com os sufixos "unknown" ou "unknown:counter" no Cloud Monitoring.

Também é possível notar que as operações de histograma, como a função quantile(), não funcionam como esperado.

Esses problemas ocorrem quando uma métrica é coletada sem um TYPE da métrica do Prometheus. Como o Monarch é de tipagem forte, o Managed Service para Prometheus contabiliza métricas sem tipagem atribuindo o sufixo "unknown" e fazendo a ingestão duas vezes, uma como medidor e outra como contador. Em seguida, o mecanismo de consulta escolhe se quer consultar a métrica do medidor ou do contador com base nas funções de consulta que você usa.

Embora essa heurística geralmente funcione muito bem, ela pode causar problemas, como resultados estranhos ao consultar uma métrica "unknown:counter" bruta. Além disso, como os histogramas são objetos com tipagem específica no Monarch, ingerir as três métricas de histograma necessárias como métricas individuais do contador faz com que as funções do histograma não funcionem. Como as métricas com a tipagem "unknown" são ingeridas duas vezes, não definir um TYPE dobra as amostras ingeridas.

Motivos comuns por que TYPE pode não estar definido incluem:

configurar acidentalmente um coletor do Managed Service para Prometheus como um servidor de federação. A federação não é compatível com o Managed Service para Prometheus. Como a federação descarta intencionalmente as informações TYPE, implementar a federação causa métricas com a tipagem "unknown";
usar a gravação remota do Prometheus em qualquer ponto do pipeline de ingestão. Esse protocolo também descarta intencionalmente as informações TYPE;
usar uma regra de redefinição de rótulo que modifica o nome da métrica. Isso faz com que a métrica renomeada seja desassociada das informações TYPE associadas ao nome da métrica original;
o exportador não estar emitindo um TYPE para cada métrica;
um problema temporário em que TYPE é descartado quando o coletor é iniciado pela primeira vez.

Para resolver esse problema, faça o seguinte:

Parar de usar federação com o Managed Service para Prometheus. Se você quiser reduzir a cardinalidade e o custo ao "acumular dados" antes de enviá-los ao Monarch, consulte Configurar a agregação local.
Pare de usar a gravação remota do Prometheus no seu caminho de coleção.
Confirme se o campo # TYPE existe para cada métrica acessando o endpoint /metrics.
Exclua todas as regras de redefinição de rótulo que modificam o nome de uma métrica.
Exclua todas as métricas conflitantes com o sufixo "unknown" ou "unknown:counter" chamando DeleteMetricDescriptor.
Ou sempre consulte os contadores usando uma rate ou outra função de processamento de contador.

Dados do Grafana não mantidos após a reinicialização do pod

Se parecer que os dados sumiram do Grafana após a reinicialização de um pod, mas estão visíveis no Cloud Monitoring, significa que você está usando o Grafana para consultar a instância local do Prometheus no lugar do Managed Service para Prometheus.

Para informações sobre como configurar o Grafana para usar o serviço gerenciado como fonte de dados, consulte este link.

Como importar painéis do Grafana

Para informações sobre como usar e resolver problemas do importador de painel, consulte Importar painéis do Grafana para o Cloud Monitoring.

Para informações sobre problemas com a conversão do conteúdo do painel, consulte o arquivo README do importador.

Problemas no processamento

Os problemas no processamento podem estar relacionados à avaliação da coleção ou de regras. Comece por analisar os registros de erros da coleção gerenciada. É possível executar os seguintes comandos:

kubectl logs -f -n gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gmp-system -lapp.kubernetes.io/name=collector -c prometheus

Nos clusters do Autopilot do GKE, é possível executar os seguintes comandos:

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/part-of=gmp

kubectl logs -f -n gke-gmp-system -lapp.kubernetes.io/name=collector -c prometheus

O recurso de status do destino pode ajudar a depurar o destino da raspagem de dados. Para mais informações, consulte as informações de status do destino.

O status do endpoint está ausente ou é muito antigo

Se você tiver ativado o recurso de status do destino, mas um ou mais dos recursos PodMonitoring ou ClusterPodMonitoring não tiverem o campo ou o valor de Status.Endpoint Statuses, talvez você tenha um dos seguintes problemas:

O serviço gerenciado para Prometheus não conseguiu acessar um coletor no mesmo nó de um dos endpoints.
Uma ou mais das configurações de PodMonitoring ou ClusterPodMonitoring não resultaram em destinos válidos.

Problemas semelhantes também podem fazer com que o campo Status.Endpoint Statuses.Last Update Time tenha um valor com mais de alguns minutos e o intervalo de raspagem de dados.

Para resolver esse problema, primeiro verifique se os pods do Kubernetes associados ao endpoint de raspagem de dados estão em execução. Se os pods do Kubernetes estiverem em execução, os seletores de rótulo serão correspondentes e será possível acessar manualmente os endpoints de raspagem de dados (normalmente visitando o endpoint /metrics) e, em seguida, verificar se os coletores do Managed Service para Prometheus estão em execução.

A fração de coletores é menor que 1

Se você tiver ativado o recurso de status do destino, receberá informações de status sobre seus recursos. O valor de Status.Endpoint Statuses.Collectors Fraction dos recursos PodMonitoring ou ClusterPodMonitoring representa a fração de coletores, expressa de 0 a 1, que podem ser acessados. Por exemplo, um valor de 0.5 indica que 50% dos coletores são acessíveis, enquanto um valor de 1 indica que 100% deles podem ser acessados.

Quando o campo Collectors Fraction tem um valor diferente de 1, um ou mais coletores estão inacessíveis e a raspagem de dados das métricas em qualquer um desses nós provavelmente não está sendo feita. Verifique se todos os coletores estão em execução e são acessíveis na rede do cluster. É possível ver o status dos pods dos coletores com o seguinte comando:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=collector"

Nos clusters do Autopilot do GKE , este comando é um pouco diferente:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=collector"

É possível investigar individualmente os pods dos coletores (por exemplo, um pod do coletor chamado collector-12345) com o seguinte comando:

kubectl -n gmp-system describe pods/collector-12345

Nos clusters do Autopilot do GKE, execute o seguinte comando:

kubectl -n gke-gmp-system describe pods/collector-12345

Se os coletores não estiverem íntegros, consulte Solução de problemas de carga de trabalho do GKE.

Se os coletores estiverem íntegros, verifique os registros do operador. Para verificar os registros do operador, primeiro execute o comando a seguir para encontrar o nome do pod do operador:

kubectl -n gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Nos clusters do Autopilot do GKE, execute o seguinte comando:

kubectl -n gke-gmp-system get pods --selector="app.kubernetes.io/name=gmp-collector"

Em seguida, verifique os registros do operador (por exemplo, um pod do operador chamado gmp-operator-12345) com o seguinte comando:

kubectl -n gmp-system logs pods/gmp-operator-12345

Nos clusters do Autopilot do GKE, execute o seguinte comando:

kubectl -n gke-gmp-system logs pods/gmp-operator-12345

Destinos não íntegros

Se você ativou o recurso de status do destino, mas um ou mais dos recursos PodMonitoring ou ClusterPodMonitoring têm o campo Status.Endpoint Statuses.Unhealthy Targets com o valor diferente de 0, o coletor não pode fazer a raspagem de dados de um ou mais dos destinos.

Veja o campo Sample Groups, que agrupa os destinos por mensagem de erro, e localize o campo Last Error. O campo Last Error é proveniente do Prometheus e informa por que não foi possível fazer a raspagem de dados do destino. Para resolver esse problema, usando os destinos de exemplo como referência, verifique se os endpoints de raspagem de dados estão em execução.

Endpoint de raspagem de dados não autorizado

Se um dos erros a seguir aparecer, e o destino de raspagem de dados exigir autorização, seu coletor não está configurado para usar tipo de autorização ou está usando o payload de autorização incorreto:

server returned HTTP status 401 Unauthorized
x509: certificate signed by unknown authority

Para resolver esse problema, consulte Como configurar um endpoint de raspagem de dados autorizado.

Cota excedida

Se for exibido o seguinte erro, você terá excedido sua cota de ingestão para a API Cloud Monitoring:

"429: cota excedida para a métrica de cota "Solicitações de ingestão de série temporal" e limitar "Solicitações de processamento de série temporal por minuto" do serviço "monitoring.googleapis.com" para o consumidor "project_number:PROJECT_NUMBER", }rateLimitExceeded"

Esse erro geralmente ocorre quando o serviço gerenciado é ativado pela primeira vez. A cota padrão será esgotada em 100.000 amostras por segundo ingeridas.

Para resolver esse problema, envie uma solicitação para aumentar a cota de ingestão para a API Monitoring. Para receber ajuda, entre em contato com o Suporte do Google Cloud. Para mais informações sobre cotas, consulte Como trabalhar com cotas.

Permissão ausente na conta de serviço padrão do nó

Se você vir um dos seguintes erros, talvez a conta de serviço padrão no nó não tenha permissões:

"execute query: Error query Prometheus: client_error: client error: 403"
"Falha na sondagem de prontidão: a sondagem HTTP falhou com código de status: 503"
"Erro ao consultar a instância do Prometheus"

A coleção gerenciada e o avaliador de regras gerenciadas no Managed Service para Prometheus usam a conta de serviço padrão no nó. Essa conta é criada com todas as permissões necessárias, mas, às vezes, os clientes removem manualmente as permissões do Monitoring. Essa remoção causa falha na coleta e na avaliação da regra.

Para verificar as permissões da conta de serviço, siga um destes procedimentos:

Identifique o nome de nó subjacente do Compute Engine e execute o seguinte comando:
```
gcloud compute instances describe NODE_NAME --format="json" | jq .serviceAccounts
```
Procure a string https://www.googleapis.com/auth/monitoring. Se necessário, adicione o Monitoring conforme descrito em Conta de serviço configurada incorretamente.
Navegue até a VM subjacente no cluster e verifique a configuração da conta de serviço do nó:
1. No Console do Google Cloud, acesse a página de clusters do Kubernetes:
  Acesse Clusters do Kubernetes
  
  Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Kubernetes Engine.
2. Selecione Nós e clique no nome do nó na tabela Nós.
3. Clique em Detalhes.
4. Clique no link Instância da VM.
5. Localize o painel API e gerenciamento de identidades e clique em Mostrar detalhes.
6. Procure a API Stackdriver Monitoring com acesso total.

Também é possível que o sincronizador de fonte de dados ou a interface do Prometheus tenham sido configurados para analisar o projeto errado. Para informações sobre como verificar se você está consultando o escopo das métricas pretendidas, consulte Alterar o projeto consultado.

Conta de serviço configurada incorretamente

Se você vir uma das seguintes mensagens de erro, isso significa que a conta de serviço usada pelo coletor não tem as permissões corretas:

"code = PermissionDenied desc = Permission monitoring.timeSeries.create denied (ou o recurso pode não existir)"
"google: não foi possível encontrar as credenciais padrão. Consulte https://developers.google.com/accounts/docs/application-default-credentials para mais informações."

Para verificar se sua conta de serviço tem as permissões corretas, faça o seguinte:

No console do Google Cloud, abra a página IAM.
Acesse o IAM

Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo IAM e administrador.
Identifique o nome da conta de serviço na lista de principais. Verifique se o nome da conta de serviço está digitado corretamente. Em seguida, clique em editar.
Selecione o campo Papel e clique em Usado atualmente e procure no papel de gravador ou monitoramento do Monitoring. Se a conta de serviço não tiver um desses papéis, conceda a ela o papel de Gravador da métrica de monitoramento (roles/monitoring.metricWriter).

Se você estiver executando em um Kubernetes que não seja do GKE, precisará passar explicitamente as credenciais para o coletor e o avaliador da regra. Repita as credenciais nas seções rules e collection. Para mais informações, consulte Fornecer credenciais explicitamente (para coleta) ou Fornecer credenciais explicitamente (para regras).

As contas de serviço geralmente têm escopo para um único projeto do Google Cloud. O uso de uma conta de serviço para gravar dados de métricas para vários projetos, por exemplo, quando um avaliador de regra gerenciada está consultando um escopo de métricas de vários projetos, pode causar esse erro de permissão. Se você estiver usando a conta de serviço padrão, configure uma conta de serviço dedicada para adicionar com segurança a permissão monitoring.timeSeries.create para vários projetos. Se não for possível conceder essa permissão, use a remarcação de métricas para reescrever o rótulo project_id com outro nome. O ID do projeto é o projeto do Google Cloud em que o servidor Prometheus ou o avaliador de regras está em execução.

Configuração de raspagem de dados inválida

Se você vir o seguinte erro, seu PodMonitoring ou ClusterPodMonitoring será formado incorretamente:

"Erro interno: falha ao chamar o webhook "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com": Post "https://gmp-operator.gmp-system.svc:443/validate/monitoring.googleapis.com/v1/podmonitorings?timeout=10s": EOF""

Para resolver esse problema, verifique se o recurso personalizado tem o formato correto de acordo com a especificação.

O webhook de admissão não consegue analisar ou a configuração do cliente HTTP é inválida

Em versões do Managed Service for Prometheus anteriores à 0.12, você pode ver um erro semelhante ao seguinte, que está relacionado à injeção de segredo no namespace não padrão:

"webhook de admissão "validate.podmonitorings.gmp-operator.gmp-system.monitoring.googleapis.com" negou a solicitação: definição inválida para endpoint com índice 0: não foi possível analisar ou configuração inválida do cliente HTTP do Prometheus: é necessário usar namespace "my-custom-namespace", obteve: "default""

Para resolver esse problema, faça upgrade para a versão 0.12 ou mais recente.

Problemas com intervalos e tempos limite de verificação

Ao usar o Managed Service para Prometheus, o tempo limite da verificação não pode ser maior que o intervalo da verificação. Para verificar os registros desse problema, execute o seguinte comando:

kubectl -n gmp-system logs ds/collector prometheus

Nos clusters do Autopilot do GKE, execute o seguinte comando:

kubectl -n gke-gmp-system logs ds/collector prometheus

Procure esta mensagem:

"tempo limite de extração superior ao intervalo da verificação para a configuração da verificação com o nome do job "PodMonitoring/gmp-system/example-app/go-metrics"

Para resolver esse problema, defina o valor do intervalo de verificação igual ou maior que o valor do tempo limite da verificação.

TYPE não encontrado na métrica

Se o seguinte erro for exibido, não há informações sobre o tipo na métrica:

"nenhum metadado encontrado para o nome da métrica "{metric_name}""

Para verificar se as informações de tipo ausentes são o problema, verifique a saída /metrics do aplicativo de exportação. Se não houver uma linha como esta, as informações de tipo estarão ausentes:

# TYPE {metric_name} <type>

Algumas bibliotecas, como as da VictoriaMetrics anteriores à versão 1.28.0, descartam intencionalmente as informações de tipo. Essas bibliotecas não são compatíveis com o Managed Service para Prometheus.

Colisões de séries temporais

Se você vir um dos seguintes erros, é possível que mais de um coletor tente gravar na mesma série temporal:

"Não foi possível gravar um ou mais séries temporais: um ou mais pontos foram gravados com uma frequência maior do que o período de amostragem máximo configurado para a métrica."
"Não foi possível escrever uma ou mais séries temporais: os pontos precisam ser escritos em ordem. Um ou mais dos pontos especificados tiveram um horário de término mais antigo do que o mais recente."

Veja a seguir as causas e soluções mais comuns:

Como usar pares de alta disponibilidade. O Managed Service para Prometheus não é compatível com a coleta tradicional de alta disponibilidade. O uso dessa configuração pode criar vários coletores que tentam gravar dados na mesma série temporal, causando esse erro.

Para resolver o problema, desative os coletores duplicados reduzindo a contagem de réplicas para 1 ou use o método de alta disponibilidade compatível.
Usar regras de rotulagem, especialmente aquelas que operam em jobs ou instâncias. O Managed Service para Prometheus identifica parcialmente uma série temporal exclusiva pela combinação de {project_id, location, cluster, namespace, job, instance }. Usar uma regra de nova rotulagem para descartar esses rótulos, especialmente os job e instance, pode causar colisões. Não é recomendável reescrever esses rótulos.

Para resolver o problema, exclua a regra que está causando o problema. Isso pode ser feito pela regra metricRelabeling que usa a ação labeldrop. É possível identificar a regra problemática comentando todas as regras de remarcação e restabelecendo-as, uma de cada vez, até que o erro se repita.

Uma causa menos comum de colisões de série temporal é usar um intervalo de scrape com menos de cinco segundos. O intervalo mínimo de verificação compatível com o Managed Service para Prometheus é de cinco segundos.

Exceder o limite no número de rótulos

Se o erro a seguir for exibido, talvez você tenha muitos rótulos definidos para uma das métricas:

"Não foi possível gravar um ou mais TimeSeries: os novos rótulos fariam com que a métrica prometheus.googleapis.com/METRIC_NAME tivesse mais de PER_PROJECT_LIMIT rótulos".

Esse erro geralmente ocorre quando você altera rapidamente a definição da métrica para que um nome de métrica tenha vários conjuntos independentes de chaves de rótulo durante todo o ciclo de vida da métrica. O Cloud Monitoring impõe um limite no número de rótulos para cada métrica. Para mais informações, consulte os limites de métricas definidas pelo usuário.

Há três etapas para resolver esse problema:

Identifique por que uma determinada métrica tem rótulos demais ou que mudam com frequência.
- Use o widget das APIs Explorer na página metricDescriptors.list para chamar o método. Para mais informações, consulte APIs Explorer. Para exemplos, consulte Listar tipos de métricas e recursos.
Resolva a origem do problema, que pode envolver o ajuste das regras de remarcação do PodMonitoring, a alteração do exportador ou a correção da instrumentação.
Exclua o descritor para essa métrica, o que resultará em perda de dados. Assim, ela poderá ser recriada com um conjunto menor e mais estável de rótulos. Para isso, use o método metricDescriptors.delete.

As fontes mais comuns do problema são:

Coletar métricas de exportadores ou aplicativos que anexam rótulos dinâmicos às métricas. Por exemplo, o cAdvisor auto-implantado com rótulos de contêiner e variáveis de ambiente adicionais ou o agente DataDog, que injeta anotações dinâmicas.

Para resolver isso, use uma seção metricRelabeling no PodMonitoring para manter ou soltar rótulos. Alguns aplicativos e exportadores também permitem a configuração que altera as métricas exportadas. Por exemplo, o cAdvisor tem várias configurações de ambiente de execução avançadas que podem adicionar rótulos de maneira dinâmica. Ao usar a coleção gerenciada, recomendamos utilizar a coleção automática kubelet integrada.
O uso de regras de redefinição de rótulo, especialmente aquelas que anexam nomes de rótulos dinamicamente, pode causar um número inesperado de rótulos.

Para resolver o problema, exclua a entrada da regra que está causando o problema.

Limites de taxa para a criação e atualização de métricas e rótulos

Se você vir o erro a seguir, significa que atingiu o limite de taxa por minuto na criação de novas métricas e na adição de novos rótulos de métrica às métricas existentes:

"Solicitação limitada. Você atingiu o limite por projeto na mudança de definição de métrica ou definição de rótulo por minuto."

Esse limite de taxa geralmente é atingido apenas na primeira integração com o Serviço gerenciado para Prometheus. Por exemplo, ao migrar uma implantação madura do Prometheus para usar uma coleção autoimplantada. Esse não é um limite de taxa para a ingestão de pontos de dados. Essa limitação de taxa se aplica apenas ao criar métricas nunca vistas antes ou ao adicionar novos rótulos a métricas existentes.

Essa cota é fixa, mas os problemas são resolvidos automaticamente conforme novas métricas e rótulos de métrica são criados até o limite por minuto.

Limites do número de descritores de métrica

Se você encontrar o erro a seguir, significa que atingiu o limite de cota para o número de descritores de métrica em um único projeto do Google Cloud:

"Sua cota do descritor de métricas está esgotada."

Por padrão, esse limite é definido como 25.000. Essa cota pode aumentar mediante solicitação quando as métricas são bem formadas, mas é muito mais provável que você atinja esse limite por estar ingerindo nomes de métricas malformados no sistema.

O Prometheus tem um modelo de dados dimensional, em que informações como cluster ou nome de namespace precisam ser codificadas como um valor de rótulo. Quando as informações dimensionais são incorporadas no próprio nome da métrica, o número de descritores de métrica aumenta indefinidamente. Além disso, como nesse cenário os rótulos não são usados corretamente, fica muito mais difícil consultar e agregar dados em clusters, namespaces ou serviços.

Nem o Cloud Monitoring nem o Managed Service para Prometheus são compatíveis com métricas não dimensionais, como aquelas formatadas para o StatsD ou Graphite. Embora a maioria dos exportadores do Prometheus esteja configurada corretamente e pronta para uso, alguns deles, como o exportador do StatsD, o exportador do Vault ou o Proxy Envoy que acompanha o Istio, precisam ser configurados explicitamente para usar rótulos em vez de incorporar informações no nome da métrica. Confira alguns exemplos de nomes de métricas malformados:

request_path_____path_to_a_resource____istio_request_duration_milliseconds
envoy_cluster_grpc_method_name_failure
envoy_cluster_clustername_upstream_cx_connect_ms_bucket
vault_rollback_attempt_path_name_1700683024
service__________________________________________latency_bucket

Para confirmar esse problema, faça isto:

No console do Google Cloud, selecione o projeto do Google Cloud vinculado ao erro.
No console do Google Cloud, acesse a página Gerenciamento de métricas:
Acesse os Gerenciamento de métricas

Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
Confirme se a soma das métricas ativas e inativas é maior que 25.000. Na maioria das situações, você verá um grande número de métricas inativas.
Selecione "Inativo" no painel "Filtros rápidos", role a lista e procure padrões.
Selecione "Ativo" no painel "Filtros rápidos", ordene por Volume faturável de amostras em ordem decrescente, percorra a lista e procure padrões.
Ordene por Volume faturável de amostras em ordem crescente, percorra a lista e procure padrões.

Outra possibilidade para confirmar esse problema é usar o Metrics Explorer:

No console do Google Cloud, selecione o projeto do Google Cloud vinculado ao erro.
No Console do Google Cloud, acesse a página do Metrics Explorer:
Acesse o Metrics explorer

Se você usar a barra de pesquisa para encontrar essa página, selecione o resultado com o subtítulo Monitoring.
No criador de consultas, clique em uma métrica e desmarque a caixa de seleção "Ativa".
Digite "prometheus" na barra de pesquisa.
Procure padrões nos nomes das métricas.

Depois de identificar os padrões que indicam métricas malformadas, é possível mitigar o problema corrigindo o exportador na origem e excluindo os descritores de métrica ofensivos.

Para evitar que esse problema aconteça novamente, primeiro configure o exportador relevante para não mais emitir métricas malformadas. Recomendamos consultar a documentação do exportador em busca de ajuda. Para confirmar se o problema foi corrigido, acesse manualmente o endpoint /metrics e inspecione os nomes das métricas exportadas.

É possível liberar sua cota excluindo as métricas incorretas usando o método projects.metricDescriptors.delete. Para iterar com mais facilidade pela lista de métricas malformadas, fornecemos um script Golang que pode ser usado. Esse script aceita uma expressão regular que pode identificar as métricas malformadas e exclui todos os descritores de métrica que correspondem ao padrão. Como a exclusão da métrica é irreversível, recomendamos primeiro executar o script usando o modo de teste.

Não há erros nem métricas

Se você estiver usando a coleção gerenciada e não vê erros, mas os dados não aparecem no Cloud Monitoring, então a causa mais provável é que as configurações de exportação ou extração de métricas não estão definidas corretamente. O Managed Service para Prometheus não envia dados de série temporal, a menos que você aplique primeiro uma configuração de scrape válida.

Para identificar se essa é a causa, tente implantar o aplicativo de exemplo e o recurso de podMonitoring. Se você vir a métrica up (pode levar alguns minutos), o problema é com a configuração de exportação ou o exportador.

A causa pode ser inúmeras coisas. Recomendamos que você verifique se:

o PodMonitoring referencia uma porta válida;
a especificação de implantação do exportador tem portas nomeadas corretamente;
os seletores (normalmente app) correspondem aos recursos do Deployment e do PodMonitoring;
você consegue ver dados no endpoint e na porta esperados ao acessá-los manualmente;
você instalou o recurso PodMonitoring no mesmo namespace do aplicativo em que quer fazer a raspagem de dados; Não instale nenhum recurso ou aplicativo personalizado nos namespace gmp-system ou gke-gmp-system.
os nomes de métricas e rótulos correspondem à expressão regular de validação do Prometheus; o serviço gerenciado para o Prometheus não é compatível com nomes de rótulos que começam com o caractere _;
você não está usando um conjunto de filtros que faz com que todos os dados sejam filtrados. Tome cuidado extra para não ter filtros conflitantes ao usar um filtro collection no recurso OperatorConfig.
se estiver em execução fora do Google Cloud, project ou project-id será definido como um projeto válido do Google Cloud, e location será definido como uma região válida do Google Cloud. Não é possível usar global como um valor para location.
A métrica é um dos quatro tipos de métrica do Prometheus. Algumas bibliotecas, como as métricas de estado do Kube, expõem tipos de métricas do OpenMetrics, como informações, estado e GaugeHistogram, mas esses tipos de métricas não são compatíveis com o serviço gerenciado para o Prometheus e são descartados silenciosamente.

Algumas métricas estão ausentes para metas de curta duração

O Google Cloud Managed Service para Prometheus é implantado e não há erros de configuração. No entanto, algumas métricas estão ausentes.

Determine a implantação que gera as métricas parcialmente ausentes. Se a implantação for um CronJob do Google Kubernetes Engine, determine por quanto tempo o job normalmente é executado:

Encontre o arquivo yaml de implantação do cron job e o status, que está listado no final do arquivo. O status neste exemplo mostra que o job foi executado por um minuto:
```
  status:
    lastScheduleTime: "2024-04-03T16:20:00Z"
    lastSuccessfulTime: "2024-04-03T16:21:07Z"
```
Se o tempo de execução for menor que cinco minutos, o job não está sendo executado por tempo suficiente para que os dados da métrica sejam consistentemente raspados.

Para resolver esse problema, tente o seguinte:
- Configure o job para garantir que ele não seja encerrado até que tenham passado pelo menos cinco minutos desde o início.
- Configure o job para detectar se as métricas foram raspadas antes de sair. Esse recurso requer suporte de biblioteca.
- Em vez de coletar dados de métricas, crie uma métrica com valor de distribuição com base em registros. Essa abordagem é sugerida quando os dados são publicados com uma taxa baixa. Para mais informações, consulte métricas com base em registros.
Se o tempo de execução for maior que cinco minutos ou for inconsistente, consulte a seção Destinos não íntegros deste documento.

Problemas com a coleta de exportadores

Se as métricas de um exportador não estiverem sendo ingeridas, verifique o seguinte:

Verifique se o exportador está funcionando e exportando métricas usando o comando kubectl port-forward.

Por exemplo, para verificar se os pods com o seletor app.kubernetes.io/name=redis no namespace test estão emitindo métricas no endpoint /metrics na porta 9121, é possível encaminhar a porta da seguinte maneira:
```
kubectl port-forward "$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].metadata.name}')" 9121
```
Acesse o endpoint localhost:9121/metrics usando o navegador ou curl em outra sessão do terminal para verificar se as métricas estão sendo expostas pelo exportador para raspagem de dados.
Verifique se é possível consultar as métricas no console do Google Cloud, mas não no Grafana. Nesse caso, o problema é com o Grafana, não com a coleta das suas métricas.
Verifique se o coletor gerenciado é capaz de copiar o exportador inspecionando a interface da Web do Prometheus que o coletor expõe.
1. Identifique o coletor gerenciado em execução no mesmo nó em que o exportador está em execução. Por exemplo, se o exportador estiver sendo executado em pods no namespace test e os pods estiverem rotulados com app.kubernetes.io/name=redis, o comando a seguir vai identificar o coletor gerenciado em execução no mesmo nó:
```
kubectl get pods -l app=managed-prometheus-collector --field-selector="spec.nodeName=$(kubectl get pods -l app.kubernetes.io/name=redis -n test -o jsonpath='{.items[0].spec.nodeName}')" -n gmp-system -o jsonpath='{.items[0].metadata.name}'
```
2. Configure o encaminhamento de portas na porta 19090 do coletor gerenciado:
```
kubectl port-forward POD_NAME -n gmp-system 19090
```
3. Acesse o URL localhost:19090/targets para acessar a interface da Web. Se o exportador estiver listado como um dos destinos, significa que o coletor gerenciado está raspando o exportador.

Erros de falta de memória do coletor (OOM)

Se você estiver usando a coleta gerenciada e encontrar erros de falta de memória (OOM) nos coletores, ative o escalonamento automático vertical de pods.

O operador tem erros de falta de memória (OOM)

Se você estiver usando a coleta gerenciada e encontrar erros de memória insuficiente (OOM) no operador, desative o recurso de status de destino. O recurso de status de destino pode causar problemas de desempenho do operador em clusters maiores.

Firewalls

Um firewall pode causar problemas de ingestão e consulta. Seu firewall precisa ser configurado para permitir solicitações POST e GET para o serviço da API Monitoring, monitoring.googleapis.com, para permitir ingestão e consultas.

Erro sobre edições simultâneas

A mensagem de erro "Há muitas edições simultâneas na configuração do projeto" geralmente é temporária, após alguns minutos. Isso geralmente é causado pela remoção de uma regra de remarcação que afeta muitas métricas diferentes. A remoção faz com que a formação de uma fila de atualizações seja feita nos descritores de métrica no seu projeto. O erro desaparece quando a fila é processada.

Para mais informações, consulte Limites para a criação e atualização de métricas e rótulos.

Consultas bloqueadas e canceladas pelo Monarch

Se você encontrar o erro a seguir, significa que atingiu o limite interno para o número de consultas simultâneas que podem ser executadas para qualquer projeto:

"internal: expanding series: generic::aborted: invalid status monarch::220: Cancelled due to the number of queries whose evaluation is blocked waiting for memory is 501, which is equal to or greater than the limit of 500."

Para proteger contra abusos, o sistema impõe um limite rígido no número de consultas de um projeto que podem ser executadas simultaneamente no Monarch. Com o uso típico do Prometheus, as consultas precisam ser rápidas, e esse limite nunca deve ser atingido.

Você pode atingir esse limite se estiver emitindo muitas consultas simultâneas que são executadas por um tempo maior do que o esperado. As consultas que solicitam mais de 25 horas de dados geralmente são mais lentas do que as consultas que solicitam menos de 25 horas de dados. Quanto maior o período de consulta, mais lenta ela será.

Normalmente, esse problema é acionado pela execução de muitas regras de lookback longo de maneira ineficiente. Por exemplo, você pode ter várias regras que são executadas uma vez a cada minuto e solicitam uma taxa de quatro semanas. Se cada uma dessas regras levar muito tempo para ser executada, pode haver um backup de consultas aguardando a execução no seu projeto, o que faz com que o Monarch limite as consultas.

Para resolver esse problema, aumente o intervalo de avaliação das suas regras de lookback longo para que elas não sejam executadas a cada 1 minuto. Executar uma consulta para uma taxa de quatro semanas a cada minuto é desnecessário. Há 40.320 minutos em quatro semanas, então cada minuto não oferece quase nenhum indicador adicional. Seus dados vão mudar no máximo em 1/40.320. O uso de um intervalo de avaliação de 1 hora deve ser suficiente para uma consulta que solicita uma taxa de 4 semanas.

Depois de resolver o gargalo causado por consultas de longa duração ineficientes executadas com muita frequência, esse problema será resolvido.

Tipos de valor incompatíveis

Se o seguinte erro aparecer na ingestão ou consulta, você terá uma incompatibilidade de tipo de valor nas suas métricas:

"O tipo de valor da métrica prometheus.googleapis.com/metric_name/gauge precisa ser INT64, mas é DOUBLE"
"O tipo de valor da métrica prometheus.googleapis.com/metric_name/gauge precisa ser DOUBLE, mas é INT64"
"Não foi possível gravar um ou mais TimeSeries: tipo de valor da métrica O prometheus.googleapis.com/target_info/gauge entra em conflito com o valor existente tipo (INT64)"

Talvez você veja esse erro após o processamento, já que o Monarch não oferece suporte para gravação de dados de tipo DOUBLE para tipo INT64 nem oferece suporte à gravação de dados do tipo INT64 métricas. Você também pode encontrar esse erro ao consultar usando um escopo de métricas de vários projetos, já que o Monarch não pode unir métricas do tipo DOUBLE em um projeto com métricas do tipo INT64 em outro.

Esse erro só acontece quando você tem coletores do OpenTelemetry que informam dados, e é mais provável que aconteça se você tiver dados de relatórios do OpenTelemetry (usando o exportador googlemanagedprometheus) e do Prometheus para a mesma métrica, como acontece com a métrica target_info.

A causa provavelmente é uma das seguintes:

Você está coletando métricas OTLP, e a biblioteca de métricas OTLP mudou o tipo de valor de DOUBLE para INT64, como aconteceu com as métricas Java do OpenTelemetry. O a nova versão da biblioteca de métricas agora é incompatível com o valor da métrica tipo criado pela versão antiga da biblioteca de métricas.
Você está coletando a métrica target_info usando o Prometheus e pelo OpenTelemetry. O Prometheus coleta essa métrica como DOUBLE, enquanto o OpenTelemetry coleta essa métrica como INT64. Agora seus colecionadores gravar dois tipos de valor para a mesma métrica no mesmo projeto, e apenas o o coletor que criou o descritor de métrica primeiro está sendo bem-sucedido.
Você está coletando target_info usando o OpenTelemetry como INT64 em um projeto e coletando target_info usando o Prometheus como DOUBLE em outro projeto. Adicionar as duas métricas ao mesmo escopo consultar essa métrica pelo escopo, uma união inválida entre tipos de valores de métricas incompatíveis.

Esse problema pode ser resolvido forçando todos os tipos de valores de métricas a DOUBLE fazendo o seguinte:

Reconfigure os coletores do OpenTelemetry para forçar todas as métricas a serem DUPLAS ativando a flag exporter.googlemanagedprometheus.intToDouble de bloqueio de recursos.
Exclua todos os descritores de métrica INT64 e deixe que eles sejam recriados como DOUBLE. Use o script delete_metric_descriptors.go para automatizar esse processo.

Seguir essas etapas exclui todos os dados armazenados como uma métrica INT64. Não há alternativa à exclusão das métricas INT64 que resolvem totalmente esse problema.