Avaliação e alertas de regras implementadas autonomamente

O Google Cloud Managed Service for Prometheus suporta a avaliação de regras e os alertas compatíveis com o Prometheus. Este documento descreve como configurar a avaliação de regras implementada automaticamente, incluindo o componente de avaliação de regras autónomo.

Só tem de seguir estas instruções se quiser executar regras e alertas no repositório de dados global.

Avaliação de regras para a recolha implementada autonomamente

Depois de implementar o Managed Service for Prometheus, pode continuar a avaliar as regras localmente em cada instância implementada através do campo rule_files do ficheiro de configuração do Prometheus. No entanto, a janela de consulta máxima para as regras é limitada pelo tempo durante o qual o servidor mantém os dados locais.

A maioria das regras é executada apenas nos últimos minutos de dados, pelo que a execução de regras em cada servidor local é frequentemente uma estratégia válida. Nesse caso, não é necessária qualquer configuração adicional.

No entanto, por vezes, é útil poder avaliar as regras em relação ao back-end de métricas global, por exemplo, quando todos os dados de uma regra não estão localizados numa determinada instância do Prometheus. Para estes casos, o Managed Service for Prometheus também fornece um componente de avaliação de regras.

Antes de começar

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

Configure o seu ambiente

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

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

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

      gcloud config set project PROJECT_ID

    • Configure a CLI kubectl para usar o seu cluster:

      kubectl config set-cluster CLUSTER_NAME

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

Configure um espaço de nomes

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

kubectl create ns NAMESPACE_NAME

Valide as credenciais da conta de serviço

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

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

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

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

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

Crie e associe a conta de serviço

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

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

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

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

Autorize a conta de serviço

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

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

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

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

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

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

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

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

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

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

Implemente o avaliador de regras autónomo

O avaliador de regras do Managed Service for Prometheus avalia as regras de alerta e gravação do Prometheus em relação à API HTTP do Managed Service for Prometheus e escreve os resultados de volta no Monarch. Aceita o mesmo formato de ficheiro de configuração e formato de ficheiro de regras que o Prometheus. As bandeiras também são quase idênticas.

  1. Crie uma implementação de exemplo do avaliador de regras pré-configurado para avaliar uma regra de alerta e uma regra de gravação:

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

  2. Confirme se os pods do avaliador de regras foram implementados com êxito:

    kubectl -n NAMESPACE_NAME get pod

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

    NAME                              READY   STATUS    RESTARTS   AGE
...
rule-evaluator-64475b696c-95z29   2/2     Running   0          1m

Depois de verificar se o avaliador de regras foi implementado com êxito, pode fazer ajustes aos manifestos instalados para fazer o seguinte:

  • Adicione os ficheiros de regras personalizadas.
  • Configure o avaliador de regras para enviar alertas para um Alertmanager do Prometheus implementado automaticamente usando o campo alertmanager_config do ficheiro de configuração.

Se o Alertmanager estiver localizado num cluster diferente do avaliador de regras, pode ter de configurar um recurso de pontos finais. Por exemplo, se o seu OperatorConfig especificar que os pontos finais do Alertmanager podem ser encontrados no objeto Endpoints ns=alertmanager/name=alertmanager, pode criar este objeto manualmente ou através de programação e preenchê-lo com IPs acessíveis do outro cluster.

Forneça credenciais explicitamente

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

  1. Defina o contexto para o projeto de destino:

    gcloud config set project PROJECT_ID

  2. Crie uma conta de serviço:

    gcloud iam service-accounts create gmp-test-sa

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

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

    gcloud projects add-iam-policy-binding PROJECT_ID \
  --member=serviceAccount:gmp-test-sa@PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/monitoring.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 transfira uma chave para a conta de serviço:

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

  5. Adicione o ficheiro de chave como um segredo ao seu cluster não GKE:

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

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

    kubectl -n NAMESPACE_NAME edit deploy rule-evaluator

    1. Adicione o texto apresentado 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. Guarde o ficheiro e feche o editor. Após a aplicação da alteração, os pods são recriados e começam a autenticar-se no back-end de métricas com a conta de serviço fornecida.

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

    Avaliação de regras globais e de vários projetos

    Recomendamos que execute uma instância do avaliador de regras em cada Google Cloud projeto e região, em vez de executar uma instância que faça a avaliação em relação a muitos projetos e regiões. No entanto, suportamos a avaliação de regras de vários projetos para cenários que o exijam.

    Quando implementado no Google Kubernetes Engine, o avaliador de regras usa o Google Cloud projeto associado ao cluster, que deteta automaticamente. Para avaliar regras que abrangem projetos, pode substituir o projeto consultado usando a flag --query.project-id e especificando um projeto com um âmbito de métricas de vários projetos. Se o âmbito das métricas contiver todos os seus projetos, as regras são avaliadas globalmente. Para mais informações, consulte o artigo Âmbitos das métricas.

    Também tem de atualizar as autorizações da conta de serviço usada pelo avaliador de regras para que a conta de serviço possa ler a partir do projeto de âmbito e escrever em todos os projetos monitorizados no âmbito das métricas.

    Preserve as etiquetas ao escrever regras

    Para os dados que o avaliador escreve novamente no Managed Service for Prometheus, o avaliador suporta as mesmas flags --export.* e a configuração baseada em external_labels que o binário do servidor do Managed Service for Prometheus. Recomendamos vivamente que escreva regras para que as etiquetas project_id, location, cluster e namespace sejam preservadas adequadamente para o respetivo nível de agregação. Caso contrário, o desempenho das consultas pode diminuir e pode deparar-se com limites de cardinalidade.

    As etiquetas project_id ou location são obrigatórias. Se estas etiquetas estiverem em falta, os valores nos resultados da avaliação de regras são definidos com base na configuração do avaliador de regras. As etiquetas cluster ou namespace em falta não têm valores atribuídos.

    Auto-observabilidade

    O avaliador de regras emite métricas do Prometheus numa porta configurável através da flag --web.listen-address.

    Por exemplo, se o pod rule-evaluator-64475b696c-95z29 estiver a expor estas métricas na porta 9092, as métricas podem ser vistas manualmente através de kubectl:

    # Port forward the metrics endpoint.
kubectl port-forward rule-evaluator-64475b696c-95z29 9092
# Then query in a separate terminal.
curl localhost:9092/metrics

    Pode configurar a sua pilha do Prometheus para recolher estas informações e ter visibilidade do desempenho do avaliador de regras.

    Implementações de alta disponibilidade

    O avaliador de regras pode ser executado numa configuração de elevada disponibilidade seguindo a mesma abordagem documentada para o servidor Prometheus.

    Alertas com métricas do Cloud Monitoring

    Pode configurar o avaliador de regras para enviar alertas sobre Google Cloud métricas do sistema através do PromQL. Para obter instruções sobre como criar uma consulta válida, consulte o artigo PromQL para métricas do Cloud Monitoring.