Avaliação e alertas de regras autoimplantadas

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:

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.

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

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

  1. Defina o contexto para seu projeto de destino:

    gcloud config set project PROJECT_ID

  2. Crie uma conta de serviço:

    gcloud iam service-accounts create gmp-test-sa

    Nesta etapa, é criada a conta de serviço que você pode já tiver criado nas instruções de Identidade da carga de trabalho.

  3. Conceda as permissões necessárias à conta de serviço:

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

  4. Crie e faça o download de uma chave para a conta de serviço:

    gcloud iam service-accounts keys create gmp-test-sa-key.json \
  --iam-account=gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com

  5. Adicione o arquivo de chave como secret ao cluster que não é do GKE:

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

  6. Abra o recurso de implantação do avaliador de regras para edição:

    kubectl -n NAMESPACE_NAME edit deploy rule-evaluator

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

    2. Salve o arquivo e feche o editor. Depois que a alteração é aplicada, os pods são recriados e começam a autenticar no back-end da métrica com a conta de serviço especificada.

    Como alternativa, em vez de usar as sinalizações definidas neste exemplo, defina o caminho do arquivo de chave usando a variável de ambiente 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 em external_labels que o binário do servidor do serviço gerenciado para Prometheus. É altamente recomendável escrever regras para que os rótulos project_id, location, cluster e namespace 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 ou location 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ótulos cluster ou namespace 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 porta 9092, as métricas poderão ser visualizadas manualmente usando kubectl:

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