Avaliação e alerta de regras gerenciadas

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

Avaliação de regras

O serviço gerenciado para o Prometheus fornece um componente de avaliação de regras que permite criar regras com segurança no contexto de um back-end global do Prometheus, impedindo a interferência com dados de outros usuários em organizações maiores. O componente é implantado automaticamente como parte da coleção gerenciada ao ser executado em clusters do Kubernetes.

É possível gravar regras e alertas nas métricas do Managed Service para Prometheus e das métricas do Cloud Monitoring. É preciso usar o recurso GlobalRules ao gravar regras para métricas do Cloud Monitoring.

Regras

O avaliador de regras gerenciadas usa o recurso Rules para configurar as regras de gravação e alerta. Veja a seguir um exemplo de recurso de regras:

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

O formato do elemento .spec.groups é idêntico à matriz upstream rule_group do Prometheus. As regras de alerta e gravação definidas em Rules têm como escopo project_id, cluster e namespace do recurso. Por exemplo, a regra job:up:sum no recurso acima consulta efetivamente sum without(instance) (up{project_id="test-project", cluster="test-cluster", namespace="NAMESPACE_NAME"}). Isso garante que as regras de alerta ou gravação não avaliem acidentalmente as métricas de aplicativos que você talvez não conheça.

Para aplicar as regras de exemplo ao cluster, execute o seguinte comando:

kubectl apply -n NAMESPACE_NAME -f https://raw.githubusercontent.com/GoogleCloudPlatform/prometheus-engine/v0.13.0/examples/rules.yaml

Após alguns minutos, a métrica job:up:sum ficará disponível. O alerta AlwaysFiring também começa a ser disparado. Para mais informações sobre como enviar alertas para um Alertmanager, consulte Configuração do Alertmanager.

Os recursos ClusterRules e GlobalRules fornecem a mesma interface que o recurso Rules, mas aplicam as regras a escopos mais amplos. O ClusterRules seleciona dados usando os rótulos project_id e cluster, e os GlobalRules selecionam todos os dados no escopo das métricas consultadas sem restringir os rótulos.

Para a documentação de referência sobre todos os recursos personalizados do Managed Service para Prometheus, consulte a referência do prometheus-engine/doc/api.

Como converter regras em regras do Prometheus

O recurso de regras fornece uma interface compatível com as regras do Prometheus para um caminho de migração perfeito para incorporar regras atuais à avaliação de regras gerenciadas. Você pode incluir suas regras em um recurso de regras. Por exemplo, veja a seguir uma regra do Prometheus:

groups:
- name: example
  interval: 30s
  rules:
  - record: job:up:sum
    expr: sum without(instance) (up)
  - alert: AlwaysFiring
    expr: vector(1)

O recurso de regras correspondente, com a regra original do Prometheus em negrito, segue o seguinte:

apiVersion: monitoring.googleapis.com/v1
kind: Rules
metadata:
  namespace: NAMESPACE_NAME
  name: example-rules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

ClusterRules

É possível usar o recurso ClusterRules para configurar regras de gravação e alerta que podem avaliar todas as séries temporais enviadas ao serviço gerenciado para o Prometheus de todos os namespaces em um cluster específico. A especificação é idêntica à de Rules. O exemplo de regra do Prometheus anterior se torna o seguinte recurso ClusterRules:

apiVersion: monitoring.googleapis.com/v1
kind: ClusterRules
metadata:
  name: example-clusterrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Recomendamos que você use os recursos do ClusterRules somente para métricas horizontais, como aquelas produzidas por uma malha de serviço. Para métricas de implantações individuais, use recursos de regras para garantir que a avaliação não inclua dados não intencionais.

GlobalRules

Use o recurso GlobalRules para configurar regras de gravação e alerta que podem avaliar todas as séries temporais enviadas ao serviço gerenciado para o Prometheus em todos os projetos de um escopo de métricas. A especificação é idêntica à de Rules. O exemplo anterior de regra do Prometheus se torna o seguinte recurso GlobalRules:

apiVersion: monitoring.googleapis.com/v1
kind: GlobalRules
metadata:
  name: example-globalrules
spec:
  groups:
  - name: example
    interval: 30s
    rules:
    - record: job:up:sum
      expr: sum without(instance) (up)
    - alert: AlwaysFiring
      expr: vector(1)

Como as métricas do Cloud Monitoring não têm escopo para um namespace ou cluster, é preciso usar o recurso GlobalRules ao gravar regras ou alertas para métricas do Cloud Monitoring. O uso de GlobalRules também é necessário ao alertar sobre métricas do sistema do Google Kubernetes Engine.

Se as regras não preservam os rótulos project_id ou location, o padrão será os valores do cluster.

Para métricas do Managed Service para Prometheus, recomendamos que você use GlobalRules apenas para casos de uso raros em que um alerta pode precisar de dados em todos os clusters de uma só vez. Para métricas de implantações individuais, use os recursos Rules ou ClusterRules para aumentar a confiabilidade e garantir que a avaliação não inclua dados indesejados. É altamente recomendável preservar os rótulos cluster e namespace nos resultados da avaliação da regra, a menos que o objetivo da regra seja agregar esses rótulos, caso contrário, o desempenho da consulta poderá diminuir e você poderá encontrar limites de cardinalidade. Não é indicado remover os dois rótulos.

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

Quando implantado no Google Kubernetes Engine, o avaliador de regras usa o projeto do Google Cloud associado ao cluster que ele detecta automaticamente. Para avaliar regras que abrangem projetos, configure o avaliador de regras que executa o recurso GlobalRules para usar um projeto com um escopo de métricas de vários projetos. Faça isso de duas maneiras:

  • Coloque o recurso GlobalRules em um projeto que tenha um escopo de métricas de vários projetos.
  • Defina o campo queryProjectID dentro do OperatorConfig para usar um projeto com um escopo de métricas de vários projetos.

Também é necessário atualizar as permissões da conta de serviço usada pelo avaliador de regras, que geralmente é a conta de serviço padrão do nó, para que a conta possa ler o projeto do escopo e gravar em todos os projetos monitorados no escopo de métricas.

Se o escopo das métricas contiver todos os projetos, as regras serão avaliadas globalmente. Saiba mais em Escopos de métricas.

Alertas de uso das métricas do Cloud Monitoring

Use o recurso GlobalRules para alertar sobre 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.

Como configurar regras e alertas usando o Terraform

É possível automatizar a criação e o gerenciamento de regras, clustersRules e recursos GlobalRules usando o tipo de recurso kubernetes_manifest do Terraform ou tipo de recurso kubectl_manifest do Terraform, que permite especificar recursos personalizados arbitrários.

Para informações gerais sobre como usar o Google Cloud com o Terraform, consulte Terraform com o Google Cloud.

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ó. Em clusters que não são do Kubernetes, as credenciais precisam ser explicitamente fornecidas por meio do recurso OperatorConfig no namespace gmp-public.

  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

  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 gmp-public create secret generic gmp-test-sa \
  --from-file=key.json=gmp-test-sa-key.json

  6. Abra o recurso OperatorConfig para edição:

    kubectl -n gmp-public edit operatorconfig config

    1. Adicione o texto exibido em negrito ao recurso:

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
rules:
  credentials:
    name: gmp-test-sa
    key: key.json
      Também é necessário adicionar essas credenciais à seção collection para que a coleta gerenciada funcione.

    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 escalonar a avaliação de regras

    O avaliador de regras é executado como uma implantação de réplica única com limites e solicitações de recursos fixos. Talvez você note interrupções na carga de trabalho, como falhar no processo de OOMKille ao avaliar um grande número de regras. Para atenuar isso, implante um VerticalPodAutoscaler para escalonar verticalmente a implantação. Primeiro, verifique se o Escalonamento automático vertical de pods está ativado no cluster do Kubernetes. Em seguida, aplique um recurso VerticalPodAutoscaler como o seguinte:

    apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: rule-evaluator
  namespace: gmp-system
spec:
  resourcePolicy:
    containerPolicies:
    - containerName: evaluator
      controlledResources:
        - memory
      maxAllowed:
        memory: 4Gi
      minAllowed:
        memory: 16Mi
      mode: Auto
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: rule-evaluator
  updatePolicy:
    updateMode: Auto

    Para conferir se o escalonador automático está funcionando, verifique o status dele:

    kubectl get vpa --namespace gmp-system rule-evaluator

    Se o escalonador automático estiver funcionando, ele informará que calculou as recomendações de recursos para a carga de trabalho na coluna "PROVIDED":

    NAME             MODE   CPU   MEM        PROVIDED   AGE
rule-evaluator   Auto   2m    11534336   True       30m

    Compactar configurações

    Se você tiver muitos recursos de regras, poderá ficar sem espaço no ConfigMap. Para corrigir isso, ative a compactação gzip no seu recurso OperatorConfig:

      apiVersion: monitoring.googleapis.com/v1
  kind: OperatorConfig
  metadata:
    namespace: gmp-public
    name: config
  features:
    config:
      compression: gzip

    Configuração do Alertmanager

    É possível usar o recurso OperatorConfig para configurar o avaliador de regras gerenciado para enviar alertas a um Alertmanager do Prometheus. É possível enviar alertas para o Alertmanager gerenciado e implantado automaticamente, além de qualquer gerenciador de alerta autoimplantado.

    Alertmanager gerenciado

    O serviço gerenciado para Prometheus implanta uma instância gerenciada do Alertmanager, para onde os avaliadores de regras são configurados automaticamente para encaminhar alertas. Por padrão, essa configuração é definida com um secret do Kubernetes especificamente chamado que contém um arquivo de configuração do Alertmanager.

    Para ativar e configurar relatórios na instância implantada do Alertmanager, faça o seguinte:

    1. Crie um arquivo de configuração local que contenha as configurações do Alertmanager (consulte os modelos de configuração de exemplo):

      touch alertmanager.yaml

    2. Atualize o arquivo com as configurações do Alertmanager desejadas e crie um Secret chamado alertmanager no namespace gmp-public:

      kubectl create secret generic alertmanager \
  -n gmp-public \
  --from-file=alertmanager.yaml

    Depois de alguns momentos, o Managed Service para Prometheus retira o novo Secret de configuração e ativa o Alertmanager gerenciado com suas configurações.

    Como personalizar o nome do Secret de configuração

    O Alertmanager gerenciado também é compatível com nomes do Secret personalizados para carregar a configuração. Esse recurso é útil quando você tem vários Secrets de configuração e quer que a instância do Alertmanager alterne entre as configurações correspondentes. Por exemplo, talvez você queira mudar os canais de notificação de alerta com base na rotação de turnos na chamada ou em uma configuração experimental do Alertmanager para testar uma nova rota de alertas.

    Para especificar um nome de Secret não padrão usando o recurso OperatorConfig, faça o seguinte:

    1. Crie um Secret a partir do arquivo de configuração local do Alertmanager:

      kubectl create secret generic SECRET_NAME \
  -n gmp-public \
  --from-file=FILE_NAME

    2. Abra o recurso OperatorConfig para edição:

      kubectl -n gmp-public edit operatorconfig config

    3. Para ativar os relatórios do Alertmanager gerenciado, edite o recurso modificando a seção managedAlertmanager, conforme mostrado no texto em negrito a seguir:

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
managedAlertmanager:
  configSecret:
    name: SECRET_NAME
    key: FILE_NAME

    Se você precisar fazer alterações na configuração do Alertmanager, edite a configuração desse AlertManager atualizando o Secret criado anteriormente.

    Personalizar o URL externo

    É possível configurar o URL externo do Gerenciador de alertas gerenciado para que as notificações de alerta possam fornecer um link de callback para a IU de alertas. Isso é equivalente a usar a sinalização --web.external-url do Prometheus Alertmanager.

    apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
managedAlertmanager:
  externalURL: EXTERNAL_URL

    Alertmanager autoimplantado

    Para configurar o avaliador de regras para um AlertManager autoimplantado, faça o seguinte:

    1. Abra o recurso OperatorConfig para edição:

      kubectl -n gmp-public edit operatorconfig config

    2. Configure o recurso para enviar alertas ao serviço Alertmanager:

      apiVersion: monitoring.googleapis.com/v1
kind: OperatorConfig
metadata:
  namespace: gmp-public
  name: config
rules:
  alerting:
    alertmanagers:
    - name: SERVICE_NAME
      namespace: SERVICE_NAMESPACE
      port: PORT_NAME

    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 informar que os endpoints do Alertmanager podem ser encontrados no objeto do Endpoints ns=alertmanager/name=alertmanager, crie esse objeto manualmente ou de maneira programática e preencha-o com IPs acessíveis do outro cluster. A seção de configuração do AlertmanagerEndpoints fornece opções para configuração de autorização, se necessário.