Avaliação de regras e alertas com coleta gerenciada

Este documento descreve uma configuração de avaliação de regras e alertas em uma implantação do Managed Service para Prometheus que usa coleta gerenciada.

O diagrama a seguir ilustra uma implantação que usa vários clusters em dois projetos do Google Cloud e utiliza a avaliação de regras e alertas, bem como o recurso opcional GlobalRules:

Para configurar e usar uma implantação como a do diagrama, lembre-se de que:

• O avaliador de regras gerenciadas é implantado automaticamente nos clusters em que a coleta gerenciada está em execução. Esses avaliadores são configurados da seguinte maneira:

  • Use recursos Rules para executar regras em dados dentro de um namespace. Os recursos Rules precisam ser aplicados a todos os namespaces em que você quer executar a regra.

  • Use recursos ClusterRules para executar regras em dados de um cluster. Os recursos ClusterRules precisam ser aplicados uma vez por cluster.

• Toda a avaliação de regras é executada no repositório de dados global, o Monarch.

  • Os recursos Rules filtram automaticamente as regras no projeto, no local, no cluster e no namespace em que estão instalados.
  • Os recursos ClusterRules filtram automaticamente as regras para o projeto, o local e o cluster em que estão instalados.
  • Todos os resultados de regra são gravados no Monarch após a avaliação.

• Uma instância AlertManager do Prometheus é implantada manualmente em cada cluster. Os avaliadores de regras gerenciadas são configurados com a edição do recurso OperatorConfig para enviar regras de alerta acionadas para a instância local do AlertManager. Silenciamentos, confirmações e fluxos de trabalho de gerenciamento de incidentes em geral são processados em uma ferramenta de terceiros, como o PagerDuty.

  É possível centralizar o gerenciamento de alertas em vários clusters em um único AlertManager com um recurso do Endpoints do Kubernetes.

O diagrama anterior também mostra o recurso opcional GlobalRules. Use GlobalRules com moderação, para tarefas como cálculo de SLOs globais em projetos ou avaliação de regras em clusters em um projeto do Google Cloud. É altamente recomendável usar Rules e ClusterRules sempre que possível. Esses recursos oferecem maior confiabilidade e são mais adequados para mecanismos de implantação e modelos de locação comuns do Kubernetes.

Se você usa o recurso GlobalRules, observe o seguinte no diagrama anterior:

• Um único cluster em execução no Google Cloud é designado como o cluster de avaliação de regra global para um escopo de métricas. Esse avaliador de regras gerenciadas está configurado para usar scoping_project_A, que contém os projetos 1 e 2. As regras executadas em scoping_project_A distribuem dados automaticamente para os projetos 1 e 2.

  A conta de serviço subjacente precisa receber as permissões de Leitor do Monitoring para scoping_project_A. Para saber mais sobre como definir esses campos, consulte Avaliação de regras globais e de vários projetos.

• Assim como em todos os outros clusters, esse avaliador de regras é configurado com recursos Rules e ClusterRules que avaliam regras com escopo para um namespace ou cluster. Essas regras são filtradas automaticamente para o projeto local — Projeto 1, neste caso. Como scoping_project_A contém o Projeto 1, as regras configuradas por Rules e ClusterRules são executadas somente com base nos dados do projeto local, conforme o esperado.

• Esse cluster também tem recursos GlobalRules que executam regras em scoping_project_A. GlobalRules não são filtradas automaticamente. Portanto, são executadas exatamente como foram gravadas em todos os projetos, locais, clusters e namespaces em scoping_project_A.

• As regras de alertas disparadas serão enviadas ao AlertManager auto-hospedado conforme esperado.

O uso de GlobalRules pode ter efeitos inesperados, dependendo se você preserva ou agrega os identificadores project_id, location, cluster e namespace nas regras:

• Se a regra GlobalRegras preservar o identificador project_id com uma cláusula by(project_id), os resultados da regra serão gravados no Monarch usando o valor project_id original da série temporal subjacente.

  Nesse cenário, você precisa garantir que a conta de serviço subjacente tenha as permissões de Gravador de métricas do Monitoring para cada projeto monitorado em scoping_project_A. Se você adicionar um novo projeto monitorado a scoping_project_A, também precisará adicionar manualmente uma nova permissão à conta de serviço.

• Se a regra GlobalRules não preservar o identificador project_id (sem o uso de uma cláusula by(project_id)), os resultados da regra são gravados na Monarch usando o valor project_id do cluster em que o avaliador de regras global está em execução.

  Nesse cenário, não é preciso modificar a conta de serviço.

• Se GlobalRules preservar o identificador location com uma cláusula by(location), os resultados da regra serão gravados no Monarch usando cada região original do Google Cloud de onde a série temporal subjacente se originou.

  Se GlobalRules não preservar o identificador location, os dados serão gravados no local do cluster em que o avaliador de regras global está em execução.

É altamente recomendável preservar os identificadores cluster e namespace nos resultados da avaliação de regras, a menos que a finalidade da regra seja agregar esses identificadores. Caso contrário, o desempenho da consulta poderá diminuir e você poderá encontrar limites de cardinalidade. Não é indicado remover os dois rótulos.