O serviço gerenciado do Google Cloud para Prometheus é compatível com a avaliação e os alertas de regras compatíveis com o Prometheus. Neste documento, você verá como configurar a avaliação de regras autoimplantadas, incluindo o componente autônomo de avaliador de regras.
Você só precisará seguir estas instruções se quiser executar regras e alertas no armazenamento de dados global.
Avaliação de regras para coleção autoimplantada
Depois de implantar o serviço gerenciado para o Prometheus, será possível continuar avaliando regras localmente em cada instância implantada usando o campo rule_files
do arquivo de configuração do Prometheus. No entanto, a janela máxima de consulta para as regras é restrita pelo tempo que o servidor mantém os dados locais.
A maioria das regras é executada somente nos últimos minutos de dados. Portanto, executar regras em cada servidor local é uma estratégia válida. Nesse caso, nenhuma configuração adicional é necessária.
No entanto, às vezes é útil avaliar regras em relação ao back-end da métrica global, por exemplo, quando todos os dados de uma regra não estão colocalizados em uma determinada instância do Prometheus. Para esses casos, o serviço gerenciado para o Prometheus também fornece um componente de avaliador de regras.
Antes de começar
Nesta seção, descrevemos a configuração necessária para as tarefas descritas neste documento.
Configurar o ambiente
Para evitar inserir repetidamente o ID do projeto ou o nome do cluster, execute a seguinte configuração:
Configure as ferramentas de linha de comando da seguinte maneira:
Configure a CLI gcloud para se referir ao ID do projeto do Google Cloud:
gcloud config set project PROJECT_ID
Configure a CLI
kubectl
para usar o cluster:kubectl config set-cluster CLUSTER_NAME
Para mais informações sobre essas ferramentas, consulte estes recursos:
Configurar um namespace
Crie o namespace NAMESPACE_NAME
do Kubernetes para os recursos que você criar
como parte do aplicativo de exemplo:
kubectl create ns NAMESPACE_NAME
Verificar as credenciais da conta de serviço
Pule essa seção se o cluster do Kubernetes tiver a Identidade da carga de trabalho ativada.
Quando executado no GKE, o Managed Service para Prometheus
recuperará automaticamente as credenciais do ambiente com base na
conta de serviço padrão do Compute Engine. A conta de serviço padrão tem as
permissões necessárias, monitoring.metricWriter
e monitoring.viewer
, por
padrão. Se você não usar a Identidade da carga de trabalho e tiver removido qualquer um desses papéis da conta de serviço do nó padrão, será necessário adicionar novamente essas permissões que faltam antes de continuar.
Se você não estiver executando no GKE, consulte Fornecer credenciais explicitamente.
Configurar uma conta de serviço para a Identidade da carga de trabalho
Você poderá pular esta seção se o cluster do Kubernetes não tiver a Identidade da carga de trabalho ativada.
O Managed Service para Prometheus captura dados de métricas usando a API Cloud Monitoring. Se o cluster estiver usando a identidade da carga de trabalho, você precisa conceder permissão à conta de serviço do Kubernetes para a API Monitoring. Esta seção descreve:
- Como criar uma conta de serviço dedicada do Google Cloud,
gmp-test-sa
. - Vincular a conta de serviço do Google Cloud à conta de serviço do
Kubernetes padrão em um namespace de teste,
NAMESPACE_NAME
. - Como conceder a permissão necessária à conta de serviço do Google Cloud.
Criar e vincular a conta de serviço
Essa etapa aparece em vários lugares na documentação do Managed Service para Prometheus. Se você já realizou esta etapa como parte de uma tarefa anterior, não é necessário repeti-la. Pule para Autorizar a conta de serviço.
A sequência de comandos a seguir cria a conta de serviço gmp-test-sa
e a vincula à conta de serviço padrão do Kubernetes no namespace 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 você estiver usando um namespace ou uma conta de serviço diferente do GKE, ajuste os comandos adequadamente.
Autorizar a conta de serviço
Grupos de permissões relacionadas são coletados em papéis, e você concede os papéis a um principal, neste exemplo, a conta de serviço do Google Cloud. Para mais informações sobre os papéis do Monitoring, consulte Controle de acesso.
O comando a seguir concede à conta de serviço do Google Cloud,
gmp-test-sa
, os papéis da API Monitoring necessários para
ler e gravar
dados de métricas.
Se você já concedeu à conta de serviço do Google Cloud um papel específico como parte da tarefa anterior, não é necessário fazer isso novamente.
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
Depurar a configuração da Identidade da carga de trabalho
Se você estiver com problemas para fazer a Identidade da carga de trabalho funcionar, consulte a documentação para verificar a configuração da Identidade da carga de trabalho e o Guia de solução de problemas da Identidade da carga de trabalho.
Como erros de digitação e cópias e colagens incompletas são as fontes mais comuns de erros ao configurar a Identidade da carga de trabalho, é altamente recomendável usar as variáveis editáveis e os ícones clicáveis de copiar/colar incorporados nos exemplos de código nestas instruções.
Identidade da carga de trabalho em ambientes de produção
O exemplo descrito neste documento vincula a conta de serviço do Google Cloud à conta de serviço padrão do Kubernetes e concede à conta de serviço do Google Cloud todas as permissões necessárias para usar a API Monitoring.
Em um ambiente de produção, convém usar uma abordagem mais refinada, com uma conta de serviço para cada componente, cada uma com permissões mínimas. Para mais informações sobre como configurar contas de serviço para gerenciamento de identidades de carga de trabalho, consulte Como usar a Identidade da carga de trabalho.
Implantar o avaliador de regras independente
O avaliador de regras do serviço gerenciado para Prometheus avalia as regras de alerta e registro do Prometheus em relação à API HTTP do serviço gerenciado para o Prometheus e grava os resultados no Monarch. Ele aceita os mesmos formatos de arquivo de configuração e de regra que o Prometheus. As sinalizações são praticamente idênticas.
Crie um exemplo de implantação do avaliador de regras pré-configurado para avaliar um alerta e uma regra de gravação:
kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.12.0/manifests/rule-evaluator.yaml
Verifique se os pods do avaliador de regras foram implantados:
kubectl -n NAMESPACE_NAME get pod
Se a implantação tiver sido bem-sucedida, você verá uma saída semelhante a esta:
NAME READY STATUS RESTARTS AGE ... rule-evaluator-64475b696c-95z29 2/2 Running 0 1m
Depois de verificar se o avaliador da regra foi implantado com sucesso, é possível fazer ajustes nos manifestos instalados para fazer o seguinte:
- Adicione seus arquivos de regras personalizados.
- Configurar o avaliador de regras para enviar alertas a um
Alertmanager do Prometheus autoimplantado usando o campo
alertmanager_config
da configuração.
Se o Alertmanager estiver localizado em um cluster
diferente do avaliador de regras, talvez seja necessário configurar um recurso do Endpoints.
Por exemplo, se o OperatorConfig especificar que os endpoints do Alertmanager podem ser
encontrados no objeto do Endpoints ns=alertmanager/name=alertmanager
, será possível
criar esse objeto manualmente ou de maneira programática e preenchê-lo
com IPs acessíveis do outro cluster.
Fornecer credenciais explicitamente
Durante a execução no GKE, o avaliador de regras recupera as credenciais automaticamente do ambiente com base na conta de serviço do nó ou na configuração da identidade da carga de trabalho.
Em clusters que não são do Kubernetes, as credenciais precisam ser explicitamente fornecidas ao avaliador de regras usando sinalizações ou a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS
.
Defina o contexto para seu projeto de destino:
gcloud config set project PROJECT_ID
Crie uma conta de serviço:
gcloud iam service-accounts create gmp-test-sa
Nesta etapa, é criada a conta de serviço que você pode já tiver criado nas instruções de Identidade da carga de trabalho.
Conceda as permissões necessárias à conta de serviço:
gcloud projects add-iam-policy-binding PROJECT_ID \ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.viewer \ && \ gcloud projects add-iam-policy-binding PROJECT_ID\ --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \ --role=roles/monitoring.metricWriter
Crie e faça o download de uma chave para a conta de serviço:
gcloud iam service-accounts keys create gmp-test-sa-key.json \ --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com
Adicione o arquivo de chave como secret ao cluster que não é do GKE:
kubectl -n NAMESPACE_NAME create secret generic gmp-test-sa \ --from-file=key.json=gmp-test-sa-key.json
Abra o recurso de implantação do avaliador de regras para edição:
kubectl -n NAMESPACE_NAME edit deploy rule-evaluator
Adicione o texto exibido em negrito ao recurso:
apiVersion: apps/v1 kind: Deployment metadata: namespace: NAMESPACE_NAME name: rule-evaluator spec: template containers: - name: evaluator args: - --query.credentials-file=/gmp/key.json - --export.credentials-file=/gmp/key.json ... volumeMounts: - name: gmp-sa mountPath: /gmp readOnly: true ... volumes: - name: gmp-sa secret: secretName: gmp-test-sa ...
Salve o arquivo e feche o editor. Depois que a alteração é aplicada, os pods são recriados e começam a autenticar no back-end da métrica com a conta de serviço especificada.
GOOGLE_APPLICATION_CREDENTIALS
.Avaliação de regras globais e de vários projetos
Observação: recomendamos executar uma instância do avaliador de regras em cada projeto e região do Google Cloud, e não executar na instância que é avaliada em relação a vários projetos e regiões. No entanto, oferecemos suporte à avaliação de regras de vários projetos em cenários que exigem isso.
Quando implantado no Google Kubernetes Engine, o avaliador de regras usa o projeto do Google Cloud associado ao cluster, que é detectado automaticamente. Para avaliar regras que abrangem projetos, modifique o projeto consultado usando a sinalização
--query.project-id
e especifique um projeto com um escopo de métricas de vários projetos. Se o escopo das métricas contiver todos os projetos, as regras serão avaliadas globalmente. Saiba mais em Escopos de métricas.Também é preciso atualizar as permissões da conta de serviço usada pelo avaliador de regras para que ela possa ler o projeto de escopo e gravar em todos os projetos monitorados no escopo das métricas.
Preservar rótulos ao escrever regras
No caso dos dados que o avaliador grava de volta no serviço gerenciado para o Prometheus, ele é compatível com as mesmas sinalizações
--export.*
e configuração com base emexternal_labels
que o binário do servidor do serviço gerenciado para Prometheus. É altamente recomendável escrever regras para que os rótulosproject_id
,location
,cluster
enamespace
sejam preservados corretamente no nível de agregação. Caso contrário, consulte o desempenho pode diminuir, e você pode encontrar os limites de cardinalidade.Os rótulos
project_id
oulocation
são obrigatórios. Se esses rótulos estiverem ausentes, os valores nos resultados da avaliação da regra serão definidos com base na configuração do avaliador da regra. Os rótuloscluster
ounamespace
ausentes não recebem valores.Autoobservabilidade
O avaliador de regras emite métricas do Prometheus em uma porta configurável usando a flag
--web.listen-address
.Por exemplo, se o pod
rule-evaluator-64475b696c-95z29
estiver expondo essas métricas na porta9092
, as métricas poderão ser visualizadas manualmente usandokubectl
:# Port forward the metrics endpoint. kubectl port-forward rule-evaluator-64475b696c-95z29 9092 # Then query in a separate terminal. curl localhost:9092/metrics
É possível configurar a pilha do Prometheus para coletar essas informações e ter visibilidade sobre a performance do avaliador de regras.
Implantações de alta disponibilidade
O avaliador de regras pode ser executado em uma configuração altamente disponível seguindo a mesma abordagem documentada para o servidor do Prometheus.
Alertas de uso das métricas do Cloud Monitoring
É possível configurar o avaliador de regras para alertar sobre as métricas do sistema do Google Cloud usando o PromQL. Para instruções sobre como criar uma consulta válida, consulte PromQL para métricas do Cloud Monitoring.